The European Data Protection Board (EDPB) adopted an official template this April for the Data Protection Impact Assessment (DPIA). Public consultation open until June 9, 2026. The declared goal: simplify GDPR compliance and harmonize the way the 31 European authorities evaluate DPIAs. For a small SaaS, this move eliminates one of the most expensive ambiguities of Article 35: "how is this supposed to be done?". This article lands when you need a DPIA, how to use the new template, and what a well-done one prevents.
When GDPR Article 35 requires a DPIA
The DPIA is mandatory when processing is "likely to result in a high risk to the rights and freedoms of natural persons". GDPR gives three concrete examples:
- Systematic large-scale evaluation with legal effects (automated credit scoring, AI hiring decisions, etc.)
- Large-scale processing of special data (health, biometrics, political opinions, religion, etc.)
- Systematic large-scale observation of publicly accessible areas (CCTV, urban IoT, etc.)
National authorities have expanded the list. Spain's AEPD, for instance, also requires DPIA for processing combining datasets from different sources with profiling, high-risk AI systems under AI Act, or processing of minors.
Typical cases where a B2B SaaS needs a DPIA
| Feature | DPIA? | Why |
|---|---|---|
| Login with email + password | No | Low standard risk |
| Recommendation system based on usage history | Likely | Systematic profiling |
| Facial recognition for employee access | Yes | Biometrics + access control |
| Automated lead scoring | Yes | Automated decision with impact |
| Aggregated analytics without identifiers | No | Anonymized data |
| CV processing with AI | Yes | Employment decision |
| Chatbot recording conversations to train models | Likely | Massive processing + secondary use |
The EDPB official template: what it includes
The template adopted in April 2026 standardizes the DPIA structure in seven blocks:
- Systematic description of processing: what data, what purpose, what technology, what actors
- Necessity and proportionality: why this processing, less invasive alternatives considered
- Risk identification: probability and impact on rights
- Mitigation measures: technical, organizational, contractual
- Consultation with stakeholders or representatives (when applicable)
- Decision on processing (proceed, modify, do not proceed)
- Review plan (when it's reassessed)
The template isn't mandatory. Each national authority can adopt it or adapt their own format. But using the EDPB template eases things if your SaaS operates in multiple EU countries, because any authority will recognize it.
How to fill the template without dying trying
1. Start with operational description, not legal
Block 1 (processing description) you write in operational language: what data you take, where, what your product does with it, where it goes. If you can't explain this in one page, the problem isn't the DPIA, it's your product design.
2. Necessity and proportionality is the section where most sanctions happen
Authorities look closely at block 2. The key question: do you really need ALL this data for the declared purpose? The honest answer is usually "no, we could do it with less". If that's your case, adjust the design before defending the processing.
3. Risks are evaluated in terms of the user, not the company
Common error: drafting risks as "reputational for the company" or "regulatory sanctions". Wrong. GDPR asks to evaluate risks for USER RIGHTS AND FREEDOMS: identity, freedom of expression, discrimination, economic loss, physical/psychological harm.
4. Mitigation measures must be specific
"Encryption at rest" is vague. "AES-256 encryption at rest, keys rotated quarterly, access only for 3 internal roles with MFA" is defensible. Concrete beats generic.
5. The review plan isn't optional
A DPIA is a living document. The review plan defines when it's reassessed (typically: every 12 months, or when there's substantial change). Without review plan, the DPIA can be declared obsolete in an audit.
What a well-done DPIA prevents
- Sanction for non-compliance with GDPR Art. 35: up to 10 million euros or 2% global revenue
- Obligation to notify processing to the authority before starting (if risk isn't mitigated, you must consult AEPD per Art. 36)
- Vulnerability to individual complaints: without DPIA, you have no documentation justifying processing
- Post-incident redesign cost: much more expensive to fix a system in production than adjust at design
Practical template for a first version
If you've never done a DPIA, this is a minimum viable 1-page-per-block structure you can scale later:
- Block 1 (1 page): what your system does with personal data, in plain language
- Block 2 (½ page): why it's necessary, what alternatives you evaluated
- Block 3 (1 page): risks table: type / probability / impact / total
- Block 4 (1 page): measures table: risk / measure / responsible / deadline
- Block 5 (optional, ¼ page): who you consulted or why it doesn't apply
- Block 6 (¼ page): decision and signature of the responsible
- Block 7 (¼ page): when it's reviewed
Total: ~4 pages. Enough for a first case. The structure will scale when processing is more complex or company size requires it.
"The template adoption is aligned with the goal of the EDPB Helsinki Statement to ease GDPR compliance" (synthesis of the official EDPB communication). Operational translation: the regulator recognizes that DPIA was opaque and proposes a common standard.
Conclusion
The DPIA stopped being optional for many SaaS that didn't identify as "high risk" but technically were. The EDPB template eliminates the excuse of "we didn't know how to do it". For your SaaS, dedicating an afternoon to doing the first DPIA (even draft) is the quarter's highest return-on-time investment.
If you want to centralize Privacy Policy, Cookie Policy, ToS, and maintain published version records (useful to reference in the DPIA when there are changes), Termerly is free and simplifies SaaS legal operations from the dashboard.
