<!-- AUTO-GENERATED by export-skills.py — DO NOT EDIT -->
---
applyTo: '**/*'
---

# gdpr-reference

> GDPR compliance reference for security agents covering key principles, lawful bases, data subject rights, DPIAs, and breach notification requirements.

# GDPR Compliance Reference

## Overview

The General Data Protection Regulation (GDPR) is the European Union's comprehensive data
protection law (Regulation (EU) 2016/679) that governs the processing of personal data of
individuals within the EU/EEA. It applies to any organization worldwide that processes
personal data of EU residents, regardless of where the organization is based.

GDPR establishes strict requirements for data controllers (who determine the purposes and
means of processing) and data processors (who process data on behalf of controllers). It
grants significant rights to data subjects and imposes penalties of up to 20 million EUR or
4% of global annual revenue for non-compliance.

Key scope considerations:
- **Material scope:** Applies to processing of personal data wholly or partly by automated means.
- **Territorial scope:** Applies to organizations established in the EU, and those outside the EU that offer goods/services to or monitor behavior of EU residents.
- **Personal data:** Any information relating to an identified or identifiable natural person.

## When to Use This Skill

- Building or reviewing a data protection program for EU market operations.
- Conducting a Data Protection Impact Assessment (DPIA) for new features or systems.
- Responding to data subject access requests (DSARs).
- Evaluating whether a data breach triggers the 72-hour notification requirement.
- Reviewing data processing agreements with third-party vendors.
- Implementing privacy by design and by default in software development.
- Assessing lawful basis for a new data processing activity.

## How It Works

### Step 1: Data Mapping

Create a comprehensive inventory of all personal data processing activities:
- Identify what personal data is collected, from whom, and through which channels.
- Document the purpose of each processing activity.
- Map data flows: where data is stored, who has access, where it is transferred.
- Classify data by sensitivity (standard personal data vs. special categories under Article 9).
- Identify data retention periods for each category.

### Step 2: Lawful Basis Identification

For each processing activity, establish and document one of six lawful bases:

| Lawful Basis | Article | When Appropriate |
|-------------|---------|-----------------|
| Consent | 6(1)(a) | Freely given, specific, informed, unambiguous; can be withdrawn |
| Contract | 6(1)(b) | Processing necessary for a contract with the data subject |
| Legal obligation | 6(1)(c) | Processing required by EU or member state law |
| Vital interests | 6(1)(d) | Protecting life -- rarely applicable in business contexts |
| Public task | 6(1)(e) | Processing for official authority or public interest functions |
| Legitimate interests | 6(1)(f) | Balanced against data subject rights; requires LIA documentation |

### Step 3: Privacy Notices

Provide transparent information to data subjects (Articles 13-14):
- Identity and contact details of the controller and DPO.
- Purposes and lawful basis for each processing activity.
- Categories of personal data processed (if not obtained directly from subject).
- Recipients or categories of recipients.
- International transfer details and safeguards.
- Retention periods or criteria for determining retention.
- Data subject rights and how to exercise them.
- Right to lodge a complaint with a supervisory authority.

### Step 4: Data Protection Impact Assessment (DPIA)

Conduct a DPIA when processing is likely to result in high risk (Article 35):
- **Mandatory triggers:** Systematic monitoring of public areas, large-scale processing of
  special categories, automated decision-making with legal effects, new technologies.
- **Assessment contents:** Description of processing, necessity and proportionality assessment,
  risk assessment to data subjects, mitigation measures.
- **Consultation:** If risks cannot be mitigated, consult the supervisory authority (Article 36).

### Step 5: Incident Response (72-Hour Breach Notification)

When a personal data breach occurs (Articles 33-34):
1. **Detect and assess:** Determine if the breach involves personal data and the likely risk.
2. **Notify supervisory authority:** Within 72 hours of becoming aware, unless the breach is
   unlikely to result in risk to individuals. Document the breach even if notification is not required.
3. **Notify data subjects:** Without undue delay if the breach is likely to result in high risk
   to their rights and freedoms.
4. **Document:** Record all breaches in a breach register, including facts, effects, and remedial
   actions taken, regardless of whether notification was triggered.

## Key GDPR Principles (Article 5)

| Principle | Description |
|-----------|-------------|
| Lawfulness, fairness, transparency | Processing must have a lawful basis and be transparent to data subjects |
| Purpose limitation | Data collected for specified, explicit, legitimate purposes only |
| Data minimization | Only process data that is adequate, relevant, and necessary |
| Accuracy | Personal data must be accurate and kept up to date |
| Storage limitation | Data retained only as long as necessary for the stated purpose |
| Integrity and confidentiality | Appropriate security measures to protect personal data |
| Accountability | Controller must demonstrate compliance with all principles |

## Data Subject Rights (Articles 15-22)

| Right | Article | Controller Obligation |
|-------|---------|----------------------|
| Right of access | 15 | Provide copy of personal data and processing details within 1 month |
| Right to rectification | 16 | Correct inaccurate data without undue delay |
| Right to erasure | 17 | Delete data when no longer necessary, consent withdrawn, or unlawful |
| Right to restriction | 18 | Restrict processing while accuracy or lawfulness is contested |
| Right to data portability | 20 | Provide data in structured, machine-readable format |
| Right to object | 21 | Stop processing based on legitimate interests or direct marketing |
| Automated decision-making | 22 | Not be subject to solely automated decisions with legal effects |
| Right to be informed | 13-14 | Receive transparent information about processing |

## Examples

### Example 1: Data Processing Inventory Template

```yaml
data_processing_inventory:
  organization: "Acme SaaS Ltd."
  dpo_contact: "dpo@acme-saas.com"
  last_reviewed: "2026-02-20"
  record_of_processing_activities:  # Article 30

    - activity_id: "PA-001"
      name: "Customer account registration"
      controller: "Acme SaaS Ltd."
      processor: null
      purpose: "Create and manage user accounts for SaaS platform access"
      lawful_basis: "contract"  # Art. 6(1)(b)
      data_subjects: "Customers (EU residents)"
      data_categories:
        - "Full name"
        - "Email address"
        - "Company name"
        - "Job title"
        - "IP address (at registration)"
      special_categories: false
      recipients:
        - "Auth0 (identity provider, processor)"
        - "Stripe (payment processing, processor)"
      international_transfers:
        - destination: "United States"
          safeguard: "EU-US Data Privacy Framework certification"
          entity: "Auth0 Inc."
      retention_period: "Account data retained for duration of contract + 30 days"
      deletion_method: "Automated deletion pipeline triggered by account closure"
      security_measures:
        - "Encryption at rest (AES-256)"
        - "Encryption in transit (TLS 1.3)"
        - "RBAC with least privilege access"
        - "Audit logging of all access"
      dpia_required: false
      dpia_reference: null

    - activity_id: "PA-002"
      name: "Product analytics and usage tracking"
      controller: "Acme SaaS Ltd."
      processor: "Mixpanel Inc."
      purpose: "Understand product usage to improve user experience"
      lawful_basis: "legitimate_interests"  # Art. 6(1)(f)
      legitimate_interest_assessment:
        interest: "Improving product based on usage patterns"
        necessity: "Analytics essential for data-driven product decisions"
        balancing_test: >
          Low impact on data subjects; data pseudonymized; opt-out provided;
          no sensitive data collected; clear privacy notice provided.
      data_subjects: "Platform users (EU and non-EU)"
      data_categories:
        - "Pseudonymized user ID"
        - "Feature usage events"
        - "Session duration"
        - "Browser and device type"
      special_categories: false
      recipients:
        - "Mixpanel Inc. (processor)"
      international_transfers:
        - destination: "United States"
          safeguard: "Standard Contractual Clauses (SCCs) + supplementary measures"
          entity: "Mixpanel Inc."
      retention_period: "26 months rolling"
      deletion_method: "Automated TTL in Mixpanel"
      security_measures:
        - "Pseudonymization of user identifiers"
        - "IP anonymization enabled"
        - "Data Processing Agreement in place"
      dpia_required: false

    - activity_id: "PA-003"
      name: "AI-powered content recommendation"
      controller: "Acme SaaS Ltd."
      processor: null
      purpose: "Provide personalized content suggestions using ML models"
      lawful_basis: "consent"  # Art. 6(1)(a) -- profiling requires consent
      data_subjects: "Platform users who opt in"
      data_categories:
        - "Content interaction history"
        - "Topic preferences"
        - "Engagement scores (derived)"
      special_categories: false
      recipients: []
      international_transfers: []
      retention_period: "Data retained while consent is active + 30 days after withdrawal"
      deletion_method: "Consent withdrawal triggers automated purge pipeline"
      dpia_required: true
      dpia_reference: "DPIA-2026-003"
```

### Example 2: DPIA Template in Structured Format

```yaml
dpia:
  reference: "DPIA-2026-003"
  title: "AI-powered content recommendation engine"
  status: "approved"
  author: "Data Protection Officer"
  date_initiated: "2026-01-10"
  date_approved: "2026-02-01"
  review_date: "2026-08-01"

  processing_description:
    nature: >
      Machine learning model analyzes user content interaction history to
      generate personalized content recommendations. Model runs server-side
      and outputs ranked content lists.
    scope: >
      All platform users who opt in to personalized recommendations.
      Estimated 50,000 EU data subjects. Processing is continuous.
    context: >
      Users expect personalization in modern SaaS platforms. Feature is
      opt-in only with clear explanation of how data is used.
    purpose: >
      Improve user engagement and content discovery by surfacing relevant
      content based on historical interaction patterns.

  necessity_and_proportionality:
    lawful_basis: "Consent (Art. 6(1)(a)) -- explicit opt-in required"
    purpose_limitation: "Data used solely for recommendation; not shared or repurposed"
    data_minimization: >
      Only content interaction events and derived scores used; no
      demographic, location, or special category data processed.
    accuracy: "Model retrained weekly; stale user profiles purged after 90 days inactivity"
    storage_limitation: "Data deleted within 30 days of consent withdrawal"
    data_subject_rights: >
      Users can withdraw consent at any time; access, delete, and export
      their recommendation profile via self-service dashboard.

  risk_assessment:
    risks:
      - risk: "Profiling leads to filter bubbles or discriminatory content selection"
        likelihood: "medium"
        severity: "medium"
        risk_level: "medium"
        mitigation:
          - "Diversity injection in recommendation algorithm (min 20% exploratory content)"
          - "Quarterly bias audit of recommendation outputs"
          - "User controls to adjust recommendation parameters"
        residual_risk: "low"

      - risk: "Unauthorized access to user interaction profiles"
        likelihood: "low"
        severity: "high"
        risk_level: "medium"
        mitigation:
          - "Encryption at rest and in transit"
          - "RBAC with least privilege; only ML team has access"
          - "Audit logging of all profile access"
        residual_risk: "low"

      - risk: "Model inversion attack reconstructs user behavior from recommendations"
        likelihood: "low"
        severity: "medium"
        risk_level: "low"
        mitigation:
          - "Differential privacy noise added to model outputs"
          - "Rate limiting on recommendation API"
        residual_risk: "low"

  dpo_opinion: >
    The processing is proportionate to its purpose. Consent-based approach
    with robust opt-out mechanism adequately protects data subject rights.
    Bias auditing addresses profiling concerns. Approved with 6-month review.

  supervisory_authority_consultation_required: false
```

## Best Practices

### Do This

- Maintain a living record of processing activities (Article 30) as a core compliance artifact.
- Implement privacy by design and by default in the software development lifecycle.
- Provide clear, layered privacy notices (summary + full detail) at every data collection point.
- Design self-service tools for data subjects to exercise their rights (access, deletion, export).
- Conduct DPIAs early in the project lifecycle, not as an afterthought.
- Include data protection clauses and DPA requirements in all vendor procurement processes.
- Train all employees on GDPR basics; provide specialized training for engineering and support teams.
- Test your 72-hour breach notification process with tabletop exercises.

### Don't Do This

- Do not rely on consent as the default lawful basis; evaluate contract and legitimate interests first.
- Do not use pre-ticked consent boxes or bundle consent with terms of service.
- Do not collect personal data "just in case" -- data minimization is a legal requirement.
- Do not assume anonymized data is truly anonymous; test for re-identification risk.
- Do not treat GDPR as a one-time project; it requires ongoing compliance management.
- Do not ignore international transfer requirements; Schrems II invalidated Privacy Shield.
- Do not delay breach assessment; the 72-hour clock starts when you become "aware."

## Security Checklist

**Governance:**
- [ ] Data Protection Officer appointed (if required under Article 37)
- [ ] Record of processing activities maintained and current
- [ ] Data protection policies published and acknowledged by all staff
- [ ] GDPR training completed by all employees annually
- [ ] Data processing agreements executed with all processors

**Lawful Basis and Transparency:**
- [ ] Lawful basis documented for every processing activity
- [ ] Privacy notices provided at all data collection points
- [ ] Consent mechanisms meet GDPR requirements (freely given, specific, informed)
- [ ] Legitimate interest assessments documented where applicable

**Data Subject Rights:**
- [ ] Process for handling DSARs within 1-month deadline
- [ ] Self-service tools for access, deletion, and data portability
- [ ] Right to object mechanism for direct marketing (immediate effect)
- [ ] Automated decision-making safeguards in place (human review option)

**Data Protection by Design:**
- [ ] DPIAs conducted for high-risk processing activities
- [ ] Data minimization applied in system design and data collection
- [ ] Pseudonymization or anonymization applied where feasible
- [ ] Retention schedules enforced with automated deletion

**Security (Article 32):**
- [ ] Encryption at rest and in transit for personal data
- [ ] Access controls with least privilege and regular reviews
- [ ] Audit logging for systems processing personal data
- [ ] Regular security testing (penetration testing, vulnerability scanning)

**Breach Response:**
- [ ] Breach detection and assessment process documented
- [ ] 72-hour notification process tested and contact details current
- [ ] Breach register maintained for all incidents (including non-notifiable)
- [ ] Data subject notification templates prepared for high-risk breaches

**International Transfers:**
- [ ] Transfer mechanisms identified for all cross-border data flows
- [ ] Transfer Impact Assessments completed post-Schrems II
- [ ] Standard Contractual Clauses (new 2021 SCCs) executed where needed
- [ ] Supplementary measures implemented where SCCs alone are insufficient

## Related Skills

- @compliance-crosswalk -- Map GDPR requirements to SOC 2, ISO 27001, and NIST CSF controls.
- @soc2-controls -- Align SOC 2 Confidentiality and Privacy criteria with GDPR obligations.
- @ir-playbook-templates -- Build incident response playbooks covering GDPR breach notification.

## Additional Resources

- [GDPR Official Text](https://gdpr-info.eu/) -- Full regulation text with recitals.
- [EDPB Guidelines](https://edpb.europa.eu/our-work-tools/general-guidance_en) -- European Data Protection Board guidance on GDPR interpretation.
- [ICO GDPR Guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/) -- UK Information Commissioner practical guidance.
- [CNIL DPIA Tool](https://www.cnil.fr/en/open-source-pia-software-helps-carry-out-data-protection-impact-assessment) -- Open-source DPIA methodology tool.
- [Standard Contractual Clauses (2021)](https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en) -- Official EU SCCs for international transfers.
