---
name: gdpr-dsgvo-expert
description: >
  GDPR and German DSGVO compliance. Use for GDPR compliance assessments, privacy
  audits, scanning codebases for privacy risks, DPIA generation, data protection
  planning, and data subject rights management.
license: MIT + Commons Clause
metadata:
  version: 1.0.0
  author: borghei
  category: compliance
  domain: privacy-compliance
  updated: 2026-03-31
  tags: [gdpr, dsgvo, dpia, data-protection, privacy]
---
# GDPR/DSGVO Expert

Tools and guidance for EU General Data Protection Regulation (GDPR) and German Bundesdatenschutzgesetz (BDSG) compliance.

---

## Table of Contents

- [Tools](#tools)
  - [GDPR Compliance Checker](#gdpr-compliance-checker)
  - [DPIA Generator](#dpia-generator)
  - [Data Subject Rights Tracker](#data-subject-rights-tracker)
- [Reference Guides](#reference-guides)
- [Workflows](#workflows)

---

## Tools

### GDPR Compliance Checker

Scans codebases for potential GDPR compliance issues including personal data patterns and risky code practices.

```bash
# Scan a project directory
python scripts/gdpr_compliance_checker.py /path/to/project

# JSON output for CI/CD integration
python scripts/gdpr_compliance_checker.py . --json --output report.json
```

**Detects:**
- Personal data patterns (email, phone, IP addresses)
- Special category data (health, biometric, religion)
- Financial data (credit cards, IBAN)
- Risky code patterns:
  - Logging personal data
  - Missing consent mechanisms
  - Indefinite data retention
  - Unencrypted sensitive data
  - Disabled deletion functionality

**Output:**
- Compliance score (0-100)
- Risk categorization (critical, high, medium)
- Prioritized recommendations with GDPR article references

---

### DPIA Generator

Generates Data Protection Impact Assessment documentation following Art. 35 requirements.

```bash
# Get input template
python scripts/dpia_generator.py --template > input.json

# Generate DPIA report
python scripts/dpia_generator.py --input input.json --output dpia_report.md
```

**Features:**
- Automatic DPIA threshold assessment
- Risk identification based on processing characteristics
- Legal basis requirements documentation
- Mitigation recommendations
- Markdown report generation

**DPIA Triggers Assessed:**
- Systematic monitoring (Art. 35(3)(c))
- Large-scale special category data (Art. 35(3)(b))
- Automated decision-making (Art. 35(3)(a))
- WP29 high-risk criteria

---

### Data Subject Rights Tracker

Manages data subject rights requests under GDPR Articles 15-22.

```bash
# Add new request
python scripts/data_subject_rights_tracker.py add \
  --type access --subject "John Doe" --email "john@example.com"

# List all requests
python scripts/data_subject_rights_tracker.py list

# Update status
python scripts/data_subject_rights_tracker.py status --id DSR-202601-0001 --update verified

# Generate compliance report
python scripts/data_subject_rights_tracker.py report --output compliance.json

# Generate response template
python scripts/data_subject_rights_tracker.py template --id DSR-202601-0001
```

**Supported Rights:**

| Right | Article | Deadline |
|-------|---------|----------|
| Access | Art. 15 | 30 days |
| Rectification | Art. 16 | 30 days |
| Erasure | Art. 17 | 30 days |
| Restriction | Art. 18 | 30 days |
| Portability | Art. 20 | 30 days |
| Objection | Art. 21 | 30 days |
| Automated decisions | Art. 22 | 30 days |

**Features:**
- Deadline tracking with overdue alerts
- Identity verification workflow
- Response template generation
- Compliance reporting

---

## Reference Guides

### GDPR Compliance Guide
`references/gdpr_compliance_guide.md`

Comprehensive implementation guidance covering:
- Legal bases for processing (Art. 6)
- Special category requirements (Art. 9)
- Data subject rights implementation
- Accountability requirements (Art. 30)
- International transfers (Chapter V)
- Breach notification (Art. 33-34)

### German BDSG Requirements
`references/german_bdsg_requirements.md`

German-specific requirements including:
- DPO appointment threshold (§ 38 BDSG - 20+ employees)
- Employment data processing (§ 26 BDSG)
- Video surveillance rules (§ 4 BDSG)
- Credit scoring requirements (§ 31 BDSG)
- State data protection laws (Landesdatenschutzgesetze)
- Works council co-determination rights

### DPIA Methodology
`references/dpia_methodology.md`

Step-by-step DPIA process:
- Threshold assessment criteria
- WP29 high-risk indicators
- Risk assessment methodology
- Mitigation measure categories
- DPO and supervisory authority consultation
- Templates and checklists

---

## Clarify First

Before running the assessment, confirm these inputs. If any is unknown or vague, ASK — do not assume:

- [ ] **Task** — codebase compliance scan, DPIA generation, or data-subject-rights tracking (selects the tool and workflow)
- [ ] **Role and jurisdiction** — controller vs processor; GDPR-only vs German BDSG applies (BDSG adds the DPO threshold, §26 employment, and §4 video rules)
- [ ] **Processing characteristics** — high-risk processing such as profiling, AI, or large-scale special-category data (determines whether a DPIA is required)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the assessment.

## Workflows

### Workflow 1: New Processing Activity Assessment

```
Step 1: Run compliance checker on codebase
        → python scripts/gdpr_compliance_checker.py /path/to/code

Step 2: Review findings and compliance score
        → Address critical and high issues

Step 3: Determine if DPIA required
        → Check references/dpia_methodology.md threshold criteria

Step 4: If DPIA required, generate assessment
        → python scripts/dpia_generator.py --template > input.json
        → Fill in processing details
        → python scripts/dpia_generator.py --input input.json --output dpia.md

Step 5: Document in records of processing activities
```

### Workflow 2: Data Subject Request Handling

```
Step 1: Log request in tracker
        → python scripts/data_subject_rights_tracker.py add --type [type] ...

Step 2: Verify identity (proportionate measures)
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update verified

Step 3: Gather data from systems
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update in_progress

Step 4: Generate response
        → python scripts/data_subject_rights_tracker.py template --id [ID]

Step 5: Send response and complete
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update completed

Step 6: Monitor compliance
        → python scripts/data_subject_rights_tracker.py report
```

### Workflow 3: German BDSG Compliance Check

```
Step 1: Determine if DPO required
        → 20+ employees processing personal data automatically
        → OR processing requires DPIA
        → OR business involves data transfer/market research

Step 2: If employees involved, review § 26 BDSG
        → Document legal basis for employee data
        → Check works council requirements

Step 3: If video surveillance, comply with § 4 BDSG
        → Install signage
        → Document necessity
        → Limit retention

Step 4: Register DPO with supervisory authority
        → See references/german_bdsg_requirements.md for authority list
```

---

## Key GDPR Concepts

### Legal Bases (Art. 6)

- **Consent**: Marketing, newsletters, analytics (must be freely given, specific, informed)
- **Contract**: Order fulfillment, service delivery
- **Legal obligation**: Tax records, employment law
- **Legitimate interests**: Fraud prevention, security (requires balancing test)

### Special Category Data (Art. 9)

Requires explicit consent or Art. 9(2) exception:
- Health data
- Biometric data
- Racial/ethnic origin
- Political opinions
- Religious beliefs
- Trade union membership
- Genetic data
- Sexual orientation

### Data Subject Rights

All rights must be fulfilled within **30 days** (extendable to 90 for complex requests):
- **Access**: Provide copy of data and processing information
- **Rectification**: Correct inaccurate data
- **Erasure**: Delete data (with exceptions for legal obligations)
- **Restriction**: Limit processing while issues are resolved
- **Portability**: Provide data in machine-readable format
- **Object**: Stop processing based on legitimate interests

### German BDSG Additions

| Topic | BDSG Section | Key Requirement |
|-------|--------------|-----------------|
| DPO threshold | § 38 | 20+ employees = mandatory DPO |
| Employment | § 26 | Detailed employee data rules |
| Video | § 4 | Signage and proportionality |
| Scoring | § 31 | Explainable algorithms |

---

## Cross-Reference: CCPA/CPRA US Privacy Comparison

When operating across EU and US jurisdictions, align GDPR compliance with California Consumer Privacy Act (CCPA) as amended by CPRA. Key differences to manage:

| Dimension | GDPR | CCPA/CPRA |
|-----------|------|-----------|
| Scope | Any org processing EU resident data | For-profit businesses meeting revenue/data thresholds |
| Legal basis | 6 lawful bases required (Art. 6) | No legal basis requirement; opt-out model |
| Consent | Opt-in by default | Opt-out (except minors and sensitive data) |
| Data subject rights | Access, rectification, erasure, portability, objection | Know, delete, correct, opt-out of sale/sharing, limit sensitive data use |
| Breach notification | 72 hours to supervisory authority (Art. 33) | "Most expedient time possible" to consumers |
| Enforcement | DPAs with fines up to 4% global turnover | California Privacy Protection Agency (CPPA), $2,500-$7,500 per violation |
| DPO requirement | Mandatory in many cases (Art. 37) | No DPO requirement |
| Children's data | Under 16 requires parental consent (Art. 8) | Under 16 opt-in for sale; under 13 parental consent |

**Practical alignment:** Build a unified privacy program that satisfies the stricter GDPR requirements by default, then layer CCPA/CPRA-specific mechanisms (e.g., "Do Not Sell or Share My Personal Information" link, annual metrics disclosure).

> **See also:** `../ccpa-cpra-specialist/SKILL.md` for full CCPA/CPRA compliance workflows and tools.

---

## Infrastructure Privacy Controls

### Cookie Consent and Tracking

Implement compliant cookie consent per GDPR Art. 6 + ePrivacy Directive:

| Category | Examples | Consent Required | Default State |
|----------|----------|------------------|---------------|
| Strictly Necessary | Session, CSRF, load balancer | No | Active |
| Functional | Language preference, UI settings | Yes | Inactive |
| Analytics | Google Analytics, Matomo, Hotjar | Yes | Inactive |
| Marketing | Facebook Pixel, Google Ads, retargeting | Yes | Inactive |

**Implementation requirements:**
- Banner must block all non-essential cookies until explicit consent
- Pre-checked boxes are NOT valid consent (Planet49 ruling, CJEU C-673/17)
- Consent must be as easy to withdraw as to give
- Record consent proof (timestamp, version, choices made)
- Re-consent on material changes to cookie policy

### Global Privacy Control (GPC) Signal

Per CCPA/CPRA regulations and emerging EU guidance:
- Detect `Sec-GPC: 1` HTTP header and `navigator.globalPrivacyControl` JavaScript API
- Treat GPC as valid opt-out signal for CCPA/CPRA
- For GDPR: GPC can serve as a signal of objection under Art. 21 — evaluate on a case-by-case basis
- Log GPC signal detection and honor it automatically

### Data Localization and Cross-Border Transfers

| Transfer Mechanism | Status (post-Schrems II) | When to Use |
|---------------------|--------------------------|-------------|
| EU Adequacy Decision | Valid | Transfers to adequate countries (e.g., Japan, UK, South Korea, US via DPF) |
| Standard Contractual Clauses (SCCs) | Valid with TIA | Default mechanism for non-adequate countries |
| Binding Corporate Rules (BCRs) | Valid | Intra-group transfers in multinationals |
| EU-US Data Privacy Framework (DPF) | Valid (since July 2023) | US companies certified under DPF |
| Derogations (Art. 49) | Limited use only | Explicit consent, contract necessity — not for systematic transfers |

**Transfer Impact Assessment (TIA) requirements for SCCs:**
1. Map the data flow (what data, to whom, where)
2. Assess recipient country legal framework (surveillance laws, access by authorities)
3. Evaluate supplementary measures needed (encryption, pseudonymization, contractual)
4. Document assessment and review annually

---

## AI-Specific GDPR Requirements

### Automated Decision-Making (Art. 22)

Art. 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects:

| Requirement | Implementation |
|-------------|----------------|
| Right not to be subject to automated decisions | Provide human review mechanism for consequential decisions |
| Right to explanation | Document and explain logic, significance, and consequences |
| Right to contest | Enable data subjects to challenge automated decisions |
| Explicit consent or contract necessity | Secure Art. 22(2) legal basis before deploying |
| Suitable safeguards | Implement human oversight, right to express point of view |

**AI transparency checklist:**
- [ ] Document algorithmic logic in plain language
- [ ] Implement human-in-the-loop for high-stakes decisions (credit, employment, insurance)
- [ ] Provide opt-out mechanism for fully automated decisions
- [ ] Conduct and document bias testing (protected characteristics under Art. 9)
- [ ] Log all automated decisions with reasoning for auditability
- [ ] Include AI decision-making in privacy notice (Art. 13(2)(f), Art. 14(2)(g))

### AI Training Data Requirements

| Requirement | GDPR Basis | Action |
|-------------|------------|--------|
| Lawful basis for training data | Art. 6 | Legitimate interest (with DPIA) or consent |
| Purpose limitation | Art. 5(1)(b) | Training purpose must be compatible with original collection |
| Data minimization | Art. 5(1)(c) | Use minimum data necessary; prefer synthetic/anonymized data |
| Accuracy | Art. 5(1)(d) | Ensure training data is accurate and up-to-date |
| Storage limitation | Art. 5(1)(e) | Define retention for training datasets |
| Special category data | Art. 9 | Explicit consent or Art. 9(2)(j) research exemption for health/biometric data |
| Right to erasure | Art. 17 | Implement mechanism to remove individual data from training sets (or document inability) |
| Data scraping | Art. 14 | Inform data subjects when using publicly available data for training |

---

## Enhanced DPIA Methodology with EU AI Act Integration

### When DPIA + AI Act Conformity Assessment Overlap

For AI systems processing personal data, both GDPR Art. 35 DPIA and EU AI Act conformity assessment may apply:

| AI Risk Level (EU AI Act) | GDPR DPIA Required? | Combined Assessment Approach |
|---------------------------|----------------------|------------------------------|
| Unacceptable (Art. 5) | N/A — prohibited | Do not deploy |
| High-risk (Annex III) | Almost always yes | Joint DPIA + conformity assessment |
| Limited risk (Art. 50) | Evaluate per Art. 35 criteria | DPIA if systematic monitoring or profiling |
| Minimal risk | Evaluate per Art. 35 criteria | Standard DPIA threshold assessment |

### Enhanced DPIA Process for AI Systems

```
Step 1: AI System Classification
        → Classify under EU AI Act risk levels
        → Map to GDPR Art. 35(3) triggers

Step 2: Data Flow and Processing Analysis
        → Document training data sources and legal basis
        → Map inference data flows
        → Identify automated decision points (Art. 22)

Step 3: AI-Specific Risk Assessment
        → Bias and discrimination risk (protected groups)
        → Accuracy and reliability risk
        → Explainability and transparency gaps
        → Data quality and representativeness
        → Model drift and ongoing monitoring needs

Step 4: Fundamental Rights Impact
        → Right to non-discrimination
        → Right to privacy and data protection
        → Freedom of expression (content moderation AI)
        → Right to an effective remedy

Step 5: Combined Mitigation Measures
        → Technical: differential privacy, federated learning, model cards
        → Organizational: AI ethics board, human oversight procedures
        → Contractual: AI-specific DPA clauses with processors
        → Monitoring: continuous bias monitoring, performance drift detection

Step 6: DPO and Supervisory Authority Consultation
        → Consult DPO on combined assessment
        → Prior consultation with SA if high residual risk (Art. 36)
        → Notify national AI authority if high-risk AI system
```

---

## Privacy by Design Technical Controls

### Data Minimization Techniques

| Technique | Description | Use Case |
|-----------|-------------|----------|
| Field-level encryption | Encrypt specific PII fields at rest | Database storage |
| Tokenization | Replace PII with non-reversible tokens | Payment processing, analytics |
| Data masking | Obscure portions of data (e.g., email: j***@example.com) | UI display, logging |
| Aggregation | Process only aggregated/statistical data | Analytics, reporting |
| Purpose-scoped access | Limit data access to specific processing purposes | Multi-purpose systems |
| Automatic expiration | TTL-based data deletion | Session data, temporary processing |

### Pseudonymization Implementation (Recital 26, Art. 4(5))

| Method | Reversibility | Strength | Best For |
|--------|---------------|----------|----------|
| HMAC-based | Reversible with key | Strong | Internal analytics with re-identification need |
| Format-preserving encryption | Reversible with key | Strong | Legacy system compatibility |
| Deterministic hashing (salted) | One-way | Medium | Cross-dataset linkage without PII |
| Random ID mapping | Reversible with lookup table | Strong | Research datasets |

**Key management for pseudonymization:**
- Store re-identification keys separately from pseudonymized data
- Apply strict access controls to key material (minimum two-person rule)
- Document key rotation schedule
- Log all re-identification events

### Encryption Standards

| Layer | Minimum Standard | Recommended |
|-------|------------------|-------------|
| At rest | AES-256 | AES-256-GCM with envelope encryption |
| In transit | TLS 1.2 | TLS 1.3 |
| Database | Transparent Data Encryption (TDE) | Column-level encryption for PII |
| Backups | AES-256 | AES-256 + separate key from production |
| Key management | Hardware-backed (HSM/KMS) | Cloud KMS with customer-managed keys (BYOK) |

---

## Cross-Framework Privacy Mapping

| Requirement | GDPR Article | CCPA/CPRA Section | HIPAA Rule | NIS2 Article |
|-------------|-------------|-------------------|------------|--------------|
| Risk assessment | Art. 35 (DPIA) | §1798.185 (risk assessment regs) | §164.308(a)(1) | Art. 21(2)(a) |
| Breach notification | Art. 33-34 (72 hrs to SA) | §1798.150 (to consumers) | §164.404-408 (60 days) | Art. 23 (24 hrs early warning) |
| Data minimization | Art. 5(1)(c) | §1798.100(c) (collection limitation) | §164.502(b) (minimum necessary) | Art. 21(2)(e) |
| Encryption | Art. 32(1)(a) | Implicit (reasonable security) | §164.312(a)(2)(iv) (addressable) | Art. 21(2)(e) |
| Access controls | Art. 32(1)(b) | Implicit (reasonable security) | §164.312(a)(1) (access control) | Art. 21(2)(d) |
| Incident response | Art. 33-34 | §1798.150 | §164.308(a)(6) | Art. 21(2)(b) |
| Supply chain security | Art. 28 (processor agreements) | §1798.140(ag) (service provider contracts) | §164.308(b) (BAAs) | Art. 21(2)(d) |
| Governance/accountability | Art. 5(2), Art. 24 | §1798.185 (audit regs) | §164.308(a)(1) | Art. 20 (governance) |
| Right to delete/erasure | Art. 17 | §1798.105 | Limited (retention rules) | N/A |
| Data portability | Art. 20 | §1798.130(a)(2) | N/A | N/A |

> **Cross-references:** See `../information-security-mana