Comprehensive global privacy compliance agent skill covering GDPR, CCPA/CPRA, HIPAA Privacy Rule, EU AI Act, LGPD, cross-border data transfer mechanisms (SCCs, BCRs, EU-US DPF), PII identification and classification, data minimization, consent management, privacy-by-design patterns, DPIA workflows, data subject access request (DSAR) handling, and breach notification procedures. Provides procedural knowledge for compliance workflows — NOT legal advice. Designed for agentic platforms including Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, GitHub Copilot, Windsurf, and OpenCode.
Instrucciones de origen · Vista previa de solo lectura
name
privacy-compliance
version
1.0.0
author
Skill Foundry
description
Comprehensive global privacy compliance agent skill covering GDPR, CCPA/CPRA, HIPAA Privacy Rule, EU AI Act, LGPD, cross-border data transfer mechanisms (SCCs, BCRs, EU-US DPF), PII identification and classification, data minimization, consent management, privacy-by-design patterns, DPIA workflows, data subject access request (DSAR) handling, and breach notification procedures. Provides procedural knowledge for compliance workflows — NOT legal advice. Designed for agentic platforms including Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, GitHub Copilot, Windsurf, and OpenCode.
{"jurisdictions_covered":["EU/EEA (GDPR)","United Kingdom (UK GDPR / Data Protection Act 2018)","United States — California (CCPA/CPRA)","United States — Federal (HIPAA Privacy Rule)","Brazil (LGPD)","Cross-jurisdictional (SCCs, BCRs, EU-US DPF)"],"regulatory_bodies":["EDPB (European Data Protection Board)","ICO (UK Information Commissioner's Office)","CPPA (California Privacy Protection Agency)","HHS OCR (Health and Human Services Office for Civil Rights)","ANPD (Brazilian National Data Protection Authority)"],"primary_workflows":["dpia_execution","dpa_agreement_drafting","breach_notification_procedure","ccpa_cpra_compliance_check","hipaa_privacy_rule_assessment","eu_ai_act_requirements_analysis","cross_border_transfer_mechanism_selection","pii_identification_and_classification","data_minimization_audit","consent_management_review","privacy_by_design_architecture_review","dsar_handling_procedure"],"complexity_level":"advanced","prerequisite_knowledge":["data_protection_fundamentals","privacy_regulation_basics","software_architecture_patterns","data_classification_taxonomies"],"target_audience":["privacy_engineers","data_protection_officers","compliance_managers","software_architects","legal_operations_teams","security_engineers"]}
Privacy Compliance Agent Skill
⚠️ IMPORTANT DISCLAIMER: THIS IS NOT LEGAL ADVICE
This skill provides procedural knowledge for compliance workflows —
checklists, patterns, reference data, and structured analysis frameworks.
It does not provide legal opinions, interpret statutes, or make
determinations about legal liability. The information herein is educational
and procedural only. For legal advice, consult a qualified privacy attorney
licensed in the relevant jurisdiction.
Never use this skill to make legally binding determinations. Its output
is advisory and should be reviewed by qualified legal counsel before any
compliance decision is finalized.
"Draft a DPA" / "Data processing agreement template"
Do NOT Activate For
The following are near-miss negatives — they touch on privacy-adjacent topics
but are not privacy compliance workflows:
General cybersecurity questions: "How do I set up a firewall?" — infrastructure security, not privacy compliance. Refer to security skills.
Encryption implementation: "How to encrypt a database column?" — cryptography engineering, not compliance. Refer to coding/security skills.
Authentication/authorization design: "Design an OAuth flow" — IAM, not privacy. Refer to auth/security skills.
Legal advice requests: "Is our company liable under Article 82?" — legal opinion, explicitly out of scope. Recommend consulting an attorney.
Contract negotiation: "Negotiate a data processing agreement" — legal services, out of scope.
Regulatory filing: "File a GDPR registration with the ICO" — administrative filing, out of scope.
Litigation support: "Prepare for a GDPR enforcement hearing" — legal proceedings, out of scope.
Pure technical infrastructure: "Set up a logging pipeline" — DevOps, not privacy (even though logging has privacy implications — redirect to privacy-by-design workflow if the user asks about PII in logs).
When in doubt, ask: "Are you asking me to help with a privacy compliance
workflow (which I can do procedurally), or are you asking for legal advice
(which I cannot provide)?"
Common Pitfalls & Anti-Patterns
❌ Compliance Anti-Patterns
Treating compliance as a one-time checkbox — Compliance is continuous. A DPIA from 2022 is not valid if the processing has changed. Flag outdated assessments.
Confusing "legitimate interest" with "convenient interest" — Legitimate interest requires a genuine, documented balance test. "We want to monetize data" is not a legitimate interest.
Relying on consent for everything — Consent is only one of six lawful bases under GDPR. Over-reliance on consent (especially for employment data) is a red flag.
"We'll just anonymize it" without understanding anonymization — True anonymization is irreversible. Pseudonymization is not anonymization. Mislabeling pseudonymized data as anonymous creates false compliance.
Ignoring data in transit vs. at rest distinction — Encrypting data at rest but sending it plaintext via email is not compliant. Both must be protected.
Collecting data "just in case" — "We might need it later" violates data minimization. Every data field must have a documented, current purpose.
Cookie banners that make rejection harder than acceptance — Dark patterns in consent management are explicitly prohibited under GDPR and are actively enforced by DPAs.
Assuming US-based compliance satisfies EU requirements — CCPA compliance ≠ GDPR compliance. Different legal bases, different rights, different enforcement.
Treating AI Act compliance as optional for non-AI companies — The EU AI Act applies to deployers, not just providers. Using a third-party AI system can trigger obligations.
Storing breach response plans only as documents — A breach response plan that hasn't been tested with a tabletop exercise is not reliable. Flag untested plans.
✅ Compliance Quality Checklist
Before publishing your analysis, verify:
The specific regulation(s) being assessed are explicitly stated
The lawful basis for each processing activity has been identified
Data minimization has been evaluated — every field has a purpose
Consent mechanisms (if applicable) have been reviewed for validity
Cross-border data flows have been mapped and transfer mechanisms identified
Data subject rights procedures (access, erasure, portability) have been covered
Breach notification timelines per jurisdiction are stated
No actual PII was included in the output (see Safety Rules)
The disclaimer about this not being legal advice is prominent
Any findings have concrete, actionable next steps
References to specific regulatory articles are verified against references/privacy-regulations.md
Workflows
Workflow 1: GDPR Compliance Baseline
Use for comprehensive GDPR readiness assessments.
Phase 1: Scope Discovery
Identify the data controller and processors. Who decides the purpose and means of processing? Who processes on behalf of the controller?
Map all personal data flows:
What categories of personal data are collected?
From whom? (data subjects, third parties, public sources)
For what purpose? (one purpose per data element)
Where is it stored? (geographic location of servers/cloud)
Who has access? (internal roles, third-party processors)
How long is it retained?
Where does it flow cross-border?
Identify the lawful basis for each processing activity:
Critical check: If processing special category data (Article 9), one of the additional conditions must apply (explicit consent, employment law, vital interests, etc.).
Phase 2: Rights & Transparency Review
Privacy notice audit:
Is the privacy notice accessible in plain language?
Does it cover: controller identity, purposes, lawful bases, recipients, transfers, retention, and all data subject rights?
Is it provided at the point of data collection (not buried)?
Data subject rights verification:
Right of access (Art. 15): Is there a documented process for handling access requests? Can you respond within 1 month?
Right to rectification (Art. 16): Can users correct inaccurate data?
Right to erasure (Art. 17): Is there a deletion mechanism? Can it cascade to processors?
Right to restriction (Art. 18): Can you flag and restrict data without deleting it?
Right to data portability (Art. 20): Can you export data in a structured, machine-readable format?
Right to object (Art. 21): Can users object to processing (especially direct marketing)?
Automated decision-making (Art. 22): Are you making decisions with legal/significant effects without human intervention?
Phase 3: Technical & Organizational Measures
Security measures assessment:
Encryption at rest and in transit
Access controls (least privilege, role-based)
Pseudonymization where appropriate
Regular testing of security measures
Incident response plan
Data Protection Impact Assessment (DPIA) requirement check:
A DPIA is required when processing is "likely to result in high risk":
Systematic and extensive profiling with legal effects
Large-scale processing of special category data
Systematic monitoring of publicly accessible areas
Processing that involves new technologies at scale
See Workflow 2: DPIA Execution for full procedure.
Data Processing Agreement (DPA) audit:
Do you have DPAs with all processors?
Do DPAs include required clauses (Art. 28): subject matter, duration, nature, purpose, type of data, categories of data subjects, controller obligations?
Are sub-processors approved and flow-down requirements in place?
Phase 4: Breach Preparedness
Breach notification readiness:
Can you detect a personal data breach within 24 hours?
Do you have a documented notification procedure?
Can you notify the supervisory authority within 72 hours?
Can you notify affected data subjects "without undue delay" when there is high risk?
See Workflow 5: Breach Notification Procedure for full procedure.
GDPR Compliance Output Format
## GDPR Compliance Assessment
### Scope
- Controller: [entity]
- Processors: [list]
- Processing activities reviewed: N
### Findings
| # | Severity | Finding | Article Reference | Recommendation |
|---|---|---|---|---|
| 1 | 🔴 CRITICAL | No DPIA for high-risk processing | Art. 35 | Execute DPIA immediately |
| 2 | 🟠 HIGH | Consent banner lacks granular opt-out | Art. 7(4) | Redesign consent mechanism |
| 3 | 🟡 MEDIUM | Privacy notice not linked at data collection point | Art. 13 | Add inline privacy notice links |
### Lawful Basis Grid
| Processing Activity | Data Category | Lawful Basis | Special Category? | Condition |
|---|---|---|---|---|
| Account creation | Email, name | Contractual necessity | No | N/A |
### Rights Coverage
| Right | Status | Gap |
|---|---|---|
| Access (Art. 15) | ✅ Implemented | — |
| Erasure (Art. 17) | ⚠️ Partial | No cascade deletion to processor |
| Portability (Art. 20) | ❌ Missing | No export mechanism |
### Recommendation
[Overall assessment with prioritized action items]
Workflow 2: DPIA Execution
A Data Protection Impact Assessment is required under GDPR Art. 35 for
processing likely to result in high risk to individuals' rights and freedoms.
DPIA Template & Steps
Describe the processing:
Nature: What are you doing with the data?
Scope: How much data, how many subjects, how long?
Context: What is the relationship with data subjects? Do they expect this?
Purposes: Be specific. "Improving user experience" is vague; "Using ML to recommend products based on purchase history" is specific.
Assess necessity and proportionality:
Is the processing necessary to achieve the purpose?
Could the purpose be achieved with less intrusive means?
Is the data adequate, relevant, and limited (data minimization)?
Retention: Is the retention period justified?
Identify and assess risks to individuals:
What could go wrong? (unauthorized access, accidental loss, re-identification)
Availability breach: Unauthorized loss/destruction (ransomware can be all three)
Assess risk to individuals: likelihood × severity of impact
If no risk to individuals: Document internally, no notification required
If risk to individuals: Proceed to notification
If high risk to individuals: Expedited notification to data subjects
Notification Timelines by Jurisdiction:
Jurisdiction
Supervisory Authority
Data Subjects
Trigger
GDPR
Within 72 hours of awareness
Without undue delay
Risk to individuals (SA); High risk (subjects)
UK GDPR
Within 72 hours
Without undue delay
Same as GDPR
CCPA/CPRA
No SA notification requirement
"In the most expedient time possible, without unreasonable delay"
Unencrypted/unredacted PI breach
HIPAA
Within 60 days (<500: annual; ≥500: concurrent)
Within 60 days
Breach of unsecured PHI
LGPD
Within a reasonable time
Must be communicated
Relevant risk or harm
Notify the Supervisory Authority (as applicable):
GDPR notification minimum content:
Nature of the breach (categories, approximate number of data subjects and records)
DPO contact details
Likely consequences
Measures taken or proposed (mitigation, prevention)
If notification is after 72 hours, include reasons for delay
Notify Data Subjects (as applicable):
Clear, plain language communication
Name and contact of DPO
Description of likely consequences
Measures taken and recommended steps for subjects (e.g., change passwords)
Do NOT include: detailed technical forensic data, raw PII of other subjects, speculative causes
Document Everything:
Breach log per Art. 33(5) GDPR: facts, effects, remedial action
CCPA: maintain records of breach response for 24 months
HIPAA: maintain documentation for 6 years
Breach Notification Decision Tree
Personal Data Breach Detected
│
├──→ CONTAIN + PRESERVE EVIDENCE (Immediate)
│
├──→ RISK ASSESSMENT
│
├── No risk to individuals?
│ └──→ DOCUMENT internally only. No external notification.
│
├── Risk to individuals?
│ ├── GDPR: Notify SA within 72h ✓
│ ├── UK GDPR: Notify ICO within 72h ✓
│ └── LGPD: Notify ANPD within reasonable time ✓
│
├── High risk to individuals?
│ ├── GDPR: Notify data subjects without undue delay ✓
│ ├── UK GDPR: Same ✓
│ └── CCPA: Notify if unencrypted/unredacted PI ✓
│
├── PHI involved (USA)?
│ └── HIPAA: Notify HHS (60 days), notify individuals (60 days) ✓
│
└──→ DOCUMENT ALL STEPS, DECISIONS, AND TIMELINES
Workflow 6: HIPAA Privacy Rule Assessment
The HIPAA Privacy Rule (45 CFR Part 160 and Part 164) protects the privacy of
individually identifiable health information (Protected Health Information / PHI).
HIPAA Applicability
Covered Entities:
Health plans (insurers, HMOs, government health programs)
Health care clearinghouses
Health care providers who transmit health information electronically
Business Associates:
Entities that create, receive, maintain, or transmit PHI on behalf of covered entities
Must have Business Associate Agreements (BAAs) in place
PHI Identification — The 18 Identifiers
Under HIPAA, PHI is health information that contains any of these 18 identifiers:
The EU AI Act (Regulation 2024/1689) classifies AI systems into risk
categories and imposes obligations accordingly.
AI Act Risk Classification
Risk Level
Definition
Requirements
Examples
🔴 Unacceptable
Prohibited entirely
Cannot be placed on market or used
Social scoring by governments, real-time remote biometric identification in public spaces (with limited exceptions), emotion recognition in workplace/schools, predictive policing based on profiling, untargeted scraping of facial images
🟠 High Risk
Significant impact on health, safety, fundamental rights
Conformity assessment, risk management, data governance, transparency, human oversight, accuracy, robustness
Medical device AI, recruitment/filtering systems, credit scoring, biometric categorization, critical infrastructure, education/vocational access, law enforcement, migration, justice
AI-powered video games, spam filters, inventory management
High-Risk AI System Requirements Checklist
For each requirement, assess the AI system:
Risk Management System (Art. 9):
Continuous, iterative process throughout lifecycle
Identification of reasonably foreseeable risks
Estimation and evaluation of risks
Adoption of risk management measures
Testing to ensure measures are appropriate
Data Governance (Art. 10):
Training, validation, and testing datasets meet quality criteria
Data governance practices address: design choices, data collection, preparation, assumptions
Examination for biases that could affect health/safety or fundamental rights
Documentation of datasets used
Technical Documentation (Art. 11):
General description of the AI system
Detailed description of elements and development process
Monitoring, functioning, and control details
Risk management system description
Any changes to the system documented
Record-Keeping / Logging (Art. 12):
Automatic logging of events during operation
Logging sufficient for traceability throughout lifecycle
Transparency and Information (Art. 13):
Clear and adequate information to deployers
Instructions for use including: identity of provider, characteristics/capabilities/limitations, changes, human oversight measures, expected lifetime, and maintenance
Human Oversight (Art. 14):
Built-in human-machine interface tools
Human overseers can: understand system capacity/limitations, detect automation bias, interpret output correctly, override or disregard output, intervene to stop operation
Accuracy, Robustness, Cybersecurity (Art. 15):
Appropriate level of accuracy declared
Resilience to errors, faults, inconsistencies
Robustness against manipulation of training data (data poisoning)
Cybersecurity measures against adversarial attacks
AI Act Applicability Timeline
Date
Obligation
Feb 2, 2025
Prohibitions on unacceptable risk AI practices take effect
Aug 2, 2025
GPAI model rules take effect (notifying GPAI with systemic risk, etc.)
Aug 2, 2026
Full AI Act applies (except Art. 6(1) and corresponding obligations)
Aug 2, 2027
Art. 6(1) — classification rules for high-risk AI systems
GPAI (General Purpose AI) Obligations
If using or providing General Purpose AI models:
Technical documentation of the model (training, testing, evaluation)
Information and documentation to downstream providers
Copyright policy and training data summary
Systemic risk GPAI (trained with >10^25 FLOPs): additional obligations — model evaluations, adversarial testing, incident reporting, cybersecurity
Workflow 8: Cross-Border Data Transfer Mechanisms
International data transfers require specific safeguards. Different mechanisms
apply to different jurisdictions.
EU/EEA Transfer Mechanisms
Adequacy Decisions (Art. 45 GDPR):
The European Commission has determined these countries provide adequate protection:
Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, United Kingdom, Uruguay.
With adequate protection for specific frameworks: EU-US Data Privacy Framework (certified entities only).
Does NOT cover all US companies — only DPF-certified entities
For non-certified entities: SCCs + TIA still required
UK Transfer Mechanisms
The UK has its own adequacy regulations and transfer mechanisms post-Brexit:
UK Adequacy Regulations: Similar list to EU, with some differences
UK International Data Transfer Agreement (IDTA): Replaces EU SCCs for UK-restricted transfers
UK Addendum to EU SCCs: An alternative that adds UK provisions to EU SCCs
UK-US Data Bridge: UK extension of the EU-US DPF (effective October 12, 2023)
Cross-Border Transfer Decision Flowchart
Is data leaving [jurisdiction]?
│
├──→ NO: No transfer mechanism needed ✓
│
├──→ YES: Is the destination covered by an adequacy decision?
│ ├──→ YES: Transfer proceeds — document adequacy reliance ✓
│ └──→ NO: Proceed to safeguards ↓
│
├──→ Is the recipient DPF-certified (EU→US)?
│ ├──→ YES: Transfer under DPF — document certification ✓
│ └──→ NO: Proceed to SCCs/BCRs ↓
│
├──→ Are SCCs appropriate?
│ ├──→ YES: Execute SCCs + conduct TIA ✓
│ └──→ NO: BCRs for intra-group transfers? ✓
│
├──→ Can a derogation apply (Art. 49)?
│ ├──→ YES: Strictly limited — document justification ⚠️
│ └──→ NO: Transfer cannot proceed ❌
│
└──→ DOCUMENT: TIA, mechanism, supplementary measures, periodic review
Workflow 9: PII Identification and Classification
Personally Identifiable Information (PII) is any data that can be used to
identify a specific individual. Different jurisdictions define it differently.
PII Classification Taxonomy
Category
Definition
Examples
Risk Level
Direct Identifiers
Uniquely identify an individual without additional data
Full name, SSN, passport number, email address, phone number, biometric data, national ID number
🔴 HIGH
Indirect Identifiers
Can identify when combined with other data
Date of birth, postal code, gender, IP address, device ID, cookie ID, vehicle plate number
🟠 MEDIUM
Sensitive PII
Special categories with enhanced protection
Race/ethnicity, political opinions, religious beliefs, trade union membership, genetic data, biometric data (for ID), health data, sex life/orientation, criminal records, precise geolocation
🔴 VERY HIGH
Pseudonymous Data
PII with identifiers replaced, but re-identifiable with a key
Hashed email, tokenized user ID, pseudonymized medical record
🟡 MEDIUM (if key is secure)
Anonymous Data
Irreversibly de-identified — no reasonable means of re-identification
Consent under GDPR must be freely given, specific, informed, and unambiguous.
Under CCPA, the focus is on opt-out rights (with opt-in for sensitive data and minors).
GDPR Consent Validity Checklist
For each consent collection point, verify:
Freely Given (Art. 7(4)):
Is consent optional — not a condition of service unless strictly necessary?
Can the user decline without negative consequences? (No cookie walls, no degradation)
Is there no power imbalance? (Employment consent requires extra scrutiny)
Is consent granular — separate for different purposes?
Specific (Art. 6(1)(a), Recital 32):
Each purpose has its own consent option
No bundled consent ("by signing up you agree to marketing + analytics + sharing")
Purposes are described specifically, not vaguely ("improve services" is too vague)
Informed (Art. 7(2), Art. 13):
Controller identity is stated
Each purpose is explained in plain language
Third-party data recipients are identified (by name or category)
Data retention periods are disclosed
Data subject rights are explained
Cross-border transfers (if any) are disclosed
Unambiguous (Art. 4(11), Recital 32):
Affirmative action required (pre-ticked boxes are invalid under GDPR)
Privacy-by-design means embedding data protection into the system architecture
from the ground up, not bolting it on afterward (Art. 25 GDPR).
Privacy-by-Design Principles
Proactive, not reactive — Preventative, not remedial
Privacy as the default setting — No action required to protect privacy
Privacy embedded into design — Integral part of the system
Full functionality — positive-sum, not zero-sum — Privacy AND utility
End-to-end security — full lifecycle protection
Visibility and transparency — Keep it open to data subjects
Respect for user privacy — Keep it user-centric
Architecture Review Dimensions
1. Data Collection Layer:
Are data fields explicitly enumerated? No catch-all "additional info" fields.
Is collection minimized to what's strictly necessary?
Are defaults privacy-preserving? (Opt-out by default, minimal data sharing)
Is sensitive data collection flagged for special handling?
Are data collection points documented with purpose specifications?
2. Data Storage Layer:
Is PII encrypted at rest? (AES-256 minimum for PII, separate key management)
Is PII stored separately from non-PII? (segregation of sensitive data)
Are database backups encrypted and access-controlled?
Is data pseudonymized/anonymized where possible?
Is there a clear data retention and automated deletion mechanism?
Is test data sanitized? No production PII in dev/staging environments.
3. Data Processing Layer:
Is processing limited to documented purposes? (purpose limitation)
Are processors identified and DPAs in place?
Is access control enforced at the application layer (not just database)?
Are there audit logs for all PII access?
Is PII minimized in memory (not cached unnecessarily)?
Is PII excluded from error messages and debug logs?
4. Data Transmission Layer:
Is TLS 1.2+ enforced for all data in transit?
Are API responses filtered to exclude unnecessary PII fields?
Is PII excluded from URL query parameters?
Are third-party integrations reviewed for PII transmission?
Is client-side storage of PII (localStorage, cookies) reviewed and justified?
5. User-Facing Layer:
Is the privacy notice accessible at the point of data collection?
Are consent mechanisms compliant (per Consent Management Review workflow)?
Are DSAR self-service tools available (data download, account deletion)?
Is PII masked or hidden by default in UI (e.g., masked email in user lists)?
Are third-party trackers disclosed and consented to?
6. Operational Layer:
Is employee access to PII on a need-to-know basis?
Are access reviews conducted regularly?
Is there a data breach detection mechanism in place?
Is there a documented breach response plan?
Are third-party vendor privacy practices assessed?
Is privacy training documented for all relevant personnel?
Privacy-by-Design Pattern Library
Pattern
Description
When to Use
Data Minimization by Design
Collect only what's needed, when it's needed, for as long as needed
Default for all new development
Purpose-Based Access Control
Access controls tied to specific processing purposes, not just roles
Multi-purpose systems
Just-in-Time Consent
Request consent at the moment of data collection, not at signup
Features collecting sensitive data
Client-Side Processing
Process data on-device, never transmit raw PII to server
Analytics, personalization
Differential Privacy
Add calibrated noise to aggregate outputs to protect individuals
Analytics, ML training
Encrypted Processing
Homomorphic encryption, secure enclaves for processing sensitive data
Highly sensitive data processing
Data Tokenization
Replace PII with tokens, store mapping separately
Payment systems, multi-system integrations
Automated Data Lifecycle
Cron-driven deletion of expired data per retention policy
All PII storage
Privacy-Preserving Analytics
Aggregate-only analytics, no per-user tracking
Web analytics, product metrics
Workflow 12: Data Subject Access Request (DSAR) Handling
Multi-Regulation DSAR Rights Summary
Right
GDPR
CCPA/CPRA
HIPAA
LGPD
Access
Art. 15 — Confirm processing + copy of data
Right to Know — categories + specific pieces
Right to Access — designated record set
Art. 18 — Confirmation + access
Rectification
Art. 16
Right to Correct (CPRA)
Right to Amend
Art. 18
Erasure
Art. 17 — "Right to be forgotten"
Right to Delete
Limited (amendment preferred)
Art. 18
Portability
Art. 20
Right to Data Portability (CPRA)
Right to Direct to Third Party
Art. 18
Restriction
Art. 18
—
Right to Request Restrictions
Blocking (Art. 18 §6)
Objection
Art. 21 — Object to processing
Opt-Out of Sale/Sharing
—
Opposition (Art. 18 §2)
Automated Decisions
Art. 22 — Human review of ADM
CPRA: Access + opt-out option
—
Review of ADM (Art. 20)
DSAR Handling Procedure
Phase 1: Receipt & Validation (Day 1–5)
Log the request — timestamp, channel (email, web form, phone, mail), request type
Verify the requester's identity:
Authenticated user in your system → verify session/account ownership
Non-authenticated user → request additional verification (ID document, email verification)
Be cautious: Do not request excessive ID verification (disproportionate under GDPR)
Clarify the scope — What specifically is the user requesting? All data? Specific processing? Deletion of specific data?
Confirm the request is valid — Is it excessive or manifestly unfounded? (If so, you may charge a reasonable fee or refuse — but document the justification)
Phase 2: Data Collection (Day 5–15)
Identify all data stores:
Primary databases (user tables, profile stores)
Analytics systems (Mixpanel, Amplitude, etc.)
Customer support systems (Zendesk, Intercom)
Marketing systems (email platforms, CRM)
Logs and backups (may be impractical — document)
Third-party processors (must assist per DPA)
Collect and collate the data:
Export in structured, machine-readable format (JSON, CSV)
Include metadata: source, purpose of processing, recipients, retention period
Redact third-party PII (do not disclose another person's data)
Translate codes/IDs where necessary (user ID → meaningful context)
Phase 3: Review & Redaction
Before releasing, review for:
Third-party personal data (must not be disclosed)
Legally privileged information
Confidential commercial information (trade secrets)
Information that would adversely affect the rights and freedoms of others
Security-sensitive information (internal security procedures)
Document your redactions — What was redacted, why, under what legal basis.
Phase 4: Response (by Day 30)
Provide the response:
Access request: Copy of all personal data + Art. 15(1) and (2) information (purposes, categories, recipients, retention, rights, source, automated decision-making)
Erasure request: Confirmation of deletion + scope of what was deleted + where deletion might be incomplete (backups, legal holds) + timeline for completion
Portability request: Data in structured, commonly used, machine-readable format
Timeline management:
GDPR: Respond within 1 month (can extend by 2 months for complex requests — notify within first month)
CCPA: Respond within 45 days (can extend by 45 days — notify within first 45 days)
HIPAA: Respond within 30 days (one 30-day extension)
LGPD: Within 15 days (confirmation of processing), rest within reasonable time
Phase 5: Closure & Documentation
Document everything:
Request log (date, type, requester, scope)
Identity verification method
Data sources searched
Redactions and justifications
Response provided and date
Any extensions and justifications
Time to complete
Metrics tracking (for accountability):
Number of DSARs received per month
Average response time
Most common request types
Extension rate (should be low)
DSAR Refusal Grounds
Valid grounds to refuse or charge a fee (document thoroughly):
Ground
GDPR
CCPA
Manifestly unfounded
Art. 12(5) — refuse or charge
Must respond (no unfounded exception for access)
Excessive (repetitive)
Art. 12(5) — refuse or charge
2 requests per 12 months; charge for additional
Cannot verify identity
Art. 12(6) — can refuse until verified
Can refuse if cannot verify
Adversely affects rights of others
Art. 15(4) — can refuse/redact
Must provide (redact third-party PI)
Legal privilege
Recital 73
Attorney-client privilege
Safety Rules
ABSOLUTE RULES — never violate these:
Never expose actual PII in outputs. When referencing data in examples,
use synthetic, obviously fake values (e.g., user@example.com,
John Doe, 123-45-6789 (synthetic)). Never echo real PII from the
user's systems. If real PII appears in your analysis context, redact it.
This is NOT legal advice. Ever. Do not offer legal opinions, interpret
statutes authoritatively, or tell users whether they are "compliant" or
"non-compliant." Say: "This analysis identifies areas that should be
reviewed by qualified legal counsel." Frame findings as "This may not
meet [regulation] requirements" not "You are in violation of [regulation]."
Do not draft legal documents for execution. You can provide templates
and checklists, but flag that every DPA, privacy notice, and consent
form must be reviewed by legal counsel before use. Do not present
templates as "ready to sign."
Do not make determinations about fines or penalties. You can cite the
regulatory maximums, but do not estimate or predict an organization's
financial exposure. That requires legal analysis by a qualified attorney.
Acknowledge jurisdictional complexity. Privacy law is fragmented.
What satisfies the CCPA may not satisfy the GDPR, and vice versa. Always
identify which jurisdiction(s) apply and note conflicts between regimes.
Respect the limits of the skill. This skill covers GDPR, CCPA/CPRA,
HIPAA, LGPD, and the EU AI Act. If the user asks about regulations not
covered here (e.g., PIPEDA, POPIA, China's PIPL), state that the skill
does not cover that regulation and recommend consulting subject-matter
expertise.
Be transparent about model limitations. AI can process procedural
checklists but cannot exercise legal judgment. Say: "This is a procedural
analysis based on my training data. Regulatory interpretations evolve
through guidance and case law. Always verify with current regulatory
guidance and qualified legal counsel."
Never recommend avoiding or circumventing regulations. If a user asks
"How can we avoid GDPR by moving servers to country X?", do not provide
a workaround. Explain that territorial scope is determined by the data
subject's location and the targeting of the EU market, not server location.
Platform Compatibility Notes
Platform
Notes
Claude Code
Use for document review and checklist generation. Works well with files in workspace. Use web search for current regulatory guidance.
Codex (OpenAI)
Strong at structured analysis. Provide clear workflow selection. Good for DPIA templates and gap analysis.
Cursor
Can read codebases for privacy-by-design reviews. Use to scan for PII in database schemas, API definitions, and code.
Gemini CLI
Large context for processing privacy policies and DPAs. Use for multi-document analysis.
OpenClaw
Full workflow execution. Use exec for regex PII scanning. Use web search for regulatory updates. Compatible with all referenced workflows.
GitHub Copilot
Best for inline privacy-by-design suggestions. Flag PII patterns in code as they're written.
Windsurf
Can scan entire codebase for PII and compliance gaps. Use for architecture reviews.
OpenCode
Terminal-based. Use for quick PII scans and checklist generation.
Platform-Specific Adjustments
For Discord/Slack delivery: Use bullet lists, not markdown tables.
Wrap multiple links in <> to suppress embeds. Keep findings concise.
For web search access: Verify current regulatory guidance. DPAs issue
new guidance frequently. Check references/privacy-regulations.md for
baseline knowledge, then supplement with web search for recent updates.
If output length is limited: Prioritize CRITICAL and HIGH findings.
Reference workflows by name rather than embedding full procedure text.
For codebase scanning: Use regex patterns from Workflow 9 (PII
Identification). Focus on email, phone, ssn, health, biometric,
address field patterns.
References
references/privacy-regulations.md — Quick-reference guide to major privacy regulations, key articles, enforcement bodies, and fine structures.
External:
GDPR Full Text — Official GDPR text with article navigation
