The EDPB's DPIA Template (2026): What It Asks For and How to Complete It

The European Data Protection Board adopted a template for data protection impact assessments on 10 March 2026 and published it on 14 April 2026 with an explainer, as part of its work on documents that make GDPR compliance easier for organisations. The version history inside the template records the adoption as "adoption of the guidelines for public consultation", and the consultation ran from 14 April to 9 June 2026. The EDPB says that, once the consultation is finished, the template "will be finalised (subject to any appropriate modifications), after which all data protection authorities will begin the necessary steps to adopt this template", either as their only standard or "as a 'meta-template' with which national specific templates will be compatible". When I checked on 8 November 2026, the EDPB's consultation page still presented version 1.0 and encouraged organisations to use it in the meantime, and I found no final version on the EDPB's pages.

This article sets out what the template asks for, section by section, how its risk method works, and how to complete it if you already hold a DPIA in another format. The text I quote is from the template and the explainer as published on 14 April 2026.

Whether you have to use it

Use of the template is voluntary. The announcement says that "it is not mandatory for organisations to use the EDPB template", and the explainer puts the point more fully: "Controllers can conduct their risk analysis and management processes as they prefer, using the DPIA methodology of their choice (see Annex A)." The template is described as "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".

Article 35(7) of the GDPR lists what a DPIA must contain, but it does not prescribe a format. The EDPB's stated aim is a single format that every supervisory authority adopts once the consultation version has been finalised, either as its own standard or as a meta-template with which national templates are compatible. The explainer also notes that "Certain redundancy between the DPIA template sections ensures that each mandatory element is addressed explicitly and in a traceable manner".

The template is an EU document. A UK organisation processing under UK GDPR works from the ICO's guidance, which includes a template the ICO says may be used; the ICO accepts other formats that cover the required content. Where the same organisation also processes under the EU GDPR, through an EU establishment or because it offers goods or services to people in the EU, an EU authority or an EU customer may ask for the assessment in the EDPB's form, and the content required under the two regimes is much the same.

The seven sections

The template has a section 0 and sections 1 to 6.

0. Overview of the processing. The controller, with the management units responsible, the main establishment or point of contact, any representative and the DPO; joint controllers, each with their obligations and tasks; the processors and sub-processors with their obligations and tasks; the internal name of the processing (the name used in the record of processing activities); the planned launch date and any end date; and a "DPIA technical sheet". The technical sheet asks for the version log of the DPIA, the team that conducted it, the guidelines and standards used, the scope (what was considered and what was left out, and why), the completion and formal validation dates, and whether the DPIA will be published or shared externally.

The technical sheet also asks for the reasons the DPIA is being conducted, with boxes to tick. These follow the law: the three cases in Article 35(3) (systematic and extensive evaluation based on automated processing including profiling with legal or similarly significant effects; large-scale processing of special category or criminal offence data; systematic monitoring of a publicly accessible area on a large scale); a requirement under national law; the nine criteria from the European guidelines (evaluation or scoring, automated decision-making with legal or similarly significant effect, systematic monitoring, sensitive data or data of a highly personal nature, data processed on a large scale, matching or combining datasets, data concerning vulnerable data subjects, innovative use or the application of new technological or organisational solutions, and processing that prevents people from exercising a right or using a service or a contract), with an "other" box for which the national lists of processing requiring a DPIA are the example; a DPIA that is necessary or beneficial on the advice of the DPO or of the people affected or their representatives, because a code of conduct, standard or best practice requires it, or for another reason such as managing risk or demonstrating accountability; and an existing high-risk processing whose risks have changed, because the processing or its organisational or societal context has changed.

1. Systematic description of the processing. The personal data processed, item by item, with the category of data subject and whether it is special category data; the purposes; any secondary or compatible uses; the nature, scope and context of the processing; a functional description; the means of processing, the supporting assets and the underlying architecture; and compliance with any approved code of conduct. This is the content Article 35(7)(a) requires, set out as tables.

2. Analysis of the processing. The legal basis for each purpose and, for special category data, the reason the prohibition in Article 9 is lifted; data minimisation and retention periods; data quality; and the measures that support compliance, in five groups: the principles in Article 5(1), the exercise of data subjects' rights, other GDPR requirements, data protection by design and by default, and security of processing.

3. Considerations on necessity and proportionality. The impacts of the processing on the rights and freedoms of the people affected, and an assessment of necessity and of proportionality, which is the content Article 35(7)(b) requires.

4. Risk assessment and management. The threats, risk sources and impacts; the method used; the inherent risk assessment; the action plan, with additional mitigating measures and their implementation status; and the residual risk assessment. Articles 35(7)(c) and (d) are met here.

5. Involvement of interested parties. The DPO's advice and how it was implemented, and the views of the people affected or their representatives, or the reasons it was not considered appropriate or possible to seek them.

6. Conclusion and decision. One of four outcomes, discussed below.

How the template scores risk

Section 4 asks you to identify, at least, the threats that could lead to illegitimate access to data, undesired modification and disappearance of data, together with threats from malfunctions and deviations from design and default, and threats to confidentiality, integrity and availability. For each, it asks how the threat could materialise, its risk sources (the explainer gives software bugs, misconfiguration, wrong access rights, operational errors, lack of maintenance, insider abuse and external attacks as typical examples) and the impact on the people affected.

The template does not impose a scoring method. It asks you to state the one you used: the likelihood and severity levels and what they mean, the risk metrics, how risks are prioritised and the acceptance levels, with a link to the external source if you follow an established method. The explainer describes the usual approach. Risk level "usually follows the standard Risk = likelihood × severity, typically using qualitative scales to derive a level (for example, low/medium/high)", and "modulating factors" may adjust the baseline up or down: a very large number of data subjects, high data sensitivity, people in a position of dependency or vulnerability (children, patients, workers, migrants) or high exposure to external adversaries push it up; design choices and measures push it down. The explainer adds, in a footnote, a qualification that bears on whether a risk can be accepted: "A risk in data protection may be deemed non-acceptable if the potential severity of its impact is very high, even when its likelihood of occurring is low."

The sequence is inherent risk first, assuming the measures already planned; then any additional measures, each with a discussion of its appropriateness and effectiveness and a status of planned, partially implemented or implemented; then the residual risk, scored the same way, with a view on whether it is acceptable.

The decision

Section 6 records the controller's decision in one of four forms. REJECTED: the processing must be abandoned. CONSULTATION: the processing will be consulted with the supervisory authority, either because the controller cannot find sufficient measures to bring the residual risk to an acceptable level and does not wish to abandon the processing (the Article 36(1) case), or because national law requires consultation or prior authorisation for processing in the public interest (Article 36(5)). APPROVED: the processing may proceed, because the residual risks are acceptable and no national law requires consultation or prior authorisation. CONDITIONALLY APPROVED: the processing may proceed only once listed conditions are met.

The fourth outcome is an express decision by the controller that the processing may begin only when named conditions have been met. It is not the same as an assessment left unfinished. A draft that records open points with owners and dates shows that the assessment is incomplete and that the controller has not yet decided whether the processing is approved, needs consultation or should not go ahead. The conditional box applies only once the controller has taken that decision and can state the specific conditions.

Completing it from an assessment you already have

A DPIA that already meets Article 35(7) contains much of what the template asks for. The description of the processing, lawful basis, necessity and proportionality, risk register, consultation record and outcome correspond to sections 1 to 6 in order. The correspondence is indicative, and every field of the template that applies to the processing should be checked. The items a controller will usually have to supply from its own records or assess separately are the version log of the DPIA and of the processing, the team that conducted the assessment, whether the assessment will be published or shared, compliance with any approved code of conduct, data quality requirements, the measures grouped by the compliance purpose they serve, and, for each additional measure, evidence of its appropriateness and effectiveness together with its implementation status.

Our DPIA tool drafts an assessment in a conversation, free to complete, and its method page sets out section by section where each part of the EDPB template is covered in the document it produces and which items you would supply or assess yourself. The tool's document is not a copy of the template and does not claim to comply with it; it covers the same ground in a similar order.

Sources

The template (version 1.0, adopted 10 March 2026, published as a Word document), the explainer (PDF) and the consultation page, all on edpb.europa.eu, read on 8 November 2026; the EDPB news item "Enhancing compliance and consistency: EDPB adopts DPIA template" of 14 April 2026; Regulation (EU) 2016/679, Articles 35 and 36; Article 29 Working Party, Guidelines on DPIA, WP248 rev.01, endorsed by the EDPB.