
Free DPIA Template (2026) — GDPR Article 35, Word + PDF
DPIA template with screening questions, Art 35(7) sections, likelihood×severity risk matrix, AI annex and DPO sign-off. Free DOCX, no email gate.
Download this template
Version 1.0 · Updated Jul 15, 2026 · Free, no email required
DPIA Template: GDPR Article 35 Impact Assessment (Word, PDF & Markdown)
This free DPIA template gives you a complete, fourteen-section GDPR Article 35 data protection impact assessment: screening questions built on the three Article 35(3) cases and the nine WP248 rev.01 high-risk criteria, the four mandatory Article 35(7) content blocks, a likelihood×severity risk matrix, an AI-feature annex aligned with the EU AI Act, and a DPO sign-off with a review log. Download it as Word (DOCX), PDF, or a machine-readable Markdown file your privacy tooling can draft from.
A DPIA is the GDPR's before-you-build control: where processing is likely to result in a high risk to individuals — new technologies, profiling, large-scale special-category data — Article 35 requires the assessment prior to the processing, and skipping it is a standalone infringement in the EUR 10 million / 2% fine tier of Article 83(4)(a). With AI features now the fastest-growing DPIA trigger, most teams' real problem is not whether to assess but where to start. This template turns the legal structure into a fill-in document. For where the DPIA sits among your wider obligations, see the GDPR compliance pillar.
Key takeaways
- Screening comes first, and it is checklist-shaped. The three Article 35(3) always-DPIA cases plus the nine WP248 rev.01 criteria (rule of thumb: two criteria met → do the DPIA) make the "do we need one?" decision documentable in minutes — and documenting a no is as valuable as a yes.
- The law fixes the skeleton. Article 35(7)(a)–(d) mandates four content blocks — systematic description, necessity and proportionality, risk assessment, and mitigation measures. The template maps one section to each, so completeness is structural.
- Risk is assessed twice. First inherent risk (likelihood × severity per risk), then residual risk after measures. Only the residual score decides whether Article 36 prior consultation with the supervisory authority is triggered — the authority then has up to eight weeks (plus six for complex cases) to respond.
- AI features are the paradigm case. They routinely stack several high-risk criteria (new technology, scoring, automated decisions, scale). For high-risk AI systems under the EU AI Act, the Article 27 FRIA is a separate duty that can be documented jointly with the DPIA — the template's AI annex covers both.
- A DPIA is a living document. Article 35(11) requires a review at least when the risk changes; the template closes with a review log and the DPO's recorded advice (Article 35(2)), which is mandatory where a DPO is designated.
- The EDPB now has its own template — and it changes nothing about the law. Version 1.0 was adopted 10 March 2026 and published for consultation on 14 April 2026. Using it is voluntary for controllers, but supervisory authorities are expected to converge on it, so align your documentation with its structure (see below).
What's inside the template
The DOCX walks through fourteen sections; the heart is the four Article 35(7) blocks:
| Section | What you enter | Legal anchor |
|---|---|---|
| Screening questions | Article 35(3) cases + the nine WP248 criteria as yes/no checks | Art 35(1), 35(3); WP248 rev.01 |
| Systematic description | Nature, scope, context and purposes; data categories; recipients; retention; systems and data flows; legitimate interest if relied on | Art 35(7)(a) |
| Consultation record | DPO's advice (mandatory where designated), data subjects' views where appropriate, processors involved | Art 35(2), 35(9) |
| Necessity & proportionality | Lawful basis, data minimisation, transparency, storage limits, rights support | Art 35(7)(b) |
| Risk assessment | Risk register scored likelihood × severity against a 3×3 matrix | Art 35(7)(c) |
| Mitigation measures | Measure per risk: safeguards, security measures, mechanisms to demonstrate compliance | Art 35(7)(d) |
| Residual risk & Article 36 decision | Post-mitigation score; if still high → prior consultation with the authority before processing | Art 36 |
| Sign-off & review log | Controller approval, DPO opinion, review triggers and dates | Art 35(2), 35(11) |
Around the core assessment, the download includes:
- The AI-feature annex — extra prompts for AI/LLM processing (training data provenance, automated-decision effects, explainability, bias and accuracy risks) and a mapping note for combining the GDPR DPIA with the EU AI Act's Article 27 fundamental rights impact assessment in one document without either duty absorbing the other.
- A worked risk-matrix example — one completed risk row (unauthorised access to a customer-support AI log), so reviewers see what "done" looks like.
- The notify-your-authority reference — when Article 36 prior consultation applies and what to submit.
The Markdown variant carries the same fourteen sections with machine-readable field definitions and enums, so an AI agent or privacy platform can draft a first-pass DPIA from the file alone.
How to use it: from screening to sign-off
- Screen before you build. Run the screening checklist as soon as the processing is designed — Article 35(1) requires the assessment prior to the processing. If no trigger is met, keep the completed screening section as your documented reasoning.
- Describe the processing as it will actually run. Data categories, subjects, recipients, retention, international transfers, and the systems involved. Vague descriptions produce vague risk assessments — and they are the first thing a supervisory authority reads.
- Get the DPO in early, not at the end. Article 35(2) makes the DPO's advice mandatory where one is designated; the template records it as a standing section rather than a signature afterthought.
- Score honestly, mitigate specifically. Each risk gets a likelihood and severity score, a named mitigation measure, and a residual score. Generic measures ("we take security seriously") do not reduce scores; specific ones (Article 32 TOMs, access controls, pseudonymisation, retention cuts) do.
- Decide the Article 36 question explicitly. If high residual risk remains, you must consult your supervisory authority before processing starts and wait for its advice — up to eight weeks, extendable by six. Most DPIAs never reach this step, but the template forces the decision to be recorded either way.
- Schedule the review. Article 35(11) requires a fresh look at least when the risk changes — a new data category, a new AI model, a new recipient. The review log keeps the DPIA alive instead of archived.
The legal basis behind each section
- GDPR Article 35 creates the duty (35(1)), fixes the three always-DPIA cases (35(3)(a)–(c)), mandates the four content blocks (35(7)(a)–(d)), requires the DPO's advice (35(2)) and the review (35(11)), and lets supervisory authorities publish lists of processing that always requires a DPIA (35(4)) — France's CNIL, for example, maintains a fourteen-category list, and Norway's Datatilsynet publishes its own.
- Article 36 adds prior consultation: where the DPIA shows high residual risk that your measures cannot sufficiently mitigate, the supervisory authority must be consulted before processing, with written advice due within eight weeks, extendable by six for complex processing.
- WP248 rev.01 — Guidelines on Data Protection Impact Assessment (adopted 4 October 2017, endorsed by the EDPB on 25 May 2018) supply the nine high-risk criteria the screening section uses — evaluation or scoring; automated decisions with significant effects; systematic monitoring; sensitive or highly personal data; large scale; matching or combining datasets; vulnerable data subjects; innovative use of new technologies; and processing that prevents rights or service access — with the two-criteria rule of thumb.
- Article 83(4)(a) puts Article 35 infringements in the EUR 10 million / 2% of worldwide turnover tier; supervisory authorities treat a missing DPIA as a standalone, fineable infringement rather than a technicality.
- EU AI Act Article 27 requires certain deployers of high-risk AI systems to run a fundamental rights impact assessment — legally separate from the DPIA, but the two can be documented jointly, which is what the template's AI annex is structured for.
How this relates to the EDPB's own DPIA template (2026)
On 14 April 2026 the EDPB published its own harmonised DPIA template — Version 1.0, adopted 10 March 2026 — together with an explainer, for public consultation that ran until 9 June 2026. It is the most significant DPIA development since WP248, and it is worth being precise about what it does and does not do:
- It is voluntary for controllers. The EDPB states plainly that organisations are not required to use its template, and may keep using the DPIA methodology of their choice (CNIL's PIA method, ISO 29134, or an in-house approach).
- It does not change the law. Article 35(7)'s four mandatory content blocks and the WP248 rev.01 high-risk criteria are untouched. The EDPB template is a documentation and reporting layer over the same obligations — it standardises the output, not the analysis.
- It is aimed at convergence between authorities. After finalisation, DPAs are expected to adopt it as their single template, or as a "meta-template" their national forms stay compatible with. That is the practical reason to care: the structure your DPIA is written in is drifting toward a common EU form.
What that means for this template. Ours is deliberately structured around the same legal spine — Article 35(7)(a)–(d), the Article 35(3) cases, the WP248 criteria, the Article 36 decision — so a DPIA completed here maps cleanly onto the EDPB's fields rather than competing with them. What we add is the working layer the official form does not: the screening checklist that decides whether you need a DPIA at all, a scored likelihood×severity matrix with a worked example, the AI annex for AI Act overlap, and the machine-readable Markdown variant. If your supervisory authority has adopted the EDPB form, produce your assessment here and transcribe into it — or use the EDPB form as your output and keep this as the analysis behind it. Treat the EDPB's version as authoritative for format; nothing below changes the underlying duties.
Using the template in the UK and Norway/EEA
No structural adaptation is needed. UK GDPR retains Article 35 in the same form, supplemented by the Data Protection Act 2018; the ICO publishes its own high-risk processing list (new surveillance technologies, large-scale special-category data, children's data under the Children's Code) and expects prior consultation where residual risk stays high. The Data (Use and Access) Act 2025 left the DPIA regime substantively unchanged. Norway applies the GDPR through the personopplysningsloven via the EEA Agreement; Datatilsynet publishes its Article 35(4) list and expects DPIAs in the same cases. The only section that changes across regimes is the authority you would consult under Article 36.
Make the DPIA part of your evidence base
A completed DPIA is accountability gold: it is the document that proves you assessed before you processed. But buyers ask for it too — enterprise security reviews increasingly request DPIA summaries for exactly the features the assessment covers. A Trust Center gives that evidence a governed home: Orbiq's Trust Center platform keeps DPIAs, records of processing, DPAs and TOMs in one access-controlled place — alongside the subprocessor notices and certificates the same reviewers ask for — so the assessment you complete with this template becomes reusable proof instead of a buried file.
Sources & References
- Regulation (EU) 2016/679 (GDPR) — Articles 35, 36, 83 — DPIA duty and triggers (35(1), 35(3)), minimum content (35(7)(a)–(d)), DPO advice (35(2)), authority lists (35(4)), review (35(11)), prior consultation and deadlines (36), fine tier (83(4)(a)).
- Article 29 Working Party — Guidelines on Data Protection Impact Assessment (WP248 rev.01) — adopted 4 October 2017, endorsed by the EDPB 25 May 2018; the nine high-risk criteria and two-criteria rule of thumb.
- EDPB — Enhancing compliance and consistency: EDPB adopts DPIA template — Version 1.0 adopted 10 March 2026, published 14 April 2026; voluntary for controllers; public consultation closed 9 June 2026.
- CNIL — List of processing operations requiring a DPIA (Article 35(4)) — the French authority's fourteen-category list and PIA methodology.
- ICO — Data protection impact assessments (UK GDPR) — UK high-risk list, DPIA content, prior consultation with the ICO.
- Datatilsynet — Vurdering av personvernkonsekvenser (DPIA) — Norwegian DPIA guidance and Article 35(4) list.
- Regulation (EU) 2024/1689 (EU AI Act) — Article 27 — fundamental rights impact assessment for high-risk AI systems, and its relationship to the GDPR DPIA.
Related Reading
- GDPR Compliance in 2026: Principles, Rights & How to Prove It — where the DPIA sits in the obligations map
- EU AI Act Compliance — the FRIA and AI-system duties the AI annex maps to
- GDPR Articles 28, 32, 33 & 34 — the security measures your mitigations draw on
- GDPR Subprocessor Change Notice Template — sibling template for processor changes
- Trust Center for Legal Teams
Download this template
Version 1.0 · Updated Jul 15, 2026 · Free, no email required
Frequently Asked Questions
What should be included in a DPIA template?
At minimum, the four elements of GDPR Article 35(7): a systematic description of the envisaged processing and its purposes including any legitimate interest pursued (a); an assessment of the necessity and proportionality of the processing in relation to those purposes (b); an assessment of the risks to the rights and freedoms of data subjects (c); and the measures envisaged to address those risks, including safeguards and security measures (d). A working template adds screening questions, a likelihood×severity risk matrix, the DPO's advice, a residual-risk decision, sign-off, and a review log.
When is a DPIA required under GDPR?
Whenever processing — in particular using new technologies — is likely to result in a high risk to the rights and freedoms of natural persons (Article 35(1)), and always in the three Article 35(3) cases: systematic and extensive automated evaluation or profiling with legal or similarly significant effects, large-scale processing of special-category or criminal-conviction data, and large-scale systematic monitoring of publicly accessible areas. The WP248 rev.01 guidelines add nine high-risk criteria; as a rule of thumb, processing meeting two of them needs a DPIA.
How do I fill out a DPIA?
Work through the template in order: screen the processing against the Article 35(3) cases and the nine WP248 criteria; describe the processing systematically (data categories, recipients, retention, systems); seek the DPO's advice (Article 35(2)) and, where appropriate, the views of data subjects (Article 35(9)); assess necessity and proportionality; score each risk by likelihood and severity; assign mitigation measures; then decide on residual risk. If residual risk stays high, you must consult the supervisory authority before processing starts (Article 36).
Do AI features require a DPIA?
Very often, yes. AI features typically meet several WP248 high-risk criteria at once — innovative use of new technologies, evaluation or scoring, automated decision-making, and large-scale processing. Any AI system that processes personal data still needs full GDPR compliance regardless of the EU AI Act. For high-risk AI systems, the AI Act's separate fundamental rights impact assessment (Article 27 FRIA) can be documented jointly with the GDPR DPIA, but neither replaces the other — this template includes an AI annex for exactly that case.
Who signs off a DPIA and when must a regulator get involved?
The controller owns the DPIA, and where a DPO is designated their advice must be sought under Article 35(2) and documented. The template ends with a controller sign-off and the DPO's recorded opinion. If the assessment shows a high residual risk that your measures cannot sufficiently mitigate, Article 36 requires prior consultation with the supervisory authority before processing begins — the authority has up to eight weeks to give written advice, extendable by six more for complex processing.
Should I use the EDPB's official DPIA template instead?
You can — and if your supervisory authority has adopted it, you should follow its format. The EDPB adopted Version 1.0 of its harmonised DPIA template on 10 March 2026 and published it for consultation on 14 April 2026 (consultation closed 9 June 2026). Using it is explicitly voluntary for controllers: the EDPB confirms organisations may keep their own DPIA methodology. It also changes nothing in law — Article 35(7)'s required content and the WP248 rev.01 criteria still govern. It standardises how a DPIA is reported, not how the analysis is done, and after finalisation DPAs are expected to adopt it as their single or 'meta' template. This template follows the same Article 35(7) spine, so it maps onto the EDPB fields, and adds the screening checklist, scored risk matrix and AI annex the official form leaves to you.
Is a DPIA required in the UK and Norway?
Yes. UK GDPR carries Article 35 in the same form, supplemented by the Data Protection Act 2018, and the ICO expects a DPIA for processing on its high-risk list — the Data (Use and Access) Act 2025 did not change the DPIA regime in substance. Norway applies the GDPR via the EEA Agreement; Datatilsynet publishes its own Article 35(4) list of processing operations that always require a DPIA. This template works unchanged in all three regimes.