A Data Protection Impact Assessment (DPIA) is a structured risk assessment required by GDPR Article 35 before you start any processing that is “likely to result in a high risk to the rights and freedoms of natural persons.” You must complete it before processing begins. Article 35(3) lists three cases where a DPIA is always mandatory; EDPB-endorsed guidance adds nine risk criteria, and meeting two or more usually means you need one.
What you get below: a plain-English trigger checklist, a copy-paste template mapped to Article 35(7), and a step-by-step method. If you would rather have it facilitated, see our GDPR audit services.
Key takeaways
- Article 35(3) sets three automatic triggers: large-scale profiling with significant effects, large-scale processing of special-category (Art. 9) or criminal (Art. 10) data, and systematic monitoring of a public area. Meet one, and a DPIA is mandatory.
- The EDPB nine criteria are the practical test. They originate in WP248 rev.01 from the Article 29 Working Party (endorsed by the EDPB); processing that meets two or more usually requires a DPIA.
- Article 35(7) fixes the minimum contents: systematic description, necessity and proportionality, risk assessment, and mitigating measures — with mandatory DPO advice under Article 35(2).
- Skipping a required DPIA is an Article 83(4) lower-tier fine (up to EUR 10M / 2% of worldwide turnover), not the EUR 20M / 4% tier that applies to core-principle breaches.
What is a Data Protection Impact Assessment (DPIA)?
A DPIA is a documented process for identifying and minimising the data-protection risks of a project before you build or launch it. Its legal basis is Article 35 GDPR, which requires the controller to carry out an assessment of the impact of the envisaged processing operations on the protection of personal data where that processing is likely to result in a high risk to individuals. Recitals 84, 90, and 91 frame it as an accountability instrument for high-risk processing.
A DPIA is not the same thing as your data inventory. Below are the terms you will see used interchangeably online — they are distinct legal instruments.
- DPIA (Data Protection Impact Assessment)
- An Article 35 risk assessment, triggered only when processing is likely to be high-risk, owned by the controller with DPO advice.
- ROPA (Records of Processing Activities)
- An Article 30 standing inventory of processing activities that most organizations must keep regardless of risk. It feeds the DPIA but is a separate obligation.
- Controller vs processor
- The controller determines the purposes and means of processing and owns the DPIA; the processor acts on the controller's instructions (typically your vendors and subprocessors).
- Special category data (Art. 9)
- Health, biometric, genetic, racial or ethnic origin, political, religious, sex-life, and similar sensitive data attracting extra protection.
- Residual risk
- The risk to rights and freedoms that remains after your planned mitigations. High residual risk triggers Article 36 prior consultation.
For a broader map of who counts as a controller or processor and when EU territorial scope reaches a US company, see GDPR obligations for US SaaS companies.
When do you need a DPIA? The Article 35 triggers
There are three layers to the “when” question: the three mandatory cases in Article 35(3), the EDPB nine-criteria rule of thumb, and the national supervisory-authority mandatory lists. Work through all three — any one of them can compel a DPIA.
The three mandatory cases in Article 35(3)
Article 35(3) names three types of processing that always require a DPIA:
- Art. 35(3)(a) — a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person (this links to Article 22 automated decision-making). Example: an AI feature that scores users to gate access to a product tier or a loan.
- Art. 35(3)(b) — processing on a large scale of special categories of data (Article 9) or personal data relating to criminal convictions and offences (Article 10). Example: a healthtech platform processing patient health records at scale.
- Art. 35(3)(c) — systematic monitoring of a publicly accessible area on a large scale. Example: a smart-camera or location-analytics product deployed across public venues.
Healthtech readers processing health data as an Art. 9 special category should also review their overlapping US obligations in our HIPAA compliance guidance — the same dataset often triggers both regimes.
The EDPB nine criteria and the “two or more” rule
Because Article 35(3) is not exhaustive, the Article 29 Working Party published WP248 rev.01 (later endorsed by the EDPB) setting out nine criteria for identifying high-risk processing. As a rule of thumb, processing that meets two or more criteria will usually require a DPIA; a single criterion may be enough in some cases. You may still conclude no DPIA is needed, but you must document that justification.
| # | Criterion | What it means | B2B SaaS / healthtech example |
|---|---|---|---|
| 1 | Evaluation or scoring | Profiling and predicting behaviour, performance, or preferences | Risk-scoring users; usage-based churn prediction |
| 2 | Automated decision-making with legal or similar effect | Decisions that affect access to a service or contract | Auto-approving or denying accounts or credit |
| 3 | Systematic monitoring | Observing, tracking, or controlling data subjects | Employee productivity monitoring; session tracking |
| 4 | Sensitive or highly personal data | Art. 9/10 data or data revealing intimate details | Health, mental-wellness, or financial records |
| 5 | Data processed on a large scale | High volume, wide range, long duration, or geography | Millions of end-user accounts across the EU |
| 6 | Matching or combining datasets | Merging data from separate operations or sources | Enriching CRM records with third-party data |
| 7 | Vulnerable data subjects | Children, employees, patients, or asymmetric relationships | Products aimed at children or patients |
| 8 | Innovative use / new technology | Applying new technical or organisational solutions | Generative-AI features; new biometric login |
| 9 | Preventing exercise of a right / use of a service | Processing that blocks a right, service, or contract | Automated denial of onboarding or benefits |
National DPA mandatory lists (and EU vs UK divergence)
Under Article 35(4), every supervisory authority must publish a list of processing operations subject to a mandatory DPIA — the “blacklist.” Under Article 35(5) they may also publish an optional “whitelist” of operations needing no DPIA. The EDPB issued consistency opinions on the draft lists of the supervisory authorities to align them, but the lists still differ by member state. If you operate in more than one country, you must check each relevant DPA's list.
| Authority (regime) | Example listed processing | Where to find the list |
|---|---|---|
| CNIL — France (EU GDPR) | 14-item list, e.g. large-scale health data, biometric identification of vulnerable people, profiling affecting access to a contract | cnil.fr deliberation on mandatory-DPIA processing |
| DPC — Ireland (EU GDPR) | List including large-scale profiling, tracking location/behaviour, processing biometric data to identify individuals | dataprotection.ie DPIA guidance |
| ICO — United Kingdom (UK GDPR) | Own 10-item high-risk list (see below) that extends beyond the EDPB nine | ico.org.uk DPIA guidance |
EU vs UK — do not treat them as one regime. The ICO's guidance and template are built for UK GDPR, which has diverged from EU GDPR following the Data (Use and Access) Act 2025 (and the earlier DPDI proposals). CNIL and the EDPB are your EU GDPR references. A US SaaS company selling into both markets must satisfy the relevant EU lead supervisory authority for EU processing and the ICO for UK processing — so label every template by the regime it belongs to.
The ICO also publishes its own high-risk list under UK GDPR that goes further than the EDPB nine: biometric data, genetic data, data matching, invisible processing (where Art. 14 notice is not feasible), tracking geolocation or behaviour, profiling children for marketing, denial of service based on automated decisions, and combining any “European guidelines” criterion with biometric or genetic data. Even for EU-only processing, it is a useful sanity check.
When you do NOT need a DPIA (and how to document it)
Low-risk processing does not require a DPIA. If your screening shows fewer than two EDPB criteria, no Article 35(3) case, and no national blacklist hit, you can decline — but record the screening decision and reasoning so you can evidence accountability. There is also a narrow exemption in Article 35(10): a separate DPIA is not required where processing under Art. 6(1)(c) or (e) has a legal basis in EU or member-state law and a DPIA was already carried out as part of a general impact assessment when that law was adopted — “unless Member States deem it necessary to carry out such an assessment prior to processing activities.”
DPIA decision matrix: the screening questions to run first
Before drafting anything, run a threshold assessment. Our screening questionnaire below maps each question to its trigger so the outcome is defensible. If any row returns “Mandatory” or you hit two or more EDPB criteria, do the DPIA.
| Trigger source | Condition | SaaS / healthtech example | DPIA outcome |
|---|---|---|---|
| Art. 35(3)(a) | Systematic profiling with legal / similar significant effect | AI scoring that gates product access | Mandatory |
| Art. 35(3)(b) | Large-scale Art. 9 / Art. 10 data | Patient health records at scale | Mandatory |
| Art. 35(3)(c) | Large-scale systematic monitoring of a public area | Location analytics across venues | Mandatory |
| EDPB nine criteria | Two or more criteria met | Innovative AI + scoring of users | Likely required |
| National blacklist | Processing appears on the relevant DPA's Art. 35(4) list | Biometric login in France (CNIL) | Mandatory |
| Single EDPB criterion | Only one criterion met | Standard analytics on a small user base | Screen & document |
| No triggers | Low-risk, routine processing | Internal contact database | Screen & document (no DPIA) |
A 10-question screening questionnaire — yes/no items covering profiling, special-category data, large scale, monitoring, children, new technology, matching, and denial of service — is included in the downloadable template so product managers can run it in minutes.
What a DPIA must contain — Article 35(7)
Article 35(7) sets the minimum content of every DPIA. Map each requirement to a section of your template and attach concrete evidence — this is what makes a DPIA defensible if a regulator asks to see it.
| GDPR requirement | What the regulation asks | Template section | Evidence to attach |
|---|---|---|---|
| Art. 35(7)(a) | Systematic description of the processing operations and purposes (incl. legitimate interest where relevant) | 1. Processing description & purposes | Data-flow diagram, ROPA extract, system inventory |
| Art. 35(7)(b) | Assessment of necessity and proportionality relative to the purposes | 2. Necessity & proportionality test | Data-minimisation notes, retention schedule, lawful basis |
| Art. 35(7)(c) | Assessment of the risks to rights and freedoms of data subjects | 3. Risk register (likelihood × severity) | Scored risk table, threat model |
| Art. 35(7)(d) | Measures envisaged to address risks, incl. safeguards, security, and protection mechanisms | 4. Mitigations & residual risk | Security controls, DPA clauses, encryption / access evidence |
| Art. 35(2) | Seek the advice of the DPO where one is designated | 5. DPO advice | DPO opinion, review date |
| Art. 35(9) | Seek the views of data subjects where appropriate | 6. Stakeholder / data-subject views | Survey, consultation notes, or documented rationale for omission |
For Art. 35(7)(d) technical measures, you can often map security safeguards you already evidence for SOC 2 — access controls, encryption, change management, and logging — instead of building a parallel control set.
Free GDPR DPIA template (copy/paste)
The field-by-field template below satisfies Article 35(7). Copy it into a document, complete each field, and keep it as a living record. A formatted Word / Google Doc version with the embedded screening questionnaire is available on request from our GDPR team. For comparison, the two canonical free public templates are the ICO sample DPIA template (UK GDPR) and the CNIL open-source PIA software, currently v3.0 (EU GDPR) — both linked in Sources.
| Section | Fields to complete |
|---|---|
| 0. Screening & threshold | Screening date; triggers met (Art. 35(3) case / EDPB criteria count / national list hit); DPIA required Y/N; rationale |
| 1. Processing description & purposes | Project name; purposes; nature, scope, context; data flows; systems and subprocessors; lawful basis (Art. 6) and any Art. 9 condition |
| 2. Data categories & subjects | Categories of personal data; special categories; volume; categories of data subjects; retention period |
| 3. Necessity & proportionality | Why the data is necessary; minimisation measures; purpose limitation; data-subject rights mechanisms; international transfers and safeguards |
| 4. Risk register | Each risk to rights and freedoms; likelihood (1–4); severity (1–4); inherent risk band |
| 5. Mitigations & residual risk | Measure for each risk; owner; residual likelihood/severity; residual risk band; accept / mitigate / prior consultation |
| 6. DPO advice (Art. 35(2)) | DPO opinion; agreement / disagreement recorded; date |
| 7. Data-subject views (Art. 35(9)) | Whether views were sought; method; outcome or documented rationale for not seeking them |
| 8. Sign-off & review | Decision to proceed; approver and role; date; scheduled review date; Art. 36 prior consultation Y/N |
Worked example — AI-based user scoring (SaaS)
A filled excerpt for a feature that scores users to prioritise support and gate a premium tier. This is the kind of populated risk register regulators and AI engines actually quote.
| Risk | Likelihood | Severity | Mitigation | Residual band |
|---|---|---|---|---|
| Discriminatory scoring against a protected group | 3 | 4 | Bias testing; feature exclusion of proxies; human review of adverse decisions (Art. 22) | Medium |
| Opaque logic — data subject cannot contest | 3 | 3 | Meaningful information about the logic; contest and human-review route | Low |
| Cross-border transfer of scoring data to US | 3 | 3 | Assess transfer risk (SCCs / adequacy); data localisation option | Medium |
| Subprocessor over-retention of training data | 2 | 3 | Record processor obligations in a GDPR-compliant DPA; retention limits | Low |
How to complete a DPIA, step by step
Run the DPIA as an ordered sequence. Each step produces an artifact that maps to a template section.
- Screen (threshold assessment). Run the questionnaire against Art. 35(3), the EDPB nine criteria, and the relevant national list. Record whether a DPIA is required.
- Describe the processing. Document purposes, data flows, categories of data and subjects, systems, and subprocessors (Art. 35(7)(a)).
- Assess necessity and proportionality. Justify each data element against the purpose; apply data minimisation, purpose limitation, and retention limits (Art. 5, Art. 35(7)(b)).
- Identify and score risks. Build the risk register, scoring likelihood × severity for each risk to rights and freedoms (Art. 35(7)(c)).
- Define mitigations. Assign a measure and owner to each risk; recompute residual risk (Art. 35(7)(d)).
- Seek DPO advice. Obtain and record the DPO's opinion (Art. 35(2)); seek data-subject views where appropriate (Art. 35(9)).
- Sign off. The controller decides to proceed and an accountable owner signs before processing starts.
- Prior consultation if needed. If high residual risk remains, consult the supervisory authority under Art. 36 before processing.
- Review. Treat the DPIA as a living document; reassess when the processing, risk, or technology changes.
Risk scoring rubric (likelihood × severity)
| Likelihood (1–4) | Severity to data subjects (1–4) | Residual risk band | Required action |
|---|---|---|---|
| 1–2 | 1–2 | Low | Proceed; document |
| 2–3 | 2–3 | Medium | Mitigate, then proceed |
| 3–4 | 3–4 | High (after mitigation) | Prior consultation under Art. 36 before processing |
| 3 (example) | 4 (example) | Medium after mitigation | Proceed with documented bias controls and human review |
Roles, ownership, and sign-off
The controller is legally responsible for the DPIA; the DPO advises and monitors (Art. 35(2)). In practice the work is shared across product, security, and legal. A simple RACI keeps ownership clear.
| Task | Product / Eng | Security | DPO | Privacy counsel | Exec sponsor |
|---|---|---|---|---|---|
| Screening | R | C | A | C | I |
| Drafting description | R | C | C | C | I |
| Risk scoring | C | R | A | C | I |
| Mitigation design | R | R | C | C | I |
| Sign-off | I | I | C | C | A/R |
| Prior consultation | I | C | R | A | I |
| Review cadence | C | C | A/R | C | I |
R = Responsible, A = Accountable, C = Consulted, I = Informed.
Article 36 prior consultation
Article 36(1) requires you to consult the supervisory authority before processing when the DPIA indicates the processing would result in a high risk in the absence of measures to mitigate it. Under Article 36(2), the authority provides written advice within up to eight weeks of the request, extendable by a further six weeks for complex processing, with notice of any extension within one month. Note the clock only runs once the authority has the information it needs — under Art. 36(3) it can request further information, which resets expectations. The authority can order changes or prohibit the processing entirely.
Prior consultation is the exception, not the rule: most DPIAs mitigate residual risk to an acceptable level and never reach the regulator. Design your mitigations to avoid it.
DPIA vs ROPA vs data map vs LIA
These documents are routinely confused. They have different legal triggers, owners, and outputs — and you may need several.
| Instrument | GDPR article | When required | Owner | Output |
|---|---|---|---|---|
| DPIA | Art. 35 | Only for likely high-risk processing | Controller (DPO advises) | Risk assessment & mitigations |
| ROPA | Art. 30 | Standing obligation for most organizations | Controller / processor | Inventory of processing activities |
| Data inventory / map | Supporting (Art. 30 / 35) | Whenever you need to know your data flows | Data / security team | Data-flow diagrams |
| Legitimate Interests Assessment | Art. 6(1)(f) | When relying on legitimate interests as lawful basis | Controller | Balancing test |
Integrating DPIAs into product and security workflows
The controllers who do this well treat the DPIA as part of data protection by design and by default (Article 25), not a compliance afterthought. Wire the screening questionnaire into your product intake so any new feature touching personal data is triaged automatically. When a DPIA is needed, reuse artifacts you already maintain: the ROPA feeds the processing description, and your existing security control evidence satisfies most of Art. 35(7)(d).
This is where audit and privacy programs converge. If you already run a SOC 2 program, the access controls, encryption, logging, and change-management evidence you produce for the Trust Services Criteria can be attached directly to a DPIA's mitigations section — one evidence set, two purposes. Keep the DPIA a living document and reassess when the processing, risk profile, or technology changes.
Tool or template? GRC platforms (Vanta, Secureframe, OneTrust) automate DPIA workflows and are worth it once you run many assessments per year. For a handful of DPIAs, the copy-paste template plus DPO review is enough — and a CPA-firm-facilitated DPIA sits usefully between the two, giving you an independently reviewed assessment without standing up a platform.
Common DPIA mistakes
These are DPIA-specific failure modes we see repeatedly — not generic compliance advice.
- Treating the DPIA as a one-off. Article 35 expects reassessment when risk changes. A DPIA filed once and never revisited is stale the moment the feature evolves.
- No residual-risk analysis. Listing mitigations without recomputing residual likelihood and severity means you cannot tell whether Art. 36 prior consultation is triggered.
- Skipping DPO advice. Art. 35(2) makes DPO consultation mandatory where one is designated; omitting it is a documented gap.
- Ignoring data-subject views. Art. 35(9) expects you to seek stakeholder views where appropriate — or record why you did not.
- Missing national blacklist obligations. Relying on the EDPB nine criteria alone and not checking the relevant DPA's Art. 35(4) list, or conflating the ICO's UK list with EU requirements.
- Doing the DPIA after launch. Article 35(1) requires it prior to processing. A retrospective DPIA does not cure the breach.
Frequently asked questions
When is a DPIA required under GDPR?
A DPIA is mandatory under GDPR Article 35(1) whenever processing is likely to result in a high risk to individuals' rights and freedoms. Article 35(3) always requires one for large-scale profiling with significant effects, large-scale processing of special-category or criminal data, or systematic monitoring of a public area. EDPB-endorsed guidance adds that meeting two or more of its nine criteria usually triggers a DPIA.
What must a GDPR DPIA contain?
Under Article 35(7), a DPIA must contain at minimum a systematic description of the processing and its purposes, an assessment of the necessity and proportionality of that processing, an assessment of the risks to data subjects' rights and freedoms, and the measures, safeguards, and security controls envisaged to address those risks. The DPO must be consulted under Article 35(2).
What is the difference between a DPIA and a Record of Processing Activities (ROPA)?
A ROPA under Article 30 is a standing inventory of all processing activities most organizations must maintain regardless of risk. A DPIA under Article 35 is a risk assessment triggered only when processing is likely to be high-risk. The ROPA and data map feed the DPIA, but they are separate documents with different legal triggers and owners.
When must you consult the supervisory authority about a DPIA?
Under Article 36, prior consultation with the supervisory authority is required when a completed DPIA shows the processing would still be high-risk even after planned mitigations. The authority provides written advice within up to eight weeks of the request, extendable by a further six weeks for complex cases, and can order changes or ban the processing.
Is a DPIA mandatory for every company?
No. A DPIA is only required when processing is likely to result in a high risk to individuals, per Article 35. Low-risk processing does not need one, though controllers should document the screening decision. National supervisory authorities such as CNIL in France and the ICO in the UK also publish mandatory-DPIA lists that can compel one regardless of the controller's own assessment.
Who is responsible for completing a DPIA?
The data controller is legally responsible for carrying out the DPIA. Under Article 35(2) it must seek the advice of its Data Protection Officer where one is designated. In practice product, engineering, and security teams supply inputs, the DPO or privacy counsel reviews, and an executive sponsor signs off before processing begins.
Does the ICO DPIA template work for EU GDPR?
The ICO's DPIA template is built for UK GDPR, which has diverged from EU GDPR after the Data (Use and Access) Act 2025. Its structure maps cleanly to EU Article 35(7), so it is a useful starting point, but for an EU-facing DPIA you should align to CNIL and EDPB guidance and satisfy the relevant EU lead supervisory authority.
What is the fine for failing to do a required DPIA?
Failing to carry out a required DPIA or to seek prior consultation falls in the lower fine tier under Article 83(4): up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. The higher EUR 20 million / 4% tier under Article 83(5) applies to breaches of core principles and data-subject rights, not to the DPIA obligation itself.
Sources & further reading
- EU GDPR — Article 35, Data protection impact assessment (Regulation (EU) 2016/679), and Article 36, Prior consultation; fine tiers at Article 83.
- Article 29 Working Party (endorsed by the EDPB) — Guidelines on Data Protection Impact Assessment (DPIA), WP248 rev.01, setting out the nine high-risk criteria.
- ICO (UK GDPR) — Data protection impact assessments guidance and its sample DPIA template (.docx).
- CNIL (EU GDPR) — Privacy Impact Assessment (PIA) methodology and free open-source PIA software (v3.0).
Reviewed by Sébastien Ruosch, CPA (US & Swiss licensed), Director of Audits at Auditsuisse. This article is general information, not legal advice; consult a Data Protection Officer or privacy counsel for your specific processing. Last reviewed July 1, 2026.
Need help running or reviewing a DPIA?
Auditsuisse helps US-first SaaS and healthtech teams scope, run, and independently review DPIAs, mapping the security safeguards you already evidence to Article 35(7) — see our GDPR audit services or book a call.
Request Consultation