Privacy Compliance

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.

Quick Reference

Workflow Priority Guide:

When to Use This Skill

Activate this skill when the user asks you to:

• "Check our GDPR compliance" / "Are we GDPR compliant?" / "GDPR audit"
• "Review our privacy policy" / "Review this consent banner"
• "We need a DPIA" / "Conduct a data protection impact assessment"
• "We had a data breach — what do we do?" / "Breach notification steps"
• "Is this CCPA compliant?" / "California privacy check"
• "Does this handle PHI correctly?" / "HIPAA review"
• "What's the EU AI Act require?" / "AI Act compliance"
• "Can we transfer this data to the US?" / "SCCs / BCRs / DPF"
• "How do we handle a DSAR?" / "Data subject access request procedure"
• "Classify this data" / "Identify PII in this dataset"
• "Review our data minimization" / "Are we collecting too much?"
• "Privacy-by-design review" / "Privacy architecture assessment"
• "LGPD requirements" / "Brazilian data protection"
• "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

1. 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.

2. Confusing "legitimate interest" with "convenient interest" — Legitimate interest requires a genuine, documented balance test. "We want to monetize data" is not a legitimate interest.

3. 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.

4. "We'll just anonymize it" without understanding anonymization — True anonymization is irreversible. Pseudonymization is not anonymization. Mislabeling pseudonymized data as anonymous creates false compliance.

5. 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.

6. Collecting data "just in case" — "We might need it later" violates data minimization. Every data field must have a documented, current purpose.

7. Cookie banners that make rejection harder than acceptance — Dark patterns in consent management are explicitly prohibited under GDPR and are actively enforced by DPAs.

8. Assuming US-based compliance satisfies EU requirements — CCPA compliance ≠ GDPR compliance. Different legal bases, different rights, different enforcement.

9. 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.

10. 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

1. Identify the data controller and processors. Who decides the purpose and means of processing? Who processes on behalf of the controller?

2. 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?

3. Identify the lawful basis for each processing activity:

   • ✓ Consent (freely given, specific, informed, unambiguous)
   • ✓ Contractual necessity
   • ✓ Legal obligation
   • ✓ Vital interests
   • ✓ Public task
   • ✓ Legitimate interests (balance test documented)

   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

4. 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)?

5. 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

6. 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

7. 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.

8. 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

9. 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

1. 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.

2. 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?

3. Identify and assess risks to individuals:

   • What could go wrong? (unauthorized access, accidental loss, re-identification)
   • What is the likelihood and severity of harm?
   • Risk matrix: Likelihood × Impact = Risk Level

4. Identify measures to address risks:

   • Technical measures (encryption, anonymization, access controls)
   • Organizational measures (staff training, policies, audits)
   • Procedural safeguards (data subject rights procedures)

5. Record the outcome:

   • Residual risk after mitigation
   • Whether the residual risk is acceptable
   • Whether prior consultation with the supervisory authority is required (Art. 36)
   • Sign-off from DPO (if appointed)

6. Integrate outcomes back into the project:

   • Ensure identified measures are actually implemented
   • Schedule review date (reassess at least every 3 years or when processing changes)

DPIA Trigger Checklist

A DPIA is mandatory when the processing involves two or more of these indicators (per EDPB guidelines WP 248):

• Evaluation or scoring (profiling, credit scoring)
• Automated decision-making with legal or similar significant effect
• Systematic monitoring (CCTV, employee monitoring, tracking)
• Sensitive data or highly personal data (special categories, criminal data, financial data)
• Data processed on a large scale (volume, duration, geographic extent, number of subjects)
• Matching or combining datasets from different sources
• Data concerning vulnerable data subjects (children, employees, patients)
• Innovative use of technological or organizational solutions (AI, IoT, biometrics)
• Data transfer across borders outside the EU
• Processing that prevents data subjects from exercising a right or using a service

Workflow 3: DPA Agreement Drafting

Data Processing Agreements (Art. 28 GDPR) are required between controllers and processors.

DPA Required Clauses Checklist

Every DPA must include (Art. 28(3)):

• Subject matter and duration of processing
• Nature and purpose of processing
• Type of personal data and categories of data subjects
• Controller obligations and rights
• Processor obligations:
  • Process only on documented instructions from controller
  • Ensure persons authorized to process are under confidentiality
  • Implement appropriate technical and organizational measures (Art. 32)
  • Do not engage sub-processors without prior authorization
  • Assist controller with data subject rights requests
  • Assist controller with security, breach notification, DPIA
  • Delete or return all personal data at end of contract
  • Make available all information to demonstrate compliance
  • Allow and contribute to audits and inspections
• Sub-processor provisions:
  • General written authorization requirement
  • Equivalent data protection obligations flow-down
  • Processor liability for sub-processor failures
• International transfer provisions (if applicable):
  • Specify transfer mechanism (SCCs, BCRs, adequacy decision, DPF)
  • Include supplementary measures if needed
• Liability and indemnification clauses
• Termination provisions (data deletion/return certification)

DPA Review Checklist

When reviewing an existing DPA:

1. Is the processor named specifically, or is it a broad "any processor" clause?
2. Are sub-processor approval mechanisms clear (general vs. specific authorization)?
3. Does the DPA cover cross-border transfers if the processor uses non-EU infrastructure?
4. Are security measures specific or just "industry standard" (too vague)?
5. Is there a clear deletion timeline and certification requirement?
6. Does the DPA reference the processor's obligation to notify the controller of breaches?
7. Is there an audit right? Is it practical or illusory?

Workflow 4: CCPA/CPRA Compliance

The California Consumer Privacy Act as amended by the CPRA (effective Jan 1, 2023) extends GDPR-like rights to California residents.

CCPA/CPRA Applicability Threshold

A business must comply if it meets any one of these thresholds AND does business in California:

• Annual gross revenue > $25 million
• Buys, sells, or shares personal information of 100,000+ consumers/households
• Derives 50%+ of annual revenue from selling or sharing personal information

Consumer Rights Under CCPA/CPRA

CCPA/CPRA Compliance Checklist

1. Notice at Collection:

   • Provided at or before the point of collection
   • Lists categories of PI collected and purposes
   • Includes "Do Not Sell/Share My Personal Information" link (if applicable)

2. Privacy Policy Requirements:

   • Categories of PI collected in past 12 months
   • Categories of sources
   • Business/commercial purpose for collection
   • Categories of third parties with whom PI is shared
   • Consumer rights disclosures
   • Updated at least every 12 months

3. Opt-Out Mechanisms:

   • "Do Not Sell or Share My Personal Information" link on homepage
   • Opt-out preference signals honored (GPC — Global Privacy Control)
   • No re-request to opt-in for 12 months after opt-out
   • Opt-in consent required for minors 13–16; parental consent <13

4. Sensitive Personal Information:

   • "Limit the Use of My Sensitive Personal Information" link
   • Opt-in consent for secondary uses of sensitive PI
   • Sensitive PI categories: SSN, financial account, precise geolocation, race/ethnicity, contents of communications, genetic data, biometric data, health, sex life/orientation

5. Data Retention:

   • Retention periods disclosed
   • PI not retained longer than reasonably necessary

6. Contracts:

   • Contracts with service providers and contractors include CPRA-required terms
   • Contracts with third parties for sale/sharing include CPRA terms

7. Risk Assessments:

   • Cybersecurity audits conducted
   • Risk assessments for processing sensitive PI

8. Employee Training:

   • Staff handling consumer requests are trained
   • Annual training requirement met

CCPA vs GDPR Key Differences

Workflow 5: Breach Notification Procedure

Multi-Jurisdiction Breach Response

When a personal data breach occurs, different regulations impose different notification requirements. Time is critical.

Step-by-Step Breach Response

1. Contain and Assess (Immediate — Hour 0):

   • Contain the breach (revoke access, isolate systems, patch vulnerability)
   • Preserve evidence (logs, access records, system snapshots)
   • Assemble incident response team
   • Document: What happened? What data? How many subjects? What risk level?

2. Risk Assessment (Hours 0–24):

   • Classify the breach:
     • Confidentiality breach: Unauthorized access/disclosure
     • Integrity breach: Unauthorized alteration
     • 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

3. Notification Timelines by Jurisdiction:

4. 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

5. 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

6. 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:

1. Names
2. Geographic subdivisions smaller than a State
3. Dates (except year) related to an individual
4. Telephone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate/license numbers
12. Vehicle identifiers and serial numbers
13. Device identifiers and serial numbers
14. Web URLs
15. IP addresses
16. Biometric identifiers (fingerprints, voice prints)
17. Full-face photographs and comparable images
18. Any other unique identifying number, characteristic, or code

De-identification safe harbor: Remove all 18 identifiers + no actual knowledge that remaining information could identify the individual.

HIPAA Privacy Rule Assessment Checklist

1. Notice of Privacy Practices:

• Provided to all patients/plan members
• Acknowledgment of receipt documented (good faith effort)
• Posted prominently in facility and on website

2. Uses and Disclosures of PHI:

• Permitted uses: Treatment, Payment, Health Care Operations (TPO) — no authorization required
• Authorization required for: marketing, sale of PHI, psychotherapy notes, research (with exceptions)
• Minimum necessary standard: Is access limited to the minimum necessary PHI?
• Facility directories: Patient opt-out honored?
• Fundraising communications: Opt-out provided?

3. Individual Rights:

• Right to Access: PHI provided within 30 days
• Right to Amend: Process for requesting corrections
• Right to Accounting of Disclosures: Records of disclosures (6 years)
• Right to Request Restrictions: Especially self-pay restrictions
• Right to Confidential Communications: Alternative contacts honored

4. Administrative Safeguards:

• Privacy Official designated
• Workforce training (within reasonable time of hire, annually for changes)
• Sanctions policy for privacy violations
• Complaint process (no retaliation for filing complaints)
• Mitigation procedures for breaches
• Data safeguards (no intimidating/retaliatory acts)

5. Business Associate Agreements:

• BAAs in place with all business associates
• BAAs require: permitted uses, reporting breaches, subcontractor flow-down, termination provisions

HIPAA vs GDPR: Quick Comparison

Workflow 7: EU AI Act Requirements

The EU AI Act (Regulation 2024/1689) classifies AI systems into risk categories and imposes obligations accordingly.

AI Act Risk Classification

High-Risk AI System Requirements Checklist

For each requirement, assess the AI system:

1. 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

2. 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

3. 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

4. Record-Keeping / Logging (Art. 12):

   • Automatic logging of events during operation
   • Logging sufficient for traceability throughout lifecycle

5. 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

6. 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

7. 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

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).

Without adequacy decision — use these safeguards:

1. Standard Contractual Clauses (SCCs):

   • Modular approach: Controller-to-Controller, Controller-to-Processor, Processor-to-Processor, Processor-to-Controller
   • Must conduct a Transfer Impact Assessment (TIA) before relying on SCCs
   • Cannot be modified (may add supplementary clauses, but cannot contradict SCCs)
   • Most common mechanism for transfers to the US and other non-adequate countries

2. Binding Corporate Rules (BCRs):

   • Legally binding internal rules for multinational groups
   • Must be approved by a competent supervisory authority
   • Covers all transfers within the corporate group
   • Complex and time-consuming to establish (6–18 months)
   • Best for large multinationals with frequent intra-group transfers

3. Derogations (Art. 49 — exceptional use only):

   • Explicit consent (informed of risks with no adequacy/safeguards)
   • Necessary for contract performance
   • Important reasons of public interest
   • Legal claims
   • Vital interests
   • Public register consultation
   • Limitation: Cannot be used for repetitive, systematic transfers

Transfer Impact Assessment (TIA) Steps

Per EDPB Recommendations 01/2020 (post-Schrems II):

1. Map the transfer: What data, to where, under what mechanism?
2. Assess the law of the destination country: Does local law allow authorities access to the data in ways disproportionate to EU standards?
3. Assess the transfer tool: Do SCCs provide sufficient protection against the assessed risks?
4. Identify supplementary measures: If needed:
   • Technical: End-to-end encryption with key held outside destination jurisdiction, pseudonymization, split processing
   • Organizational: Policies, transparency reports, warrant canary
   • Contractual: Enhanced rights for data subjects
5. Procedural steps: Document the TIA, adopt supplementary measures, re-assess periodically
6. If insufficient protection after supplementary measures: Suspend or terminate the transfer

EU-US Data Privacy Framework (DPF)

• Replaced Privacy Shield (invalidated by Schrems II)
• Adequacy decision adopted July 10, 2023
• Only available for US entities certified under the DPF
• Check certification at: https://www.dataprivacyframework.gov/
• 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

PII Detection Framework

When reviewing code, data schemas, or documentation for PII:

1. Data Inventory Scan:

   • Search for known PII field patterns: email, phone, ssn, passport, dob, birth_date, address, ip_address, device_id, biometric, health, medical, national_id, tax_id
   • Search for PII in unstructured data: free-text fields, comments, logs, error messages, debug output
   • Check data at all layers: database schemas, API payloads, log files, analytics events, URL parameters, client-side storage

2. Context Assessment:

   • Does the data element alone identify an individual?
   • What happens when combined with other available data?
   • Is the data necessary for the stated purpose?
   • Would a reasonable person consider this data personal?

3. Data Flow Mapping:

   • Where does PII enter the system? (User input, API, third-party integration, device sensor)
   • Where is PII stored? (Database, cache, logs, file system, cloud storage)
   • Where does PII travel? (Network calls, API responses, data exports, analytics, emails)
   • Where does PII leave the system? (Third-party integrations, backups, exports, deletions)

4. Classification Output:

## PII Inventory: [System/Feature Name]

| Field Name | Data Type | PII Category | Sensitivity | Storage Location | Retention | Cross-Border? | Access Control |
|---|---|---|---|---|---|---|---|
| user_email | STRING | Direct Identifier | HIGH | PostgreSQL `users` table | Account lifecycle | No (EU-only) | Role: admin, self |
| ip_address | STRING | Indirect Identifier | MEDIUM | Access logs (S3) | 30 days | No (EU-only) | Role: security_team |
| medical_condition | TEXT | Sensitive PII | VERY HIGH | Encrypted column `health_records` | 10 years (legal req) | No (EU-only) | Role: medical_staff |

Data Minimization Audit

For each PII field in the inventory, answer:

1. Purpose: What specific business purpose does this field serve?
2. Necessity: Could this purpose be achieved without collecting this field?
3. Alternatives: Could a less identifying alternative serve the same purpose? (e.g., age range instead of DOB, country instead of full address)
4. Retention: Is the retention period proportionate to the purpose?
5. Verdict: Keep ✓ | Minimize ⚠️ (use alternative) | Remove ❌ (no valid purpose)

Workflow 10: Consent Management Review

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 da

…(truncated)