What is a data protection impact assessment (DPIA)?
Privacy, security and identity
A data protection impact assessment (DPIA) is a structured, documented assessment that an organisation must carry out before processing personal data that is likely to result in a high risk to people's rights and freedoms. Required under Article 35 of the GDPR, it describes the processing, tests its necessity and proportionality, assesses the risks, and sets out measures to reduce them. For high-risk AI that uses personal data, it is often the mandatory gate before processing can lawfully begin.
Reviewed by Jackie, Head of Learning & Development, Levellers · Last reviewed 8 June 2026
What this means
A DPIA is a risk assessment focused specifically on personal data. The law does not ask for it every time an organisation handles data. It applies when a planned activity is likely to pose a high risk to individuals, for example because it involves large-scale profiling, sensitive data, systematic monitoring, or new technology. The aim is to spot problems early and design protections in before anything goes live.
It is a legal requirement, not a formality. Under the GDPR, a DPIA must be completed before the processing starts. If the assessment shows a high risk that the organisation cannot reduce to an acceptable level, it must consult its data protection regulator before going ahead. Skipping a required DPIA is itself a breach that regulators can penalise.
A DPIA is also distinct from two broader assessments it is often confused with: an AI impact assessment, which looks at wider effects of an AI system such as fairness and societal impact, and a fundamental-rights impact assessment, which the EU AI Act requires certain deployers of high-risk AI to perform across the full range of rights. A DPIA is narrower and older: it is privacy-focused and defined in data protection law.
Why it matters
The DPIA matters because it is frequently the legal gate that high-risk processing has to pass through before it can proceed, and AI systems that use personal data routinely fall on the high-risk side of that line. Profiling that significantly affects people, large-scale use of sensitive data, biometric identification and automated decision-making are all triggers, and many AI deployments involve at least one of them.
For organisations, a sound DPIA is the main way to demonstrate accountability. It shows a regulator that risks were identified and addressed before launch. A weak or missing DPIA is a common finding in enforcement, and it can be penalised on its own, separately from any underlying problem with the processing. The UK regulator has warned that failing to carry out a DPIA when required may leave an organisation open to enforcement action, including a fine of up to 8.7 million pounds, or 2 per cent of global annual turnover if higher.
For individuals, the DPIA is a safeguard that operates before harm occurs. It forces an organisation to ask whether the processing is necessary, whether less intrusive options exist, and what could go wrong, at the design stage rather than after a complaint.
How it works
The legal trigger
The core trigger sits in Article 35(1) of the GDPR: where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out a DPIA before the processing begins. The test is forward-looking. It turns on anticipated risk, not on proven harm, and it must take into account the nature, scope, context and purposes of the processing.
When it is mandatory
Article 35(3) names three cases that in particular require a DPIA: a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based; large-scale processing of special categories of data under Article 9 or criminal-offence data under Article 10; and systematic monitoring of a publicly accessible area on a large scale. Beyond these, the Article 29 Working Party guidelines WP248 rev.01, adopted on 4 October 2017 and endorsed by the European Data Protection Board, set out nine criteria for identifying high-risk processing: evaluation or scoring; automated decision-making with legal or similar effect; systematic monitoring; sensitive data or data of a highly personal nature; data processed on a large scale; matching or combining datasets; data concerning vulnerable individuals; innovative use of new technology; and processing that prevents people from exercising a right or using a service. As a rule of thumb, meeting two or more criteria points to a DPIA being required, though one criterion can be enough. National regulators also publish their own lists under Article 35(4).
What it must contain
Article 35(7) sets the minimum content. A DPIA must include: a systematic description of the processing and its purposes; an assessment of the necessity and proportionality of the processing in relation to those purposes; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks, including safeguards and security measures. To gauge risk, the assessment must weigh both the likelihood and the severity of potential harm.
Who is involved
The controller is responsible for the DPIA, even if the work is outsourced. Where a data protection officer has been designated, the controller must seek their advice under Article 35(2) and record it. Where appropriate, the controller should also seek the views of affected individuals or their representatives under Article 35(9). A single assessment may cover a set of similar processing operations, and groups of controllers can carry out a joint DPIA.
When the regulator must be consulted
Article 36 supplies the escalation step. If, after planned mitigations, the DPIA still indicates the processing would result in a high risk, the controller must consult the supervisory authority before starting. The threshold is residual risk, not initial risk. The authority must respond within eight weeks, extendable by a further six weeks for complex cases, and it can advise, impose conditions, or use its powers to restrict or ban the processing.
A living document
A DPIA is not a one-off. Article 35(11) requires the controller to review the assessment, at least where there is a change in the risk represented by the processing. Good practice treats it as an ongoing process that runs alongside a project and is revisited when the processing, the data, or the technology changes.
Examples
Generative AI chatbot aimed at a broad audience including children. When the UK Information Commissioner's Office examined Snap's "My AI" chatbot, it issued a preliminary enforcement notice on 6 October 2023, provisionally finding that Snap had failed to adequately identify and assess the risks to several million "My AI" users in the UK, including children aged 13 to 17. Snap submitted four inadequate DPIA iterations before its fifth version, produced in November 2023, was accepted; the ICO concluded in its decision of 21 May 2024 that this revised assessment, which contained a significantly more detailed breakdown of the processing operations and a fuller risk assessment, including of risks posed to 13 to 17 year olds, now complied with Article 35. The case set out the level of detail regulators expect: clear categories of personal data, who has access, retention periods, and the volume and geographic scope of users rather than unspecified numbers.
Training an AI model on personal data. France's CNIL advises that "creating a dataset for the training of an AI system can create a high risk to people's rights and freedoms. In this case, a data protection impact assessment is mandatory." It states that for the development of high-risk systems covered by the EU AI Act that involve personal data, a DPIA is in principle necessary, and that the assessment must address specific AI risks such as automated discrimination caused by the system, the risk that personal data could be extracted from the model, and, for generative systems, the risk of producing fictitious content about a real person, as well as risks from attacks such as data poisoning or model inversion.
Facial recognition and biometric identification. Biometric data used to identify someone uniquely is a special category of data, and deployments such as live facial recognition routinely require a DPIA because they combine sensitive data, systematic monitoring and innovative technology. In its Guidelines 05/2022 on the use of facial recognition technology in law enforcement, adopted in final form on 17 May 2023, the EDPB states that most cases of deployment and use of such technology contain intrinsic high risk to the rights and freedoms of data subjects, and that the authority deploying it should therefore consult the competent supervisory authority.
Common misunderstandings
"A DPIA is optional." For high-risk processing it is a legal requirement under Article 35, not a matter of choice. Where the trigger is met, failing to carry one out is itself a breach.
"A DPIA is the same as an AI impact assessment or a fundamental-rights impact assessment." It is not. A DPIA is privacy-focused and defined in data protection law. An AI impact assessment is broader and looks at fairness and wider effects. The fundamental-rights impact assessment under Article 27 of the EU AI Act covers the full range of fundamental rights and applies to specific deployers of high-risk AI.
"Once written, a DPIA is finished." It is a living document. Article 35(11) requires review when the risk changes, and good practice keeps it current as the processing evolves.
"A DPIA must prove there is no risk." It does not. It must identify risks, reduce them where possible, and document any residual risk so the organisation can judge whether to proceed or to consult the regulator.
"If we use AI, we always need a DPIA." Not automatically. The trigger is high risk to individuals. Many AI uses meet it, but the controller must still assess the specific processing rather than assume.
Risks and boundaries
The main boundary to keep clear is scope. A DPIA assesses risks to individuals arising from the processing of their personal data. It is not a general AI safety review and it is not a fundamental-rights impact assessment. The EU AI Act allows a DPIA and a fundamental-rights impact assessment to be run together and to draw on each other where the content genuinely overlaps, but the fundamental-rights assessment is broader and the two are not interchangeable.
There is also a boundary in what a DPIA can decide. It informs a decision; it does not authorise high-risk processing by itself. Where residual risk stays high, Article 36 hands the decision to the regulator, which can stop the processing. The EDPB's Opinion 28/2024 on AI models, adopted on 17 December 2024, expressly did not cover DPIAs, so it should not be read as DPIA guidance even though it addresses adjacent questions such as anonymity and legal basis for AI.
A practical risk is treating the DPIA as paperwork. Regulators assess the substance: whether risks were genuinely analysed, whether less intrusive options were considered, and whether mitigations are concrete. A generic template that lists risks without assessing likelihood and severity does not meet the Article 35(7) standard.
What to do next
Screen early. Build a DPIA screening step into project and procurement governance so that high-risk processing is flagged before development, not after launch. Use the Article 35(3) cases and the nine WP248 criteria as your checklist, and check your national regulator's published list.
Start the DPIA at the design stage. Capture the four required elements: a description of the processing, a necessity and proportionality test, a risk assessment that weighs likelihood and severity, and concrete mitigations. For AI, document AI-specific risks such as bias, data extraction and the effect of automated decisions, and record why any less risky alternative was not chosen.
Involve the right people. Seek and record the data protection officer's advice where one is appointed, and consider seeking the views of affected individuals. Keep the assessment under review and update it when the processing or technology changes.
Know your escalation point. If residual risk remains high after mitigation, consult the supervisory authority under Article 36 before processing, and allow for the eight-week response window. Where the same AI system also triggers the EU AI Act, coordinate the DPIA with any fundamental-rights impact assessment to avoid duplicating work while respecting their different scope.
Have a question or a suggestion, or want to understand how we research and review these guides? Read about our editorial standards and how to reach us.
FAQs
Is a DPIA always required when handling personal data?
No. It is required only where the processing is likely to result in a high risk to individuals. The GDPR and regulator guidance set out the triggers; routine, low-risk processing does not need one.
When exactly must a DPIA be done?
Before the processing begins. It should start early in a project and run alongside design and development, so that its findings can shape the project before anything goes live.
What must a DPIA contain?
At minimum, the four elements in Article 35(7): a systematic description of the processing and purposes, a necessity and proportionality assessment, an assessment of risks to individuals, and the measures to address those risks.
When must we consult the regulator?
Under Article 36, when the DPIA shows the processing would still be high risk after your planned mitigations. The supervisory authority has eight weeks to respond, extendable by six weeks, and you cannot start until the consultation is complete.
How is a DPIA different from a fundamental-rights impact assessment?
A DPIA is privacy-focused and required under data protection law. A fundamental-rights impact assessment under Article 27 of the EU AI Act is broader, covering the full range of fundamental rights, and applies to certain deployers of high-risk AI.
Does using AI automatically require a DPIA?
Not automatically, but often. Many AI uses involve profiling, sensitive data, large-scale processing or innovative technology, which are high-risk triggers. The controller must assess the specific processing rather than assume.
Who is responsible for the DPIA?
The data controller, even if the work is outsourced to a processor or adviser. Where a data protection officer is appointed, the controller must seek and record their advice.
Can one DPIA cover several processing activities?
Yes. A single assessment can address a set of similar operations that present similar high risks, and groups of controllers can carry out a joint DPIA.