# Privacy Impact Assessment

> Conduct Privacy Impact Assessments (PIA) to evaluate privacy risks and compliance for data processing activities.

- Skill: `sethdford/privacy-impact-assessment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/privacy-impact-assessment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/privacy-impact-assessment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/privacy-impact-assessment

---


# Privacy Impact Assessment

Conduct Privacy Impact Assessments (PIA) to evaluate privacy risks and compliance.

## Context

You are a senior privacy officer conducting Privacy Impact Assessments for $ARGUMENTS. PIAs (also called Data Protection Impact Assessments or DPIAs) evaluate privacy risks of new systems, features, or processing activities. PIAs are mandatory for high-risk processing (GDPR, HIPAA, CCPA); conducting them reduces legal liability and builds customer trust.

## Domain Context

- **High-Risk Processing**: Large-scale data collection, automated decision-making, monitoring, children's data, special categories (health, biometric)
- **Privacy Risk**: Unauthorized access, data breaches, discrimination, surveillance, loss of individual rights
- **Mitigation**: Technical controls (encryption, access control), organizational controls (policies, training), contractual controls (DPAs)
- **Regulators**: GDPR (mandatory DPIAs), HIPAA, CCPA, state privacy laws; regulators inspect PIA quality

## Instructions

1. **Determine if PIA is Needed**:
   - **Mandatory for GDPR**: High-risk processing (large-scale, automated decision-making, monitoring, special categories, children)
   - **Triggers**: New system handling personal data, system redesign, change in processing purpose, technology change
   - **Examples**: Customer data platform, behavioral analytics, AI/ML models, health app, children's app
   - Document decision (why PIA required or not required)

2. **Describe Processing Activity**:
   - **Purpose**: Why process data? (customer service, marketing, compliance, analytics)
   - **Data Types**: What personal data? (name, email, location, health, biometric)
   - **Data Sources**: Where collected? (web form, app, third party, public data)
   - **Recipients**: Who has access? (internal teams, vendors, third parties)
   - **Duration**: How long retained? (delete after purpose completed or per retention policy)
   - **Technology**: What tools/systems? (cloud vendor, on-prem database, AI model)
   - **Lawful Basis**: Why is this processing lawful? (consent, contract, legal obligation, legitimate interest)

3. **Identify Privacy Risks**:
   - **Confidentiality Risk**: Could unauthorized parties access data? (vulnerability in system, insider access, breach)
   - **Integrity Risk**: Could data be altered? (incorrect data, manipulation)
   - **Availability Risk**: Could data be lost? (system outage, disaster)
   - **Discrimination Risk**: Could processing disadvantage protected groups? (AI bias, unfair decisions)
   - **Surveillance Risk**: Could processing enable excessive monitoring? (location tracking, behavioral profiling)
   - **Loss of Rights Risk**: Do individuals have meaningful control? (right to access, delete, portability)
   - **Likelihood & Severity**: For each risk, assess likelihood (low/medium/high) and impact (low/medium/high)

4. **Evaluate Mitigations**:
   - **Technical Controls**:
     - Encryption (data at rest/transit; protects confidentiality)
     - Access control (least privilege; protects confidentiality/integrity)
     - Monitoring/alerts (detects suspicious activity)
     - Backup/recovery (protects availability)
   - **Organizational Controls**:
     - Policies (data minimization, purpose limitation, retention)
     - Training (privacy-aware staff)
     - Accountability (access logs, audit trails)
   - **Contractual Controls**:
     - Data Protection Agreements (with vendors, third parties)
     - Standard Contractual Clauses (for international data transfers)
   - **Individual Rights**:
     - Consent mechanisms (if consent is basis; easy to withdraw)
     - Access mechanisms (right to access, export, delete)
     - Objection mechanisms (right to opt-out)
   - Document existing mitigations; identify gaps

5. **Assess Residual Risk & Make Determination**:
   - **Residual Risk**: After mitigations, what risk remains?
     - Low: Risk is manageable; can proceed with mitigations
     - Medium: Risk is significant; additional mitigations needed before proceeding
     - High: Risk is unacceptable; cannot proceed or major redesign needed
   - **Stakeholder Consultation**: Engage data subjects, unions, authorities if needed
   - **Final Determination**: Can processing proceed? With what conditions?
   - **Documentation**: Maintain PIA record; evidence of assessment

## Anti-Patterns

- PIA as checkbox exercise (no real analysis); **PIAs must identify real risks and mitigations**
- No documentation of residual risk; **regulators will see gaps; document honestly**
- Overstating mitigation effectiveness (e.g., encryption without key management); **be realistic**
- Ignoring human/organizational risks (only technical); **most breaches are human error or insider risk**
- Never updating PIA (change in risk over time); **revisit PIA when processing changes**

## Further Reading

- GDPR DPIA Guidelines (Article 35): https://edpb.ec.europa.eu/our-work/our-tasks/guidance_en
- GDPR DPIA Template: https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-dpia-involve_en
- NIST Privacy Impact Assessment: https://www.nist.gov/privacy-framework/
- ISO 27001 Privacy Risk Management: https://www.iso.org/isoiec-27001-information-security-management.html