DPIA before launch: turn high-risk processing into a decision (2026)

A proposed project is moving toward launch. The product team has mapped the feature, procurement has named the vendor, and security has listed controls. The privacy question is narrower and more consequential: is this processing likely to create a high risk for people, and has anyone made that decision before the data starts moving?

A DPIA is the record that should answer it. Under GDPR Article 35, a controller must assess processing before it begins when the operation is likely to result in a high risk to people's rights and freedoms. The assessment is not a formality added after design. It is where the organisation tests whether the proposed processing is necessary, proportionate, and sufficiently controlled to proceed. 1

Start with the processing, not the product

A product name hides the facts a DPIA needs. “Deploy the analytics platform” does not say what data is collected, whose data it is, what the system infers, who receives the output, or what decision the output supports.

Write the activity as a data flow instead:

collect employee messages to detect security incidents;
compare customer behaviour to identify suspected account takeover;
score applicants to rank them for a human review;
monitor a public space with cameras and retain footage for investigation.

Then define the boundary. A single DPIA can cover a set of similar operations with similar high risks, but a broad project label should not swallow different purposes or different populations. 1

The EDPB’s 2026 template makes this concrete. It asks the controller to identify the processing, its version history, its planned launch and end conditions, the team responsible, the reason for the DPIA, and what the assessment includes or leaves out. It is an optional template, not a mandatory EU form, but its fields show the level of specificity a reviewer needs. 2

When does Article 35 require one?

The legal trigger is likely high risk, judged against the nature, scope, context, and purposes of the processing. Article 35 also identifies three situations where a DPIA is especially required:

systematic and extensive evaluation of personal aspects using automated processing, including profiling, where decisions produce legal or similarly significant effects;
large-scale processing of special-category data or data about criminal convictions and offences; or
systematic monitoring of a publicly accessible area on a large scale. 1

These are not the only possible triggers. Supervisory authorities publish lists of processing operations that require a DPIA and may publish lists of operations that do not. The EDPB maintains a page linking to this work and describes the basic rule in operational terms: controllers carry out a DPIA before processing likely to result in high risk, and consult the authority if the risk cannot be mitigated by appropriate measures. 3

A useful screening decision therefore has two layers. First, check the explicit cases and the relevant authority lists. Second, assess the combination of factors in the proposed activity. A small amount of ordinary contact data used once for a narrow service may not resemble continuous location monitoring, large-scale profiling, or an automated decision about access to a benefit. The assessment must explain which facts led to the conclusion rather than merely selecting “DPIA not required.”

What the assessment must contain

Article 35 sets a minimum. A DPIA must include:

a systematic description of the planned processing operations and purposes, including the legitimate interest pursued where relevant;
an assessment of necessity and proportionality in relation to those purposes;
an assessment of risks to people's rights and freedoms; and
the measures planned to address those risks, including safeguards, security measures, and mechanisms that demonstrate compliance. 1

The first item is more than a data inventory. The EDPB template explainer asks organisations to describe the data, purposes, nature, scope, context, processing stages, and full lifecycle from collection to deletion. It also asks them to identify controllers, processors, and sub-processors, and to state the boundaries of the assessment. 4

That level of detail exposes the decisions that often disappear inside a project plan:

Purpose: What outcome does the processing support? Is there a secondary use, such as training a model or measuring behaviour?
People: Who is affected, and are any groups vulnerable or unable to avoid the processing?
Data: Which fields are collected, derived, combined, retained, or disclosed?
Scale and context: How many people, how often, for how long, across which locations and organisations?
Output: Does the system make a prediction, rank, recommendation, eligibility decision, or investigation lead?
Lifecycle: Where does data enter, move, get accessed, get backed up, and get deleted?

Necessity and proportionality deserve their own answer. “The business wants better detection” is a purpose, not proof that the chosen data and method are necessary. Compare the proposed operation with less intrusive ways to achieve the same result. Explain why the data fields, retention period, access model, and level of automation fit the stated purpose.

Move from inherent risk to a launch decision

A DPIA should separate the risk before safeguards from the risk that remains after them. Otherwise a list of controls can create the appearance of analysis without showing whether any control changes the outcome.

For each material risk, record:

the possible effect on people, such as discrimination, loss of confidentiality, financial harm, exclusion, or loss of control;
the cause of the risk in the actual data flow;
the likelihood and severity assessment, using a method the organisation can explain;
the measure that reduces it;
the owner and implementation evidence; and
the residual risk after the measure is in place.

The conclusion should say what happens next: proceed, proceed subject to named conditions, redesign, pause, or consult the supervisory authority. A DPIA does not itself create a lawful basis, cure inaccurate data, or make an unfair purpose acceptable. It records whether the proposed operation can be justified and controlled against the risks identified.

The EDPB says controllers may use the risk-analysis and management methodology they prefer. Its template is designed to prompt complete, structured responses and reduce omissions; organisations do not have to use that template. 2

The consultation boundary

The most important decision is not whether a document exists. It is whether high risk remains after the organisation has taken measures to reduce it.

Article 36 requires the controller to consult the supervisory authority before processing when the DPIA shows that the operation would still result in high risk without measures taken to mitigate it. The request must include the roles of the parties where relevant, the purposes and means, the safeguards, the DPO's contact details where applicable, the DPIA, and other information the authority requests. 1

The EDPB states the same boundary plainly: if the risks cannot be mitigated by appropriate measures, the controller needs to consult the data-protection authority before proceeding. 3

This is different from asking a regulator for comfort after launch. The consultation path belongs in the project plan early enough to affect the design and timetable.

Why AI projects expose weak DPIAs

AI is a useful stress test because the processing can change across training, testing, deployment, monitoring, and later model improvement. A team may assess the user-facing feature while leaving the training dataset, inferred attributes, or vendor reuse outside the boundary.

The ICO says Article 35 requires a DPIA when processing, particularly with new technologies, is likely to create high risk. It identifies systematic and extensive profiling or automated evaluation used for legal or similarly significant decisions as a case where a DPIA is always required, and says the assessment should be completed before processing and reviewed when the nature, scope, context, or purposes change. 5

The practical question is not “Does the system use AI?” It is “Which personal-data operations does the system perform, on whom, at what scale, and with what effect?” A model that recommends articles and a model that ranks people for a consequential service may share a technical stack while presenting very different risks. The DPIA should make that difference visible.

Common mistakes

Starting after the design is fixed

A late DPIA turns safeguards into expensive patches. Start with the proposed data flow and use the assessment to challenge fields, retention, recipients, and automation before launch.

Assessing the product instead of the operation

One product can contain separate processing activities: customer service, fraud prevention, analytics, model training, and legal retention. Split the purposes and assess the actual boundaries.

Treating a completed form as permission

A signed document proves that someone recorded a decision. It does not prove necessity, proportionality, adequate safeguards, or a tolerable residual risk.

Describing controls without linking them to harm

“Encryption is enabled” is an implementation statement. The DPIA should state which confidentiality risk it reduces, which data it covers, who controls the keys, and what risk remains elsewhere in the lifecycle.

Forgetting change triggers

A new data source, model, recipient, retention period, population, geographic scope, or decision consequence can change the risk. Article 35 requires review at least when the risk represented by the processing changes. 1

The record a reviewer can use

Keep a dated DPIA record with these fields:

Processing boundary: purpose, operations, systems, parties, data, people, scale, context, and lifecycle.
Trigger analysis: Article 35 cases, authority lists, risk factors, and the reason a DPIA is or is not required.
Necessity and proportionality: the goal, alternatives considered, and why the chosen data and method fit it.
Risk register: harms, causes, likelihood, severity, affected groups, inherent risk, and residual risk.
Safeguard plan: technical and organisational measures, owners, evidence, and completion conditions.
People and oversight: DPO advice, views of affected people or representatives where appropriate, and responsible approver.
Decision and change path: launch conditions, unresolved risks, consultation decision, review date, and triggers for reopening the assessment.

The record should let a new reviewer reconstruct the decision without relying on the project team's memory. That is the practical test: can someone see what the processing does, why it is needed, what could go wrong, what reduces the risk, and what would make the conclusion change?

A DPIA is strongest when it changes the project before launch. Begin with the data flow, not the template; separate the purposes; test necessity and proportionality; show the safeguards against specific harms; and treat residual high risk as a consultation decision, not a paragraph to hide at the end.

References

1
Regulation (EU) 2016/679, Article 35
data.europa.eu
2
EDPB, Enhancing compliance and consistency: EDPB adopts DPIA template
edpb.europa.eu
3
EDPB, Data protection impact assessment
edpb.europa.eu
4
EDPB, DPIA Template explainer
edpb.europa.eu
5
ICO, Legal framework for explaining AI-assisted decisions
ico.org.uk