DPIA checklist: when a Data Protection Impact Assessment is required (GDPR Art. 35)
5 min read
A Data Protection Impact Assessment (DPIA) is a documented process for identifying and minimising the data-protection risks of a project, required by GDPR Art. 35 whenever processing is “likely to result in a high risk to the rights and freedoms of natural persons.” You run it before the processing starts, and it must describe the processing, assess its necessity and proportionality, evaluate the risks, and set out the measures that bring those risks down. This checklist covers when a DPIA is mandatory and what a compliant one must contain.
TL;DR
- A DPIA is mandatory when processing is likely to result in a high risk — GDPR Art. 35(1).
- Art. 35(3) names three automatic triggers; the EDPB (WP248) nine-criteria list helps you judge the rest. Two or more criteria usually means “do a DPIA.”
- Art. 35(7) fixes the four required contents: description, necessity/proportionality, risk assessment, and mitigating measures.
- Involve your DPO (Art. 35(2)) and, if high residual risk remains, consult your supervisory authority (Art. 36).
- Anonymization and data minimisation are among the strongest mitigations — they shrink or remove the personal data whose risk you would otherwise have to carry.
When is a DPIA required?
Run a DPIA whenever processing is likely to result in a high risk. Art. 35(3) makes it automatic for three cases:
- Systematic and extensive evaluation based on automated processing, including profiling, that produces legal or similarly significant effects.
- Large-scale processing of special-category data (Art. 9) or of criminal-offence data (Art. 10).
- Systematic monitoring of a publicly accessible area on a large scale.
Beyond those, the EDPB guidelines (WP248 rev.01) give nine criteria. As a rule of thumb, if your processing hits two or more, do a DPIA:
- Evaluation or scoring (including profiling)
- Automated decision-making with legal or significant effect
- Systematic monitoring
- Sensitive data or highly personal data
- Data processed on a large scale
- Matching or combining datasets
- Data about vulnerable subjects (children, employees, patients)
- Innovative use of new technology (e.g. AI, IoT)
- Processing that itself prevents subjects from exercising a right or using a service
What a compliant DPIA must contain — Art. 35(7)
A DPIA is not a form; it is a reasoned document. Art. 35(7) requires at minimum:
| Required element | What it means in practice |
|---|---|
| (a) Systematic description | What data, whose, why, how, where it flows, how long you keep it |
| (b) Necessity & proportionality | Do you actually need all of it for the purpose? Could less do the job? |
| (c) Risk assessment | Concrete risks to individuals’ rights and freedoms, and their likelihood/severity |
| (d) Mitigating measures | Safeguards and controls that reduce each risk to an acceptable level |
The step-by-step DPIA checklist
- Describe the processing. Map data categories, subjects, purposes, recipients, transfers, and retention. Draw the data flow.
- Confirm the trigger. Record which Art. 35(3) case or WP248 criteria apply, and why a DPIA is needed (or, if not, document that screening decision).
- Consult your DPO. Art. 35(2) requires you to seek the DPO’s advice; record it.
- Assess necessity and proportionality. Justify the lawful basis, the purpose limitation, and — crucially — data minimisation. Can any field be dropped, aggregated, pseudonymised, or anonymized?
- Identify and rate the risks. For each risk to individuals (not to the business), estimate likelihood and severity.
- Choose mitigations. Technical and organisational measures: access control, encryption, retention limits, pseudonymization, and anonymization of data you don’t need in identifiable form.
- Assess residual risk. If high risk remains after mitigation, consult the supervisory authority before processing (Art. 36).
- Sign off, act, and review. Implement the measures, keep the DPIA as an accountability record (Art. 5(2)), and revisit it when the processing changes.
How anonymization changes the risk you have to assess
The cheapest way to pass step 5 is to have less to protect at step 4. If a purpose can be met with anonymized data, that data leaves the scope of the GDPR entirely (see does GDPR apply to anonymized data) — there is no personal-data risk left to assess for it.
Where you do need identifiable data, masking the fields you don’t strictly need — names, national IDs, contact details — cuts both the likelihood and the severity of a breach. Before feeding records to an AI model or an analytics tool, redacting PII locally is a textbook Art. 35(7)(d) mitigation:
Before (high risk — full identifiers to a third-party tool):
Jan Kowalski, 85010212345, +48 601 234 567, diagnosis: ...
After (mitigated — masked before it leaves your device):
[PERSON], [PESEL], [PHONE], diagnosis: ...FAQ
Who is responsible for the DPIA? The controller. Where a DPO is appointed, the controller must seek their advice (Art. 35(2)), but accountability for the DPIA sits with the controller.
When exactly must the DPIA be done? Before the processing begins — a DPIA is a prior assessment. It should then be reviewed whenever the risk profile of the processing changes.
What happens if residual risk is still high? You must consult your supervisory authority under Art. 36 before starting, and follow any advice or conditions they give.
Does using AI on personal data always need a DPIA? Not automatically, but “innovative use of new technology” is a WP248 criterion, and AI often combines with profiling, large scale, or sensitive data — so two-or-more criteria are common. Screen it properly.
Can anonymization remove the need for a DPIA? If the processing genuinely uses only anonymized data, that data is outside the GDPR and doesn’t count toward the high-risk assessment. Mixed processing still needs screening for the identifiable parts.
Amaze masks personal data — names (including Polish inflected forms), PESEL, NIP, REGON, KRS, emails, phones, IBANs and more — locally on your own machine, and produces an audit report your DPO can attach to the DPIA as evidence of the mitigation. See how it works.
Part of our complete guide to data anonymization.