Most DPIAs fail in one of two ways: they are never started because nobody screened the project, or they are written after go-live as a compliance document that changed nothing. Article 35 of the GDPR (and the UK GDPR) requires a data protection impact assessment before any processing that is "likely to result in a high risk" to people's rights and freedoms, and Article 36 requires prior consultation with the regulator when a high risk remains. This guide covers when a DPIA is mandatory, how to screen projects with a privacy threshold analysis, how to run and score the assessment, what the DPO, processors and data subjects contribute, how prior consultation works, and how DPIAs apply to AI systems. It is written for privacy leads, DPOs, security architects and product owners who need an assessment that stands up to a regulator and actually shapes the design.
Key takeaways
- The trigger is likely high risk, not certainty. Article 35(3) names three mandatory cases, and the EDPB-endorsed WP29 guidelines add nine criteria: in most cases, processing that meets two of them needs a DPIA.
- Screen everything, assess what screens in. A short, documented privacy threshold analysis on every new or changed processing activity is what makes the DPIA duty manageable, and a written "no DPIA needed" decision is evidence too.
- Article 35(7) sets the minimum content. A systematic description, necessity and proportionality, an assessment of risks to individuals and the measures to address them. Missing any of the four is a defective DPIA.
- Residual high risk means you must consult before you process. Under Article 36 the supervisory authority has up to eight weeks, extendable by six, to give written advice, so build that into project plans.
- A DPIA is a living control. Article 35(11) requires review at least when the risk changes; new data sources, new recipients, a model retrain or a new vulnerability are all review triggers.
What a DPIA is, and how it differs from a PIA, PTA or FRIA
The ICO describes a DPIA as "a process designed to help you systematically analyse, identify and minimise the data protection risks" of a project. The focus is harm to individuals, not risk to the organisation. Related assessments are often confused with it.
| Assessment | Source | Question it answers | Output |
|---|---|---|---|
| Privacy threshold analysis (PTA) or initial privacy assessment | Internal screening practice; the US DHS uses a formal PTA | Does this processing need a full assessment? | Documented screening decision |
| Data protection impact assessment (DPIA) | GDPR and UK GDPR Art. 35 | Is processing likely to be high risk to individuals, and are the measures enough? | DPIA record, residual risk, DPO advice, Art. 36 decision |
| Privacy impact assessment (PIA) | ISO/IEC 29134:2023; US federal privacy programmes | What are the privacy impacts of a project processing PII? | PIA report (often broader than GDPR minimum) |
| Fundamental rights impact assessment (FRIA) | EU AI Act Art. 27 | What are the risks to fundamental rights of deploying a high-risk AI system? | FRIA notified to the market surveillance authority |
| Legitimate interests assessment (LIA) | GDPR Art. 6(1)(f) | Can this processing rely on legitimate interests? | Purpose, necessity and balancing record |
On "PIA vs DPIA": a well-built PIA can satisfy Article 35 if it includes everything in Article 35(7) and the DPO's advice, but generic PIA templates rarely cover necessity and proportionality or the prior consultation decision. The DHS model shows the value of formal screening: its PTA is "a required document that serves as the official determination", re-certified every three years.
When a DPIA is required
Article 35(1) requires a DPIA before processing that is likely to result in a high risk, "in particular using new technologies". Recital 84 asks controllers to evaluate "the origin, nature, particularity and severity of that risk". The triggers come from three layers.
Layer 1: the three mandatory cases in Article 35(3)
- (a) Automated evaluation with significant effects: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based. Credit scoring and automated recruitment screening are typical.
- (b) Large-scale special category or criminal data: Article 9(1) data (health, biometric for identification, genetic and others) or Article 10 criminal conviction data processed on a large scale.
- (c) Large-scale public monitoring: systematic monitoring of a publicly accessible area on a large scale, such as city-centre CCTV or retail facial recognition.
Layer 2: the nine WP29 criteria
The Article 29 Working Party guidelines (WP248 rev.01, endorsed by the EDPB) set out nine criteria. The guidelines say "a processing meeting two criteria would require a DPIA to be carried out" in most cases, and that one criterion can be enough.
| # | Criterion | Example that meets it |
|---|---|---|
| 1 | Evaluation or scoring, including profiling and prediction | A bank screening customers against a credit reference database |
| 2 | Automated decision-making with legal or similarly significant effect | Automatic refusal of an account, loan or benefit |
| 3 | Systematic monitoring | Employee endpoint telemetry, network monitoring, location tracking |
| 4 | Sensitive data or data of a highly personal nature | Hospital patient records, financial data, private communications |
| 5 | Data processed on a large scale | Judged by number of people, volume and range of data, duration, geographic extent |
| 6 | Matching or combining datasets | Joining CRM, web analytics and third-party enrichment data |
| 7 | Data concerning vulnerable data subjects | Children, employees, patients, elderly people |
| 8 | Innovative use or new technological or organisational solutions | Combined fingerprint and face recognition for physical access |
| 9 | Processing that prevents people exercising a right or using a service or contract | Screening that decides whether someone can open an account |
Layer 3: national lists
Article 35(4) requires each supervisory authority to publish a list of processing that requires a DPIA, and Article 35(5) allows an exemption list. The EDPB issues opinions on these lists (for example, Opinion 10/2019 on the Cyprus list). The ICO's list has ten items: innovative technology (including AI), denial of service, large-scale profiling, biometrics, genetic data, data matching, invisible processing, tracking, targeting children or other vulnerable individuals, and risk of physical harm. For innovative technology, biometrics, genetic data, invisible processing and tracking, the ICO requires a DPIA when the item is combined with any WP29 criterion; the others need one on their own. The ICO has not published an exemption list.
No DPIA is needed where processing is unlikely to be high risk, is very similar to processing already assessed, has a specific legal basis assessed when the law was made (Article 35(10)), or is on an exemption list. One DPIA can cover "a set of similar processing operations that present similar high risks" (Article 35(1)).
Screening with a privacy threshold analysis
Screening decides which projects get scrutiny. The ICO's position is blunt: "If in any doubt, we would always recommend that you do a DPIA", and if you decide not to, document why. A usable screening form asks:
- Is personal data involved? Including pseudonymised data, device identifiers and logs.
- Does it hit an Article 35(3) case? If yes, a DPIA is mandatory: stop screening.
- Which of the nine WP29 criteria apply? Tick each with a one-line reason. Two or more means DPIA by default.
- Is it on the national list? Check the list of every supervisory authority whose residents are affected, not only the lead authority.
- Is it a change to existing processing? New purpose, data category, recipient, retention period, technology or geography. If the existing processing has a DPIA, this is a DPIA review, not a new screen.
- Record the decision and the DPO's view. WP29 expects the reasons and the DPO's views to be documented where criteria are met but no DPIA is done.
Embed the screen in existing gates: architecture review, change advisory board, SaaS procurement intake, data sharing requests and model deployment approvals. A screen that relies on teams remembering to ask will be skipped.
Running the DPIA step by step
The ICO and WP29 processes line up closely, and WP29 maps the generic process to ISO 31000 (establish context, assess risk, treat risk, monitor and review). Start "early in the life of a project, before you start your processing", while the design can still change.
- Describe the processing (Art. 35(7)(a)): nature, scope, context and purposes; data categories, volumes and sources; systems; recipients and processors; transfers; retention; and any legitimate interest relied on. A data flow diagram exposes hidden flows such as analytics SDKs, logging pipelines and support tooling.
- Consult (Art. 35(2) and 35(9)): seek the DPO's advice, the views of data subjects or their representatives "where appropriate", information security, and processors. The ICO says "Your contracts with processors should require them to assist", which Article 28(3)(f) supports.
- Assess necessity and proportionality (Art. 35(7)(b)): lawful basis, whether a less intrusive way achieves the purpose, data minimisation, accuracy, retention, transparency, how rights will be honoured, processor compliance and transfer safeguards.
- Identify and score risks to individuals (Art. 35(7)(c)): see the next section.
- Identify measures (Art. 35(7)(d)): record, per risk, the measure, whether it eliminates, reduces or accepts the risk, the owner and the date.
- Sign off: record residual risk, DPO advice, and reasons where you depart from the DPO's advice or from data subjects' views. Decide whether Article 36 prior consultation is needed.
- Integrate: turn measures into backlog items with named owners and make go-live conditional on the high-rated ones.
- Review: set review triggers and a review date (see Detection and measurement).
Testing and rollback: pilot new processing on synthetic or test data first, run a limited production pilot only after high-rated measures are in place, and write a rollback plan into the DPIA: how processing is switched off, what data is deleted, and who decides. The CNIL methodology's three validation outcomes ("validated", "conditional on improvement" or "refused") are a useful discipline, because "refused" must be a real option.
Choosing an approach: small and large organisations
| Situation | Recommended approach | Trade-off |
|---|---|---|
| Small organisation, few high-risk activities | ICO DPIA template or CNIL PIA templates, DPO or external adviser reviews | Low overhead; depends on one person's judgement |
| Large organisation, many product teams | Mandatory screening in delivery gates, a central risk matrix, a privacy engineering review board, DPIAs in a GRC or privacy tool linked to the record of processing | Consistent and auditable; risk of form-filling without design change |
| Group or multi-country | One DPIA per processing type (Art. 35(1)) with local annexes | Saves effort; must track local divergence |
| Need an international method | ISO/IEC 29134:2023 for PIA process and report structure, mapped to Art. 35(7) | Recognised standard; check GDPR-specific elements are added |
On publishing, WP29 notes "Publishing a DPIA is not a legal requirement of the GDPR", but publishing a summary builds trust, particularly for public bodies and workforce monitoring. Redact security details that would help an attacker.
Assessing and scoring risk to individuals
The ICO says "You must make an objective assessment of the risks", considering both likelihood and severity of harm. Harm must be more than remote but need not be certain. The CNIL methodology frames security-related risk as three feared events: illegitimate access to personal data (confidentiality), unwanted change (integrity) and disappearance (availability). Add non-security harms such as discrimination, loss of control, chilling effects and financial loss.
| Severity / likelihood | Remote | Possible | Probable |
|---|---|---|---|
| Minimal (inconvenience, easily overcome) | Low | Low | Low |
| Significant (distress, financial cost, loss of control) | Low | Medium | High |
| Severe (lasting or irreversible harm, threat to safety) | Medium | High | High |
Use one matrix across the organisation, define each level with sector examples, and score each risk before and after measures. WP29 gives two examples of residual risk that cannot be accepted: illegitimate access to data that could threaten people's lives, and cases where it "seems obvious that the risk will occur", such as running on a well-known unpatched vulnerability.
Mitigation and residual risk
Measures should target the source of each risk. The table lists common high-rated risks and the measures that usually move them.
| Risk to individuals | Typical measures | Evidence to keep |
|---|---|---|
| Unauthorised access to sensitive records | Phishing-resistant MFA, least-privilege roles, just-in-time admin access, encryption with separated keys, access logging and review | Access review results, key custody records, log retention settings |
| Excessive collection or retention | Field-level minimisation, retention schedules enforced in code, deletion jobs | Data dictionary, deletion job logs |
| Inaccurate or unfair automated decisions | Meaningful human review, documented error margins, appeal route, bias testing | Model cards, review statistics, appeal outcomes |
| Function creep and secondary use | Purpose tags on datasets, pseudonymisation for analytics, contract limits on processors | Data sharing register, processor terms |
| Transfers to weaker regimes | Transfer tool, TIA, encryption with EU-held keys | TIA and transfer register |
The ICO is clear that a DPIA does not have to remove all risk; the test is whether residual risk is acceptable given the benefits. If residual risk remains high after all reasonable measures, Article 36 applies. See the Privacy-Enhancing Technologies Guide for measures that often bring a risk below high.
Where security and identity fit
A DPIA's security section is often a pasted list of certifications rather than an analysis of who and what can reach the data. Ask three identity questions. Which human roles have access, and are they reviewed? Which non-human identities (service accounts, API keys, integration tokens, AI agents) can read or export the data, and who owns them? What happens to access when people and integrations leave? The 23andMe breach, where credential stuffing on about 18,000 accounts exposed genetic data on nearly 7 million people, shows how account-level weaknesses scale into harm when genetic data, a listed high-risk category, is involved. See the Service Account Security Guide and the GDPR Compliance Guide for Security Teams for Article 32 measures.
DPO advice, processors and prior consultation
- The DPO advises, the controller decides: Article 35(2) requires the controller to seek the DPO's advice, and Article 39(1)(c) makes it a DPO task "to provide advice where requested as regards the data protection impact assessment and monitor its performance". Keep the DPO advisory rather than author and approver, so the advice stays independent.
- Processors supply facts: hosting locations, sub-processors, logging and deletion capabilities. Ask at procurement.
- Data subjects' views: user research, or works councils for workforce monitoring. Record departures and why.
- Prior consultation (Art. 36): required when the DPIA shows high risk that you cannot mitigate. You send the allocation of responsibilities, purposes and means, measures and safeguards, DPO contact details and the DPIA. The authority gives written advice within up to eight weeks, extendable by six for complex processing, and the clock pauses while it waits for information. The ICO confirms within 10 days whether it accepts the submission and says "we can extend this to a maximum of 14 weeks"; outcomes range from proceeding as planned to a warning, limitation or ban.
- Penalties: breaching Articles 35 or 36 falls under Article 83(4), up to EUR 10 million or 2% of worldwide annual turnover. The ICO quotes "a fine of up to £8.7 million, or 2% global annual turnover if higher" for failing to do a required DPIA.
DPIAs for AI systems and new technology
The ICO's AI guidance states that "in the vast majority of cases" using AI involves processing likely to be high risk, so a DPIA is needed, and the ICO's own Article 35(4) list names innovative technology including AI. For AI, the ICO expects the DPIA to cover:
- Roles: controller, processor or joint controller status for the model provider, the platform and you, especially where AI is partly or fully outsourced.
- Margins of error: variance in system performance that could affect fairness, by group where you can measure it.
- Human involvement: the degree and stage of human review, and whether reviewers can and do overturn outputs.
- Trade-offs: for example accuracy against data minimisation, with the reasoning recorded.
- Agentic systems (our addition): which tools, data stores and identities an AI agent can reach, and how its actions are logged. An agent on a broad service account can read far more personal data than the DPIA described. See the Agentic AI Compliance Guide.
Under the EU AI Act, Article 26(9) tells deployers of high-risk AI systems to use the provider's Article 13 information to carry out their DPIA, and Article 27 requires certain deployers (including public bodies and deployers of credit scoring or life and health insurance pricing systems) to complete a fundamental rights impact assessment. Article 27(4) says the FRIA "shall complement that data protection impact assessment": run them as one exercise.
Detection and measurement
Article 35(11) requires review "at least when there is a change of the risk". WP29 adds that a DPIA "should be continuously reviewed and regularly re-assessed". Wire review triggers into change management: new data sources, recipients, processors or countries, a model retrain, a relevant incident or a new vulnerability class. Metrics that show the programme is working:
- Screening coverage: percentage of new or changed processing activities in the record of processing with a dated screening decision (target close to 100%).
- Timeliness: percentage of DPIAs signed off before processing started, and median days from screen to sign-off.
- Design impact: number of DPIAs that changed the design (data removed, retention cut, feature dropped). Zero over a year suggests rubber-stamping.
- Measure closure: percentage of DPIA measures delivered by their due date, and overdue high-rated measures.
- Review currency: percentage of DPIAs reviewed within their review period or after a trigger event.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| GDPR and UK GDPR | Art. 25, 35, 36, 39(1)(c), Recital 84 | Data protection by design; DPIA duty; prior consultation; DPO role |
| EU AI Act | Art. 26(9), Art. 27 | DPIA input from providers; FRIA complements the DPIA |
| ISO/IEC 29134:2023 | Whole standard | PIA process and report structure |
| ISO/IEC 27001:2022 | Annex A 5.34 Privacy and protection of PII | Identify and meet PII protection requirements |
| NIST SP 800-53 Rev. 5 | RA-8 Privacy Impact Assessments | Conduct PIAs before developing or procuring systems that process PII |
| NIST CSF 2.0 | GV.OC-03, ID.RA | Legal and privacy obligations understood; risk assessment |
Common failure patterns
- Retrospective DPIAs: written after launch to satisfy an audit. The ICO is clear the assessment must happen before processing and while it can still change the plans.
- Description without analysis: pages of data flow description, one line of risk, no necessity and proportionality test. That misses two of the four Article 35(7) elements.
- Organisational risk instead of individual risk: scoring fines and reputational damage rather than harm to the people whose data is processed.
- Boilerplate security sections: certifications listed, but no answer to which accounts, service identities and processors can reach the data.
- "Accept" with no owner: high residual risks accepted by a project manager, with no senior sign-off and no Article 36 decision recorded.
- Frozen DPIAs: no review triggers, so new data sources, new vendors or an AI feature added a year later are never assessed.
Practitioner checklist
- Add a documented privacy threshold analysis to architecture review, procurement intake and change management.
- Screen against Article 35(3), the nine WP29 criteria and every relevant national list, and record no-DPIA decisions with the DPO's view.
- Use one organisation-wide likelihood and severity matrix focused on harm to individuals.
- Cover all four Article 35(7) elements, including necessity and proportionality, in every DPIA.
- Seek and record DPO advice, processor input and, where appropriate, data subjects' views.
- Make go-live conditional on high-rated measures and include a rollback plan.
- Decide and record whether Article 36 prior consultation is needed, and plan for up to 14 weeks if it is.
- For AI, cover roles, error margins, human review and agent access, and align the DPIA with any AI Act FRIA.
- Set review triggers and track screening coverage, timeliness, measure closure and review currency.
Standards and references
- GDPR: Article 35, Data protection impact assessment
- GDPR: Article 36, Prior consultation
- Article 29 Working Party (endorsed by the EDPB): Guidelines on Data Protection Impact Assessment, WP248 rev.01
- EDPB: Data protection impact assessment documents and opinions on national lists
- ICO: When do we need to do a DPIA?
- ICO: How do we do a DPIA?
- CNIL: Privacy Impact Assessment, Methodology
- EU AI Act: Article 27, Fundamental rights impact assessment
Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · Privacy Programme Guide for Security Teams · Privacy-Enhancing Technologies Guide · Identity Data Privacy and Consent Guide · Agentic AI Compliance Guide. This guide summarises the GDPR, UK GDPR, WP29, EDPB and ICO requirements for data protection impact assessments as they stood in October 2026 and is not legal advice.