# 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.


**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](/eu-regulations/gdpr-compliance).

## Key takeaways

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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](#edpb-template)).

## 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:

- <span id="ai-annex"></span>**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](/eu-regulations/eu-ai-act-compliance) 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

1. **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.
2. **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.
3. **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.
4. **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](/eu-regulations/gdpr-article-28-32-33-34), access controls, pseudonymisation, retention cuts) do.
5. **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.
6. **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](https://eur-lex.europa.eu/eli/reg/2016/679/oj)** 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](https://www.edpb.europa.eu/documents/guideline/data-protection-impact-assessments-high-risk-processing_en)** (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](/eu-regulations/eu-ai-act-compliance)** 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.

<h2 id="edpb-template">How this relates to the EDPB's own DPIA template (2026)</h2>

On **14 April 2026** the EDPB published its own **[harmonised DPIA template](https://www.edpb.europa.eu/news/enhancing-compliance-and-consistency-edpb-adopts-dpia-template_en)** — Version 1.0, adopted 10 March 2026 — together with an explainer, for [public consultation](https://www.edpb.europa.eu/public-consultations/template-for-data-protection-impact-assessment_en) 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](#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](/trust-center/what-is-a-trust-center) gives that evidence a governed home: [Orbiq's Trust Center platform](/platform/trust-center-platform) keeps DPIAs, [records of processing, DPAs and TOMs](/eu-regulations/gdpr-compliance) in one access-controlled place — alongside the [subprocessor notices](/templates/gdpr-subprocessor-change-notice) 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

1. [Regulation (EU) 2016/679 (GDPR) — Articles 35, 36, 83](https://eur-lex.europa.eu/eli/reg/2016/679/oj) — 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)).
2. [Article 29 Working Party — Guidelines on Data Protection Impact Assessment (WP248 rev.01)](https://www.edpb.europa.eu/documents/guideline/data-protection-impact-assessments-high-risk-processing_en) — adopted 4 October 2017, endorsed by the EDPB 25 May 2018; the nine high-risk criteria and two-criteria rule of thumb.
3. [EDPB — Enhancing compliance and consistency: EDPB adopts DPIA template](https://www.edpb.europa.eu/news/enhancing-compliance-and-consistency-edpb-adopts-dpia-template_en) — Version 1.0 adopted 10 March 2026, published 14 April 2026; voluntary for controllers; [public consultation](https://www.edpb.europa.eu/public-consultations/template-for-data-protection-impact-assessment_en) closed 9 June 2026.
4. [CNIL — List of processing operations requiring a DPIA (Article 35(4))](https://www.cnil.fr/en/guidelines-dpia) — the French authority's fourteen-category list and PIA methodology.
5. [ICO — Data protection impact assessments (UK GDPR)](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/) — UK high-risk list, DPIA content, prior consultation with the ICO.
6. [Datatilsynet — Vurdering av personvernkonsekvenser (DPIA)](https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/vurdering-av-personvernkonsekvenser/) — Norwegian DPIA guidance and Article 35(4) list.
7. [Regulation (EU) 2024/1689 (EU AI Act) — Article 27](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) — 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](/eu-regulations/gdpr-compliance) — where the DPIA sits in the obligations map
- [EU AI Act Compliance](/eu-regulations/eu-ai-act-compliance) — the FRIA and AI-system duties the AI annex maps to
- [GDPR Articles 28, 32, 33 & 34](/eu-regulations/gdpr-article-28-32-33-34) — the security measures your mitigations draw on
- [GDPR Subprocessor Change Notice Template](/templates/gdpr-subprocessor-change-notice) — sibling template for processor changes
- [Trust Center for Legal Teams](/trust-center/trust-center-for-legal-teams)