Template for a Data Protection Impact Assessment (and its Explainer)

Published by

European Data Protection Board (EDPB)

Type

Template (DOCX) plus an Explainer (PDF) — Version 1.0, adopted 10 March 2026 for public consultation. Fifty-one numbered instructions, numbered 0 to 50, across seven sections (0 Overview · 1 Systematic description · 2 Analysis · 3 Necessity and proportionality · 4 Risk assessment and management · 5 Involvement of interested parties · 6 Conclusion and decision).

Status

DRAFT. Consultation ran 14 April – 9 June 2026 and is closed; the template is not finalised as at 17 July 2026. Note the EDPB's own news item is headlined “EDPB adopts DPIA template”, which reads as final adoption and is not. In the EDPB's words it “will be finalised (subject to any appropriate modifications), after which all data protection authorities will begin the necessary steps to adopt this template as their unique template or as a ‘meta-template’ with which national specific templates will be compatible.” In the meantime “organisations are encouraged to use this template”.

Jurisdiction

EU / EEA. Not binding, and expressly not mandatory — and it has no status in the UK, where ICO guidance remains the reference. The structure maps to GDPR Articles 35 and 36, which the UK GDPR carries across in substantially the same form.

Primary audience

DPOs, controllers and privacy counsel — and anyone who will one day have to hand a DPIA to a supervisory authority

Topic tags

DPIA · methodology · accountability · risk management · harmonisation

The part to read first

Annex 1 of the Explainer — an EDPB-maintained index of the DPIA guidance each supervisory authority points to, where it points to any. Thirty-one rows; fourteen are blank (Belgium, Cyprus, the EDPS, Hungary, Iceland, Italy, Liechtenstein, Lithuania, Luxembourg, Norway, Portugal, Romania, Slovakia, Sweden). Not all of it is methodology — some rows point to Article 35(4) trigger lists rather than methods. Germany's entry is the Standard Data Protection Model, which we surfaced on 3 July. It is simultaneously a reading list and a map of where nothing national exists.

Why it matters

Read instruction 36 of the Explainer — the template's Method field at 4.1.2 — and the shape of the problem changes. It asks you to “explain the details of the method followed to assess and manage risk” — likelihood and severity scales and their meanings, risk metrics, how risks are prioritised, risk acceptance levels — and adds: “If an established method is used, provide the link to the external source introducing this method.” The Explainer is explicit that the choice is yours: “Controllers can conduct their risk analysis and management processes as they prefer, using the DPIA methodology of their choice (see Annex A). The EDPB template is one way to record the most important results, a minimum amount of information that should always be documented, in the format adopted by the EDPB and easily accepted by all SAs.” So the record gets harmonised and the method does not — but the method becomes a named, linked, auditable field. That is the useful pressure, and it lands on the part of DPIA work that is genuinely hardest. Writing one assessment is a task. Having a consistent mechanism — the same scales, the same acceptance thresholds, the same reasoning, applied the same way across a portfolio and defensible when someone reads three of them side by side — is the difficult thing, and it is the thing an implied or inherited method quietly fails at. A privacy function that has been running DPIAs on a per-project instinct now has a box that asks it to say so out loud, in a document a regulator reads. If the honest answer to that field differs from assessment to assessment, better to find that out before someone else does. Two other things repay attention. The template splits risk into two passes that most templates collapse: section 3.1 covers impacts arising when everything works exactly as designed — “design choices themselves create risks for data subjects’ rights and freedoms, even where there is no failure or attack” — while 4.1.1 covers what happens when something breaks or someone attacks. And section 6 will not let a DPIA end in a shrug: it must conclude with a decision — abandon the processing, consult the supervisory authority, proceed, or proceed conditionally on named changes. Two caveats worth carrying. First, this is a draft, and it may move. Second, and more important: it harmonises the form, not the threshold. Instruction 8 asks you to “explain the reasons to conduct the DPIA” and footnotes it straight back to WP248 rev.01 — a 2017 document that remains the operative EU reference for the “likely high risk” test. The Article 35(4) national lists are untouched, still in force, and still diverge sharply: on the EDPB's own register of them, Finland's list runs to five entries and Hungary's to twenty-four; employee monitoring is a named trigger in around a dozen national lists and appears nowhere on the ICO's; and Germany treats anonymisation for onward transmission as a trigger where the ICO treats anonymisation as a mitigation. (That register has had nothing added since January 2020 — old, but not superseded: a non-binding template cannot displace a list adopted under Article 35(4).) So the threshold question stays where it was. What has changed is that the EDPB has put the method question on the record, and published in Annex 1 the DPIA guidance its own authorities point to. The three that follow are on that list.