A Data Protection Impact Assessment is a documented analysis of how a processing activity affects individuals' data-protection rights. Article 35 of the GDPR requires one when processing is likely to result in a high risk to those rights. The DPIA describes the processing, tests whether it is necessary and proportionate, assesses the risks to individuals, and sets out the measures that reduce them. If a high risk remains after those measures, the controller must consult the supervisory authority before going ahead.
A DPIA is the GDPR's version of a risk assessment, aimed at the rights and freedoms of the people whose data is processed rather than at the organization's own exposure. It is the document a supervisory authority asks for first when a high-risk processing activity is questioned, and the one that shows whether the controller thought through the impact before building the system or after.
This guide covers what a DPIA is, when Article 35 requires one, what it has to contain, how to run it, when prior consultation is triggered, and the mistakes that turn a DPIA into a problem.
What a DPIA is
A DPIA is a process for identifying and minimizing the data-protection risks of a project. Under Article 35(1) of the GDPR, the controller carries it out where a type of processing, in particular one using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. It is the controller's tool, not the regulator's, and it is meant to be done before the processing starts.
When a DPIA is required
The trigger is high risk. Article 35(3) names three cases where a DPIA is always required:
- A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that produces legal or similarly significant effects.
- Processing on a large scale of special-category data, or of personal data relating to criminal convictions and offences.
- Systematic monitoring of a publicly accessible area on a large scale.
Beyond those, each supervisory authority publishes a list of processing operations that require a DPIA under Article 35(4). The European Data Protection Board's guidelines (WP248) set out nine criteria that signal high risk, such as evaluation or scoring, automated decision-making with significant effect, systematic monitoring, sensitive data, large scale, matching or combining datasets, vulnerable data subjects, innovative use of technology, and processing that prevents data subjects from exercising a right. As a rule of thumb in the EDPB guidelines, processing that meets two or more of these criteria usually calls for a DPIA.
What a DPIA must contain
Article 35(7) sets the minimum content. A DPIA that is missing any of these elements is incomplete.
| Element | What it requires |
|---|---|
| Description | A systematic description of the processing operations and their purposes, including the controller's legitimate interest where relevant. |
| Necessity and proportionality | An assessment of whether the processing is necessary and proportionate to its purposes. |
| Risks | An assessment of the risks to the rights and freedoms of data subjects. |
| Measures | The measures envisaged to address the risks, including safeguards and security measures. |
How to conduct a DPIA
The steps below follow Article 35 and the EDPB guidelines.
Step 1: Describe the processing
Set out what data is processed, for what purpose, on what legal basis, who has access, how long it is kept, and what flows in and out. A clear description is the foundation; the rest of the assessment depends on it.
Step 2: Consult the DPO
Article 35(2) requires the controller to seek the advice of the data protection officer where one is designated. Where the processing involves a processor, the processor must assist under Article 28.
Step 3: Assess necessity and proportionality
Test whether the processing actually achieves its purpose, whether less intrusive means would do, and whether the data collected is limited to what is needed. This is where data minimization and purpose limitation are evidenced.
Step 4: Identify and assess the risks
Identify the risks to individuals, such as loss of control over their data, discrimination, identity theft, financial loss, or reputational harm, and rate each by likelihood and severity.
Step 5: Identify measures to reduce the risks
For each risk, set the measures that reduce it, such as encryption, pseudonymization, access controls, retention limits, or changes to the processing itself. Record the residual risk that remains after the measures.
Step 6: Document, sign off, and review
Record the assessment, have it approved, and revisit it when the processing changes. A DPIA is a living document, not a one-time form.
Prior consultation
If the DPIA indicates that the processing would result in a high risk in the absence of measures to mitigate it, Article 36 requires the controller to consult the supervisory authority before processing. The authority can give written advice or, in the relevant cases, use its powers. Prior consultation is the safety valve: it is what happens when the controller cannot bring the residual risk down on its own.
Who is responsible
The controller is responsible for carrying out the DPIA. The data protection officer advises and monitors but does not own it. A processor must help the controller meet the obligation. In practice the DPIA is a shared effort, but accountability sits with the controller, consistent with the GDPR's accountability principle.
Where DPIAs go wrong
- Done too late. The DPIA is run after the system is built, when it can only document risk rather than reduce it.
- A form, not an assessment. The four Article 35(7) elements are filled in generically, without real analysis of necessity or risk.
- No residual-risk conclusion. Measures are listed but the assessment never states what risk remains, so it cannot tell whether prior consultation is needed.
- Never revisited. The processing changes and the DPIA does not, so it describes something that no longer exists.
A DPIA is the GDPR's risk discipline applied to people rather than to the business. Run it early, do the necessity and risk analysis for real, state the residual risk plainly, and keep it current. For the wider regime, see the GDPR compliance guide and the GDPR glossary; for the same inherent-to-residual logic in a financial-crime setting, see the BSA/AML risk assessment guide.
Primary sources
- GDPR Article 35: Data protection impact assessment: when a DPIA is required and the minimum content it must include.
- GDPR Article 36: Prior consultation with the supervisory authority when a DPIA shows high residual risk.
- EDPB (Article 29 Working Party) Guidelines on DPIA, WP248 rev.01: The criteria for when processing is likely to result in a high risk, and how to carry out a DPIA.