The EDPB published a standardized DPIA template on 14 April 2026. Here is what each of its seven sections demands, mapped to GDPR Article 35, and where most organizations' current DPIAs will fall short.
The EDPB's DPIA template is seven sections long, carries more than twenty subsections, and puts a structured table with named columns behind nearly every requirement. The explainer published alongside it runs to 50 numbered paragraphs and closes with an annex listing 31 supervisory authorities, each row pointing at that authority's own DPIA guidance where one exists.
That annex is the problem the template is aimed at: one set of four requirements in Article 35(7), and a separate national reading of them for every authority that has published one.
The bar moved. Here is exactly how far.
GDPR Article 35(7) has been in force since 2018. It lists four requirements for a DPIA:
That is a performance spec. It says what a DPIA must contain. It says nothing about how to structure it, what format to use, or what level of detail counts as "systematic." For eight years, every organization has interpreted those four paragraphs differently. Most interpreted them minimally.
On 10 March 2026, the EDPB adopted a standardized DPIA template. It was published on 14 April 2026. The press release says the template "is not mandatory." The same press release also says "all Data Protection Authorities will initiate the necessary steps to adopt this template either as their sole standard or as a 'meta-template' to which national-specific templates will align." Read those two sentences together. The template is voluntary today. It is the de facto standard tomorrow.
The template comes with a 50-paragraph explainer document that spells out what each field means and how to fill it. The explainer calls what the template asks for "a minimum amount of information that should always be documented." It is written as a floor.
What follows is a close read of the template and the explainer against Article 35, section by section: what each one requires, and where existing DPIAs will break.
Section 0 is the part most organizations already do reasonably well. Controller identity, processor list, processing name, launch date. But two things stand out.
First, subsection 0.5 asks for a "DPIA technical sheet" that includes a version log, the team involved (the explainer suggests a RACI matrix), and the guidelines or standards used. This is project metadata. It means auditors can trace who made each assessment decision and when.
Second, 0.5 includes a checkbox list of reasons to conduct the DPIA. The list has ten-plus categories drawn from Article 35(3) and existing EDPB DPIA guidance (wp248rev.01). It forces the team to document why a DPIA was triggered -- not just that it was.
This is where the gap between current practice and the template's expectations is widest. Section 1 maps to Article 35(7)(a): "a systematic description of the envisaged processing operations."
Most organizations satisfy 35(7)(a) with a paragraph. Something like: "We collect personal data from users to provide our service." The template replaces that paragraph with seven structured requirements.
1.1.a -- Processed personal data. A table with columns for each data item, an explanation of data type and subject category, and checkboxes for Article 9 special category identification. Not a list. A table. Per item.
1.1.b -- Purposes of the processing. Another table mapping each purpose to the personal data involved, with a justification column. If you process email addresses for marketing and for account recovery, those are two rows with two justifications.
1.1.c -- Secondary or compatible uses. A separate table. Each secondary use gets its own compatibility assessment. Most DPIAs I have seen do not even mention secondary uses.
1.1.d -- Nature, scope, and context. Three separate documented dimensions. Nature: "the way personal data will be handled (operations involved, technologies used)." Scope: "breadth and extent (the volume or scale given the number of data subjects or data items, geographical and organisational reach, frequency or duration)." Context: circumstances, cross-border processing, international transfers. Three rows. Three answers.
1.2 -- Functional description. A table decomposing the processing into phases or stages, each tagged with lifecycle operations: Collection, Use, Storage, Sharing and Transfer, Deletion and Destruction. The template adds a note: "Ideally, this table should be supplemented with one or more diagrams representing data flows or a similar figure." The explainer (paragraph 19) reinforces this: "Explain the data lifecycle and data flows: provide a comprehensive overview of how personal data is managed throughout its entire lifecycle, from collection to deletion."
Data flow diagrams. Not optional in spirit, even if the word "ideally" gives nominal cover.
1.3 -- Supporting assets. An inventory of the means of processing: hardware, infrastructure, network, software, APIs, models, personnel, sites, organizational assets. The explainer (paragraph 20) calls it an inventory of "essential supporting assets." This is an asset register scoped to the processing operation.
The gap: most organizations fill Article 35(7)(a) with a paragraph. The template fills it with seven structured tables plus data flow diagrams plus an asset inventory.
Section 2 maps to the analytical requirements of Article 35(7)(a) and (b). It has three major subsections.
2.1 -- Lawfulness. A three-column table per purpose: the purpose, the legal basis (with Article 6(1) options listed verbatim in the template), and the justification. For legitimate interest, the justification column requires the balancing test. For Article 9 special categories, a separate sub-table lists Article 9(2) exceptions verbatim. No free text. Pick from the regulation's own list. Justify.
2.2 -- Data minimization, retention, and data quality. This is a six-column table: personal data item, justification of need/relevance, recipients, justification for sharing, retention period, and justification for retention period. Six columns. Per data item. Most DPIAs I have reviewed have a single sentence about retention: "Data is retained in accordance with our retention policy." The template requires the retention period and its justification per item.
A second sub-table (2.2.b) addresses data quality: for each data item, what quality metrics, requirements, or thresholds apply, and why.
2.3 -- Compliance measures. This is the longest subsection. Five sub-tables cover:
The implementation status column has three defined values: Planned, Partially implemented, and Implemented. The explainer (paragraph 27) specifies what "Implemented" means: "the measure exists, is deployed, and is effectively operating in the live environment, not just on paper, there is evidence that the control works as intended." Not just on paper. Evidence required.
Section 3 maps to Article 35(7)(b): "an assessment of the necessity and proportionality of the processing operations in relation to the purposes."
Most DPIAs handle necessity in one sentence: "We only collect what is necessary." The template disaggregates this into three separate documented analyses.
3.1 -- Impacts of processing on rights and freedoms as designed. A four-column table: threats posed by the processing as designed, how they materialize, risk sources, and impact on data subjects' rights. This is not about breaches or accidents. This is about the processing working as intended. The explainer (paragraph 32) clarifies: "Explain how the threats that the planned processing (as it has been designed and is projected to be implemented) poses to the rights and freedoms of the data subjects can be materialised." Even a perfectly functioning system can create risks to rights and freedoms. The template requires documenting those risks explicitly.
3.2 -- Necessity assessment. The template text: "Evaluate if the envisaged processing is effective and the least intrusive for the data subject's rights and freedoms. Provide evidence (for example, concerning the different considered alternatives) and justification." Evidence and alternatives considered. Most organizations skip this entirely. The template makes alternatives analysis a named requirement.
3.3 -- Proportionality assessment. "Discuss the importance of the processing and its potential benefits for the data subject and collectively. Conduct an evaluation that compares the potential impacts on rights and freedoms of data subjects with the advantages resulting from the processing, to ensure that the processing is proportional and fairly balanced. Provide evidence and justification." This is a documented balancing exercise, not a sentence -- an exercise backed by evidence.
This is Section 4, mapping to Article 35(7)(c): "an assessment of the risks to the rights and freedoms of data subjects." It is the section that will cause the most operational friction, because it overturns a common assumption.
Most organizations use an ad-hoc likelihood-times-impact matrix. A 3x3 or a 5x5 grid, color-coded, undocumented criteria for what counts as "high." The template does not prescribe a specific matrix. Instead, it prescribes what any chosen methodology must document.
4.1.b -- Method. The template requires: "Likelihood and severity levels and their meanings (often a 2 to 5 levels scale is used). Risk metrics. How to prioritise risks. Risk acceptance levels." You pick the method. But you write it down. The methodology itself becomes an auditable artifact.
4.1.a -- Impacts from non-default events. Section 4 risks are distinct from Section 3 risks. Section 3 covers risks from the processing working as designed. Section 4 covers risks from things going wrong: "threats that could lead to illegitimate access, undesired modification and disappearance of data." The explainer (paragraph 35) draws the line sharply: "The root cause is a deviation from the intended, compliant state." Most DPIAs conflate design-level risks and operational risks into a single list. The template requires separating them.
4.1.c -- Inherent risk assessment. A six-column table: risks, likelihood, severity, modulating factors, risk level, and acceptability discussion. The "modulating factors" column is new for most organizations. The explainer (paragraph 37) defines these as "characteristics that increase or decrease the likelihood or severity of a risk." Examples: "a very large number of data subjects or high data sensitivity, data subjects in a situation of dependency or vulnerability (children, patients, workers, migrants), or high exposure to external adversaries." These factors modulate the score up or down before controls are applied.
One footnote in the template (footnote 8) breaks the standard likelihood-times-impact assumption: "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." Severity alone can make a risk unacceptable. If your current matrix only flags risks where both likelihood and severity are high, the template's framework will produce different outcomes.
4.2 -- Action plan. After inherent risk assessment, three sub-tables:
The gap: most DPIAs list generic controls ("we use encryption and access control") without connecting them to specific risks. The template requires explicit risk-to-measure traceability with cross-references, effectiveness justification, and a residual risk recalculation for each risk.
Section 5 maps to Article 35(2), which requires the controller to seek the advice of the data protection officer.
5.1 -- DPO advice. The template requires: "Provide their opinion, conclusions and recommendations concerning the envisaged processing." Then: "Explain how the DPO's advice has been implemented." Two fields. The DPO's documented opinion. The controller's documented response. Most organizations treat this as a signature line. The template turns it into a dialogue with a paper trail.
5.2 -- Views of data subjects. The template requires documenting whether data subjects or their representatives were consulted, and if not, why not. The text: "Explain their participation in the DPIA process, including explanations of why it has not been considered appropriate for them to participate or why it has not been possible for them to do so." The absence of consultation is itself a documented decision.
Section 6 is short but operationally significant. The template defines four possible outcomes:
The Article 36 trigger is explicit: the CONSULTATION outcome applies when "the data controller cannot find sufficient measures to reduce the risks to an acceptable level (i.e. the residual risks are still high)." That is a direct operationalization of Article 36(1): prior consultation with the supervisory authority when "the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk." The template makes this a structured decision, not a judgment call buried in free text.
I read the EDPB-EDPS Joint Opinion 4/2026 on cybersecurity looking for structural links to the DPIA template. There are none. The DPIA template does not cite NIS2 Article 21 or reference any ENISA risk framework.
The connection is thematic, not structural. The Joint Opinion (paragraph 36) states there is "opportunity to establish synergies so that the risk assessment can integrate the protection of the rights and freedoms of individuals." And paragraph 39 makes a point that matters for anyone filling out Section 2.3.e (security of processing): "certain cybersecurity controls create specific data protection risks. This can be the case with monitoring and logging, deep packet inspection, or user behaviour analytics." Cybersecurity measures can themselves be the thing that triggers a DPIA risk. That tension belongs in the Section 4 risk assessment, but the template does not spell it out.
I mention this to be honest about what the template does and does not contain. If you are looking for a single document that unifies GDPR risk assessment with NIS2 risk management, this is not it. Not yet.
Four sections will expose the widest gaps between current practice and what the template expects.
Section 1 (Systematic description). Free-text paragraphs do not survive contact with the template's structured tables. The per-item data mapping, the lifecycle-phase decomposition, and the data flow diagram requirement are new work for most organizations.
Section 3 (Necessity and proportionality). The alternatives analysis in 3.2 and the balancing exercise in 3.3 are where most DPIAs are thinnest. Asserting necessity is easy. Documenting the alternatives you considered and rejected is not.
Section 4.1.c (Inherent risk assessment). The modulating-factors column and the footnote 8 severity override will change scores for organizations that rely on a simple likelihood-times-impact grid. The requirement to separate design-level risks (Section 3) from operational risks (Section 4) will force restructuring existing risk registers.
Section 5.1 (DPO consultation). A signature is not a documented opinion. The template's two-field structure -- DPO opinion, controller response -- will surface gaps in how organizations engage their DPOs.
The template is the floor, not the ceiling. But from what I have seen, most organizations are not at the floor yet. Download the template. Open your last DPIA. Compare section by section. The gaps will be specific and measurable.
The measures a DPIA lists still have to be implemented, evidenced and reviewed somewhere. devguard keeps records, evidence and review cycles against a control set in one workspace: devguard.ch.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.