From privacy-legal-uk
Generate a Data Protection Impact Assessment (DPIA) under UK GDPR Art.35 in house format for a new feature, product, or processing activity. Follows the ICO DPIA template structure. Checks Art.35(3) mandatory triggers, identifies the required DPO consultation, and flags prior ICO consultation (Art.36) where residual high risk remains. Use when the user says "write a DPIA", "data protection impact assessment for", "do we need a DPIA for this", "privacy review this feature", or describes a new data processing activity requiring assessment.
How this skill is triggered — by the user, by Claude, or both
Slash command
/privacy-legal-uk:dpia-generation [feature name or description][feature name or description]The summary Claude sees in its skill listing — used to decide when to auto-load this skill
1. Load `~/.claude/plugins/config/uk-legal-plugins/privacy-legal-uk/CLAUDE.md` → DPIA house style (trigger, structure, depth, sign-off, DPO consultation requirement).
~/.claude/plugins/config/uk-legal-plugins/privacy-legal-uk/CLAUDE.md → DPIA house style (trigger, structure, depth, sign-off, DPO consultation requirement)./privacy-legal-uk:dpia-generation "Location sharing feature"
/privacy-legal-uk:dpia-generation
PRD: [link or paste]
Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph. If enabled and there is no active matter, ask: "Which matter is this for? Run /privacy-legal-uk:matter-workspace switch <slug> or say practice-level." Write outputs to the matter folder.
Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty), ask whether it's inside the privilege circle. See canonical ## Shared guardrails → Destination check in the plugin CLAUDE.md.
Special note on DPIAs: A DPIA is not automatically privileged. Where a DPIA is mandatory under Art.35(3) and a prior ICO consultation (Art.36) occurs, the DPIA becomes part of the supervisory record. Under UK GDPR Art.58(1), the ICO may request the DPIA as part of its investigative powers. A privilege claim over a DPIA will only stand where litigation privilege conditions are met (litigation in reasonable contemplation at the time the document was created). Do not assume a DPIA is protected from ICO scrutiny.
A DPIA is the structured analysis required by UK GDPR Art.35 for high-risk processing. It asks: what data, why, how long, who sees it, what could go wrong, what mitigations are in place. This skill structures that analysis and writes the output in this team's format — the one learned from the seed DPIA during cold-start.
Unlike a generic PIA, a UK GDPR DPIA has specific legal requirements: it must be done before the processing begins; it must cover the Art.35(7) mandatory content; the DPO must be consulted (Art.35(2)) where one is designated; and where the assessment concludes that residual high risk remains after mitigations, the controller must consult the ICO before processing (Art.36).
This DPIA is produced under UK GDPR as the primary regime. If EU GDPR also applies (EU data subjects, EU-established controller/processor), note this — the two regimes have parallel DPIA obligations and the ICO is not the EU supervisory authority. A DPIA produced for UK purposes does not automatically satisfy EU GDPR Art.35.
Before writing a new DPIA, check the outputs folder for prior work on the same feature, processing activity, or counterparty. Scan for:
use-case-triage results — the triage's risk rating, mandatory triggers, Children's Code flags, and PECR conditions are the entry point for this DPIA.dpia-generation outputs for the same or overlapping activity — a superseding DPIA should reconcile what changed, what carried over. A DPIA that silently produces different conclusions than a prior DPIA on the same activity is a contradiction a reviewing DPO cannot see.dpa-review outputs for vendors in scope — the DPA review's findings inform the DPIA's analysis of processor / sub-processor / international transfer risk.Cite any prior output found:
"Prior triage ([date]) rated this [risk level] and required [conditions]. This DPIA builds on that finding — [which conditions are satisfied, which remain, which are re-scoped]."
Carry severity from upstream as a floor per the cross-skill severity floor rule.
If no prior output is found, say so explicitly.
Read ~/.claude/plugins/config/uk-legal-plugins/privacy-legal-uk/CLAUDE.md → ## DPIA house style. That has:
If the seed DPIA structure is in the config CLAUDE.md, use it. The point is that this DPIA looks like the other DPIAs this team produces, not like a generic one. If no seed DPIA was provided, default to the ICO DPIA template structure (set out below).
Check the trigger criteria in ~/.claude/plugins/config/uk-legal-plugins/privacy-legal-uk/CLAUDE.md. That is the team's house answer.
In addition, research the currently operative UK GDPR Art.35 mandatory triggers using the uk-legal MCP and the ICO's published list of processing operations that require a DPIA. Cite the controlling statute and guidance with OSCOLA-style references. Verify currency — the ICO updates its DPIA guidance list. Flag uncertainty rather than guess.
No silent supplement. If the uk-legal MCP returns few or no results for Art.35(3) triggers or DPO consultation requirements, report what was found and stop. Options: (1) broaden the query; (2) check govuk MCP; (3) proceed on model knowledge tagged
[model knowledge — verify]; (4) flag as unverified and stop. A DPO or solicitor decides.
Art.35(3) mandatory triggers [UK-GDPR-ART.35(3)]:
ICO list of processing operations that always require a DPIA — check current ICO guidance via uk-legal or govuk MCP [ICO-GUIDANCE — verify current list].
Strong indicators (DPIA REQUIRED minimum, not just house trigger):
If no statutory trigger and no house trigger → write a one-paragraph "no DPIA required" note for the file, explaining why, in case anyone asks. Even "no DPIA needed" gets documented.
Before writing anything, get answers to these from the product / technical team. Conversational is fine.
For UK GDPR processing, identify the Art.6 lawful basis for each purpose. For special category data, identify the Art.9 condition in addition to the Art.6 basis. Research the specific requirements using the uk-legal MCP where available.
[DPA2018-S.123]).Use the seed DPIA structure from the config CLAUDE.md. If none was captured during setup, use the ICO DPIA template structure below.
The ICO's published DPIA template covers these sections (verify current ICO guidance for the latest version [ICO-GUIDANCE]):
Prepend the work-product header from ~/.claude/plugins/config/uk-legal-plugins/privacy-legal-uk/CLAUDE.md ## Outputs (it differs by user role).
[WORK-PRODUCT HEADER — per plugin config ## Outputs]
# Data Protection Impact Assessment: [Feature / Product Name]
## UK GDPR Art.35
**Prepared by:** [name] | **Date:** [date] | **Status:** DRAFT / APPROVED
**Product owner:** [name] | **Privacy reviewer:** [name]
**DPO consulted?:** [Yes — [name] — [date] / Not yet / N/A — no designated DPO]
---
## Executive summary
[Two sentences: what this is, whether it can proceed. E.g., "Feature X processes location
data to provide real-time navigation. Processing uses consent as the lawful basis and is
consistent with the privacy notice. Two mitigations are required before launch; no
Art.36 prior ICO consultation needed after implementing mitigations."]
**Overall risk (after mitigations):** [Reviewer to set: 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high — residual high risk = Art.36 prior ICO consultation required]
---
## 1. Identify the need for a DPIA
**Mandatory Art.35(3) trigger?** [Yes — [specify trigger] | No]
**ICO high-risk list trigger?** [Yes — [specify] | No | Could not confirm — verify current ICO list `[ICO-GUIDANCE]`]
**House trigger met?** [Yes | No]
**DPIA required because:** [one sentence]
---
## 2. Description of processing
**What:** [the feature, in plain English]
**Data categories:** [specific fields — not "user data"; identify if any are Art.9 special category or Art.10 criminal data]
**Data subjects:** [customers / end users / employees / children / etc.]
**Purpose:** [why — tie to data subject benefit and business need]
**New collection?** [yes — these fields are new / no — reusing existing data]
**Nature of processing:** [storage / analysis / automated decision-making / profiling / sharing / etc.]
**Scope:** [scale — how many data subjects, geographic extent, duration]
---
## 3. Consultation process
**DPO consultation:** [DPO consulted? Yes — [name], [date], [summary of advice given] / Not yet — required under UK GDPR Art.35(2) before finalising DPIA `[UK-GDPR-ART.35(2)]` / N/A — no designated DPO]
**Stakeholders consulted:** [product team / engineering / security / legal]
**Data subjects consulted or represented?:** [Yes — [how] / No — [reason; note Art.35(9) says the controller shall seek the views of data subjects or their representatives where appropriate]]
---
## 4. Necessity and proportionality
| Question | Assessment |
|---|---|
| Is the processing necessary for the stated purpose? | |
| Is the processing proportionate to the purpose? | |
| **UK GDPR Art.6 lawful basis:** | [basis for each purpose] |
| **UK GDPR Art.9 condition (if special category data):** | [condition + DPA 2018 Sch.1 condition if applicable] |
| If legitimate interests: LIA completed? | [Yes — [ref] / No — required before processing begins] |
| Data minimisation: is only the minimum necessary data collected? | |
| Purpose limitation: will data be used only for stated purposes? | |
| Storage limitation: is a defined retention period in place? | |
| **Children's Code applicable?** | [Yes — [conditions identified] / No — [reasoning]] |
| **PECR applicable?** | [Yes — [specific regs and consent/notice mechanism] / No] |
---
## 5. Identify and assess risks
**Risk quality standard:** Risks must be specific and tied to the design, not generic. "Data breach" is not a risk — "location history accessible by support staff via admin console without audit logging" is a risk.
| # | Risk | Description | Likelihood | Impact | Risk level |
|---|---|---|---|---|---|
| 1 | [specific risk] | [design-specific description] | L/M/H | L/M/H | 🟢/🟡/🟠/🔴 |
**Privacy notice consistency:**
| Policy commitment | Consistent? | Notes |
|---|---|---|
| [commitment from config CLAUDE.md privacy notice section] | 🟢 / 🟡 Partial / 🔴 Conflict | |
---
## 6. Identify measures to reduce risk
| # | Risk ref | Mitigation | Owner | Due | Status |
|---|---|---|---|---|---|
| 1 | [#] | [specific, actionable — not "improve security"] | [name] | [date] | Done / Planned / Gap |
**Residual risk after mitigations:** [assessment — must be specific]
**🔴 If residual high risk remains after all mitigations:** Prior ICO consultation under UK GDPR Art.36 is required before the processing begins. Do not proceed without it. `[UK-GDPR-ART.36]`
---
## 7. Data subject rights
| Right | Can be exercised for this processing? | How |
|---|---|---|
| Access (Art.15) | | |
| Erasure (Art.17) | | |
| Rectification (Art.16) | | |
| Portability (Art.20) (if consent / contract basis + automated processing) | | |
| Objection (Art.21) | | |
| Restriction (Art.18) | | |
| Rights re automated decision-making (Art.22 if applicable) | | |
---
## 8. Recommendation and sign-off
[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED / PRIOR ICO CONSULTATION REQUIRED BEFORE PROCESSING BEGINS]
**DPO sign-off:** [name, date, notes — UK GDPR Art.35(2) requires DPO consultation; their views must be documented `[UK-GDPR-ART.35(2)]`]
**Controller sign-off:** [name, date]
**Conditions before launch (if any):**
- [ ] [specific action with owner and deadline]
**Art.36 prior ICO consultation:** [Required — [reason] / Not required — residual risk is [level] after mitigations]
Risks in a DPIA must be specific and tied to the design, not generic.
| Bad risk | Why bad | Better |
|---|---|---|
| "Data breach" | Applies to everything; says nothing | "Location history accessible by support staff via admin console without audit logging — a malicious insider could track a data subject undetected" |
| "Non-compliance with UK GDPR" | Circular — the DPIA is supposed to assess compliance | Name the specific article and the gap |
| "Users might not like it" | Vague | "Data subjects who have objected to profiling under Art.21 may still have inferred scores generated because the objection flag is not checked in this flow" |
Aim for 2-5 real risks, not 15 generic ones.
Every DPIA should cross-check against the privacy notice commitments in ~/.claude/plugins/config/uk-legal-plugins/privacy-legal-uk/CLAUDE.md. Common drift:
Flag every mismatch. One of them has to change before launch.
[UK-GDPR-ART.36(2)]Producing an internal DPIA is documentation. Submitting it to the ICO (under Art.36) or disclosing it voluntarily to a third party or regulator is the consequential act.
Before submitting a DPIA to the ICO under Art.36 or disclosing to any regulator: Read ## Who's using this in the practice-level CLAUDE.md. If the Role is Non-lawyer:
Submitting a DPIA to the ICO under Art.36 has legal consequences — the document becomes part of the supervisory record and any material omission or error becomes enforcement exposure. Have you reviewed this with a solicitor or DPO? If yes, proceed. If no, here's a brief to bring to them:
[Generate a 1-page summary: regime and mandatory trigger, why Art.36 prior consultation is required, the risks identified, residual risk after mitigations, the specific ICO-facing questions, and the three things to ask the professional before submitting.]
If you need to find a qualified solicitor or barrister: the SRA's Find a Solicitor service is the fastest starting point.
Do not proceed past this gate without an explicit yes.
End with the next-steps decision tree per CLAUDE.md ## Outputs. Customize the options to what this skill just produced.
npx claudepluginhub uk-agents/uk-legal-plugins --plugin privacy-legal-ukCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.