Data Protection Impact Assessment
A structured process for identifying, evaluating, and mitigating the privacy risks of a project, feature, or system before it is built — turning data protection from an abstract legal requirement into concrete design decisions.
What is it?
A Data Protection Impact Assessment (DPIA) is the formal tool that connects data governance principles to engineering practice. It’s a structured analysis you conduct before building a feature that processes personal data, asking: what could go wrong, how likely is it, and what will I do to prevent it?
Under the GDPR (Art. 35) and Swiss nDSG (Art. 16), a DPIA is legally required when processing is “likely to result in a high risk to the rights and freedoms of natural persons.” But even when not legally mandated, a DPIA is valuable as a design tool — it forces you to think through data flows, identify risks, and document decisions before writing code.1
A DPIA is not a bureaucratic exercise. Done well, it produces specific, actionable architectural requirements: minimum aggregation thresholds, encryption standards, retention periods, access controls, and user-facing transparency features. It’s the bridge between “we should respect privacy” and “here’s exactly how we’ll do it in this system.”2
In plain terms
A DPIA is like an environmental impact assessment before building a factory. Before construction begins, you study what the factory will emit, who will be affected, and what safeguards will prevent harm. You don’t build first and assess later — by then, the damage is done and retrofitting is expensive.
At a glance
The DPIA process (click to expand)
graph TD A[Describe the Processing] --> B[Assess Necessity & Proportionality] B --> C[Identify Risks] C --> D[Evaluate Risk Level] D --> E[Define Mitigations] E --> F[Document & Approve] F --> G[Monitor & Review] G -->|Processing changes| A style C fill:#4a9ede,color:#fff style E fill:#4a9ede,color:#fffKey: The DPIA is cyclical — it’s revisited when processing changes. The two critical steps (highlighted) are risk identification and mitigation definition, where governance principles become architecture decisions.
How does it work?
When is a DPIA required?
Under GDPR Art. 35, a DPIA is mandatory when processing involves:1
| Trigger | Example |
|---|---|
| Systematic evaluation of personal aspects (profiling) | Recommendation engine based on user behaviour |
| Large-scale processing of sensitive data | Health data, political opinions, biometric data |
| Systematic monitoring of public areas | CCTV, location tracking |
| New technologies with unknown risks | AI-powered decision-making |
| Combining datasets in unexpected ways | Merging user analytics with public records |
| Processing that could prevent rights exercise | Blocking access based on automated scoring |
Developer rule of thumb
If you’re uncertain whether a DPIA is required, do one anyway. A DPIA that finds low risk takes a few hours and documents your due diligence. Skipping one that should have been done can cost millions.
The seven stages
Stage 1 — Describe the processing
Document what you’re planning to build:
- What personal data will be processed?
- Why? (Purpose and legal basis)
- How? (Technical architecture, data flows)
- Who? (Data subjects, data processors, recipients)
- Where? (Storage locations, cross-border transfers)
- How long? (Retention periods)
Think of it like...
A doctor taking a patient history before prescribing treatment. You need the full picture before you can diagnose risks.
Stage 2 — Assess necessity and proportionality
For each piece of data and each processing activity, ask:3
- Is this necessary? Could we achieve the purpose with less data?
- Is this proportionate? Does the benefit justify the privacy intrusion?
- Is there a less invasive alternative? Could we use anonymised or aggregated data instead?
Stage 3 — Identify risks
Map out what could go wrong. Think from the data subject’s perspective:
| Risk category | Example risks |
|---|---|
| Confidentiality | Data breach, unauthorised access, accidental disclosure |
| Integrity | Data corruption, inaccurate records, wrong recommendations |
| Availability | System failure preventing data access or deletion |
| Re-identification | Aggregated data enabling individual identification |
| Function creep | Data collected for one purpose used for another |
| Discrimination | Biased algorithms producing unfair outcomes |
| Chilling effect | Users avoiding legitimate activities due to surveillance fears |
Stage 4 — Evaluate risk level
For each risk, assess:
| Dimension | Scale |
|---|---|
| Likelihood | Unlikely — Possible — Likely — Almost certain |
| Severity | Negligible — Limited — Significant — Maximum |
The combination produces a risk level:
Risk Level = Likelihood x Severity
Negligible Limited Significant Maximum
Unlikely Low Low Medium Medium
Possible Low Medium Medium High
Likely Medium Medium High High
Almost cert. Medium High High Critical
Stage 5 — Define mitigations
For each medium/high/critical risk, specify concrete mitigations:
| Risk | Mitigation | Architecture implication |
|---|---|---|
| Re-identification via small counts | Minimum display threshold of 10 | WHERE count >= 10 in queries; suppress results below threshold |
| Geographic re-identification | Aggregate at canton level, not commune | Geographic data model uses canton-level granularity |
| Unauthorised access | Field-level encryption for PII | Encrypt columns containing personal data at rest |
| Function creep | Purpose-separated databases | Separate schemas for analytics vs user data |
| Inaccurate AI recommendations | Disclaimers + human review | Pre-output disclaimer component; review queue for edge cases |
For example: DPIA for a community matching feature
Feature: “23 others in your area care about this topic”
Processing described:
- User interests stored per account
- Geographic location (commune level)
- Count of users per geography per topic
Risks identified:
- Re-identification: small count + specific commune + niche topic = identified individual (Likelihood: Likely, Severity: Significant → HIGH)
- Function creep: interest data used for political profiling (Likelihood: Possible, Severity: Maximum → HIGH)
- Chilling effect: users avoid expressing interests if they fear being identified (Likelihood: Possible, Severity: Significant → MEDIUM)
Mitigations:
- Minimum threshold: 10 (never display counts below 10)
- Geographic aggregation: canton level, not commune
- Consider differential privacy for counts
- No profiling: interests never used for recommendations
- Clear privacy notice explaining what is stored and how
Residual risk after mitigation: LOW
Stage 6 — Document and approve
The DPIA document should be:
- Signed off by the project lead or data protection officer
- Stored as a project artefact (version-controlled)
- Referenced in the system’s privacy notice
- Updated when the processing changes
Stage 7 — Monitor and review
A DPIA is not a one-time document. Review it:
- When the feature changes significantly
- When new data sources are added
- When the regulatory environment changes
- At regular intervals (annually minimum)
Concept to explore
The DPIA’s risk identification step draws heavily on re-identification-risk analysis. If your processing involves aggregated or anonymised data, re-identification risk is often the highest-priority risk to assess.
Why do we use it?
Key reasons
1. Legal requirement. GDPR Art. 35 and nDSG Art. 16 mandate DPIAs for high-risk processing. Failure to conduct one when required is a regulatory violation in itself — regardless of whether harm actually occurs.
2. Design tool. A DPIA turns abstract privacy principles into concrete architecture requirements. It tells you exactly what thresholds to set, what to encrypt, what to log, and what to suppress.
3. Defensibility. If a complaint or incident occurs, a completed DPIA demonstrates that you identified risks and took reasonable steps to mitigate them. It’s your evidence of due diligence.
When do we use it?
- Before building any feature that processes personal data at scale
- Before deploying AI systems that make decisions about or affecting individuals
- Before combining datasets that could enable re-identification
- Before processing sensitive data (health, politics, religion, ethnicity)
- Before using new technologies whose privacy impact is unclear
- When a regulator or data protection officer requests one
- When an existing feature’s processing changes significantly
Rule of thumb
A DPIA should happen during the design phase, not after launch. If you’re already writing code, you’ve waited too long. The best time for a DPIA is when you’re drawing architecture diagrams and writing specifications.
How can I think about it?
The pre-flight checklist analogy
Pilots run pre-flight checklists before every flight. They don’t skip it because “the plane was fine yesterday.” They check fuel, instruments, controls, weather — systematically, every time.
A DPIA is your pre-flight checklist for data processing:
- Fuel = legal basis (do you have a valid reason?)
- Instruments = data flows (do you know where data goes?)
- Controls = mitigations (can you respond to risks?)
- Weather = threat landscape (what could go wrong?)
Flying without a pre-flight check is reckless. Processing personal data without a DPIA is the same.
The fire safety assessment analogy
Before a building is occupied, a fire safety assessment identifies risks (flammable materials, overcrowding, blocked exits) and requires mitigations (sprinklers, fire doors, emergency lighting, evacuation plans).
The assessment doesn’t prevent all fires. But it ensures that when a fire occurs, the damage is minimised and the building owner can prove they took reasonable precautions.
- Risk identification = fire hazards = data risks
- Mitigations = sprinklers = encryption, thresholds, access controls
- Documentation = fire safety certificate = DPIA report
- Regular review = annual inspection = DPIA update cycle
Concepts to explore next
| Concept | What it covers | Status |
|---|---|---|
| re-identification-risk | The most common high-risk finding in DPIAs | complete |
| privacy-by-design | The architectural principle that DPIAs operationalise | complete |
| personal-data-protection | The legal framework that triggers DPIA requirements | complete |
Some cards don't exist yet
A broken link is a placeholder for future learning, not an error.
Check your understanding
Test yourself (click to expand)
- Explain — Why should a DPIA be conducted during the design phase rather than after a feature is built?
- Name — List the seven stages of a DPIA process.
- Distinguish — What is the difference between a DPIA (a process) and Privacy by Design (a principle)? How do they relate?
- Interpret — You’re building a feature that combines user location data with topic interests and displays counts per area. The DPIA identifies re-identification as a HIGH risk. What specific mitigations would you implement?
- Connect — How does the DPIA’s “necessity and proportionality” assessment relate to the data minimisation principle of data protection law?
Where this concept fits
Position in the knowledge graph
graph TD A[Data Governance] --> B[DPIA] A --> C[Privacy by Design] A --> D[Personal Data Protection] B --> E[Risk Assessment Methodology] B --> F[Processing Records] B --> G[Data Protection Officer] style B fill:#4a9ede,color:#fffRelated concepts:
- privacy-by-design — DPIA is the process that operationalises PbD principles into specific mitigations
- re-identification-risk — the most common high-risk finding in DPIAs involving aggregated data
- personal-data-protection — the legal framework that defines when DPIAs are mandatory
Sources
Further reading
Resources
- Data Protection Impact Assessment: Complete Guide — Comprehensive DPIA guide with GDPR Article 35 analysis
- Data Protection Impact Assessments: When and How — Practical guide with examples
- 7 Key Stages of the DPIA Process — Step-by-step DPIA process breakdown
- How to Build a DPIA: A Template-Based Approach — Template-driven approach for teams doing their first DPIA
- GDPR DPIA Guide: Complete Step-by-Step — Audit-focused guide with compliance checklists
Footnotes
-
GDPR Local. (2026). Data Protection Impact Assessment (DPIA): Complete Guide. GDPR Local. ↩ ↩2
-
Bastion. (2026). Data Protection Impact Assessments (DPIA): When and How. Bastion. ↩
-
IT Governance. (2025). 7 Key Stages of the Data Protection Impact Assessment (DPIA). IT Governance. ↩