A data protection impact assessment (DPIA) is a structured process that identifies and mitigates privacy risks before a processing activity begins. Required by Article 35 of the GDPR, DPIAs are not optional for high-risk processing. They are binding legal obligations, and failing to conduct one when required can result in fines of up to EUR 10 million or 2% of worldwide annual turnover under Article 83(4)(a).
The first decision is whether the proposed activity requires a DPIA. A short screening record should identify the processing, the applicable mandatory triggers and national lists, the likely effects on people and the evidence behind the conclusion.
This guide helps a project owner document that screening decision. Once a DPIA is required, use the DPIA implementation guide to build the assessment, assign mitigations and decide whether the project can proceed.
Definition and Legal Basis
A data protection impact assessment is a documented risk analysis that controllers must perform whenever a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons” (Article 35(1)). The assessment evaluates the necessity and proportionality of the processing, assesses risks to data subjects, and identifies measures to address those risks.
The concept is rooted in the broader accountability principle, which requires controllers not merely to comply with GDPR principles but to demonstrate that compliance through documented evidence. A DPIA is one of the primary tools for discharging that obligation.
DPIAs and Privacy by Design
DPIAs are closely connected to privacy by design obligations under Article 25. While privacy by design requires data protection to be embedded into processing from the outset, the DPIA provides the structured methodology for assessing whether those design choices are adequate. In practice, conducting a DPIA early in a project lifecycle ensures that data privacy principles are integrated before systems go live, rather than retrofitted after deployment.
The Role of the Data Protection Officer
Article 35(2) requires the controller to seek the advice of the Data Protection Officer where one is designated. The controller remains accountable for the DPIA. A project team, adviser or DPO can contribute to its preparation, but the DPO’s advice and monitoring role should remain independent of management’s decision to proceed. Needing a DPIA does not itself create a requirement to appoint a DPO; assess the separate DPO criteria.
When Is a DPIA Required?
Article 35(3) lists three situations where a DPIA is mandatory:
- 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 (Article 9) or data relating to criminal convictions (Article 10).
- Systematic monitoring of publicly accessible areas on a large scale, such as CCTV surveillance or location tracking.
Beyond these explicit triggers, Article 35(1) applies the general threshold of processing that is “likely to result in a high risk.” The EDPB’s Guidelines on DPIAs (WP 248 rev.01) identify nine criteria to help controllers assess whether this threshold is met. The guidelines use two criteria as a practical indication that a DPIA will usually be needed, not as a statutory safe harbour: one criterion may suffice, and a decision not to assess despite multiple criteria needs a reasoned explanation. These criteria include evaluation or scoring, automated decision-making with legal effect, systematic monitoring, processing of sensitive data, large-scale processing, matching or combining data sets, data concerning vulnerable subjects, innovative use of technology, and processing that prevents data subjects from exercising a right.
National supervisory authority lists. Each EU member state supervisory authority publishes a list of processing operations that require a DPIA (Article 35(4)). For example, the French CNIL publishes its DPIA required list identifying specific categories of processing, and any applicable Article 35(5) list of processing not requiring a DPIA must be considered within its stated conditions. The UK ICO’s list relates to the separate UK regime. Controllers must check the list published by the relevant authority in their jurisdiction, as these lists supplement — and sometimes expand — the criteria above.
Record the Screening Decision Before Approval
Describe the actual project rather than its product category. “New HR software” conceals whether the tool merely stores contact details or scores workers’ performance. Obtain the workflow, affected population, data fields, suppliers, access arrangements and expected decisions before scoring risk criteria.
| Proposed activity | Screening question | Decision to document |
|---|---|---|
| Small supplier contact directory | Any sensitive data, unusual linkage, monitoring or relevant national-list entry? | If high risk is not likely, record why; ordinary GDPR duties still apply |
| Recruitment scoring that determines rejection | Is there systematic extensive automated evaluation with significant effects? Are vulnerable people affected? | Assess Article 35(3)(a), national lists and any separate Article 22 issue before deployment |
| Hospital patient-record platform | Is processing of health data large scale? What are the volume, duration and geographic reach? | Record Article 35(3)(b) analysis and scope the DPIA around the whole patient workflow |
| Existing CCTV expanded into public areas with analytics | Does the expansion create large-scale systematic public monitoring or another high-risk trigger? | Reopen the prior decision and assess the changed processing before use |
These examples illustrate questions, not automatic approvals for a named product. Keep the source version of each relevant national list and explain how its conditions fit the activity. Resolve uncertain scale or system behaviour with the project owner rather than marking an unknown answer “no”.
The screening output should name the controller, project owner, evidence reviewed, conclusion, date and reopening triggers. If the project changes from a contact directory to performance scoring, the earlier conclusion cannot simply be carried forward. Where high risk is likely, the next deliverable is the full DPIA, not a more elaborate screening form.
What a Required DPIA Must Cover
Article 35(7) sets out the minimum contents. Use this outline to commission the work and the implementation guide to develop evidence and a launch decision.
Describe the Processing Operations
The DPIA must include a systematic description of the envisaged processing operations and their purposes, including the legitimate interest pursued where applicable. This description should cover the nature, scope, context, and purposes of the processing; the categories of personal data involved; the recipients and any data processors engaged; data flows, storage locations, and retention periods (see storage limitation); and the legal basis under Article 6.
Assess Necessity, Proportionality, and Risks
The DPIA must evaluate whether the processing is necessary and proportionate in relation to its purpose. This involves asking whether the stated objective could be achieved with less data, less intrusive methods, or shorter retention periods. Controllers should document why alternatives were considered and rejected.
The core of any data protection impact assessment is then a risk analysis that evaluates threats to the rights and freedoms of data subjects. Risks should be assessed on two dimensions: likelihood and severity. Common risk categories include unauthorised access or disclosure (see handling data breaches), inaccurate or excessive data leading to unfair decisions, loss of control over personal data, discrimination or reputational damage, and financial harm or identity theft.
Consider harms beyond a security breach. An inaccurate score can exclude someone from employment even if the system is well encrypted. Identify the affected people and the decision or disclosure that could cause the harm.
Define Mitigation Measures and Residual Risk
For each identified risk, the DPIA must describe the measures envisaged to address it. These include safeguards, security measures, and mechanisms to ensure protection of personal data and demonstrate compliance. Examples include pseudonymisation, encryption, access controls, data minimisation techniques, and contractual safeguards with processors.
The controller must then assess residual risk — the risk remaining after mitigation. If residual risk remains high, Article 36 requires prior consultation with the supervisory authority before proceeding with the processing.
Common Mistakes in DPIA Practice
Enforcement actions and supervisory authority guidance reveal recurring deficiencies in how organisations approach DPIAs. Understanding these pitfalls helps compliance teams avoid repeating them.
Confusing different assessment regimes. A California risk assessment is not automatically the same deliverable as an Article 35 DPIA. The CPPA’s regulations have their own scope and phased compliance dates; map obligations separately when both laws apply.
Conducting the DPIA too late. Article 35(1) requires it before the processing. Procurement approval, a live pilot with real personal data or a limited rollout can already involve the relevant processing. Schedule the screening while design alternatives remain available.
Treating the DPIA as a one-time exercise. Article 35(11) requires controllers to review the DPIA when there is a change in the risk represented by the processing. System upgrades, new data sharing arrangements, or changes in the volume of data processed can all alter the risk profile. Organisations should establish review triggers and schedule periodic reassessments, at a frequency justified by the activity; Article 35 does not prescribe an annual review for every DPIA.
Insufficient risk analysis. A DPIA that merely lists risks without assessing their likelihood and severity, or that fails to describe concrete mitigation measures, does not meet the Article 35(7) requirements. The ICO’s DPIA guidance emphasises that the risk assessment must be specific to the processing activity, not a generic template.
FAQ
Is a DPIA required for every processing activity?
No. A DPIA is only mandatory when processing is likely to result in a high risk to the rights and freedoms of individuals. Where the need is unclear, the endorsed guidelines recommend carrying out a DPIA. A voluntary assessment can also support accountability, but “more than minimal risk” is not the GDPR’s mandatory threshold.
What happens if you fail to conduct a required DPIA?
Failure to carry out a required DPIA is an infringement under Article 83(4)(a), punishable by administrative fines. Supervisory authorities can also order the controller to suspend the processing activity until a DPIA is completed, effectively halting the project.
Who bears legal responsibility for the DPIA?
The controller bears legal responsibility. In practice, the task is often delegated to a project team, privacy office, or external adviser. The DPO, where designated, must be consulted during the process (Article 35(2)), but the DPO does not sign off on or approve the DPIA — that decision rests with the controller.