When Is a DPIA Required? 2026 Guide & New EDPB Template

Key Takeaways

• A Data Protection Impact Assessment (DPIA) is mandatory under GDPR Article 35 before starting any processing "likely to result in a high risk" to people's rights and freedoms — it is a pre-launch exercise, not retrospective paperwork.
• Article 35(3) names three always-mandatory cases: systematic and extensive profiling producing legal or similarly significant effects, large-scale processing of special-category data, and systematic large-scale monitoring of publicly accessible areas.
• European regulators' rule of thumb: if your processing matches two or more of nine high-risk criteria (scoring, automated decisions, monitoring, sensitive data, scale, dataset matching, vulnerable people, innovative technology, blocking access to services), do a DPIA.
• In March 2026 the EDPB adopted its first standardized DPIA template with an explainer, opened for public consultation — the clearest signal yet of how regulators expect DPIAs to be structured and evidenced.
• Most production AI systems — recommendation engines, dynamic pricing, fraud scoring — sit squarely in DPIA territory, and the EU AI Act adds its own adjacent assessment duties.

Introduction

The DPIA is the GDPR's "look before you leap" mechanism: a structured risk assessment you must complete before launching processing that could seriously affect the people whose data you use. It is also one of the most postponed obligations in practice — teams ship the feature, then wonder whether someone should have written something down.

2026 is a good year to fix that. In March, the European Data Protection Board adopted its first common DPIA template, giving organizations across the EU a concrete, harmonized answer to "what does a good DPIA actually look like?" This guide covers when a DPIA is required, how to run one, and what the new template means for your process.

This article is informational content, not legal advice. For assessments with significant legal exposure, involve a qualified professional.

When Is a DPIA Required Under Article 35?

The general trigger is Article 35(1): a DPIA is required where processing — "in particular using new technologies" — is likely to result in a high risk to the rights and freedoms of natural persons. The assessment must happen prior to the processing.

The three always-mandatory cases

Article 35(3) removes the judgment call for three scenarios:

1. Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects — credit scoring, automated application rejection, algorithmic account termination.
2. Large-scale processing of special categories of data (Article 9 — health, biometrics, beliefs, sexual orientation) or criminal-offense data (Article 10).
3. Systematic monitoring of a publicly accessible area on a large scale — the classic example is camera surveillance, but the logic extends to comparable tracking.

The nine high-risk criteria

For everything else, regulators use the nine criteria from the Article 29 Working Party's DPIA guidelines (WP248, endorsed by the EDPB):

1. Evaluation or scoring, including profiling and predicting behavior
2. Automated decision-making with legal or similarly significant effects
3. Systematic monitoring of data subjects
4. Sensitive data or data of a highly personal nature
5. Large-scale processing
6. Matching or combining datasets in ways people would not expect
7. Data concerning vulnerable subjects — children, employees, patients
8. Innovative use or new technological solutions — AI, IoT, biometrics
9. Processing that prevents people from exercising a right or using a service or contract

The accepted rule of thumb: two or more criteria → conduct a DPIA. One criterion can suffice where the risk is plainly high. For an eCommerce example: a personalization engine that scores customers (1), monitors browsing systematically (3), at scale (5), using machine learning (8) is four-for-nine — this is not a close call.

National lists and the edge cases

Under Article 35(4), each supervisory authority publishes a list of processing operations that always require a DPIA in its jurisdiction — check the list of every market you operate in, because they differ. Conversely, no new DPIA is needed where an existing assessment already covers a similar set of similar operations (Article 35(1)), so one well-scoped DPIA can cover a family of related processing.

If in doubt, do the assessment. The fine tier for skipping a required DPIA reaches €10 million or 2% of global annual turnover (Article 83(4)) — and a documented "we screened this and concluded no DPIA was needed" is itself valuable evidence if a regulator ever asks.

The 60-second screening test

Run every new feature or tool through these questions at intake. Two or more "yes" answers — or one emphatic one — means schedule a DPIA before build, not after:

• Does it score, rank, profile, or predict anything about individual people?
• Do its outputs decide or materially influence what a person gets, pays, or is denied?
• Does it process health, biometric, location, financial, or children's data?
• Does it watch behavior systematically — session tracking, monitoring, surveillance?
• Is it large-scale relative to your customer base?
• Does it combine datasets from different sources or contexts?
• Does it use AI, machine learning, or otherwise novel technology?

What the EDPB's 2026 Template Changes

On 10 March 2026, the EDPB adopted its first standardized DPIA template, published as version 1.0 together with a plain-language explainer and opened for public consultation through 9 June 2026. Until now, every supervisory authority had its own format — the French CNIL's tooling, the German standard data protection model, national checklists — and multinational teams had to guess which structure would satisfy whom.

The template walks a controller through the full DPIA lifecycle across seven sections, from identifying the controllers, processors, and sub-processors involved and a technical sheet for the processing, through the systematic description, the necessity and proportionality analysis, the risk assessment, and the mitigation measures — mirroring the minimum contents Article 35(7) has always required:

• a systematic description of the processing and its purposes
• an assessment of necessity and proportionality
• an assessment of the risks to data subjects' rights and freedoms
• the measures addressing those risks, including safeguards and security

The template is a harmonization tool, not a new obligation — national formats remain valid. But it is the clearest available statement of what EU regulators collectively consider a complete DPIA, which makes it the sensible default structure for any new assessment started in 2026.

How to Run a DPIA in 7 Steps

Step 1: Screen at project intake

Add the Article 35(3) cases and the nine criteria as a checklist in your project or feature intake process. The cheapest DPIA is the screening that correctly concludes you do not need one — documented.

Step 2: Describe the processing

What data, from whom, flowing where, stored how long, accessed by which vendors. If you maintain a [record of processing activities](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities), most of this section already exists — reuse it.

Step 3: Assess necessity and proportionality

Could the purpose be achieved with less data, shorter retention, or less intrusive means? This is where data minimization stops being abstract.

Step 4: Identify the risks to individuals

Not risks to your business — risks to data subjects: discrimination, financial loss, exclusion from services, exposure of sensitive traits, loss of control over their data. Rate likelihood and severity.

Step 5: Define mitigations and involve the right people

Map each risk to safeguards: pseudonymization, access controls, human review of automated decisions, opt-outs, transparency measures. Seek your DPO's advice where one is appointed (Article 35(2)), and where appropriate, seek the views of data subjects or their representatives (Article 35(9)).

Step 6: Decide — and consult the regulator if needed

If residual risk remains high despite mitigations, Article 36 requires prior consultation with your supervisory authority before processing starts. If mitigations bring risk down to acceptable, document the sign-off and launch.

Step 7: Keep it alive

A DPIA is a living document. Article 35(11) requires review when the risk profile changes — new data categories, a new model, a new vendor. Tie reviews to your change process, not the calendar alone.

DPIAs and AI: Where Most Teams Get Caught

AI features are where eCommerce teams most often trip the DPIA threshold without noticing: recommendation engines, dynamic pricing, churn prediction, fraud scoring, and support chatbots routinely combine scoring, systematic monitoring, scale, and innovative technology — multiple criteria at once. Our guide to [AI and GDPR compliance challenges](/resources/blog/ai-gdpr-compliance-challenges) covers the underlying tension in depth.

Layer on the EU AI Act: deployers of certain high-risk AI systems must conduct a fundamental rights impact assessment (FRIA, Article 27) — a distinct obligation that overlaps heavily with DPIA content. The Act explicitly anticipates the two being combined, so build one assessment workflow that satisfies both rather than running parallel paperwork. Note that high-risk AI Act deadlines are in motion under the [EU Digital Omnibus](/resources/blog/eu-digital-omnibus-gdpr-ai-act-2026) — the DPIA duty under GDPR, however, applies now.

Common DPIA Mistakes

• Doing it after launch. Article 35 says "prior to the processing." A retroactive DPIA documents a violation while fixing it.
• Treating it as one-and-done. Models retrain, vendors change, features expand. An unreviewed two-year-old DPIA for an evolving system is stale evidence.
• Copy-pasting generic risks. "Risk of data breach — mitigation: security" satisfies no one. Risks must be specific to this processing and these data subjects.
• Assessing risk to the company instead of to individuals. A DPIA is not a business risk register; its subject is the people in the data.
• Confusing the DPIA with a security audit or an AI Act FRIA. They overlap, but each has distinct required content. Map the overlaps deliberately.

How PrivacyForge Helps

A DPIA is only as good as the inventory and evidence behind it — which is the layer PrivacyForge maintains for you:

• Data mapping holds the systematic description a DPIA starts from: data categories, purposes, recipients, retention, and vendors per processing activity.
• AI governance registers each AI system with its risk profile and vendor assessments, so AI-driven processing that needs a DPIA is visible instead of buried in the stack.
• Compliance scoring highlights high-risk processing patterns and documentation gaps across your program, helping you catch the "we never screened this" cases.
• Reporting keeps the audit trail — assessments, decisions, reviews — exportable for the day a regulator or enterprise customer asks.

Get a first read on your risk surface with the [free compliance scan](/scan).

Conclusion

The DPIA question — "is this processing likely to put people at high risk?" — is one every team shipping data-driven features should be able to answer on demand, with paperwork to match. The 2026 EDPB template removes the last good excuse: there is now a common, regulator-authored structure for doing this well.

Wire the screening into project intake, reuse your data map for the description, and treat the assessment as a living document. Done that way, DPIAs stop being a compliance tax and start being what they were designed as: a forcing function for building products people can trust.