On 14 April 2026, the European Data Protection Board opened its first EU-wide harmonised DPIA template for public consultation. Behind the promise of administrative simplification, a quieter methodological shift: the separation between design risks and incident risks. A distinction that redistributes the cards between platforms that protect data, and those that engineer the absence of risk.
The harmonisation DPOs have been waiting for since 2018
On 14 April 2026, the EDPB released its first harmonised Data Protection Impact Assessment template, adopted as version 1.0 on 10 March through written procedure. The document is open for public consultation until 9 June 2026. After that date, all European authorities (including France’s CNIL) will have to adopt it as their sole standard, or as a meta-template with which their national templates must remain compatible.
For DPOs handling cross-border processing, this ends a fragmentation that has lasted seven years. Until now, a DPIA structured according to one national approach was not necessarily recognised by another authority. The EDPB template puts an end to this asymmetry.
That is the consensus reading of the text. It is accurate, but it misses the essential point.
Two risks, two sections, two logics
The real innovation of the 2026 template is not formal. It is methodological. For the first time in a document enforceable across Europe, the template distinguishes two natures of risks that most first-generation DPIA methodologies mixed into a single matrix.
In section 3, the controller documents the risks inherent to the processing itself. Those that exist even if everything works perfectly, if no configuration goes wrong, if no attacker enters the system. Data centralisation, extended retention periods, persistent identifiers, combination of heterogeneous datasets. These risks are consequences of architectural choices, not events.
In section 4, separately, operational risks are documented. Bugs, misconfigurations, human errors, abusive access, external attacks. These are incident risks.
This separation seems technical. It is in fact political. It forces a question that first-generation DPIAs regularly sidestepped: is this architecture compatible with people’s rights and freedoms, even when it operates as intended?
In other words, before even talking about security, does the design itself pose a problem? The answer to this question is not found in the quality of firewalls. It is found in the architecture blueprint.
When security does not repair design
The answer, for a large number of current architectures, is uncomfortable. A data lake built around centralised long-duration storage, even perfectly operated, carries structural risks that will now be documented in a separate section, without operational measures answering them.
Encryption does not turn a ten-year retention into an absence of retention. Access control does not make it harmless to concentrate in a single place the sensitive data of millions of people. Section 3 of the template will require documenting these choices for what they are.
Platforms that grew on the « collect broadly, store durably, protect intensively » model will have to face this mirror. This is not an accusation, it is an observation. The EDPB template invents nothing: it makes explicit what Article 25 of the GDPR has required since 2018. But it makes it explicit in a dedicated, traceable, comparable section from one file to another.
The other mirror: architectures that have nothing to store
The mirror returns a very different image when we look at architectures designed differently.
A platform that processes data during its transport, without moving or storing it, compresses section 3 of the template by design. There is no centralisation to document, because there is no centralisation. There is no retention period to justify, because processing is in-transit. Combined datasets leave no persistent trace, because the combination dissolves with the usage context. Persistent identifiers disappear, because the platform does not manufacture any.
This is the principle of iD4Connect’s DataCell technology: each processing unit acts on the data during its transit, then releases it. Nothing persists on the platform side. DataGraph provides contextual intelligence, which dissolves with the usage context. The architecture is not a protection layer added on top of a classic topology. It is a different topology (see the full architecture).
And section 4, on incidents? It still needs to be filled in, of course. No architecture exempts one from analysing its own failures. But when the asset to defend includes neither a data lake nor a warehouse, the question « what happens if an attacker gets in » changes in nature. There is no estate to exfiltrate outside the sources, which remain within the original controller’s perimeter with their own measures.
An architecture that has nothing to lose is not defended like one that has everything to protect.
Five questions to test your current DPIA
Before the template is finalised in June, it may be useful to run your current DPIA, or your latest review, through five questions. They do not replace a compliance analysis, but they give a quick signal.
- Does your risk section clearly distinguish risks coming from the design of the processing from those coming from operational incidents, or are both treated in a single matrix?
- When you describe your measures under Article 25 (data protection by design), are they parameters added on top of an existing architecture, or intrinsic properties of the architecture itself?
- If an authority asked you tomorrow: « what would happen to data subjects if the entire architecture worked perfectly, without any incident », would your answer be short or long?
- Does your asset inventory (section 1.3 of the template) include long-duration storage components that exist mainly for historical reasons, and whose business value would be hard to defend today?
- If you started the architecture from scratch, with 2026 standards in mind, would you choose the same data topology, or a different one?
These questions were not asked in these terms a year ago. They will be asked in these terms for the next five.
What it changes depending on your role
For a DPO: at equal scope, the volume of documentation required now depends on the type of architecture. Defending a DPIA before an authority becomes mechanically simpler when the underlying architecture does not require justifying each structural risk with a compensatory measure.
For a CISO: a new type of tool enters the conversation. Not an additional security product, but a data architecture that mechanically reduces the surface to defend. « Data that cannot be stolen does not need to be defended » stops being an aphorism and becomes a documentary category.
For a CIO or CTO: an economic trade-off becomes formal. Centralised analytics platforms carry both an operational cost and a compliance cost. Until now, the latter remained diffuse, uneven, hard to quantify. The EDPB template makes it visible section by section. In regulated sectors (finance & banking, healthcare, energy, public sector), where every DPIA is documented, audited and reviewed, this trade-off stops being theoretical.
For a regulatory authority: a differentiation criterion gains legibility. Architectures that embody Article 25 by design rather than by parameter now have a common language to demonstrate it, and authorities have a common language to recognise it.
Contributing to the consultation while it is open
The EDPB consultation is open until 9 June. Every contribution will be published on the authority’s website.
We believe the template would benefit from explicitly recognising, in its section on data protection by design, the category of data-at-source and stateless architectures. Not because they would be better in themselves (that judgment belongs to controllers and their authorities), but because they transform qualitatively, and not quantitatively, the risk profile of a processing operation.
That is why we invite DPOs, lawyers, integrators and vendors with concrete experience of these architectures to participate in the consultation. A public consultation is only useful if those who do the work take the time to write.
In six weeks, the template will be finalised. In a few months, it will be the benchmark applicable to every data platform vendor operating in Europe. Two questions arise at that point, one technical and one strategic. We have just asked the first.
The second is simpler: if you were starting the architecture tomorrow, would you choose the same one?
The EDPB DPIA template creates no new obligation. It simply makes legible what Article 25 of the GDPR has required since 2018: to separate what relates to the design of processing from what relates to incidents. Within this reading grid, architectures that do not store data have no need to compensate for their design with measures: they mechanically reduce the perimeter to document. By June, it will no longer be an intuition. It will be an enforceable format.