Reference — generated from the toolkit
Source of truth: toolkit/templates/dpia.md. Edit it there; this page is regenerated on build.
DPIA — {product / feature}
- ID: DPIA-{NNNN} Date started: {YYYY-MM-DD}
- Owner: … Product/feature: … Linked PFD: …
- Status: draft / in review / signed / due for review
1. Processing description
What is being done with personal data, in plain language:
- Nature — collection, storage, use, sharing, deletion; the data flow end to end (diagram or link).
- Scope — data categories and volumes, number of data subjects, geographic reach (UK / India access).
- Context — relationship with the data subjects (policyholders, claimants, employees), what they would expect.
- Purpose — the outcome for the business and for the data subject.
- AI involvement — which models/agents touch this data, under what class of the AI usage policy matrix; any automated decision-making or profiling (if yes, flag to DPO immediately).
2. Necessity & proportionality
- Lawful basis for each purpose (and Article 9 condition for any special-category data, e.g. health data in claims).
- Why this data, this much — minimisation: what was excluded, and why what remains is the minimum.
- Alternatives considered — could synthetic or anonymised data achieve the purpose? If not, why not.
- Data-subject rights — how access, rectification, erasure and portability will actually work in this design.
3. Data categories & classification
| Data category | Classification tag | Special category? | Volume / subjects | Source | Retention |
|---|---|---|---|---|---|
| {e.g. policyholder contact details} | client-confidential / regulated-PII | no | … | … | … |
| {e.g. claims medical narrative} | regulated-PII | yes — health | … | … | … |
Tags per the AI usage policy data classification matrix; these tags drive what tooling may touch the data.
4. Risks to data subjects
| # | Risk | Likelihood | Severity | Mitigation | Residual risk |
|---|---|---|---|---|---|
| 1 | {e.g. claims health data exposed to unapproved AI tool} | low/med/high | low/med/high | {e.g. guardrail denylist + classification tags} | low/med/high |
| 2 | {e.g. offshore access breaches client contract} | … | … | … | … |
| 3 | {e.g. re-identification from "anonymised" free text} | … | … | … | … |
5. Residual-risk sign-off
- Residual risks accepted: {list of #s from the table, each low}
- Any medium+ residual risk requires a risk-acceptance record and DPO agreement; any high residual risk requires prior consultation with the ICO — stop and escalate.
- Signed: {name, role, date}
6. DPO consultation record
| Date | Advice given | Accepted? (if not, why) |
|---|---|---|
| … | … | … |
7. Review
- Review date: {YYYY-MM-DD} — at latest 12 months, or on any material change to the processing.
- Change log: {date — what changed — re-assessed sections}