DPIA checklist: when GDPR Article 35 requires one

A DPIA checklist is the practical bridge between an abstract legal obligation — “carry out a Data Protection Impact Assessment when processing is likely to result in a high risk” — and a deliverable a regulator will accept. GDPR Article 35 has been in force for eight years now, and the question that still trips up most engineering teams and DPOs is not how to fill the template. It is the prior, deceptively simple question: do we actually need one for this project?

This post answers that question with a decision-aligned checklist, walks through the European Data Protection Board’s nine high-risk criteria, surfaces where national supervisors (CNIL, AP, Garante) have added their own mandatory categories, and provides a 9-step assessment template you can lift into your own documentation. It is scoped to EU controllers operating websites and SaaS products — the kind of organisation our analysis of GDPR fines for small businesses covers.

When is a DPIA mandatory under GDPR?

Article 35(1) of the General Data Protection Regulation sets the legal trigger: a Data Protection Impact Assessment is required where a processing operation, “in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons.” The text is purposefully open-ended. To make it operational, three sources of concrete guidance overlap.

Article 35(3) lists three cases that are always mandatory: systematic and extensive automated decision-making with legal or similarly significant effect on the individual; large-scale processing of special-category or criminal-conviction data; and systematic monitoring of publicly accessible areas on a large scale. Those three were not exhaustive, by design.

The EDPB then layered on Working Party 29 Guidelines WP248rev.01 — endorsed by the Board on its first plenary — which set out nine criteria that, taken together, indicate high-risk processing. As a rule of thumb, two or more criteria make a DPIA appropriate; a single criterion can be enough where the potential impact is severe.

Finally, each national supervisory authority publishes a list under Article 35(4) of processing operations that always require a DPIA in its jurisdiction. The French CNIL, the Dutch Autoriteit Persoonsgegevens and the Italian Garante all maintain such lists, and the contents diverge meaningfully across member states.

The EDPB nine-criteria decision filter

Run any new processing operation against the nine EDPB criteria. If two or more apply, the default answer is “DPIA required”. If only one applies but the potential impact is severe, document the reasoning and lean towards conducting the assessment — the cost of being wrong is asymmetric.

1. Evaluation or scoring, including profiling and predicting behaviour, performance, or preferences.
2. Automated decision-making with legal or similarly significant effect on the individual.
3. Systematic monitoring of data subjects, including via publicly accessible spaces or covert tracking.
4. Sensitive data or data of a highly personal nature — special categories under Article 9, plus location, financial, and communications metadata.
5. Data processed on a large scale, measured by number of subjects, volume, geographic spread, duration, or permanence.
6. Matching or combining datasets originating from different processing operations or controllers.
7. Data concerning vulnerable data subjects — children, employees, patients, asylum seekers, the elderly.
8. Innovative use or applying new technological or organisational solutions — AI-based features, biometric authentication, IoT deployments.
9. Processing that itself prevents data subjects from exercising a right or using a service or contract.

A SaaS product running behavioural analytics on logged-in users, profiling them into retention segments, will hit criteria 1, 3, and 5 in a single sweep. The threshold is well met. Compare that with a payroll database with role-based access and standard safeguards: zero criteria typically apply, and a DPIA is not needed.

National additions — when one country adds what the EDPB did not

The Article 35(4) national blacklists matter because they often catch processing that the EDPB nine criteria leave ambiguous. Three examples illustrate the variance:

• The CNIL treats any processing for the management of internal alerts and whistleblowing reports as mandatory-DPIA, regardless of size — see the CNIL DPIA guidelines for the current French list of 14 categories.
• The Autoriteit Persoonsgegevens (Netherlands) lists camera surveillance of employees and credit-scoring beyond payment defaults as always requiring a DPIA.
• The Garante (Italy) names systematic monitoring of workplace email and internet use as inherently high-risk.

If your processing touches any member state on a national list, the national obligation prevails over your headquarters’ lighter posture. A controller established in Ireland that monitors French employees still owes a DPIA under the CNIL list when the processing covers French data subjects. The same logic applies in reverse — operating from France does not exempt you from the Garante’s whistleblowing-specific expectations if Italian staff are in scope.

When you do not need a DPIA

Article 35(10) and the EDPB guidelines also describe carve-outs. Processing carried out on the basis of a legal obligation or task in the public interest, where a DPIA was conducted as part of the legislative process, does not need a separate one. National supervisors may also publish “whitelists” under Article 35(5) — kinds of processing that, in their view, are unlikely to result in a high risk. These are rare and narrow; do not lean on them for a borderline call.

A more practical filter for SMBs: routine processing whose risks are well understood and whose safeguards are standard (a payroll database, a CRM with role-based access, a customer-support inbox with documented retention) does not require a DPIA. Documenting why no DPIA is needed — in a short memo on file — is itself a defensible compliance artefact when a regulator asks. “We considered the nine EDPB criteria, none applied, here is the reasoning” beats silence every time.

A 9-step DPIA template

The structure below maps directly to Article 35(7) and the EDPB acceptability criteria. It is the template our internal assessments use, condensed.

1. Project description. Purpose, controller and processors, data sources, recipients, retention, cross-border transfers. Link to the corresponding Article 30 records of processing so the DPIA does not duplicate that documentation.
2. Necessity and proportionality assessment. Why is the processing needed? Could the purpose be achieved with less data, or with pseudonymised data? What is the lawful basis under Article 6, and the additional condition under Article 9 if special-category data is involved?
3. Data flow mapping. Diagram every system, third party, and storage location the data passes through. List the categories of data at each stop. This is also where most teams discover an undocumented sub-processor.
4. Risk identification. Enumerate threats to rights and freedoms — discrimination, financial loss, reputational damage, identity theft, loss of control over personal data, unauthorised re-identification of pseudonymised records.
5. Likelihood and severity rating. Score each risk on a defensible scale (low / medium / high for both axes) with written reasoning. A guess in a table is worse than no table.
6. Mitigation measures. Technical (encryption at rest and in transit, pseudonymisation, access controls, audit logging) and organisational (training, processor contracts under Article 28, retention enforcement, incident-response runbooks).
7. Residual risk assessment. After mitigations, re-score. If residual risk remains high on any axis, escalate to step 9.
8. Consultation record. Include the DPO’s opinion under Article 39(1)(c), input from affected stakeholders or their representatives where appropriate under Article 35(9), and the date the assessment was completed.
9. Prior consultation decision. If residual risk remains high, Article 36 requires consulting the supervisory authority before processing begins. The DPA has eight weeks (extendable by six) to respond.

The DPIA is a living document, not a one-time deliverable. Material changes to the processing — a new sub-processor, a change in retention, a new geography, a new feature — trigger a review, not a fresh assessment from scratch. Most teams underweight this maintenance obligation, which is why the original DPIA goes stale within 18 months and the regulator sees mismatched paperwork at the first audit.

A practical next step

Most websites that need a DPIA also have unresolved cookie consent or accessibility gaps that the DPIA itself will surface during the data flow mapping in step 3. To get a fast read on the public-surface compliance posture of your site before drafting the DPIA, run a free audit on the Elgarde platform — the report covers ePrivacy consent handling, third-party tracker behaviour, and WCAG 2.1 AA accessibility, with each finding mapped to the article of the regulation that applies. For the canonical text, refer to GDPR Article 35 on EUR-Lex; the WP248rev.01 DPIA guidelines remain the European Data Protection Board’s primary working reference.