How to run a DPIA in practice, with a checklist

Step 1. Does the project need a DPIA?

Check the project against Article 35(3), against the list published by the competent supervisory authority (Article 35(4)), and against the nine criteria in the European DPIA guidelines (in most cases, processing that meets two of them needs a DPIA). If the processing matches those cases but you conclude that it is not likely to result in a high risk, the guidelines say to justify and document the reasons, and to record the views of the data protection officer. If the project also falls under § 7150(b) of the California regulations, plan one document that serves both laws (see DPIA vs PIA).

Step 2. How do you describe the processing?

Article 35(7)(a) asks for a systematic description of the processing operations and their purposes, including, where applicable, the legitimate interest pursued. Cover: what data, about whom, from which sources; what is done with it and by which systems; who receives it (including processors and their sub-processors); where it is stored and transferred; and how long it is kept. A data-flow diagram saves pages.

Step 3. Is the processing necessary and proportionate?

Article 35(7)(b). For each purpose, state the legal basis, why each data item is needed, the retention period, how people are informed, and how they can exercise their rights. Where a less intrusive way would achieve the purpose, say why it was not chosen.

Step 4. What are the risks to people?

Article 35(7)(c) is about the risks to the rights and freedoms of the people concerned, not risks to the company. For each risk (for example unlawful access, loss, unexpected use, discrimination, or loss of control over the data), record how likely it is and how severe it would be, on a scale used the same way throughout.

Step 5. Which measures reduce them?

Article 35(7)(d): the measures envisaged to address the risks, including safeguards, security measures and mechanisms to protect the data and to demonstrate compliance. Examples are pseudonymisation, access controls, shorter retention, encryption, contractual limits on processors (Article 28), human review of automated decisions, and clear notices. Record the risk that remains after each measure.

Step 6. Who must be consulted?

• The DPO, where one is designated: the controller must seek the DPO's advice (Article 35(2)). Record the advice.
• The people concerned or their representatives, where appropriate (Article 35(9)).
• Processors, who must assist the controller with the obligations in Articles 32 to 36 (Article 28(3)(f)).
• In California, the employees who take part in the processing must be included, and external parties may be (§ 7151 of the CCPA regulations).

Step 7. What if the risk stays high?

The controller decides whether to proceed. Where the DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate it, the controller must consult the supervisory authority before starting (Article 36(1)). If the authority considers that the processing would infringe the GDPR, it gives written advice within up to eight weeks, which may be extended by six weeks for complex processing (Article 36(2)).

Step 8. How do the measures reach the project?

Turn each measure into a task with an owner and a date: a configuration, a contract clause, a notice, a training. A DPIA whose measures never reach the build does not protect anyone.

Step 9. When is it reviewed?

Where necessary, the controller must review whether the processing follows the DPIA, at least when the risk represented by the processing changes (Article 35(11)). Set a review date and a list of triggers: new data, a new purpose, a new vendor, a new country, a new technology. In California, a risk assessment is reviewed at least once every three years and updated within 45 calendar days of a material change (§ 7155(a)).

Sources: GDPR, Articles 28, 35 and 36, EUR-Lex; Guidelines on DPIA (WP248 rev.01); CCPA Regulations, §§ 7151 and 7155.

Checklist

• Screening recorded (Article 35(3) and (4), the nine criteria, § 7150(b)), with reasons where no DPIA is done
• Systematic description, with a data-flow diagram
• Legal basis, data needed, retention, notices and rights for each purpose
• Risks to people, each with likelihood and severity
• Measures for each risk, and the risk that remains
• DPO advice recorded; people concerned consulted where appropriate; processors' input
• Decision to proceed recorded; prior consultation where Article 36(1) requires it
• Measures assigned to owners with dates
• Review date and triggers set

Questions people ask

How long does a DPIA take? The law sets no duration; it depends on the scope. In our view, a single product feature with known vendors needs far less work than a new platform with many data sources, and starting at the design stage is quicker than assessing a finished system.

Can we use a template? Yes. The European DPIA guidelines list methodologies published by several national authorities (Annex 1 of the guidelines). A template helps only if the description in step 2 is specific to the project.

Does a vendor's DPIA cover us? No. The controller carries out the DPIA. A vendor's own assessment, security documents and answers are inputs to yours, and a processor must assist (Article 28(3)(f)).

Do we publish the DPIA? The GDPR does not require it. The European DPIA guidelines suggest that controllers consider publishing at least parts of it, such as a summary or the conclusion.

Update log

• 16 October 2026: first published; sources checked and citations added the same day.