A Data Protection Impact Assessment (DPIA) is a structured process for identifying and reducing the privacy risks of a new processing activity before it goes live. Under GDPR Article 35, a DPIA is mandatory for processing likely to result in high risk to individuals. For everyone else, it is best practice whenever you build a new feature that handles personal data in a non-trivial way.
This guide explains when a DPIA is required, how to run one, and what a completed DPIA should contain.
When a DPIA Is Mandatory
Article 35 requires a DPIA when processing is "likely to result in a high risk." Three types of processing always require one:
- Systematic and extensive evaluation or profiling of individuals with legal or similarly significant effects — this includes credit scoring, behavioural profiling, and automated hiring decisions
- Large-scale processing of special category data — health data, biometric data, ethnic origin, political opinions, etc.
- Systematic monitoring of a publicly accessible area — surveillance systems
Beyond these three, the European Data Protection Board (EDPB) has identified additional criteria that indicate high risk. If two or more apply, a DPIA is recommended:
- Evaluation or scoring (including profiling)
- Automated decision-making with significant effects
- Systematic monitoring
- Processing sensitive or highly personal data (special categories, financial, location data)
- Large-scale data processing
- Matching or combining datasets from different sources
- Processing data about vulnerable data subjects (children, employees, patients)
- Using new technology or applying existing technology in a novel way
- Processing that prevents individuals from exercising a right or using a service
For SaaS companies, a DPIA is commonly triggered by: onboarding AI features, adding behavioural tracking, processing health data, expanding into new jurisdictions, or acquiring a new data source.
When to Run a DPIA
A DPIA must be completed before the processing starts — not after. Running a DPIA on an existing feature that has been live for a year is still useful for documentation, but it cannot satisfy the Article 35 requirement retroactively.
The practical implication: DPIA should be part of your product development process. When a feature involves personal data and reaches the high-risk criteria, trigger a DPIA at the design stage.
The Five Steps of a DPIA
Step 1 — Describe the Processing
Document what you are doing:
- What data will be processed?
- Who will it be collected from?
- What is the source of the data?
- What will be done with it?
- Who will have access?
- Where will it be stored?
- How long will it be kept?
This is essentially a detailed RoPA entry for the specific processing activity.
Step 2 — Assess Necessity and Proportionality
Evaluate whether the processing is justified:
- Is the purpose legitimate?
- Is the processing necessary to achieve that purpose?
- Could a less privacy-invasive approach achieve the same result?
- What is the lawful basis?
- How does the processing respect data subject rights?
This step forces you to challenge your own design decisions. If you are processing location data of users but only need to know their country for tax purposes, location tracking is disproportionate.
Step 3 — Identify the Risks
Identify risks to data subjects — not to your business. Relevant risks include:
| Risk type | Example |
|---|---|
| Unauthorised access or breach | Data exfiltration exposing user records |
| Discrimination | AI model producing biased outputs affecting individuals |
| Identity theft or fraud | Processing financial data without adequate security |
| Financial loss | Insecure payment data handling |
| Reputational damage | Sensitive information leaked |
| Loss of control over personal data | Third-party data sharing without adequate controls |
| Profiling and loss of anonymity | Behavioural tracking identifying users across services |
For each risk, assess: the likelihood it occurs, and the severity of the harm to individuals if it does. Document both.
Step 4 — Identify Measures to Address the Risks
For each identified risk, document:
- The technical measures you will implement (encryption, access controls, anonymisation, data minimisation)
- The organisational measures (training, policies, contractual controls with third parties)
- The residual risk after measures are applied
A DPIA does not require you to eliminate all risk — it requires you to reduce risk to an acceptable level and document that you have done so. If residual risk remains high, consult your supervisory authority before proceeding (Article 36 — prior consultation).
Step 5 — Conclude and Document
Record:
- Your conclusion — is the processing justified given the risks and mitigations?
- The measures implemented or committed
- Whether any residual risks require further action
- Who conducted the assessment and when
- Whether DPO advice was sought (if you have a DPO)
DPIA Template
DPIA Reference: [number]
Processing Activity: [name]
Date: [date]
Conducted by: [name, role]
DPO consulted: Yes / No / N/A
---
SECTION 1 — DESCRIPTION OF PROCESSING
Purpose: [why you are processing this data]
Data subjects: [who the data is about]
Personal data categories: [what types]
Special categories: [yes/no — specify if yes]
Source of data: [where it comes from]
Processing operations: [what you do with it]
Data recipients: [who you share with]
International transfers: [if applicable, mechanism]
Retention: [how long]
Technology and systems involved: [platforms, vendors]
---
SECTION 2 — NECESSITY AND PROPORTIONALITY
Lawful basis: [Article 6 basis — and Article 9 if special categories]
Is the processing necessary for the stated purpose? [yes, with rationale]
Could the purpose be achieved with less data or less invasive processing? [assessment]
Compliance with data minimisation: [what minimisation measures are in place]
Data subject rights: [how rights are respected and exercised]
---
SECTION 3 — RISK ASSESSMENT
| Risk | Likelihood (1-3) | Severity (1-3) | Risk score | Mitigation |
|---|---|---|---|---|
| [Risk 1] | [1-3] | [1-3] | [L×S] | [measure] |
| [Risk 2] | | | | |
Risk scoring: 1 = low, 2 = medium, 3 = high
Residual risk after mitigation: Low / Medium / High
---
SECTION 4 — MEASURES
Technical measures:
- [e.g., AES-256 encryption at rest and in transit]
- [e.g., Role-based access controls with audit logging]
- [e.g., Data anonymisation for analytics]
Organisational measures:
- [e.g., Staff training on data handling]
- [e.g., DPA signed with all processors]
- [e.g., Breach response procedure in place]
---
SECTION 5 — CONCLUSION
Residual risk level: [Low / Medium — proceed / High — prior consultation required]
Decision: [Proceed / Proceed with conditions / Do not proceed / Consult DPA]
Conditions (if any): [list any outstanding actions]
Review date: [when this DPIA should be reviewed]
Signed: [name, role]
Date: [date]
Prior Consultation
If your DPIA concludes that residual risk remains high despite all mitigations, you must consult your supervisory authority before proceeding (Article 36). The DPA will review and respond within 8 weeks (extendable to 14 weeks for complex cases). They may:
- Provide written advice
- Advise against the processing
- Request additional information
- Impose conditions or restrictions
This situation is uncommon for typical SaaS features, but it applies to genuinely high-risk processing — large-scale health data processing, real-time biometric identification, or novel AI systems with significant individual impact.