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.

Frequently Asked Questions

When is a DPIA mandatory under GDPR Article 35?

A DPIA is mandatory under Article 35(1) whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3) identifies three categories that always require one: systematic evaluation of individuals using automated processing that produces legal or similarly significant effects (including profiling for credit scoring, recruitment screening, and insurance risk); large-scale processing of special category data under Article 9 or criminal convictions data under Article 10; and systematic monitoring of publicly accessible areas on a large scale. Beyond these, national DPAs publish lists of additional processing types that require a DPIA in their jurisdiction, and organisations should check the applicable national list alongside the Article 35(3) categories.

What must a GDPR DPIA contain?

Article 35(7) defines the mandatory elements: a systematic description of the processing (what data, what purpose, what systems, what processors); an assessment of necessity and proportionality (whether the processing is necessary and whether privacy intrusion is proportionate to the objective); an assessment of risks to data subjects (likelihood and severity of potential harms); and the measures intended to address those risks (technical and organisational controls with residual risk re-assessed after mitigations). Where a Data Protection Officer has been appointed, their consultation must be recorded. The assessment of whether data subjects' views were sought or considered, and the reasoning, must also be documented.

Do you need to consult the supervisory authority after completing a DPIA?

Only if residual risk remains high after applying all feasible mitigation measures. Article 36 requires prior consultation with the national DPA before commencing processing where the DPIA indicates that residual risk is high and the controller cannot reduce it further through its own measures. This is a high threshold — completing a DPIA does not automatically trigger DPA consultation. If consultation is required, the DPA must receive the full DPIA documentation and has eight weeks to respond, extendable by a further six weeks for complex cases. Processing must not begin during this consultation period.

Sources

• Regulation (EU) 2016/679 — GDPR, Article 35 (Data Protection Impact Assessment) — Statutory text of the DPIA obligation, mandatory categories, required content under Article 35(7), and prior consultation requirement under Article 36.
• EDPB Guidelines 09/2022 on Data Protection Impact Assessments — European Data Protection Board guidance on when DPIAs are required, the nine criteria indicating high risk, and the methodology for completing a compliant assessment.
• ICO — Data Protection Impact Assessments guidance — UK Information Commissioner's Office practical guidance on DPIA structure, mandatory cases, and best-practice templates applicable across EU member state frameworks.
• WP29 Guidelines on Data Protection Impact Assessment (WP248) — Article 29 Working Party guidelines adopted before the EDPB, setting out the nine criteria for high-risk processing and the methodology endorsed by supervisory authorities across the EU.