What Is a Data Protection Impact Assessment (DPIA)

Introduction

A European hospital begins deploying an AI system to analyze patient health records and predict readmission risk. The system processes tens of thousands of records containing some of the most sensitive personal data imaginable — diagnoses, medications, and mental health history. Before a single line of code runs in production, the GDPR requires the hospital to perform a formal written assessment of the privacy risks involved and document how those risks will be mitigated.

That process is called a Data Protection Impact Assessment, or DPIA. Introduced in Article 35 of the General Data Protection Regulation, a DPIA is not simply a best-practice checklist — it is a legally mandated accountability mechanism. Organizations that skip it face fines of up to €10 million or 2% of global annual turnover, whichever is higher.

Yet many compliance teams treat DPIAs as bureaucratic box-ticking exercises, producing thin documentation that fails to identify genuine risk. This approach satisfies neither the letter nor the spirit of the GDPR, and it leaves organizations exposed if a supervisory authority investigates. Understanding what a DPIA actually involves — and when it is truly required — is essential for anyone handling personal data at scale.

What Is a Data Protection Impact Assessment?

A DPIA is a systematic process for identifying, assessing, and mitigating the privacy risks associated with a specific processing activity before that activity begins. It is a forward-looking document: you conduct it before you deploy the system, not after.

The GDPR’s data protection by design principle (Article 25) demands that privacy safeguards be built into systems from the ground up. The DPIA operationalizes this principle — it forces data controllers to think critically about the data they intend to collect, the purposes for which they will use it, and the harms that could result if something goes wrong.

Article 35 requires three elements in every DPIA:

1. A systematic description of the processing, its purposes, and the legitimate interests pursued.
2. An assessment of the necessity and proportionality of the processing relative to those purposes.
3. An assessment of the risks to the rights and freedoms of individuals, and the measures to address those risks.

The output is a written record that demonstrates the controller evaluated the risks and took proportionate action — a core component of demonstrating GDPR accountability to supervisory authorities.

How a DPIA Works

A structured DPIA typically moves through four phases, each building on the last.

Phase 1 — Scoping: Define the boundaries of the assessment. What system, process, or project is being assessed? What personal data will be processed? Who are the data subjects? At what scale? Identify all the actors: the controller, any processors or sub-processors, joint controllers, and the DPO.

Phase 2 — Necessity and Proportionality Review: Assess whether the processing is lawful, necessary, and proportionate. What is the legal basis under Article 6 (and Article 9 for special category data)? Is there a less privacy-intrusive way to achieve the same goal? Could pseudonymisation or data minimization reduce the data footprint?

Phase 3 — Risk Assessment: This is the analytical core of the DPIA. For each processing operation, identify the potential threats (e.g., unauthorized access, data breach, function creep), the likelihood of those threats materializing, and the severity of harm to individuals. Harm is assessed both in probability and magnitude — a small chance of catastrophic reputational harm can outweigh a high chance of minor inconvenience.

Phase 4 — Risk Treatment and Sign-off: Document the technical and organizational measures you will implement to reduce identified risks to an acceptable level. Common measures include encryption at rest and in transit, access controls, pseudonymization, audit logging, and retention limits. If the residual risk remains high after applying all feasible measures, the controller must consult the supervisory authority under Article 36 before proceeding.

VIDEO · READY 16:9

PLAY

What is a DPIA? The GDPR Data Protection Impact Assessment

DPIA Required vs Not Required

One of the most common compliance questions is determining which projects actually trigger the DPIA obligation. The answer hinges on the concept of “likely to result in a high risk.”

When in doubt, Article 35(1) provides the general rule: if processing is likely to result in high risk, a DPIA is required. The ICO’s guidance recommends that if you have any doubt, conducting a DPIA is always safer than not doing one.

Real-World Use Cases

AI-Powered Recruitment Screening: A large employer deploys an AI tool to screen 50,000 job applications per year, scoring candidates on predicted job performance using data including their CV, LinkedIn profile, and automated video interviews. This triggers a mandatory DPIA because it constitutes “systematic and extensive evaluation based on automated processing, including profiling,” which produces “decisions that produce legal or similarly significant effects.” The DPIA would need to assess the risk of algorithmic bias, the right to explanation under Article 22, and the legal basis for automated decision-making.

Smart City Monitoring: A municipality installs IoT sensors combined with video analytics to monitor pedestrian flows and identify anti-social behaviour in public spaces. This constitutes “systematic monitoring of a publicly accessible area.” The DPIA must assess whether the public interest basis is sufficient, whether the data is retained longer than necessary, and what safeguards prevent function creep into law enforcement use cases not covered by the original purpose.

Cross-Border Health Data Research: A pharmaceutical company transfers anonymized patient data from European hospitals to a US-based research partner for drug trial analysis. The DPIA must assess whether the anonymization is truly irreversible, the legal mechanism for the cross-border transfer (Standard Contractual Clauses, Binding Corporate Rules, or adequacy decision), and the risk that re-identification becomes possible when combined with external datasets.

Common Mistakes to Avoid

The most damaging mistake is treating a DPIA as a post-hoc justification exercise — writing it after the system has already been deployed and simply describing decisions already made. A DPIA must be conducted before processing begins, while design decisions can still be influenced. Supervisory authorities have fined organizations for exactly this failure: presenting a DPIA with a conclusion determined before the assessment was undertaken.

A second critical error is underestimating the scope of “special category data” under GDPR Article 9. Health data, biometric data, political opinions, religious beliefs, and data about sexual orientation all attract special protection. Processing any of these categories at more than trivial scale will almost always require a DPIA, and must have an explicit Article 9(2) exemption in addition to an Article 6 lawful basis.

Many organizations also fail to include meaningful consultation with data subjects or their representatives as part of the DPIA process. Article 35(9) requires the controller to “seek the views of data subjects or their representatives where appropriate.” This does not always require formal consultation, but skipping it entirely — particularly for processing that affects vulnerable groups like children or employees — is frequently criticised by DPAs during investigations.

Getting Started

Embedding DPIA practice into your organization is a matter of building the right triggers and templates into your existing project governance. Use the compliance checklist below to operationalize each requirement.

1. Create a DPIA screening questionnaire: Every new project handling personal data should answer eight to ten trigger questions. If any answer is “yes” — new technology, special category data, large scale, profiling, systematic monitoring — a DPIA is mandatory (GDPR Art. 35(1) and Art. 35(3)).

2. Use a structured template: Regulators including the ICO and the CNIL publish free DPIA templates. These templates ensure you cover all three mandatory Article 35 elements and are formatted to demonstrate accountability (GDPR Art. 35(7)).

3. Involve your DPO early: If your organization has a Data Protection Officer (DPO), they must be consulted before the DPIA is finalized. Their advice should be recorded, whether or not you follow it (GDPR Art. 35(2) and Art. 39(1)(c)).

4. Build DPIA into your SDLC gate reviews: Add a DPIA as a mandatory artifact at the requirements-sign-off stage of your Software Development Lifecycle. This prevents the post-hoc problem entirely (GDPR Art. 25 — Data protection by design).

5. Maintain a register: Article 30 registers of processing activities and DPIA records are complementary. Cross-reference them so auditors can trace from any processing activity to its associated DPIA (GDPR Art. 30 and Art. 35(11)).

6. Consult the supervisory authority when residual risk remains high: If mitigation cannot reduce the identified risk to an acceptable level, submit the DPIA to your national DPA before processing begins (GDPR Art. 36(1)).

Understanding what constitutes high risk in data processing is closely tied to your organization’s broader GDPR compliance obligations under Article 32. A DPIA is one of the most powerful tools in your accountability arsenal — when conducted properly, it converts vague regulatory obligation into a documented, defensible decision record.