DPIA Step-by-Step: When You Need One and How to Write It

A Data Protection Impact Assessment (DPIA) is a structured process for identifying and mitigating privacy risks before you begin a processing activity. Under GDPR Article 35, it is mandatory — not optional — for certain categories of high-risk processing. Getting it wrong means either running high-risk processing without proper analysis, or investing time in assessments you did not need.

This guide explains when a DPIA is required, what it must contain, and how to work through one efficiently.

What a DPIA Is

Article 35(7) defines what a DPIA must contain. At its core, it is four things:

1. A systematic description of the processing: what you are doing, why, and how.
2. An assessment of necessity and proportionality: is this processing necessary for the purpose? Is the privacy intrusion proportionate to the benefit?
3. An assessment of risks to data subjects: what could go wrong for the people whose data you process, and how likely and severe are those outcomes?
4. The measures you will take to address those risks: technical controls, organisational procedures, safeguards.

A DPIA is not a box-ticking exercise. Its purpose is to surface risks that you might otherwise miss and to build in mitigations before processing begins — not after a breach.

When a DPIA Is Mandatory

Article 35(1) requires a DPIA where processing is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3) specifies three categories that always require one:

1. Systematic evaluation of natural persons using automated processing, including profiling, that produces decisions with legal or similarly significant effects. This includes credit scoring, insurance risk models, automated recruitment screening, and fraud detection systems that trigger consequential outcomes.

2. Large-scale processing of special category data (Article 9) or personal data relating to criminal convictions and offences (Article 10). Special categories include health data, biometric data used for identification, genetic data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, and sexual orientation.

3. Systematic monitoring of publicly accessible areas on a large scale. CCTV covering a large public space is the clearest example, but this also covers tracking of movements or behaviour in public via mobile data or IoT sensors.

Beyond these three, national data protection authorities (DPAs) publish lists of processing types that require a DPIA in their jurisdiction. Check your national DPA's list — the ICO, CNIL, BfDI, and others maintain these. Where your DPA's list and Article 35(3) overlap, either source is sufficient to trigger the obligation.

Two or more of the following criteria also indicate high risk (from WP29 guidelines): evaluation or scoring of individuals; automated decision-making with legal or similarly significant effects; systematic monitoring; sensitive data or data of a vulnerable nature; data processed at large scale; matching or combining datasets; data concerning vulnerable data subjects; innovative use of technology; transfer outside the EU; processing that prevents data subjects from exercising their rights.

When a DPIA Is Not Required

A DPIA is not required where processing is unlikely to result in a high risk. Indicators of lower risk include: small-scale processing of non-sensitive data; processing that does not involve automated decision-making; processing that data subjects would reasonably expect; and processing covered by an existing, up-to-date DPIA for the same type of activity.

If you have previously conducted a DPIA for the same type of processing and the risk profile has not changed, you can reference the existing DPIA rather than starting from scratch.

The 7 Elements a Valid DPIA Must Contain

Article 35(7) lists the required elements:

| # | Element | What It Means | |---|---------|---------------| | 1 | Systematic description | What data, what processing, what purpose, what systems | | 2 | Assessment of necessity and proportionality | Why this processing is necessary; less privacy-intrusive alternatives considered | | 3 | Assessment of risks to data subjects | Likelihood × severity for each identified risk | | 4 | Measures to address risks | Technical and organisational mitigations | | 5 | DPO consultation | If you have a DPO, they must be consulted | | 6 | Data subject views | How you considered or sought views of data subjects (or why not) | | 7 | Lawful basis and compliance with principles | Confirmation that processing complies with GDPR principles (Article 5) |

Step-by-Step Walkthrough

Step 1: Describe the processing Answer: What personal data are you collecting? From whom? By what means? For what purpose? Who has access? Where is it stored? How long is it retained? Who are the processors involved? This section should be detailed enough that someone unfamiliar with the project can understand what is being built.

Step 2: Assess necessity and proportionality Answer: Is this processing necessary for the stated purpose? Could the purpose be achieved with less data or less intrusive processing? What is the lawful basis? How long will the data be retained, and is that proportionate? What rights do data subjects have, and how will you enable them to exercise those rights?

Step 3: Identify risks to data subjects For each identified risk, assess: What is the threat? What is the likelihood (low/medium/high)? What is the severity of harm if it materialises? Typical risks include: unauthorised access, data breach, function creep (data used for unanticipated purposes), inaccuracy and its consequences, exclusion or discrimination from automated decisions, loss of control by data subjects.

Step 4: Define mitigations For each risk, define the control that will address it. Map each control to a specific risk. After applying controls, re-assess residual risk.

Step 5: Consult your DPO If your organisation has a Data Protection Officer, they must be consulted. Record their input and whether it was incorporated.

Step 6: Document data subject views Explain how you considered the interests and reasonable expectations of data subjects. This does not always require a survey — for many processing activities, you can document your assessment of what data subjects would reasonably expect, and why this processing falls within or outside those expectations.

Step 7: Sign off and record The DPIA should be approved by the relevant business owner. Record the date of completion and any conditions attached to approval.

When to Consult Your DPA

Article 36 requires prior consultation with your national DPA where the residual risk remains high after mitigation measures have been applied. This is a high bar — it is not triggered every time a DPIA is completed, only when you cannot reduce risk to an acceptable level through your own measures.

If prior consultation is required, submit your DPIA to the DPA before commencing processing. The DPA has eight weeks to respond (extendable by six further weeks for complex cases).

How Long a DPIA Is Valid

There is no fixed expiry for a DPIA, but Article 35(11) requires a review "where there is a change in the risk represented by processing operations." Best practice is to review high-risk processing DPIAs at least annually, and to trigger a review whenever there is a material change to the processing: new data categories, new processors, new automated decision logic, new jurisdictions.

Combining DPIA with an AI Act Fundamental Rights Impact Assessment

For high-risk AI systems under the EU AI Act, deployers must conduct a Fundamental Rights Impact Assessment (FRIA) under Article 27. The FRIA covers similar ground to a DPIA but with a focus on fundamental rights beyond data protection.

Where the processing involves a high-risk AI system, conduct a combined DPIA + FRIA. Use the GDPR Article 35 structure as the base; add a section on non-data-protection fundamental rights impacts (fair trial, non-discrimination, freedom of expression). A single combined document satisfies both obligations and avoids duplicating the systematic description and risk assessment sections.

---

Last updated: April 2026. For informational purposes only — not legal advice.