---
title: "Data Protection Impact Assessment (DPIA)"
processing_activity: "REPLACE — short name of the activity assessed"
controller: "REPLACE — legal name of the controller"
last_reviewed_at: "REPLACE — YYYY-MM-DD"
review_cadence_days: 365
risk_level: "REPLACE — low | medium | high"
---

> ⚠️ **STARTER TEMPLATE — REPLACE BEFORE COMMITTING.**
> Installed on demand via `devaudit bootstrap-governance` (v0.1.36+) as a starting point.
> It does **not** describe your project's actual data protection risks. Edit before committing.
> Auditors reject unedited stubs. See `docs/governance-templates.md` for guidance.

# Data Protection Impact Assessment

**Framework coverage:** `GDPR.Art-35` (Data protection impact assessment)

**Evidence type:** `dpia` · **Cadence:** refresh every 365 days, or whenever the processing materially changes.

> A DPIA is **mandatory** for processing likely to result in high risk to data subjects: large-scale special-category data, systematic monitoring, automated decision-making with legal effect, etc. See Art. 35(3) and your supervisory authority's "blacklist" guidance.

## Uploading this artefact

- **File path:** `compliance/governance/dpia.md` (or `dpia-<reqid>.md` for a per-REQ DPIA tied to a HIGH-risk requirement). Kept in-repo for review; CI does NOT upload it.
- **Upload trigger:** manual via the portal Upload Evidence form at `/projects/<slug>/upload` — select evidence type `dpia`. Tier-2 governance docs are operator-uploaded only since DevAudit-Installer v0.1.39 — the previous CI auto-upload was treating placeholder content as canonical evidence. The matrix MISSING row for `GDPR.Art-35` renders an `Upload dpia.md →` deep-link that pre-fills the form for you.
- **Verify after upload:** open `/projects/<slug>/compliance`. The **GDPR Art. 35** clause should flip MISSING → COVERED immediately.
- **Refresh cadence:** annually (365 days), or sooner whenever the assessed processing materially changes (new data category, new recipient, new automated-decision path). The portal renders an inline `Expires YYYY-MM-DD` on the clause (amber within 30 days, red once stale).

## Framework checklist — GDPR Art. 35

- [ ] §1 Description of processing: purpose + scope + lawful basis + data flow diagram or text-equivalent
- [ ] §2 Necessity + proportionality: justified why this processing is needed, alternatives considered
- [ ] §3 Risks to rights and freedoms: each risk → likelihood + severity + affected data subjects
- [ ] §4 Measures to address the risks: each risk has a concrete mitigation (technical or organisational)
- [ ] §5 Consultation: DPO + affected stakeholders consulted (or "not applicable — sole-dev project" stated explicitly)
- [ ] §6 Sign-off: data controller approval recorded with date

## 1. Description of the processing

- **Activity name:** REPLACE
- **Nature, scope, context, purposes:** REPLACE — what data is processed, how, why, for whom, at what scale
- **Data flow diagram or reference:** REPLACE — link to architecture doc / threat model
- **Cross-reference to ROPA:** `compliance/governance/ropa.md` activity REPLACE

## 2. Necessity and proportionality

- **Lawful basis (Art. 6):** REPLACE
- **Special-category basis (Art. 9), if applicable:** REPLACE
- **Less-intrusive alternatives considered:** REPLACE
- **Data minimisation:** REPLACE — what's not collected and why
- **Retention justification:** REPLACE
- **Data subject rights — how exercised:** REPLACE — link to SAR procedure, rectification, erasure, portability

## 3. Risks to rights and freedoms

For each risk, populate one row. Add or remove rows to fit your assessment.

| # | Risk | Likelihood (1–3) | Severity (1–3) | Inherent risk | Existing controls | Residual risk | Acceptable? |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | REPLACE — e.g. unauthorised access to user accounts | REPLACE | REPLACE | REPLACE | REPLACE — MFA, RBAC, encryption-at-rest | REPLACE | REPLACE Y/N |
| 2 | REPLACE | | | | | | |

## 4. Measures to address the risks

- **Technical measures:** REPLACE — encryption, pseudonymisation, access controls, logging
- **Organisational measures:** REPLACE — training, policies, contractual safeguards
- **Residual high risk?** REPLACE — if YES, you must consult the supervisory authority (Art. 36) **before** processing begins. Document the consultation outcome.

## 5. Consultation

- **DPO opinion:** REPLACE — name, date, conclusion
- **Data subjects / representatives consulted:** REPLACE — describe or document why not
- **Supervisory authority prior consultation:** REPLACE — required only when residual high risk remains

## 6. Sign-off

| Role | Name | Date | Decision |
| --- | --- | --- | --- |
| Controller | REPLACE | REPLACE | REPLACE — approved / rejected / conditional |
| DPO | REPLACE | REPLACE | REPLACE |
| Technical lead | REPLACE | REPLACE | REPLACE |

## Sources

- [EDPB DPIA guidelines (WP248 rev.01)](https://edpb.europa.eu/our-work-tools/our-documents/guidelines/)
- [ICO DPIA template](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/)
- [CNIL PIA software](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assessment)

## Review log

| Date | Reviewer | Changes |
| --- | --- | --- |
| REPLACE — YYYY-MM-DD | REPLACE | Initial DPIA authored from starter template |