--- name: privacy_impact_assessment description: "Run a full privacy impact assessment (DPIA under GDPR Article 35, or a PIA under regimes like US E-Government Act Section 208): screening against the legal triggers, data mapping, necessity and proportionality testing, risk scoring focused on harm to individuals, mitigations, sign-off, and prior consultation when residual risk stays high. Ships the assessment template, a screening checklist, a risk scoring tool, and a complete worked example. Use when someone asks for a DPIA, a PIA, a privacy risk assessment for a new product, feature, vendor, or data use, whether an assessment is legally required, or how to document one for a regulator, auditor, or enterprise customer." --- # Privacy Impact Assessment ## Purpose A privacy impact assessment is a structured judgement, made before processing starts, about what a planned use of personal data could do to the people the data describes, and what will be done about it. Two forms matter in practice: - **DPIA (Data Protection Impact Assessment).** A legal duty under GDPR Article 35 where processing is likely to result in high risk to the rights and freedoms of individuals. It has mandatory content (Article 35(7)), a mandatory adviser where a Data Protection Officer exists (Article 35(2)), and a hard stop: if high risk remains after mitigation, the controller must consult the supervisory authority before processing (Article 36). - **PIA (Privacy Impact Assessment).** The broader, older term. In the US federal sector it is required by Section 208 of the E-Government Act of 2002 before an agency develops or procures IT that handles information in identifiable form. Elsewhere it is a governance document: same core method, published for transparency, without the GDPR trigger test and prior consultation stop. This skill runs the whole assessment, not a tick box version of it: - A screening record that shows why an assessment was or was not required - A data map of the processing, complete enough to assess - A necessity and proportionality test with the less intrusive alternative considered on paper - A risk register scored for harm to individuals, with mitigations, owners, and residual scores - A sign-off block that records DPO advice, the decision, and any disagreement - A review trigger list so the assessment stays live after launch Method sources: GDPR Articles 35 and 36, ICO DPIA guidance and template structure, the EDPB criteria for high risk processing, the CNIL feared events approach to privacy risk, NIST PRAM and the NIST Privacy Framework for the US side, and Section 208 of the E-Government Act of 2002. Full notes in `references/methodology.md`. ## Workflow ### 1. Screen first, and write the screening down Never jump straight to the full report. Run `assets/screening-checklist.md` against the planned processing: 1. **Article 35(3) named cases.** Any one of these makes a DPIA mandatory: systematic and extensive automated evaluation, including profiling, that produces legal or similarly significant effects; large scale processing of special category data (health, biometric, genetic, and the other Article 9 categories) or criminal offence data; systematic monitoring of a publicly accessible area on a large scale. 2. **Regulator lists.** Check the relevant supervisory authority list of processing that requires a DPIA (Article 35(4)). The ICO list, for example, also catches innovative technology, biometric and genetic processing, data matching, invisible processing, location or behaviour tracking, profiling children, and processing where a breach could endanger physical health or safety. 3. **EDPB criteria.** Score the nine criteria in the checklist. Two or more criteria met usually means high risk is likely and a DPIA is required. 4. **US federal PIA trigger.** New or substantially changed IT collecting, maintaining, or disseminating identifiable information, or a new electronic collection from 10 or more people, triggers a Section 208 PIA. Record the outcome either way. A documented decision that no DPIA is required, with the screening answers, is itself an accountability record. A vague memory that someone checked is not. ### 2. Set up the assessment properly - Name the controller, the assessor, the project owner, and every processor in scope. - Consult the DPO where one is designated. Record their advice verbatim in the sign-off block. If the controller decides against DPO advice, record the reasons. - Where appropriate, seek the views of the people affected or their representatives (Article 35(9)), and record either what they said or why consultation was not appropriate. - Pull the existing records before interviewing anyone: the record of processing activities, the data inventory, vendor contracts, retention schedule, and any earlier assessment of the same processing. A new assessment that contradicts an old one without saying so will not survive review. ### 3. Describe the processing and build the data map Use `assets/data-map.csv` as the working table. One row per data flow, covering: - Data categories and whether any are special category - Who the data describes, including whether they are vulnerable (children, employees, patients, people in a power imbalance with the controller) - Source, purpose, lawful basis, recipients, processors, and any country transfers - Retention period and what triggers deletion - Systems it touches and the security controls already in place Then write the four part description Article 35(7)(a) expects: the **nature** of the processing (what actually happens to the data, step by step), the **scope** (volume, variety, number of people, geography, duration), the **context** (the relationship with the individuals, how much control they have, what they would reasonably expect), and the **purposes**. If the team cannot fill the data map, stop. An assessment of processing nobody can describe is fiction. ### 4. Test necessity and proportionality For each purpose, work through these questions and write the answers, not just yes or no: - Lawful basis under Article 6, and the Article 9 condition if special category data is involved - Could the purpose be met with less data, less identifiable data, shorter retention, or a less intrusive method? Name the alternative that was considered and why it was accepted or rejected - Data minimisation: every field in the map traces to a stated purpose, or it comes out - Accuracy: where the data comes from, how errors get corrected, what a wrong record does to the person - Rights handling: how access, erasure, objection, and restriction requests reach this data in practice - Transparency: what the privacy notice says about this processing, in words the affected people would understand ### 5. Identify risks to individuals Risks in an impact assessment are harms to people, not harms to the organisation. A fine is a business risk. It does not belong in this register unless it is restated as what happens to the individuals. Work two passes: **Pass A, feared events (CNIL pattern).** For the data itself: illegitimate access, unwanted modification, and loss of data. For each, name the risk sources (internal and external, human and non-human), the threats on the systems and media the data sits on, and the effect on individuals if it happens. **Pass B, harm from the processing working as designed.** Perfect security does not fix these: - Discrimination or unfair denial of a service, price, job, or benefit - Automated decisions with no meaningful human review or route to challenge - Loss of control: data reused for purposes people never agreed to or expected (function creep) - Chilling effects: people avoiding a service, a place, or a conversation because they feel watched - Re-identification of data that was sold or shared as anonymous - Identity theft and fraud after a breach - Financial loss, reputational damage, distress, and, for location or health data, physical harm - People being unable to exercise their rights because the controller cannot find, correct, or delete their data Use the harm prompts in `references/methodology.md` and the NIST PRAM idea of problematic data actions: ask what the data action itself (collection, retention, sharing, inference) does to people, not only what an attacker could do. ### 6. Score the risks Score every risk on severity and likelihood, each on the 1 to 4 scale defined in `references/methodology.md`: - **Severity** is judged from the harm to individuals: sensitivity of the data, how identifiable people are, how many are affected, whether they are vulnerable, and whether the harm can be undone. - **Likelihood** is judged from the risk sources and threats, how exposed the processing is, and how well existing controls actually work, not how well the policy says they work. Run the register through the scoring tool so the arithmetic and bands are consistent: ``` python3 bin/score_risks.py assets/risk-register.csv ``` It prints inherent and residual scores with bands, and flags any residual High. Judge the score, do not worship it: if the band looks wrong for the facts, change the inputs and write down why. ### 7. Mitigate, then rescore For each risk, pick measures that change the severity or the likelihood, assign an owner and a date, and rescore to a residual. Measures that usually move a score: - Collect less, identify less, keep it for less time - Pseudonymise or aggregate, with the key held separately and access logged - Human review with real authority to overturn automated outputs, plus a published challenge route - Access control on least privilege, encryption in transit and at rest, audit logs that someone actually reads - Contract terms and audits for processors, transfer safeguards for cross border flows - Clear notice, real choices, and defaults set to the least intrusive option What is left after mitigation gets an explicit decision per risk: reduce further, avoid by dropping the feature, transfer, or accept with a named person accepting it. Undocumented acceptance is not acceptance, it is a gap. ### 8. Decide, sign off, and respect the hard stop Complete the sign-off block in `assets/dpia-template.md`: assessor, DPO advice, decision, accepted residual risks, review date. **Hard stop.** If any residual risk is still High, the controller must consult the supervisory authority before processing starts (Article 36). The authority replies with written advice within 8 weeks, and can extend by 6 weeks for complex processing. Processing does not begin while that is open. For a Section 208 PIA, the equivalent gate is CIO review and approval before the system goes live, with the PIA made public unless an exception applies. ### 9. Integrate and keep it under review - Move every mitigation into the project plan as a tracked task with an owner. An assessment whose actions live only inside the assessment document changes nothing. - Set the review triggers: change of purpose, new data category, new vendor or country, new technology, scale jump, an incident involving this data, or a change in the risk itself (Article 35(11)). Review on any trigger, and on the scheduled date, whichever comes first. - File the assessment with the record of processing so the next assessor finds it. ## Output Contract Every run produces, in this order: 1. **Screening record.** The checklist answers, the trigger analysis, and the decision, signed and dated even when the answer is no assessment required. 2. **Data map.** The completed flow table from `assets/data-map.csv`. 3. **Assessment report.** The completed `assets/dpia-template.md`: description of processing, necessity and proportionality, consultation record, risk register reference, measures, residual position, sign-off. 4. **Scored risk register.** The register CSV plus the scoring tool output, inherent and residual, with any residual High flagged and the prior consultation step stated. 5. **Action list.** Each mitigation as a task: owner, date, and where it is tracked in the project plan. A worked example of all five, for a fictional staff location tracking rollout, is in `references/worked-example.md`. Read it before your first assessment for this skill. ## Operating Rules 1. Risks are scored for harm to individuals. If a line in the register is really about cost, fines, or embarrassment to the organisation, rewrite it as the harm to people or move it to the business risk register. 2. The DPO advises, the controller decides. Record both. Never present DPO advice as DPO approval, and never bury a disagreement. 3. Do not start, and do not advise starting, processing with a residual High risk before prior consultation concludes. This is a stop, not a paperwork delay. 4. Never backdate a screening or an assessment, and never write one after launch and present it as done beforehand. If an assessment is retrospective, label it retrospective and say why. 5. Check the current regulator list and the current law for the jurisdiction in scope before relying on the trigger lists here. Lists change, and a UK list does not settle an EU question or the other way round. 6. This skill produces an assessment, not legal advice. Where the trigger test is genuinely borderline, or prior consultation is in play, say plainly that qualified counsel in the jurisdiction should review it. 7. Keep personal data out of the assessment itself. Describe categories and counts. A DPIA that contains a real person's health record is a new processing problem, not evidence. 8. Write plainly. If the people affected by the processing could not follow the summary of the assessment, the summary is not finished.