A data protection impact assessment helps a controller decide whether a high-risk processing project can proceed, with which safeguards and on what evidence. The deliverable is a reasoned decision linked to the actual design, not a generic risk template filled in after launch.
This guide provides a concrete, step-by-step implementation methodology for conducting a data protection impact assessment that meets Article 35 requirements and withstands regulatory scrutiny. It is aimed at DPOs, compliance officers, and project managers who need to operationalise the DPIA process rather than simply understand the theory.
If the threshold decision is unresolved, complete the DPIA screening record first. This implementation guide’s output is the documented risk assessment, verified mitigation plan and accountable decision on whether the proposed processing can proceed.
When Is a Data Protection Impact Assessment Mandatory?
Article 35(1) of the GDPR requires a DPIA whenever processing is “likely to result in a high risk to the rights and freedoms of natural persons.” The threshold is forward-looking: the assessment must happen before processing begins, based on the anticipated risk profile rather than demonstrated harm.
The Three Explicit Triggers
Article 35(3) identifies three categories where a DPIA is always required:
- Systematic and extensive profiling with significant effects – automated decision-making producing legal or similarly significant outcomes, such as credit scoring or automated recruitment screening.
- Large-scale processing of special category data – Article 9 data (health, biometric, genetic, political opinions, etc.) or Article 10 criminal conviction data processed at scale. This is why the assessment is effectively unavoidable for hospitals, laboratories and patient-facing platforms; the sector-specific treatment is in our guide to the DPIA for health data.
- Systematic monitoring of publicly accessible areas on a large scale – CCTV networks, Wi-Fi tracking, drone surveillance, or facial recognition in public spaces.
The EDPB Nine-Criteria Framework
Beyond the three explicit triggers, the EDPB Guidelines on DPIAs (WP 248 rev.01) identify nine criteria for assessing whether processing is likely to result in high risk. When a processing activity meets two or more of these criteria, a DPIA should generally be conducted:
- Evaluation or scoring (including profiling and predicting)
- Automated decision-making with legal or similarly significant effect
- Systematic monitoring of data subjects
- Sensitive data or data of a highly personal nature
- Data processed on a large scale
- Matching or combining datasets from different sources
- Data concerning vulnerable data subjects (children, employees, patients)
- Innovative use or application of new technological or organisational solutions
- Processing that itself prevents data subjects from exercising a right or using a service or contract
The nine criteria are a screening aid, not a statutory two-box rule. One criterion can be sufficient; where a controller concludes that processing meeting two criteria does not require a DPIA, it should justify and document that conclusion, taking account of the applicable supervisory-authority list.
How Do National DPA Blacklists Affect Your Obligations?
Article 35(4) requires each national supervisory authority to publish a list of processing operations that require a DPIA. These lists supplement the GDPR criteria and can impose additional obligations specific to the jurisdiction.
Use the current Article 35(4) and, where applicable, Article 35(5) lists issued by the competent supervisory authorities. The relevant German authority may be a state authority rather than the BfDI. The UK ICO’s list concerns UK law and should not be presented as an EU national list.
For cross-border processing, identify the competent authorities and the lists relevant to that processing, including their scope and conditions. Do not mechanically apply every country’s entire list or ignore local requirements. Record the source and reasoning in the GDPR compliance review.
Step-by-Step DPIA Implementation Process
A data protection impact assessment is a process, not a document. The output is documentation, but the value lies in the structured analysis. The following methodology maps directly to the four minimum elements specified in Article 35(7).
Step 1: Systematic Description of the Processing
Document the processing operations in sufficient detail for a third party to understand exactly what happens to personal data:
- Purpose and legal basis under Article 6 GDPR, including the balancing test where legitimate interest is relied upon
- Data categories and sources, distinguishing between direct collection and third-party data
- Data flows through systems, cross-referenced with your Records of Processing Activities
- Retention periods and the criteria used to determine them
- Technology stack, particularly any automated decision-making components
Include recipients and processor access, international transfers, interfaces and any manual decisions. A reviewer should be able to follow one person’s data from collection through use, disclosure and deletion without relying on an undocumented explanation from the project team.
Step 2: Necessity and Proportionality Assessment
Article 35(7)(b) requires assessing “the necessity and proportionality of the processing operations in relation to the purposes.” The assessment must answer: Could the purpose be achieved with less data or with anonymised data? Is the scope limited to what is strictly necessary? Are retention periods the shortest possible?
Document each question and the reasoning behind your answers. Where alternatives were considered and rejected, explain why. This analysis is directly tied to the data privacy principles of data minimisation, purpose limitation, and storage limitation.
Step 3: Risk Assessment
Evaluate threats to data subjects’ rights and freedoms. For each risk, assess likelihood and severity on a defined scale (low/medium/high/very high). Structure the analysis around confidentiality risks (unauthorised access, breaches), integrity risks (inaccurate data leading to wrong decisions), availability risks (data loss), and rights and freedoms risks (discrimination, financial harm, loss of autonomy).
For each risk, document the specific scenario, affected data subjects, existing controls, and residual risk level. Generic risk registers copied between DPIAs do not satisfy Article 35(7) requirements.
Step 4: Mitigation Measures and Residual Risk
Define measures proportionate to each identified risk and document the method used to prioritise them; GDPR does not prescribe a universal “medium” scoring threshold. Measures can be: technical (encryption, pseudonymisation, access controls, audit logging), organisational (staff training, incident response procedures, regular audits), and contractual (Article 28 data processing agreements, data sharing agreements with defined safeguards).
After applying measures, reassess each risk to determine the residual level. If residual risk remains high despite all reasonable measures, Article 36 requires prior consultation with the supervisory authority.
Prior Consultation Under Article 36
When a DPIA shows that residual risk cannot be sufficiently reduced, Article 36 requires the controller to consult the supervisory authority before processing begins. The controller submits the DPIA along with information about responsibilities, purposes, means, safeguards, and DPO contact details.
Under Article 36(2), the authority provides written advice within up to eight weeks where it considers the intended processing would infringe GDPR, with a possible six-week extension for complexity. These periods may be suspended while requested information is outstanding. Consultation is not a deemed approval after the clock expires, and processing must not begin while the prerequisite consultation remains unresolved.
Make the Launch Decision Explicit
Consider a recruitment project that scores applicants from interview recordings. The DPIA must assess risks to candidates: inaccurate scoring, discriminatory outcomes, loss of opportunity, unexpected reuse and difficulty challenging a decision. A cybersecurity-only assessment misses these harms. Determine the Article 6 basis and any Article 9 or Article 22 conditions separately before treating security controls as sufficient.
For each risk, keep the scenario, affected people, severity, likelihood, proposed measure, evidence owner and residual assessment. A promised human review is not a verified safeguard until the reviewer can understand the score, obtain relevant information and change the outcome. Record how that will be tested with the people operating the recruitment process.
Use three explicit outcomes: proceed under a lawful design with implemented measures; redesign and reassess; or stop and, where Article 36 requires it, consult the authority before processing. The controller makes the decision and retains the DPO’s advice where a DPO is designated. Where appropriate, seek the views of people affected under Article 35(9) and record how they influenced the design.
Attach implementation conditions to the project release process. An open action such as “add an appeal route” needs an owner, completion evidence and a decision on whether launch is blocked. Do not lower the residual-risk score merely because a measure appears in a future roadmap. The EDPB-endorsed DPIA guidelines explain the risk methodology and accountability expected from the process.
Integrating DPIAs into Your Compliance Programme
Connect the assessment to the ROPA, processor evidence and project change control. Set review triggers under Article 35(11): new data sources, recipients, scoring purposes, deployment scale or evidence that safeguards do not work. Preserve versions so the current decision can be compared with the design actually assessed.
A useful handover gives the service owner the permitted scope, live safeguards, unresolved conditions and review triggers. The DPO can advise and monitor, but the controller and project owner must ensure that the agreed controls operate after launch.
FAQ
What is the difference between a DPIA and a privacy impact assessment?
A DPIA has a specific legal meaning under GDPR Article 35. A privacy impact assessment (PIA) is a broader concept that predates the GDPR and may not include all four elements required by Article 35(7). Any assessment conducted to satisfy GDPR obligations must meet the Article 35 requirements regardless of terminology.
Can a single DPIA cover multiple processing activities?
Yes. Article 35(1) permits a single DPIA to address “a set of similar processing operations that present similar high risks.” A retail chain deploying identical CCTV across all stores could conduct one DPIA with annexes for location-specific variations, provided the risk profile is genuinely similar.
How often should a DPIA be reviewed?
Article 35(11) requires review at least when the processing risk changes. Set a review interval suited to the activity and reopen the assessment for material changes, such as new recipients, decision logic, system migrations or increased scale. The GDPR does not prescribe a universal annual DPIA review.
Does a DPIA guarantee that processing is lawful?
No. A DPIA assesses risk and identifies mitigation measures, but does not establish a legal basis for processing. You still need a valid legal basis under Article 6, compliance with data subject rights, adequate security measures, and all other GDPR requirements. A DPIA is one component of accountability, not a substitute for comprehensive compliance.