---
name: dpia-drafter
description: Draft a UK GDPR Data Protection Impact Assessment for a new system, vendor, or processing activity — including necessity/proportionality test, risk register, mitigations, and consultation record.
version: 1.0.0
author: VantagePoint Networks
author_url: https://www.vpnetworks.co.uk
audience: DPOs, IT Managers, Compliance Leads, Project Managers introducing a new system, MSP consultants
output_format: Formatted Markdown DPIA document aligned to the ICO's recommended structure — description of processing, necessity/proportionality, risk assessment, mitigations, and sign-off.
license: MIT
last-reviewed: 2026-04
---

# DPIA Drafter

A Claude Code skill for drafting a proper Data Protection Impact Assessment under UK GDPR — producing a document that satisfies the ICO's structure, identifies real risks, and documents real mitigations, in a day rather than a fortnight.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/dpia-drafter`. Describe the processing you're assessing. Answer the clarifying questions. Receive a DPIA draft.

## When to use this

- You're introducing new tech that processes personal data (AI tools, monitoring, analytics, biometric access).
- A vendor or SaaS that handles personal data is being onboarded.
- A new business process changes how you handle personal data (remote working rollout, outsourcing, marketing automation).
- The ICO or your own DPIA threshold policy flags a new processing as "likely high risk to rights and freedoms."
- You want a template you can reuse for the next several DPIAs without rewriting from scratch.

## What you'll get

A single Markdown document containing the ICO-recommended sections:

- Step 1 — identify the need for a DPIA
- Step 2 — describe the processing (nature, scope, context, purpose)
- Step 3 — consultation (data subjects, DPO, stakeholders)
- Step 4 — necessity and proportionality
- Step 5 — identify and assess risks (likelihood × severity)
- Step 6 — identify measures to reduce risk
- Step 7 — sign-off and record outcomes
- **Ongoing review** and update triggers
- **Appendices:** data-flow diagram notes, sub-processor list, legal-basis analysis

## Clarifying questions I will ask you

1. **What's the project / processing in one sentence?**
2. **What categories of personal data?** (contact, financial, HR, health, biometric, behavioural, children)
3. **How many data subjects?** (rough estimate)
4. **Who are the data subjects?** (staff, clients, prospects, public, children, vulnerable groups)
5. **What's the lawful basis?** (consent, contract, legal obligation, vital interests, public task, legitimate interests)
6. **Is special-category data processed?** (health, ethnicity, religion, biometric, sexual orientation)
7. **New vendor / sub-processor involved?** (who, where hosted)
8. **Automated decision-making or profiling?**
9. **Is this likely to be considered "high risk"?** (large-scale, systematic monitoring, special categories, innovative tech like AI/biometric)
10. **How was the data originally collected?** (from data subject, via third party, observed, inferred)
11. **Retention period intended?**
12. **Who needs to consult on this?** (data subjects, DPO, business leads)

## Output template

```markdown
# Data Protection Impact Assessment — <project name>

**DPIA ref:** DPIA-<N> · **Version:** 1.0 · **Date:** <date>
**Prepared by:** <role> · **DPO consulted:** <Yes/No, date>
**Status:** DRAFT / FINAL / REVIEWED

## Step 1 — Identify the need for a DPIA
### Project summary
<One paragraph describing what's being introduced or changed.>

### DPIA threshold triggers
The following factors indicate a DPIA is required / strongly recommended:
- [ ] Systematic and extensive automated decision-making with legal / significant effects
- [ ] Large-scale processing of special-category or criminal-offence data
- [ ] Systematic monitoring of publicly accessible areas
- [ ] New technology (AI, biometric, IoT, tracking)
- [ ] Matching / combining datasets across controllers
- [ ] Data processed about children
- [ ] Data processed about vulnerable data subjects
- [ ] Data transfer to third countries without adequacy
- [ ] Processing preventing exercise of a right

**Conclusion:** DPIA is <required / recommended / voluntary but prudent> because <reason>.

## Step 2 — Describe the processing

### Nature of the processing
- **What's happening:** <description of how data is collected, processed, stored, shared, destroyed>
- **Source(s) of data:** <from data subject directly / from employer / from public records / inferred>
- **Recipients:** <internal roles, external vendors, third parties>
- **Sub-processors:** <named — with countries>
- **International transfers:** <Yes / No — mechanism, e.g. UK-IDTA, BCRs, adequacy>
- **Retention:** <how long, why, what happens at end>

### Scope
- **Data types:**
  | Category | Specific fields | Special category? |
  |---|---|---|
  | Contact | name, email, phone | No |
  | Employment | job title, start date | No |
  | Behavioural | log-in times, AI prompts | No |
  | Health (if any) | | Yes |
- **Number of data subjects:** <N>
- **Geographic coverage:** <UK, EEA, global>
- **Volume and frequency:** <records per day / per event>

### Context
- **Nature of relationship with data subjects:** <employee, client, prospect, public>
- **Reasonable expectations:** <what would the average data subject expect>
- **Power imbalance:** <none / employee-employer / service-provider-client>
- **Public concerns / prior issues:** <past complaints, media coverage, regulator interest>
- **Compliance with codes of conduct / ICO guidance:** <reference>

### Purpose
- **Legitimate business purpose:** <specific>
- **Benefits:** <to the org, to data subjects, to third parties>
- **Alternative less-intrusive options considered:** <list, and why rejected>

## Step 3 — Consultation
| Consulted | How | Outcome |
|---|---|---|
| DPO | <meeting / review / email> | <summary of DPO views> |
| Data subjects (where appropriate) | <survey / representatives / focus group / none — justified> | <views captured> |
| Business lead | | |
| IT / Security | | |
| Legal / Compliance | | |
| Affected third parties | | |

If data subjects weren't consulted directly, explain why: <reason, aligned to ICO guidance>.

## Step 4 — Necessity and proportionality
- **Lawful basis for processing:** <Art. 6(1)(a-f) — and (9)(a-j) if special category>. Specific reasoning below.
- **Lawful-basis analysis:**
  <paragraph addressing the specific basis chosen, why that basis fits, what happens if the data subject objects / withdraws consent>
- **Necessity:** Is this processing truly necessary to achieve the purpose, or could it be achieved with less data?
- **Proportionality:** Is the scope of data, retention, and access proportionate to the benefit?
- **Data minimisation:** What's the minimum dataset to achieve the purpose? Are we collecting more?
- **Accuracy:** How is data kept accurate and up to date?
- **Storage limitation:** Retention schedule defensible?
- **Data-subject rights:** How does this processing affect rights of access, rectification, erasure, restriction, portability, objection?

## Step 5 — Identify and assess risks

### Risk register
| # | Risk | Likelihood (1-5) | Severity (1-5) | Score | Notes |
|---|---|---|---|---|---|
| R1 | Unauthorised access via vendor breach | 2 | 4 | 8 | Vendor SOC 2 in place; data minimisation reduces blast radius |
| R2 | Data subject unaware their data is processed this way | 3 | 3 | 9 | Privacy notice update needed |
| R3 | Over-retention past purpose | 3 | 2 | 6 | Retention policy exists; technical enforcement absent |
| R4 | Function creep (used for another purpose later) | 3 | 3 | 9 | Purpose-limitation policy + periodic review |
| R5 | Automated-decision-making without sufficient human oversight | 2 | 4 | 8 | Human-in-the-loop designed in |
| R6 | International transfer weakens rights | 2 | 3 | 6 | UK-IDTA signed; sub-processor list monitored |

### Residual risk summary
After proposed mitigations (§6), residual risk is assessed as: <Low / Medium / High>.
If High: escalation to ICO consultation may be required (Art. 36).

## Step 6 — Identify measures to reduce risk
| Risk ref | Measure | Owner | Target date | Effectiveness |
|---|---|---|---|---|
| R1 | Enable customer-managed keys; quarterly access review | CTO | <date> | Reduces likelihood |
| R2 | Update privacy notice; add just-in-time notice at data-entry points | DPO | <date> | Addresses transparency |
| R3 | Technical enforcement of retention via scheduled-delete job | IT | <date> | Reduces likelihood |
| R4 | Purpose-limitation clause in contract; annual review | DPO + Legal | <date> | Reduces likelihood |
| R5 | Human-review step mandatory before action; documented | Business Lead | <date> | Reduces severity |
| R6 | Sub-processor change-notification clause; quarterly check | DPO | <date> | Maintains control |

## Step 7 — Sign-off and record outcomes
**Measures integrated back into project plan:** <ref project tracker entry>
**Residual risks accepted:** <if any, by whom, on what basis>
**ICO consultation required:** <Yes / No — if Yes, submit via ICO's Art. 36 process>

**Signed off by:**
- Project Lead: ____________________________  Date: __________
- DPO: ____________________________  Date: __________
- Business Sponsor: ____________________________  Date: __________

## Ongoing Review
Triggers for DPIA re-review:
- New data source introduced
- New recipient or sub-processor
- Change of lawful basis or retention
- Change of purpose
- New regulator guidance
- Annual re-review (minimum)

## Appendix A — Data-Flow Notes
<Text or reference to diagram showing where data moves, who touches it, where it rests.>

## Appendix B — Sub-Processor List
| Sub-processor | Country | Function | DPA signed | Transfer mechanism |
|---|---|---|---|---|
| | | | | |

## Appendix C — Lawful-Basis Decision Record
Detailed reasoning for the chosen Art. 6 (and 9 if applicable) basis.
```

## Example invocation

**User:** "We're introducing Microsoft 365 Copilot across 40 staff at our London law firm. It will have access to client-facing matter files. SRA-regulated. Want to document a DPIA before go-live."

**What the skill will do:**
1. Ask 12 questions, drilling on: whether any client privilege is at stake (yes — always, for a law firm), whether Copilot usage will be logged (yes, M365 audit), and whether SRA guidance specifically on AI has been consulted.
2. Produce the DPIA with: "High risk" threshold confirmed (AI + special categories possible + large scale for the firm); necessity/proportionality analysis that justifies Copilot over no-AI baseline; risk register including privilege exposure, client-data training concerns (addressed with EU Data Boundary), over-sharing via SharePoint.
3. Mitigations mapped to the Copilot Rollout Plan (so the DPIA and rollout plan stay in sync).
4. Consultation note: SRA / Law Society guidance checked; clients informed via privacy notice update.
5. Flag that, because this is a borderline high-risk processing at SMB scale, ICO Art. 36 prior consultation is NOT typically required but the DPIA must be retained for 7 years per firm policy.

## Notes for the requester

- **A DPIA isn't a one-time document.** Every material change triggers a review. Keep it living.
- **Consult data subjects where you can.** For employee-monitoring / staff-AI use, a brief internal consultation of staff representatives is good practice and cheap. For client data, privacy-notice updates and FAQ usually cover expectations.
- **Residual "Medium" is fine. Residual "High" is not.** If you end up at High, either add mitigation until you don't, or accept the formal ICO Art. 36 consultation route.
- **Lawful-basis analysis is the most-skipped step.** Be specific: "Art. 6(1)(f) legitimate interests — balanced against the data subject's expectations..." — not just "legitimate interests."
- **Keep the DPIA for the retention period.** Typically 7 years after the processing stops.
- **Good looks like:** a 4-6 page document that a regulator, a client, and an auditor can read in 10 minutes and conclude: yes, the firm has thought about this seriously, and the mitigations are real.

---
*VantagePoint Networks · <https://www.vpnetworks.co.uk> · Authored by Hak · Free under the MIT licence*