A Data Protection Impact Assessment (DPIA) under Article 35 GDPR is required whenever processing is likely to result in a high risk to the rights and freedoms of natural persons. The Article 29 Working Party (now EDPB) set out nine criteria — when two or more apply, do a DPIA.

A defensible DPIA has five stages: describe processing, assess necessity and proportionality, identify risks, identify mitigations, then formally sign off and schedule review. ICO methodology and EDPB Guidelines align tightly on this structure.

Done well, a DPIA is a product-shaping artefact — not a compliance ritual. It surfaces risk early and forces choices about data minimisation, retention, and access. The best DPIAs are completed before the first line of code.

Article 35(1) requires a DPIA where processing is "likely to result in a high risk." Article 35(3) lists three mandatory cases:

1. Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, which produces legal effects or similarly significant effects.
2. Processing on a large scale of special categories of data (Article 9) or criminal-conviction data (Article 10).
3. Systematic monitoring of a publicly accessible area on a large scale.

Most Supervisory Authorities publish national lists (Article 35(4)) of additional processing that always requires a DPIA. Check the lists of your lead SA and any SAs whose Member State residents you process.

Where it's unclear, run the nine-criteria test. Two or more = DPIA required.

1. Evaluation or scoring — profiling, behavioural analysis.
2. Automated decision-making with legal or similarly significant effect.
3. Systematic monitoring — observation of public area, employee monitoring, web tracking.
4. Sensitive or highly personal data — special categories, criminal data, but also financial, location, electronic communications.
5. Data processed on a large scale.
6. Matching or combining datasets — including from different controllers or for different purposes.
7. Data concerning vulnerable data subjects — children, employees, mentally ill, asylum seekers.
8. Innovative use or applying new technological or organisational solutions — AI, biometrics, IoT.
9. Prevents data subjects from exercising a right or using a service / contract.

The foundation of any DPIA is a precise description of what you actually do with data. Capture:

• Nature — categories of personal data, sources, recipients, retention, technical security, cross-border transfers.
• Scope — volume of data, number of data subjects, geographic and temporal extent.
• Context — nature of the relationship with data subjects, control they have, sensitivity of context (workplace, health).
• Purposes — what you're trying to achieve, intended outcomes, business value.

Pair this with a data-flow diagram. Free-text descriptions miss things data-flow diagrams catch.

• Lawful basis — Article 6(1)(a)–(f). If special category, also Article 9(2) condition.
• Less-intrusive alternatives considered — could you achieve the purpose with less data, anonymised data, aggregated data, or shorter retention?
• Purpose limitation — does each data category genuinely support the stated purpose?
• Data minimisation — explicit list of fields and a documented reason for each.
• Quality & accuracy — what mechanisms keep data current?
• Retention & deletion — exact periods, with the legal/business rationale.
• Information & rights — how do you inform data subjects and how do they exercise rights?

For each identifiable risk, document:

• Description of the risk (clear, plain language).
• Source of the risk.
• Likelihood of the threat materialising (low / medium / high).
• Severity of harm to data subjects (low / medium / high).
• Overall risk score.

Threat-types to cover routinely: unauthorised access (insider, external attacker), modification (integrity loss), loss (destruction, unavailability), discrimination, identity theft, financial loss, reputational damage, loss of confidentiality, loss of control over data, re-identification of pseudonymised data.

For each risk, identify the planned treatment:

• Accept — residual risk is acceptable. Document why and who approved.
• Reduce — controls applied (encryption, access management, training, retention reduction).
• Avoid — change the processing to remove the risk (use anonymised data instead, drop a feature).
• Transfer — contractual allocation (rare for primary risks; common for residual liability via insurance or vendor terms).

Re-score the residual risk after planned controls. If residual risk remains high, you must consult the Supervisory Authority before processing begins (Article 36).

• DPO advice (Article 35(2)) — the DPO must be consulted; the controller may depart from the advice but must document the reasoning.
• Stakeholder consultation — Article 35(9) recommends consulting data subjects or their representatives where appropriate.
• Sign-off authority — typically the data controller's senior accountable person (CISO, COO, or CEO for enterprise-critical processing).
• Publication — not required by GDPR, but ICO and many SAs recommend publishing redacted DPIA summaries as a trust signal.
• Review cycle — Article 35(11) requires review when there is a change of risk represented by the processing operations. Set a calendar review at minimum annually.

Article 36 prior consultation is required when, after applying mitigations, residual risk to rights and freedoms remains high.

SA receives:

• The DPIA itself.
• Responsibilities of controller and any joint controllers / processors.
• Purposes and means of intended processing.
• Measures and safeguards.
• Contact details of the DPO.
• Any other information requested by the SA.

SA response window: 8 weeks (extendable by 6 weeks for complex cases). Processing cannot begin during this period without authorisation.

Scenario: A logistics company plans to introduce facial-recognition based clock-in/clock-out for 4,500 warehouse workers across 12 sites in Germany and Spain.

Threshold test: Sensitive data (Article 9 biometric data for identification) + large scale + vulnerable subjects (employees) + innovative use = clear DPIA territory. German & Spanish SA lists also list biometric workplace identification as mandatory DPIA.

Description (Stage 1): Facial templates derived from front-facing camera at site entry; matched against enrolled template stored on a per-site appliance; matches logged with timestamp and worker ID; biometric templates retained for the period of employment + 30 days; matching logs retained 3 years.

Necessity (Stage 2): Lawful basis Article 6(1)(b) employment contract + 9(2)(b) employment law obligation (Germany) and explicit consent (Spain, with works council co-determination). Considered alternatives: PIN-card swipe (rejected — buddy-punching), badge with NFC (rejected — same), fingerprint (rejected — hygiene). Justified necessity of facial templates over alternatives.

Risks (Stage 3): (a) Centralisation of biometric templates creates honeypot for breach. (b) False non-match causing wage deduction. (c) Function creep — clock-in data used for performance evaluation. (d) Employee coercion: refusing biometric collection forced opt-out into worse conditions.

Treatment (Stage 4): (a) On-prem per-site appliance; templates encrypted with HSM-managed keys; no cloud copy. (b) Manual override workflow for non-match; payroll cannot deduct based solely on clock-in failure. (c) Contractual prohibition + technical separation between clock-in data and HR performance systems. (d) Genuine opt-out path (badge fallback) with no detriment, documented in works council agreement.

Sign-off: DPO advice obtained — recommended deletion of facial templates after 7 days post-employment instead of 30. Controller accepted. Works council co-determination obtained. Residual risk: medium-low. No SA consultation required.

• Skipping the threshold test. Done DPIA early; later realised they didn't need one. The opposite (didn't do one, enforcement uncovered need) is far worse.
• Treating necessity as a rubber-stamp. "Less-intrusive alternatives considered" is the section regulators read most carefully. Token mentions don't survive audit.
• Risk owner ambiguity. Risks without a named accountable person tend to remain untreated.
• Missing the data subject consultation step. Where appropriate (employees, large user base), Article 35(9) consultation strengthens defensibility.
• No residual risk re-scoring. If you don't re-score after treatment, you can't demonstrate whether Article 36 is triggered.
• Treating DPIA as a one-time artefact. Material changes (new data category, new processor, new jurisdiction, new purpose) re-trigger the assessment.
• Letting engineering complete the DPIA themselves. Privacy professional involvement is required by Article 35(2). Without it, the assessment lacks legal grounding.