How to Conduct a Data Protection Impact Assessment (DPIA)
Comprehensive guide to conducting Data Protection Impact Assessments under GDPR Article 35, covering when a DPIA is mandatory, the step-by-step process, risk assessment methodology, prior consultation with supervisory authorities under Article 36, and documentation requirements.
- 1
A DPIA is mandatory when processing is likely to result in high risk to data subjects — particularly for automated decision-making, large-scale special category data processing, and systematic monitoring.
- 2
The DPIA risk assessment focuses on risks to data subjects (physical, material, non-material harm and chilling effects), not risks to the organisation.
- 3
Prior consultation with the DPA under Article 36 is required only when residual risk remains high after all feasible mitigation measures are applied.
- 4
Integrate DPIA triggers into project governance and procurement processes to ensure assessments happen before processing begins, not after.
- 5
DPIAs are living documents — review when processing changes and maintain a register tracking all assessments, their status, and review schedules.
1. What Is a DPIA and When Is It Mandatory
A Data Protection Impact Assessment (DPIA) is a structured process for evaluating the potential impact of a data processing activity on the rights and freedoms of natural persons, and for identifying measures to mitigate those risks. It is a forward-looking assessment, conducted before the processing begins, that helps the data controller determine whether the processing can proceed as planned, whether modifications are needed to reduce risk, or whether the residual risk is so high that prior consultation with the supervisory authority is required (GDPR Article 36). The DPIA is both a compliance obligation and a practical risk management tool — when done well, it prevents privacy harms and regulatory enforcement actions before they occur.
GDPR Article 35(1) makes a DPIA mandatory when 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.' Article 35(3) provides three specific scenarios where a DPIA is always required: (a) systematic and extensive evaluation of personal aspects relating to natural persons, based on automated processing including profiling, which produces legal effects or similarly significantly affects the individual; (b) processing on a large scale of special category data (Article 9) or data relating to criminal convictions and offences (Article 10); and (c) systematic monitoring of a publicly accessible area on a large scale. These are not exhaustive — a DPIA may be required in other high-risk scenarios.
The European Data Protection Board (EDPB) Guidelines on DPIAs (WP 248 rev.01, adopted April 2017) provide nine criteria for assessing whether processing is 'likely to result in a high risk': evaluation or scoring, automated decision-making with legal or similar effects, systematic monitoring, sensitive data or data of a highly personal nature, large-scale processing, matching or combining datasets, data concerning vulnerable data subjects, innovative use or application of new technological or organisational solutions, and processing that prevents data subjects from exercising a right or using a service or contract. The EDPB recommends that processing meeting two or more of these criteria should generally require a DPIA. Additionally, each national supervisory authority publishes a list of processing operations that require a DPIA (Article 35(4)) — check your applicable DPA's published list, as it may include sector-specific or jurisdiction-specific triggers beyond the EDPB criteria.
Each EU national data protection authority publishes a list of processing operations that require a DPIA under Article 35(4). These lists include jurisdiction-specific triggers beyond the EDPB's general criteria. Always check your applicable DPA's published list.
2. Step-by-Step DPIA Process
The DPIA process follows a structured sequence: describe the processing, assess necessity and proportionality, identify and assess risks to data subjects, identify measures to mitigate risks, document the assessment and outcomes, and implement and monitor. While GDPR Article 35(7) prescribes the minimum content (systematic description of processing, assessment of necessity and proportionality, assessment of risks, and measures to address risks), a thorough DPIA expands each of these elements into a rigorous analysis.
Step 1 — Describe the Processing: Document the nature, scope, context, and purposes of the processing. What personal data is collected? From whom? How is it collected (directly from data subjects, from third parties, generated through observation)? What processing operations are performed (collection, storage, analysis, profiling, automated decision-making, sharing, transfer)? What technologies are used? Where is the data stored and processed? How long is it retained? Who has access? This description must be specific enough that a reader unfamiliar with the processing activity can understand exactly what happens to the personal data from collection to deletion. Include a data flow diagram that visually maps the data journey through your systems, any transfers to third parties or third countries, and the technical and organisational measures applied at each stage.
Step 2 — Assess Necessity and Proportionality: Evaluate whether the processing is necessary for the stated purpose (GDPR Article 5(1)(c) — data minimisation) and whether the purpose could be achieved with less intrusive means. Document the lawful basis for processing (Article 6, and Article 9(2) for special category data). Assess whether the data collected is limited to what is necessary, whether the retention period is justified, and whether data subjects are adequately informed (Articles 13/14). This step is where many DPIAs identify quick wins: processing activities that can be redesigned to collect less data, retain it for shorter periods, or use pseudonymisation to reduce identifiability — each of which reduces risk without sacrificing the processing purpose.
3. Risk Assessment Methodology for Data Processing
The risk assessment is the analytical core of the DPIA. Unlike a cybersecurity risk assessment that focuses on threats to the organisation, a DPIA risk assessment focuses on risks to data subjects — the individuals whose personal data is being processed. The question is not 'what could go wrong for us?' but 'what could go wrong for the people whose data we process?' This perspective shift is essential: a data breach that costs the organisation a regulatory fine is a risk to the organisation; the same breach exposing an individual's health records, enabling identity theft, or revealing their political opinions is a risk to the data subject's rights and freedoms.
Assess risks across four dimensions of harm to data subjects: physical harm (e.g., stalking enabled by location data exposure), material harm (e.g., financial loss from identity theft, discriminatory treatment from profiling), non-material harm (e.g., reputational damage, emotional distress, embarrassment), and chilling effects on the exercise of fundamental rights (e.g., self-censorship due to surveillance, reluctance to access healthcare services if health data protection is inadequate). For each identified risk, assess the likelihood of occurrence (considering the nature of the processing, the threat landscape, the existing safeguards, and the vulnerability of the data subjects) and the severity of impact (considering the nature and sensitivity of the data, the number of data subjects affected, and the reversibility of the harm).
Use a risk matrix to combine likelihood and severity into an overall risk level (low, medium, high, very high). The EDPB has not prescribed a specific methodology, giving controllers flexibility to use qualitative or quantitative approaches appropriate to their context. However, the assessment must be systematic, documented, and defensible. Common methodologies include the French CNIL's PIA methodology (which structures risk around feared events, threats, and risk sources), the German BSI's Standard Data Protection Model (which maps processing activities against data protection goals), and the ISO 29134 standard (which provides a structured DPIA framework aligned with ISO 27005 risk management). Whichever methodology you adopt, apply it consistently across DPIAs to enable comparison and trend analysis.
A DPIA risk assessment focuses on risks to data subjects, not risks to the organisation. The question is 'what could go wrong for the people whose data we process?' — not 'what could this cost us?' This perspective shift is fundamental to a valid DPIA.
4. Mitigation Measures and Residual Risk
For each identified risk, define specific mitigation measures that reduce the likelihood, the severity, or both. Mitigation measures fall into three categories: technical measures (encryption, pseudonymisation, access controls, data minimisation through architectural design, automated data deletion, differential privacy techniques), organisational measures (policies, training, contractual obligations on processors, data protection by design reviews, audit procedures), and governance measures (DPO oversight, regular DPIA review, data subject rights procedures, complaint handling mechanisms).
Map each mitigation measure to the specific risk it addresses, and re-assess the residual risk after mitigation. The residual risk is the risk that remains after all identified measures are implemented. If the residual risk is acceptable (i.e., it is proportionate to the processing purpose and the measures are appropriate under Article 32), document this conclusion and proceed with the processing. If the residual risk remains high despite all feasible mitigation measures, GDPR Article 36 requires the controller to consult the supervisory authority before proceeding. The consultation obligation is not optional — it is a legal requirement when the controller cannot sufficiently mitigate the high risk through its own measures.
When designing mitigation measures, prioritise data protection by design and by default (Article 25). Measures that are embedded in the system architecture — pseudonymisation, data minimisation at collection, automated retention enforcement, privacy-preserving analytics — are more reliable and more effective than procedural controls that depend on human compliance. For example, aggregating location data before analysis (technical measure) is more effective than training analysts not to re-identify individuals from location patterns (organisational measure). GDPR Article 25(1) requires the controller to implement appropriate technical and organisational measures 'both at the time of the determination of the means for processing and at the time of the processing itself' — the DPIA is the mechanism through which this obligation is operationalised.
5. Prior Consultation with the DPA (Article 36)
GDPR Article 36(1) requires the controller to consult the supervisory authority prior to processing where the DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk — and the controller cannot sufficiently mitigate that risk. This is a narrow but important obligation: it applies only when, after identifying all feasible mitigation measures, the residual risk to data subjects remains high. Prior consultation is not a general approval mechanism — it is a safety valve for processing activities where the controller's own measures are insufficient.
The consultation process requires the controller to provide the supervisory authority with the DPIA, information about the respective responsibilities of the controller and any processors, the purposes and means of the intended processing, the measures and safeguards provided to protect data subjects' rights, contact details of the DPO, and any other information requested by the supervisory authority (Article 36(3)). The supervisory authority must provide written advice within eight weeks (extendable by six weeks for complex cases). During the consultation period, the supervisory authority may exercise its corrective powers under Article 58(2), which include issuing warnings, imposing bans on processing, or ordering specific changes to the processing operations.
In practice, prior consultation is rare — most organisations are able to mitigate identified risks to acceptable levels through technical and organisational measures. However, certain processing types are more likely to require consultation: large-scale biometric identification systems, AI-driven automated decision-making with significant effects on individuals, population-scale health data processing, and novel surveillance technologies. If your DPIA identifies residual high risk, engage with your DPA early and constructively. Present a well-documented DPIA that demonstrates a thorough risk analysis and a genuine effort to mitigate risks. DPAs are far more receptive to controllers who proactively consult with a comprehensive assessment than to those who attempt to minimise risks to avoid the consultation obligation.
Prior consultation under Article 36 is required only when residual risk remains high after all feasible mitigation measures. The DPA has eight weeks (extendable by six) to respond with written advice. Most processing activities can be mitigated to acceptable risk levels without consultation.
6. DPIA Templates and Documentation Requirements
GDPR Article 35(7) prescribes the minimum content of a DPIA: (a) a systematic description of the envisaged processing operations and the purposes, including the legitimate interest pursued where applicable; (b) an assessment of the necessity and proportionality of the processing in relation to the purposes; (c) an assessment of the risks to the rights and freedoms of data subjects; and (d) the measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure the protection of personal data and demonstrate compliance. Your DPIA template should expand each of these elements into structured sections with prompts that guide the assessor through a thorough analysis.
A practical DPIA template includes the following sections: project overview and processing description (what, why, who, how, where, when), data flow diagram, lawful basis analysis, necessity and proportionality assessment, stakeholder consultation record (input from the DPO, data subjects or their representatives where appropriate, and relevant business functions), risk identification and assessment (risk description, likelihood, severity, risk level for each identified risk), mitigation measures (mapped to specific risks, with implementation responsibility and timeline), residual risk assessment (post-mitigation risk level for each risk), consultation outcome (DPO advice, and where applicable, DPA consultation response), and approval and sign-off (by the data controller or authorised delegate, with date and conditions).
Maintain a DPIA register that tracks all DPIAs conducted, their status (draft, approved, in review), the processing activity they cover, the date of the last review, and the next scheduled review date. DPIAs are not one-time documents — Article 35(11) requires the controller to carry out a review when there is a change in the risk represented by the processing operations, including when the nature, scope, context, or purposes of the processing change. Establish a trigger-based review process: any change to the processing activity (new data sources, expanded scope, new technology, new data sharing arrangements) should trigger a DPIA review to assess whether the risk profile has changed. For large organisations with many processing activities, integrate DPIA tracking into your broader privacy management programme alongside the records of processing activities (Article 30) and the data subject rights response log.
7. Integrating DPIAs into Organisational Processes
The greatest challenge with DPIAs is not conducting them but ensuring they are conducted at the right time — before processing begins, not after. Integrate DPIA triggers into your existing project governance and procurement processes so that new processing activities are automatically assessed for DPIA requirements. In the project lifecycle, include a DPIA screening step at the project initiation or requirements phase — a brief questionnaire (does the project involve personal data? new technology? automated decision-making? large-scale processing?) that determines whether a full DPIA is required. In procurement, include a DPIA screening step when new systems, tools, or vendors that process personal data are being evaluated.
The DPO plays a critical role in the DPIA process. GDPR Article 35(2) requires the controller to seek the advice of the DPO when carrying out a DPIA. Article 39(1)(c) specifies that the DPO's tasks include providing advice regarding the DPIA and monitoring its performance. Ensure the DPO is involved early — at the screening stage, not after the DPIA is drafted — and that the DPO's advice is documented and demonstrably considered. Where the controller departs from the DPO's advice, document the rationale. The DPO should maintain oversight of the DPIA register and escalate to the management body when DPIAs identify high residual risks or when processing activities proceed without required DPIAs.
For organisations subject to both GDPR and NIS2, the DPIA process should coordinate with the broader risk management framework. NIS2 Article 21(2)(a) requires risk analysis that may overlap with DPIA risk assessments — where a processing activity involves both personal data risks and network/information system security risks, conduct the assessments in coordination to avoid duplication and ensure consistency. The same applies to DORA-regulated financial entities, where ICT risk assessments under Article 5-6 may cover technology platforms that also process personal data. A unified risk assessment approach that addresses cybersecurity risk, operational risk, and data protection risk in a coordinated framework produces better outcomes than three separate, potentially contradictory assessments.
When is a DPIA legally required under GDPR?
A DPIA is required whenever processing is 'likely to result in a high risk to the rights and freedoms of natural persons' (Article 35(1)). Three specific scenarios always require a DPIA: systematic and extensive automated profiling with legal or significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of publicly accessible areas. The EDPB recommends that processing meeting two or more of its nine criteria (evaluation/scoring, automated decisions, systematic monitoring, sensitive data, large scale, data matching, vulnerable subjects, innovative technology, rights-preventing processing) should generally require a DPIA. Additionally, check your national DPA's published list of mandatory DPIA processing types.
Can we skip a DPIA if the processing is based on legitimate interest?
No. The lawful basis for processing does not determine whether a DPIA is required. A DPIA is triggered by the risk level of the processing, not by the lawful basis. Processing based on legitimate interest (Article 6(1)(f)) that meets the high-risk criteria requires a DPIA just as much as processing based on consent or contractual necessity. In fact, the legitimate interest balancing test (assessing whether the controller's interest is overridden by the data subject's rights) and the DPIA risk assessment are complementary — the DPIA provides the detailed risk analysis that informs the balancing test.
What happens if we do not conduct a required DPIA?
Failure to conduct a required DPIA is a direct infringement of GDPR Article 35 and is subject to administrative fines under Article 83(4)(a) — up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Additionally, processing that proceeds without a required DPIA may be found to lack appropriate safeguards under Article 32, potentially compounding the infringement. Several DPAs have already imposed fines for missing DPIAs, including significant penalties for public sector bodies and private companies deploying new technologies without assessment.
Do we need a DPIA for existing processing activities or only new ones?
The GDPR text focuses on assessments 'prior to the processing' (Article 35(1)), suggesting forward-looking application. However, the EDPB has clarified that DPIAs are also strongly recommended for existing processing operations that have not previously been assessed, particularly where the processing has changed since it was originally designed or where the risk environment has evolved. Where existing processing clearly meets the mandatory DPIA criteria, conducting a retrospective DPIA is essential — supervisory authorities will not accept 'this processing pre-dates GDPR' as justification for the absence of a DPIA.
What role does the DPO play in the DPIA process?
Article 35(2) requires the controller to seek the DPO's advice when carrying out a DPIA. Article 39(1)(c) includes DPIA advice and monitoring in the DPO's statutory tasks. The DPO should be involved from the screening stage (determining whether a DPIA is required) through the assessment (advising on methodology, risk assessment, and mitigation measures) to the outcome (reviewing the residual risk assessment and advising on whether prior consultation is needed). The DPO's advice must be documented, and if the controller departs from it, the rationale must be recorded. The DPO also monitors the DPIA register and ensures that reviews are conducted when processing changes.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.