What Is a DPIA?
A Data Protection Impact Assessment (DPIA) is a structured process for identifying and minimising the data protection risks of a project or processing activity before you launch it. It's required by GDPR Article 35 when processing is likely to result in a high risk to the rights and freedoms of natural persons.
The key word is before. A DPIA is a preventive tool — you run it before deployment, not after something goes wrong. Running one after launch doesn't eliminate the GDPR violation of having failed to run it earlier.
When Is a DPIA Mandatory? (The GDPR Article 35 Triggers)
GDPR Article 35(3) lists three processing types that always require a DPIA:
- Systematic and extensive automated decision-making — including profiling — that produces legal or similarly significant effects on individuals (e.g. credit scoring, insurance pricing, job application screening)
- Large-scale processing of special category data — health, biometric, racial/ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, sex life / sexual orientation
- Systematic large-scale monitoring of a publicly accessible area — e.g. CCTV, location tracking
Beyond these three, each EU data protection authority (DPA) publishes a list of processing types requiring a mandatory DPIA in their jurisdiction. These lists are available on each DPA's website and typically include: employee monitoring, behavioural advertising, data broker activities, and government / law enforcement processing.
The WP29 / EDPB Nine Criteria
The Article 29 Working Party (now EDPB) issued guidelines identifying 9 criteria that indicate high-risk processing. If your processing meets two or more, a DPIA is recommended even if not strictly mandated:
| # | Criterion | SaaS Examples |
|---|---|---|
| 1 | Evaluation or scoring of individuals | User credit scoring, health risk assessment, lead scoring with personal data |
| 2 | Automated decision-making with legal or significant effects | Automated loan decisions, insurance underwriting, job candidate shortlisting |
| 3 | Systematic monitoring | Employee monitoring software, continuous location tracking, network traffic monitoring |
| 4 | Sensitive data or highly personal data | Health records, financial data, location, communications content, children's data |
| 5 | Data processed at large scale | Any SaaS processing data of >100,000 individuals across the EU |
| 6 | Matching or combining datasets | Combining CRM data with third-party data enrichment; linking behavioural analytics to identity |
| 7 | Data about vulnerable individuals | Children (EdTech), patients (HealthTech), employees (HR SaaS), asylum seekers |
| 8 | Innovative use or novel technologies | AI-powered features, facial recognition, emotion detection, LLM-based processing of user data |
| 9 | Data transfers outside the EU with inadequate protection | Sending personal data to US processors without SCCs or BCRs in place |
Common SaaS Scenarios That Trigger a DPIA
- AI / ML feature on user data: Training a model on user conversations, documents, or behaviour. Meets criteria 2, 5, and 8 — DPIA required.
- Employee monitoring software: Screenshots, keystroke logging, productivity tracking. Meets criteria 3, 4, 7 — DPIA required.
- HealthTech SaaS processing patient data: Meets criteria 4, 5 automatically — DPIA mandatory under Art. 35(3)(b).
- EdTech processing children's data at scale: Meets criteria 5, 7 — DPIA recommended and likely mandatory.
- B2B analytics combining customer data sources: Meets criteria 1, 6 — DPIA recommended.
- Profiling-based personalisation: Content recommendation, pricing personalisation based on individual profiles. Meets criteria 1, 2.
What a DPIA Must Contain (Art. 35(7))
GDPR Article 35(7) specifies four mandatory elements:
- Systematic description of processing: Purpose, nature, scope, context, categories of data and data subjects
- Assessment of necessity and proportionality: Why is this processing necessary for the purpose? Could a less intrusive approach achieve the same goal?
- Assessment of risks to individuals: What are the likelihood and severity of risks? Unauthorised access, discrimination, financial loss, reputational damage, physical harm, loss of autonomy?
- Measures to address the risks: Technical and organisational measures to mitigate identified risks. Residual risk assessment after measures.
DPIA Process: Step by Step
Step 1 — Screen for Necessity
Before starting a full DPIA, run a quick screening: does the processing meet two or more WP29 criteria? If not, document your screening decision (this itself shows good faith). If yes, proceed.
Step 2 — Describe the Processing
- What personal data is processed? (categories, volume, source)
- Who are the data subjects? (customers, employees, third parties, vulnerable groups?)
- What is the purpose and lawful basis?
- Who has access? (internal teams, third-party processors)
- How long is data retained?
- Where is data transferred? (EU/EEA, or third countries?)
Step 3 — Assess Necessity and Proportionality
- Is the processing necessary for the stated purpose?
- Is the data collection limited to what's necessary (data minimisation, Art. 5(1)(c))?
- Are privacy-preserving alternatives available (anonymisation, aggregation, pseudonymisation)?
- Is the lawful basis appropriate and documented?
Step 4 — Identify and Assess Risks
For each risk, assess: likelihood (1 = unlikely, 2 = possible, 3 = likely) × severity (1 = minor, 2 = significant, 3 = severe) = risk score (1–9). Risk scores of 6+ require mitigation.
Common SaaS risks to assess:
- Unauthorised access (data breach)
- Discrimination / unfair automated decisions
- Financial harm to individuals
- Reputational damage
- Loss of confidentiality for sensitive data
- Profiling / loss of individual autonomy
- Data subject unable to exercise rights
Step 5 — Define Mitigation Measures
- Encryption (at rest and in transit)
- Access controls (RBAC, MFA, least privilege)
- Pseudonymisation or anonymisation where feasible
- Human review of automated decisions
- Data minimisation (collect less, retain less)
- User rights tooling (access, deletion, correction, objection)
- Vendor controls (Art. 28 DPAs, sub-processor list)
- Regular security testing
Step 6 — Assess Residual Risk
After mitigations, re-score each risk. If any residual risk remains high (score 6+), you must consult your supervisory authority before proceeding (Art. 36 prior consultation). This is rare for typical SaaS processing if proper mitigations are in place.
Step 7 — Document and Approve
The DPIA must be approved by a senior decision-maker (typically DPO, if you have one, plus engineering/product lead). Keep the document — it's part of your Records of Processing Activities (RoPA) under Art. 30.
Step 8 — Review
DPIAs are living documents. Review when: (1) the processing changes materially; (2) new risk information emerges; (3) a new technology is introduced; (4) periodically (annually or bi-annually as a minimum).
Do I Need a DPO to Run a DPIA?
No — but if you have a DPO, they must be consulted (Art. 35(2)). If you don't have a DPO, the data controller (you) runs the DPIA. For complex processing or novel AI features, engaging an external privacy consultant for the DPIA is prudent.
Consequences of Skipping a Required DPIA
Failure to conduct a mandatory DPIA is itself a GDPR violation under Art. 83(4), subject to fines of up to €10 million or 2% of global annual turnover. The EDPB has issued fines specifically for DPIA failures, independent of whether a breach occurred.
Examples from enforcement: Spanish DPA fined Vodafone €75,000 for launching a service without a required DPIA; Belgian DPA found IAB Europe's Transparency and Consent Framework violated Art. 35 for failing to conduct DPIAs on high-risk processing.
DPIA and Privacy by Design
The DPIA process is the implementation mechanism for Privacy by Design (Art. 25). By running DPIAs before product launches, you systematically embed privacy into your development process rather than bolting it on afterward.
👉 Generate your GDPR Privacy Policy — documents your processing activities and lawful bases.
👉 Generate a GDPR Data Processing Agreement — required for any sub-processor relationship identified in your DPIA.
Key Takeaways
- A DPIA is mandatory before high-risk processing under GDPR Art. 35 — failure to conduct one is independently punishable.
- Use the EDPB's 9 criteria: two or more triggers = DPIA required.
- AI features, employee monitoring, large-scale health data, and behavioural profiling are the most common SaaS triggers.
- A DPIA must cover: description, necessity assessment, risk assessment, and mitigation measures.
- DPIAs are living documents — update them when processing or risk profile changes.