<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->

# NERF Privacy Engineering Deep Training
## Privacy Impact Assessments, Data Flow Mapping & Privacy-Preserving Architectures

**Training Module**: PRIVACY mode deep knowledge
**Last Updated**: 2026-03-14
**Sources**: GDPR Article 35, UK ICO DPIA guidance, EDPB Guidelines 4/2019, OWASP privacy cheat sheets, OpenDP, Google DP, PySyft, Microsoft SEAL

---

## Table of Contents

1. [Complete DPIA Template with Worked Example](#1-complete-dpia-template-with-worked-example)
2. [Data Flow Mapping Methodology](#2-data-flow-mapping-methodology)
3. [Privacy-Preserving Architecture Patterns Catalog](#3-privacy-preserving-architecture-patterns-catalog)
4. [Privacy by Design Implementation Guide](#4-privacy-by-design-implementation-guide)
5. [Cross-Border Data Transfer Assessment Template](#5-cross-border-data-transfer-assessment-template)
6. [Cookie Consent and Tracking Compliance Guide](#6-cookie-consent-and-tracking-compliance-guide)

---

## 1. Complete DPIA Template with Worked Example

### 1.1 DPIA Legal Basis

**GDPR Article 35** mandates a DPIA prior to processing when the type of processing — particularly using new technologies — is "likely to result in a high risk to the rights and freedoms of natural persons."

**Mandatory DPIA triggers** (Art. 35(3)):
- Systematic and extensive automated evaluation of personal aspects (profiling) producing legal effects or similarly significant effects
- Large-scale processing of special categories (Art. 9) or criminal conviction data (Art. 10)
- Systematic monitoring of a publicly accessible area on a large scale

**Additional high-risk indicators** (UK ICO / EDPB WP248):
- Innovative technologies
- Invisible processing (data subjects unaware)
- Processing affecting vulnerable individuals
- Preventing data subjects from exercising rights
- Data matching or combining from multiple sources
- Large-scale processing
- Scoring or evaluation

**Rule of thumb**: If processing matches two or more indicators, a DPIA is required.

### 1.2 DPIA Required Contents (Art. 35(7))

A DPIA must contain at minimum:

| Element | Description |
|---------|-------------|
| **Systematic description** | Nature, scope, context, and purposes of processing |
| **Necessity & proportionality** | Assessment against the processing purpose |
| **Risk assessment** | Risks to rights and freedoms of data subjects |
| **Mitigation measures** | Safeguards, security measures, and mechanisms to ensure compliance |

### 1.3 Seven-Step DPIA Process (ICO Framework)

```
Step 1: SCREENING    — Determine whether DPIA is required
Step 2: DESCRIPTION  — Document the processing comprehensively
Step 3: CONSULTATION — Engage DPO, stakeholders, and data subjects
Step 4: NECESSITY    — Assess necessity and proportionality
Step 5: RISK ID      — Identify risks to individuals
Step 6: MITIGATION   — Identify measures to reduce risk
Step 7: SIGN-OFF     — Document outcome, obtain approval, schedule review
```

### 1.4 DPIA Template

```
============================================================
DATA PROTECTION IMPACT ASSESSMENT
============================================================

DOCUMENT CONTROL
  Version     : [X.Y]
  Date        : [YYYY-MM-DD]
  Author      : [Name, Role]
  DPO Review  : [Name, Date]
  Status      : Draft | Under Review | Approved | Requires Consultation

------------------------------------------------------------
SECTION 1: SCREENING
------------------------------------------------------------

1.1 Processing Description (summary)
  [Brief description of what is being processed and why]

1.2 DPIA Screening Checklist

  [ ] Automated decision-making with legal/significant effects
  [ ] Large-scale processing of special category data
  [ ] Systematic monitoring of public areas
  [ ] Evaluation/scoring of individuals
  [ ] Matching or combining datasets
  [ ] Processing of vulnerable individuals' data
  [ ] Innovative use of technology
  [ ] Processing that prevents exercise of rights
  [ ] Invisible processing
  [ ] Large-scale processing

  Triggers matched: [N] — DPIA required: YES / NO

------------------------------------------------------------
SECTION 2: SYSTEMATIC DESCRIPTION OF PROCESSING
------------------------------------------------------------

2.1 Nature of Processing
  What will you do with the data?
  [Describe collection, storage, use, sharing, deletion]

2.2 Scope of Processing
  - Data categories        : [List all personal data categories]
  - Special categories     : [Art. 9 data: health, biometric, etc.]
  - Data subjects          : [Who: customers, employees, public]
  - Volume                 : [Approximate number of records/subjects]
  - Geographic scope       : [Regions/countries]
  - Retention period       : [How long data is kept]

2.3 Context of Processing
  - Relationship with data subjects : [Direct, indirect, none]
  - Data subject expectations       : [Would they expect this?]
  - Prior processing history        : [New or existing processing]
  - Applicable sector codes         : [Industry-specific rules]

2.4 Purpose of Processing
  - Primary purpose    : [Core business reason]
  - Secondary purposes : [Any additional uses]
  - Legal basis        : [Art. 6(1)(a-f) — specify]
  - Legitimate interest assessment : [If Art. 6(1)(f)]

2.5 Data Flows
  [Attach data flow diagram — see Section 2 methodology]

  Source → Collection → Storage → Processing → Output → Sharing → Deletion

  Recipients:
  - Internal : [Departments/roles with access]
  - External : [Third parties, processors, sub-processors]
  - Transfers: [Any cross-border transfers — see Section 5]

2.6 Technology Stack
  - Systems/platforms   : [Software, cloud services]
  - Algorithms          : [ML models, scoring logic]
  - Infrastructure      : [On-prem, cloud provider, hybrid]
  - Encryption          : [At rest, in transit, in use]

------------------------------------------------------------
SECTION 3: CONSULTATION
------------------------------------------------------------

3.1 DPO Consultation
  - DPO name        : [Name]
  - Date consulted  : [Date]
  - DPO advice      : [Summary of advice provided]
  - Advice followed : YES / NO — if NO, justification:

3.2 Data Subject Consultation
  - Method          : [Survey, focus group, public consultation]
  - Sample size     : [N]
  - Key concerns    : [Summary]
  - Response        : [How concerns were addressed]
  - If not consulted, justification: [Why]

3.3 Other Stakeholders
  - Engineering     : [Input on technical feasibility]
  - Legal           : [Input on legal basis]
  - Business        : [Input on business necessity]

------------------------------------------------------------
SECTION 4: NECESSITY AND PROPORTIONALITY
------------------------------------------------------------

4.1 Lawful Basis Justification
  Legal basis: [Specify Art. 6 basis]
  Justification: [Why this basis applies]

4.2 Purpose Limitation
  Is processing limited to stated purposes?  YES / NO
  Safeguards against function creep: [Describe]

4.3 Data Minimization
  Is each data element necessary?
  | Data Element | Purpose | Necessary? | Justification |
  |-------------|---------|------------|---------------|
  | [field]     | [why]   | Y/N        | [reason]      |

4.4 Accuracy Measures
  How is data accuracy ensured? [Describe]
  Correction mechanisms: [Describe]

4.5 Storage Limitation
  Retention schedule: [Describe]
  Deletion/anonymization procedures: [Describe]

4.6 Less Intrusive Alternatives
  Were alternatives considered?
  | Alternative | Feasible? | Why Not Chosen |
  |------------|-----------|----------------|
  | [option]   | Y/N       | [reason]       |

------------------------------------------------------------
SECTION 5: RISK IDENTIFICATION AND ASSESSMENT
------------------------------------------------------------

Risk assessment matrix:

  Likelihood: Remote (1) | Possible (2) | Likely (3) | Almost Certain (4)
  Severity:   Minimal (1) | Significant (2) | Severe (3) | Critical (4)
  Risk Level: Likelihood x Severity
    1-4 = Low | 5-8 = Medium | 9-12 = High | 13-16 = Critical

5.1 Risk Register

| ID | Risk Description | Harm Type | Likelihood | Severity | Risk Level |
|----|-----------------|-----------|------------|----------|------------|
| R1 | [description]   | [type]    | [1-4]     | [1-4]    | [score]    |

  Harm types:
  - Physical harm
  - Material harm (financial loss, discrimination)
  - Non-material harm (distress, reputational damage)
  - Loss of control over personal data
  - Limitation of rights
  - Discrimination
  - Identity theft or fraud
  - Financial loss
  - Unauthorized reversal of pseudonymization
  - Damage to reputation
  - Loss of confidentiality of data protected by professional secrecy

------------------------------------------------------------
SECTION 6: RISK MITIGATION
------------------------------------------------------------

| Risk ID | Mitigation Measure | Type | Owner | Status | Residual Risk |
|---------|-------------------|------|-------|--------|---------------|
| R1      | [measure]         | [T/O/L] | [who] | [status] | [L/M/H/C] |

  Type: T = Technical, O = Organizational, L = Legal

------------------------------------------------------------
SECTION 7: SIGN-OFF AND REVIEW
------------------------------------------------------------

7.1 Residual Risk Assessment
  Overall residual risk: LOW / MEDIUM / HIGH / CRITICAL
  Acceptable? YES / NO
  If HIGH/CRITICAL: Supervisory authority consultation required (Art. 36)

7.2 Approval

  | Role | Name | Decision | Date | Signature |
  |------|------|----------|------|-----------|
  | DPO  |      | Approve/Reject/Conditional | | |
  | Controller | | Approve/Reject | | |
  | CISO |      | Approve/Reject | | |

7.3 Review Schedule
  Next review date: [Date or trigger event]
  Review triggers:
  - Change in processing scope
  - New data categories
  - Technology change
  - Security incident
  - Regulatory change

7.4 Supervisory Authority Consultation (if required)
  Authority: [Name]
  Date submitted: [Date]
  Response: [Outcome]
```

### 1.5 Worked Example: ML-Powered Recommendation System

```
============================================================
DATA PROTECTION IMPACT ASSESSMENT
============================================================

DOCUMENT CONTROL
  Version     : 1.0
  Date        : 2026-03-14
  Author      : Privacy Engineering Team
  DPO Review  : J. Chen, 2026-03-10
  Status      : Approved

------------------------------------------------------------
SECTION 1: SCREENING
------------------------------------------------------------

1.1 Processing Description
  E-commerce platform deploying ML recommendation engine that
  analyzes purchase history, browsing behavior, demographic data,
  and inferred preferences to generate personalized product
  recommendations and targeted promotional content.

1.2 DPIA Screening Checklist
  [X] Automated decision-making with legal/significant effects
      — Personalization affects pricing, product visibility,
        and promotional offers with financial impact
  [ ] Large-scale processing of special category data
  [ ] Systematic monitoring of public areas
  [X] Evaluation/scoring of individuals
      — User preference scoring and behavioral profiling
  [X] Matching or combining datasets
      — Purchase, browsing, demographic, and third-party data
  [ ] Processing of vulnerable individuals' data
  [X] Innovative use of technology
      — Deep learning recommendation model
  [ ] Processing that prevents exercise of rights
  [X] Invisible processing
      — Users unaware of full extent of behavioral tracking
  [X] Large-scale processing
      — 2.3M active users

  Triggers matched: 6 — DPIA required: YES

------------------------------------------------------------
SECTION 2: SYSTEMATIC DESCRIPTION OF PROCESSING
------------------------------------------------------------

2.1 Nature of Processing
  - Collection of behavioral signals (page views, clicks,
    dwell time, cart actions, purchases)
  - Aggregation into user profiles with preference vectors
  - ML model training on historical interaction data
  - Real-time inference for recommendation generation
  - A/B testing of recommendation strategies
  - Periodic model retraining (weekly)

2.2 Scope
  - Data categories: Name, email, purchase history, browsing
    behavior, device info, IP address, location (city-level),
    age range, gender, inferred interests
  - Special categories: None directly; inferred health interests
    possible from purchases (supplements, medical devices)
  - Data subjects: Registered customers (2.3M), guest browsers
    (est. 8M unique/month via cookies)
  - Geographic scope: EU/EEA + UK
  - Retention: Behavioral data 24 months, aggregated profiles
    36 months, model training data anonymized after use

2.3 Context
  - Relationship: Direct (registered) and indirect (guest)
  - Expectations: Users expect basic recommendations; may not
    expect depth of behavioral profiling, cross-session
    tracking, or inferred category creation
  - History: Replacing rule-based system with ML model

2.4 Purpose
  - Primary: Improve product discovery and user experience
  - Secondary: Increase conversion rate and average order value
  - Legal basis: Legitimate interest (Art. 6(1)(f)) for
    registered users; Consent (Art. 6(1)(a)) for cookie-based
    tracking of guest users
  - LIA conducted: YES — documented separately

2.5 Data Flows

  User Browser --> CDN/WAF --> Web App --> Event Collector
       |                                       |
       v                                       v
  Cookie Store                          Kafka Event Stream
                                               |
                                    +----------+----------+
                                    |                     |
                                    v                     v
                              Feature Store         Training Pipeline
                                    |                     |
                                    v                     v
                              Inference API          Model Registry
                                    |
                                    v
                              Recommendation
                              Response --> User

  Recipients:
  - Internal: Data Science (model development), Marketing
    (campaign targeting), Product (A/B testing)
  - External: Cloud provider (AWS eu-west-1), CDN (Cloudflare),
    analytics processor (Amplitude — US, SCCs in place)
  - No data sold to third parties

2.6 Technology
  - Systems: Python/PyTorch recommendation model, PostgreSQL
    user store, Redis feature cache, Kafka event stream
  - Algorithm: Two-tower neural collaborative filtering with
    content features; 128-dim user/item embeddings
  - Infrastructure: AWS eu-west-1 (Frankfurt), encrypted EBS,
    VPC isolation
  - Encryption: TLS 1.3 in transit, AES-256 at rest, feature
    store encrypted at application layer

------------------------------------------------------------
SECTION 3: CONSULTATION
------------------------------------------------------------

3.1 DPO Consultation
  - DPO: J. Chen
  - Consulted: 2026-03-10
  - Advice: (1) Implement granular opt-out for profiling
    beyond basic recommendations, (2) Conduct LIA for
    legitimate interest basis, (3) Add transparency
    mechanism showing users why items are recommended,
    (4) Ensure inferred health-related categories trigger
    special category review
  - All advice followed: YES

3.2 Data Subject Consultation
  - Method: In-app survey to 5,000 randomly selected users
  - Key concerns: (1) "Creepy" factor of precise recommendations,
    (2) Unclear what data drives recommendations,
    (3) Want ability to reset/delete profile,
    (4) Concern about data sharing with advertisers
  - Response: Implemented "Why this recommendation" explainability,
    profile reset button, explicit no-third-party-sale commitment

------------------------------------------------------------
SECTION 4: NECESSITY AND PROPORTIONALITY
------------------------------------------------------------

4.1 Legal Basis: Legitimate interest (Art. 6(1)(f))
  - Interest: Improving user experience and business performance
  - Necessity: ML model requires behavioral data for accuracy
  - Balance: User benefit (better discovery) vs. profiling
    intrusiveness — mitigated by transparency and opt-out

4.3 Data Minimization Assessment
  | Data Element | Purpose | Necessary? | Justification |
  |-------------|---------|------------|---------------|
  | Purchase history | Core signal | Y | Primary recommendation input |
  | Browse behavior | Implicit signal | Y | Required for cold-start users |
  | Device info | Deduplication | Y | Prevent duplicate profiles |
  | IP address | Geolocation | Partial | Truncated to /24, city-level only |
  | Age range | Demographic feature | N | REMOVED — marginal model improvement (0.2% CTR) does not justify collection |
  | Gender | Demographic feature | N | REMOVED — same rationale |
  | Exact timestamps | Temporal patterns | Partial | Rounded to hour granularity |

4.6 Less Intrusive Alternatives
  | Alternative | Feasible? | Why Not Chosen |
  |------------|-----------|----------------|
  | Rule-based recommendations | Y | 34% lower relevance; already deployed, replacing |
  | Collaborative filtering only (no behavioral) | Y | 18% lower accuracy; considered acceptable fallback for opt-out users |
  | On-device recommendation | Partial | Latency/model size constraints; evaluated for future |
  | Federated learning | Partial | Infrastructure not ready; planned Phase 2 |

------------------------------------------------------------
SECTION 5: RISK IDENTIFICATION
------------------------------------------------------------

| ID | Risk | Harm | L | S | Score |
|----|------|------|---|---|-------|
| R1 | Behavioral profile breach exposing browsing/purchase patterns | Material + reputational harm, identity theft | 2 | 3 | 6 (M) |
| R2 | Inference of sensitive attributes (health, religion) from purchase patterns | Discrimination, distress | 3 | 3 | 9 (H) |
| R3 | Filter bubble effect limiting product discovery | Autonomy limitation | 3 | 2 | 6 (M) |
| R4 | Price discrimination via personalization | Financial harm, discrimination | 2 | 3 | 6 (M) |
| R5 | Re-identification of anonymized training data | Loss of control over personal data | 2 | 3 | 6 (M) |
| R6 | Third-party analytics processor breach (US transfer) | Material harm, regulatory penalty | 2 | 4 | 8 (M) |
| R7 | Model memorization of individual user patterns | Privacy violation, potential extraction | 2 | 3 | 6 (M) |
| R8 | Lack of transparency — users unaware of profiling depth | Loss of autonomy, trust erosion | 3 | 2 | 6 (M) |

------------------------------------------------------------
SECTION 6: RISK MITIGATION
------------------------------------------------------------

| Risk | Mitigation | Type | Owner | Status | Residual |
|------|-----------|------|-------|--------|----------|
| R1 | Application-layer encryption of feature store, field-level access controls, SOC monitoring | T | Security | Done | Low |
| R2 | Sensitive category classifier on inferred interests; auto-delete health/religion/political inferences; quarterly bias audit | T+O | Data Science + DPO | In Progress | Medium |
| R3 | Diversity injection in recommendation algorithm (explore/exploit ratio minimum 20%); "Discover New" section | T | Product | Done | Low |
| R4 | Policy: no personalized pricing; technical control blocking price variance by user profile | T+L | Legal + Eng | Done | Low |
| R5 | Differential privacy (epsilon=1.0) applied during model training; k-anonymity (k=50) on training datasets | T | Data Science | In Progress | Low |
| R6 | SCCs + supplementary measures (encryption in transit/rest, US access limited to aggregates, contractual audit rights) | L+T | Legal + Security | Done | Medium |
| R7 | DP-SGD training (epsilon=1.0, delta=1e-6); membership inference testing pre-deployment; no model serialization of raw user data | T | ML Eng | In Progress | Low |
| R8 | "Why this recommendation" feature; privacy dashboard; layered privacy notice; annual transparency report | T+O | Product + Legal | Done | Low |

------------------------------------------------------------
SECTION 7: SIGN-OFF
------------------------------------------------------------

7.1 Residual Risk: MEDIUM
  Acceptable: YES — with ongoing monitoring and completion
  of in-progress mitigations by Q2 2026

7.2 Approval
  | Role | Decision | Date |
  |------|----------|------|
  | DPO  | Conditional Approve — pending R2/R5/R7 completion | 2026-03-10 |
  | Controller | Approved | 2026-03-12 |
  | CISO | Approved | 2026-03-11 |

7.3 Review Schedule
  Next review: 2026-09-14 (6 months) or upon:
  - Model architecture change
  - New data source integration
  - Expansion to new jurisdiction
  - Security incident involving user data
  - Regulatory guidance update
```

---

## 2. Data Flow Mapping Methodology

### 2.1 Purpose

Data flow mapping is the foundation of privacy engineering. Without knowing where data goes, you cannot protect it, assess risk, or demonstrate compliance. A data flow map answers:

- What personal data do we collect?
- Where does it come from?
- Where does it go?
- Who can access it?
- How is it protected at each stage?
- When is it deleted?

### 2.2 Methodology: Six-Phase Approach

```
Phase 1: INVENTORY    — Enumerate all systems, services, and data stores
Phase 2: CLASSIFY     — Categorize data by type, sensitivity, and legal basis
Phase 3: MAP          — Trace data from collection to deletion
Phase 4: ANNOTATE     — Add controls, legal bases, and retention at each node
Phase 5: VALIDATE     — Verify with system owners and test with technical tools
Phase 6: MAINTAIN     — Integrate into change management and review cycles
```

### 2.3 Phase 1: Data Inventory

Enumerate every system that touches personal data:

```
DATA INVENTORY REGISTER

| System ID | System Name | Type | Owner | Data Categories | Subjects | Volume | Location |
|-----------|------------|------|-------|-----------------|----------|--------|----------|
| SYS-001   | [name]     | [app/db/service/file] | [team] | [list] | [who] | [N records] | [region] |

System Types:
  - Application (web, mobile, desktop)
  - Database (relational, document, graph, cache)
  - Service (API, microservice, message queue)
  - File Store (object storage, file share, backup)
  - Third-Party (SaaS, processor, sub-processor)
  - Endpoint (laptop, mobile device)
```

Discovery techniques:
- **Network scanning**: Map active services and data stores (nmap, asset inventory)
- **Code analysis**: Static analysis for data model definitions, API schemas, ORM models
- **Config review**: Infrastructure-as-code, Terraform, Kubernetes manifests
- **Procurement review**: Vendor contracts with DPA clauses indicate data processing
- **Interview**: System owners, developers, and data stewards
- **Automated tools**: Privado (static code scanning for data flows), OneTrust, BigID

### 2.4 Phase 2: Data Classification

```
CLASSIFICATION SCHEME

| Level | Category | Examples | Handling Requirements |
|-------|----------|---------|----------------------|
| P1 - Public | Non-personal | Product catalog, public pages | Standard controls |
| P2 - Internal | Pseudonymized / low sensitivity | Hashed user IDs, aggregated metrics | Access control, audit logging |
| P3 - Confidential | Directly identifying PII | Name, email, address, phone | Encryption, access control, retention limits |
| P4 - Restricted | Special category / high risk | Health data, biometrics, financial, children's data | Encryption + additional safeguards, DPIA required, strict access |
| P5 - Regulated | Sector-specific regulated | Payment card (PCI), health records (HIPAA) | Regulatory controls in addition to above |

GDPR Special Categories (Art. 9):
  - Racial or ethnic origin
  - Political opinions
  - Religious or philosophical beliefs
  - Trade union membership
  - Genetic data
  - Biometric data (for identification)
  - Health data
  - Sex life or sexual orientation
```

### 2.5 Phase 3: Data Flow Diagram Template

Use a layered approach — context level, then detailed per subsystem.

**Level 0: Context Diagram**
```
                    +-----------------+
   Data Subjects -->| YOUR SYSTEM     |--> Recipients
   (customers,      | (trust boundary) |    (processors,
    employees)      +-----------------+     authorities,
                           |                 partners)
                           v
                    [Data Stores]
```

**Level 1: System Decomposition**
```
NOTATION:
  [Entity]        = External entity (person, organization, system)
  (Process)       = Processing activity
  |Data Store|    = Persistent storage
  -->              = Data flow (label with data categories)
  ====             = Trust boundary
  {Control}       = Security/privacy control on the flow

TEMPLATE:

  [Data Subject]
       |
       | Name, Email, Behavior {TLS 1.3, Consent}
       v
  ==================== TRUST BOUNDARY: PERIMETER ====================
       |
       v
  (Collection Service)
       |
       | Validated PII {Input validation, purpose tagging}
       |
       +-----> |User Database| {AES-256, RBAC, 24mo retention}
       |
       | Pseudonymized ID + Events {HMAC-SHA256}
       v
  (Analytics Pipeline)
       |
       | Aggregated Metrics {k-anonymity k=100}
       v
  ==================== TRUST BOUNDARY: EXTERNAL ====================
       |
       v
  [Analytics Processor] {DPA, SCCs, encryption}
```

**Mermaid template for tooling**:
```mermaid
graph TD
    subgraph "Trust Boundary: Client"
        A[User Browser]
    end
    subgraph "Trust Boundary: Application"
        B(API Gateway)
        C(Auth Service)
        D(Business Logic)
        E[(User DB)]
        F[(Event Store)]
    end
    subgraph "Trust Boundary: External"
        G[Payment Processor]
        H[Email Service]
    end

    A -->|"PII: name, email [TLS 1.3, consent]"| B
    B -->|"Auth token"| C
    B -->|"Validated request"| D
    D -->|"PII [AES-256, RBAC]"| E
    D -->|"Pseudonymized events"| F
    D -->|"Payment token [PCI tokenized]"| G
    D -->|"Email address [TLS, DPA]"| H
```

### 2.6 Phase 4: Annotation Layer

For each data flow arrow, document:

```
FLOW ANNOTATION TEMPLATE

| Flow ID | Source | Destination | Data Categories | Legal Basis | Encryption | Access Control | Retention | Cross-Border? |
|---------|--------|-------------|-----------------|-------------|------------|----------------|-----------|---------------|
| F-001   | User   | API         | Name, Email     | Art.6(1)(b) | TLS 1.3    | Public endpoint | Session   | No            |
| F-002   | API    | User DB     | Full PII        | Art.6(1)(b) | AES-256    | RBAC, least privilege | 24 months | No          |
| F-003   | API    | Analytics   | Pseudonymized   | Art.6(1)(f) | TLS 1.3    | Service account | 12 months | Yes (US, SCCs)|
```

### 2.7 Phase 5: Validation

- **Technical validation**: Deploy data flow monitoring (Privado, network taps, API gateway logs) to verify declared flows match reality
- **Interview validation**: Walk through diagrams with engineering teams; ask "what happens when X?"
- **Penetration testing**: Test trust boundaries — can data cross them unexpectedly?
- **Shadow IT discovery**: Check for undeclared SaaS, personal device usage, ad-hoc exports

### 2.8 Phase 6: Maintenance

Integrate data flow maps into:
- **Change management**: Any new system, API, or vendor triggers flow map update
- **CI/CD pipeline**: Privado or similar static analysis scans code changes for new data flows
- **Quarterly review**: DPO reviews data flow maps against processing register (Art. 30)
- **Incident response**: After any data incident, validate and update flow maps

---

## 3. Privacy-Preserving Architecture Patterns Catalog

### 3.1 Pattern Overview

| Pattern | Privacy Goal | Data Utility | Implementation Complexity | Runtime Overhead |
|---------|-------------|-------------|--------------------------|-----------------|
| Data Minimization | Reduce attack surface | Unchanged for intended purpose | Low | None |
| Pseudonymization | Reduce re-identification risk | High (reversible) | Low-Medium | Low |
| Anonymization | Eliminate re-identification | Reduced (irreversible) | Medium-High | Low |
| Differential Privacy | Formal privacy guarantees | Reduced (noise added) | Medium | Low-Medium |
| Federated Learning | Keep data at source | Comparable to centralized | High | High |
| Secure Multi-Party Computation | Compute without revealing inputs | Exact results | Very High | Very High |
| Homomorphic Encryption | Compute on encrypted data | Exact/approximate results | Very High | Extreme |

### 3.2 Data Minimization

**Principle**: Collect only what is strictly necessary for the stated purpose (GDPR Art. 5(1)(c)).

**Technical Controls**:

```
COLLECTION MINIMIZATION
  - Schema enforcement: reject unexpected fields at API boundary
  - Purpose-tagged fields: each data element mapped to processing purpose
  - Graduated collection: collect minimum at signup, request more only when needed
  - Client-side processing: compute on-device where possible (e.g., age verification
    without transmitting date of birth — send boolean "over_18" instead)

STORAGE MINIMIZATION
  - Automated retention enforcement: TTL on records, cron-based purging
  - Aggregation pipelines: replace individual records with aggregates on schedule
  - Purpose-expiry: delete data when the purpose it was collected for is fulfilled
  - Selective persistence: ephemeral processing without writing to disk

ACCESS MINIMIZATION
  - Field-level access control: different roles see different columns
  - Query-level filtering: database views that exclude unnecessary fields
  - API response filtering: return only fields the consumer needs
  - Temporal access: time-limited access grants that auto-expire

IMPLEMENTATION EXAMPLE (Python):
```

```python
from dataclasses import dataclass, field
from enum import Enum
from datetime import datetime, timedelta
from typing import Optional

class Purpose(Enum):
    ACCOUNT = "account_management"
    BILLING = "billing"
    ANALYTICS = "analytics"
    MARKETING = "marketing"

@dataclass
class DataField:
    value: any
    purpose: Purpose
    collected_at: datetime
    retention_days: int
    legal_basis: str

    @property
    def expired(self) -> bool:
        return datetime.utcnow() > self.collected_at + timedelta(days=self.retention_days)

@dataclass
class MinimalUserProfile:
    """Only stores fields with explicit purpose and retention."""
    user_id: str  # pseudonymized
    email: DataField  # Purpose: ACCOUNT, 365 days, Art.6(1)(b)
    # No name, DOB, gender — not necessary for service delivery

    def fields_for_purpose(self, purpose: Purpose) -> dict:
        """Return only fields matching the requested purpose."""
        return {
            k: v for k, v in self.__dict__.items()
            if isinstance(v, DataField) and v.purpose == purpose and not v.expired
        }
```

### 3.3 Pseudonymization

**Principle**: Replace directly identifying attributes with tokens that can only be re-linked with separately held additional information (GDPR Art. 4(5), Recital 26).

**Techniques**:

| Technique | Reversibility | Collision Risk | Performance | Use Case |
|-----------|--------------|----------------|-------------|----------|
| HMAC-SHA256 with secret key | Yes (with key) | Negligible | Fast | Cross-system linking without exposing identifiers |
| AES-256 encryption of identifiers | Yes (with key) | None | Fast | Reversible pseudonymization for authorized use |
| Tokenization (vault-based) | Yes (via vault lookup) | None | Medium (network hop) | Payment data, regulated identifiers |
| Format-preserving encryption (FPE) | Yes (with key) | None | Fast | When format must be preserved (e.g., SSN format) |
| Sequential token mapping | Yes (via mapping table) | None | Fast | Simple internal pseudonymization |

**Architecture Pattern**:
```
                    +-------------------+
  Raw PII --------->| Pseudonymization  |-------> Pseudonymized Data
                    | Service           |         (used by applications)
                    +-------------------+
                           |
                           | Mapping stored separately
                           v
                    +-------------------+
                    | Key/Mapping Vault |  <-- Strict access control
                    | (HSM-backed)      |      Separate admin domain
                    +-------------------+

KEY SEPARATION REQUIREMENTS:
  - Mapping/key stored in different system than pseudonymized data
  - Different access controls and administrators
  - Audit logging on all re-identification requests
  - Key rotation schedule with re-pseudonymization pipeline
  - Breach of either system alone insufficient for re-identification
```

### 3.4 Anonymization

**Principle**: Process data such that re-identification is no longer reasonably possible, even with additional information. Anonymized data falls outside GDPR scope (Recital 26).

**WARNING**: True anonymization is extremely difficult. The "reasonable means" test considers all means reasonably likely to be used. Published anonymized datasets have been repeatedly re-identified (Netflix Prize, NYC taxi data, Australian Medicare).

**Techniques**:

```
K-ANONYMITY
  Definition : Every record is indistinguishable from at least k-1 other
               records on quasi-identifier attributes
  Strength   : Prevents singling out
  Weakness   : Vulnerable to homogeneity attack (all k records share
               sensitive value) and background knowledge attack
  Use when   : Publishing aggregate data with quasi-identifiers

L-DIVERSITY
  Definition : Each equivalence class has at least l distinct values
               for sensitive attributes
  Strength   : Addresses k-anonymity homogeneity weakness
  Weakness   : Vulnerable to skewness attack
  Use when   : Publishing data with sensitive attributes

T-CLOSENESS
  Definition : Distribution of sensitive attributes in each equivalence
               class is within threshold t of the overall distribution
  Strength   : Addresses l-diversity skewness weakness
  Weakness   : Can significantly reduce data utility
  Use when   : Highest anonymization requirements

GENERALIZATION AND SUPPRESSION
  - Generalize: Replace specific values with ranges (age 34 -> 30-39)
  - Suppress: Remove outlier records that cannot be generalized
  - Top/bottom coding: Cap extreme values

MICRO-AGGREGATION
  - Group similar records and replace values with group averages
  - Preserves statistical properties better than generalization

SYNTHETIC DATA GENERATION
  - Train generative model on real data, produce synthetic records
  - Preserves statistical distributions without real individuals
  - Tools: SDV (Synthetic Data Vault), Gretel.ai, MOSTLY AI
  - Risk: Model may memorize and reproduce real records
  - Mitigation: Apply differential privacy during generation
```

**Anonymization Assessment Criteria** (Article 29 WP Opinion 05/2014):

| Criterion | Test | Pass Condition |
|-----------|------|----------------|
| Singling out | Can an individual be isolated in the dataset? | No |
| Linkability | Can records be linked across datasets to the same individual? | No |
| Inference | Can personal data be inferred from the anonymized data? | No |

### 3.5 Differential Privacy

**Principle**: A mechanism M satisfies epsilon-differential privacy if for all datasets D1 and D2 differing in one individual's data, and for all outputs S:

```
Pr[M(D1) ∈ S] ≤ e^ε × Pr[M(D2) ∈ S]
```

Epsilon (ε) is the privacy budget — lower values provide stronger privacy guarantees at the cost of more noise.

**Key Properties**:
- **Composability**: Sequential queries consume privacy budget additively (basic) or sub-linearly (advanced composition)
- **Post-processing immunity**: Any computation on DP output remains DP
- **Group privacy**: Protects groups of k individuals with privacy parameter kε

**Practical Guidance**:

| Epsilon Range | Privacy Level | Typical Use |
|--------------|--------------|------------|
| 0.01 - 0.1 | Very strong | Sensitive medical/financial data |
| 0.1 - 1.0 | Strong | General personal data analytics |
| 1.0 - 5.0 | Moderate | Behavioral analytics, recommendations |
| 5.0 - 10.0 | Weak | Low-sensitivity aggregate statistics |
| > 10.0 | Minimal | Rarely justified for personal data |

**Noise Mechanisms**:

```
LAPLACE MECHANISM
  - Adds noise drawn from Laplace(0, Δf/ε) distribution
  - Δf = global sensitivity (max change from one individual)
  - Best for: counting queries, histograms, numeric aggregates
  - Satisfies: pure ε-differential privacy

GAUSSIAN MECHANISM
  - Adds noise drawn from N(0, σ²) where σ = Δf√(2ln(1.25/δ))/ε
  - Satisfies: (ε,δ)-differential privacy (relaxed)
  - Better utility for high-dimensional queries
  - Requires δ > 0 (small probability of privacy failure)

EXPONENTIAL MECHANISM
  - For non-numeric outputs (categorical selection)
  - Selects output with probability proportional to e^(εu(x)/2Δu)
  - u = utility function, Δu = sensitivity of utility function

RANDOMIZED RESPONSE
  - Local differential privacy — noise added before data leaves device
  - Each user flips a biased coin to decide whether to report true value
  - Used by: Apple (iOS analytics), Google (RAPPOR/Chrome)
  - Advantage: No trusted central party needed
  - Disadvantage: Much more noise required per-user
```

**Frameworks**:

| Framework | Language | Maintainer | Key Features |
|-----------|----------|-----------|--------------|
| OpenDP | Rust + Python + R | Harvard/OpenDP | Modular, composable, proof-oriented |
| Google DP | C++ + Go + Java + Python | Google | Production-grade, Beam integration |
| Opacus | Python (PyTorch) | Meta | DP-SGD for deep learning training |
| IBM diffprivlib | Python | IBM | Scikit-learn compatible DP algorithms |
| Tumult Analytics | Python (Spark) | Tumult Labs | SQL-like API for DP queries on large datasets |

**Implementation Pattern — DP-SGD for ML Training**:
```python
# Using Opacus for differentially private model training
import torch
from opacus import PrivacyEngine

model = YourModel()
optimizer = torch.optim.SGD(model.parameters(), lr=0.1)
data_loader = torch.utils.data.DataLoader(dataset, batch_size=64)

privacy_engine = PrivacyEngine()
model, optimizer, data_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=data_loader,
    epochs=10,
    target_epsilon=1.0,    # Privacy budget
    target_delta=1e-5,     # Probability of privacy failure
    max_grad_norm=1.0,     # Gradient clipping bound
)

# Training loop — Opacus automatically clips gradients and adds noise
for epoch in range(10):
    for batch in data_loader:
        optimizer.zero_grad()
        loss = criterion(model(batch), labels)
        loss.backward()
        optimizer.step()

# Check actual privacy spent
epsilon = privacy_engine.get_epsilon(delta=1e-5)
print(f"Achieved (ε={epsilon:.2f}, δ=1e-5)-differential privacy")
```

### 3.6 Federated Learning

**Principle**: Train ML models across decentralized data sources without centralizing raw data. Each participant trains locally and shares only model updates (gradients or parameters).

**Architecture**:
```
  +----------+    +----------+    +----------+
  | Client 1 |    | Client 2 |    | Client N |
  | (local   |    | (local   |    | (local   |
  |  data)   |    |  data)   |    |  data)   |
  +----+-----+    +----+-----+    +----+-----+
       |               |               |
       | Model updates | Model updates | Model updates
       | (gradients)   | (gradients)   | (gradients)
       v               v               v
  +----------------------------------------+
  |         Aggregation Server             |
  |  (FedAvg / Secure Aggregation)         |
  +----------------------------------------+
       |
       | Global model update
       v
  Distribute to clients for next round
```

**Federated Learning Variants**:

| Variant | Data Distribution | Communication | Example |
|---------|------------------|---------------|---------|
| Horizontal FL | Same features, different samples | Gradients to server | Mobile keyboard prediction |
| Vertical FL | Different features, same samples | Intermediate results | Bank + insurer collaboration |
| Federated Transfer | Different features and samples | Model parameters | Cross-domain adaptation |

**Privacy Risks in FL** (it is NOT inherently private):
- **Gradient inversion attacks**: Reconstruct training data from shared gradients (Zhu et al., 2019)
- **Membership inference**: Determine if a sample was in training data
- **Model poisoning**: Malicious participants corrupt the global model

**Mitigations**:
- **Secure aggregation**: Cryptographic protocol ensuring server sees only aggregate update
- **Differential privacy**: Add noise to gradients before sharing (DP-FedAvg)
- **Gradient compression**: Reduce information leakage by compressing updates
- **Participant validation**: Anomaly detection on submitted updates

**Frameworks**:
- **PySyft** (OpenMined): Python, supports FL + DP + secure computation, Datasite architecture
- **Flower** (Adap): Framework-agnostic FL, supports PyTorch/TensorFlow/JAX
- **FATE** (WeBank): Industrial-grade FL with horizontal/vertical/transfer support
- **TensorFlow Federated**: Google's FL framework integrated with TF ecosystem
- **APPFL**: Advanced Privacy-Preserving Federated Learning (Argonne National Lab)

### 3.7 Secure Multi-Party Computation (SMPC)

**Principle**: Multiple parties jointly compute a function over their inputs while keeping those inputs private. No party learns anything beyond their own input and the final output.

**Key Protocols**:

| Protocol | Security Model | Parties | Round Complexity | Use Case |
|----------|---------------|---------|-----------------|----------|
| Yao's Garbled Circuits | Semi-honest, 2-party | 2 | Constant | Boolean circuits |
| GMW Protocol | Semi-honest, n-party | N | O(depth) | Arithmetic/Boolean circuits |
| SPDZ | Malicious, n-party | N | O(depth) | General computation with strong security |
| Secret Sharing (Shamir) | Semi-honest, n-party | N | O(depth) | Threshold computation |
| Oblivious Transfer | Semi-honest/Malicious | 2 | O(1) per transfer | Building block for GC/GMW |

**Architecture Pattern — Privacy-Preserving Analytics**:
```
  Party A           Party B           Party C
  (Hospital 1)      (Hospital 2)      (Hospital 3)
       |                 |                 |
       | Secret share    | Secret share    | Secret share
       | of local data   | of local data   | of local data
       v                 v                 v
  +--------------------------------------------------+
  |            MPC Protocol Execution                 |
  |  (Computation performed on shares —               |
  |   no party sees any other party's data)           |
  +--------------------------------------------------+
       |
       v
  Aggregate Result (e.g., joint survival statistics)
  — revealed to authorized parties only
```

**Practical Considerations**:
- **Communication overhead**: MPC requires extensive inter-party communication; latency-sensitive
- **Computation overhead**: Orders of magnitude slower than plaintext computation
- **Honest majority assumption**: Many protocols require majority of parties to be honest
- **Best for**: High-value computations on small-to-medium datasets where privacy is paramount
- **Frameworks**: MP-SPDZ, ABY, CrypTen (Meta, PyTorch-based), SecretFlow (Ant Group)

### 3.8 Homomorphic Encryption (HE)

**Principle**: Perform computations directly on encrypted data. The result, when decrypted, matches the result of performing the same computation on plaintext.

**Scheme Comparison** (Microsoft SEAL):

| Scheme | Operations | Data Type | Result | Best For |
|--------|-----------|-----------|--------|----------|
| BFV | Add + Multiply (exact) | Integers | Exact | Voting, counting, exact arithmetic |
| BGV | Add + Multiply (exact) | Integers | Exact | Similar to BFV, different noise management |
| CKKS | Add + Multiply (approximate) | Real/Complex numbers | Approximate | ML inference, statistical computation |

**Capability Levels**:

| Level | Operations | Practical? | Examples |
|-------|-----------|-----------|---------|
| Partially HE (PHE) | Add OR Multiply (not both) | Yes | Paillier (add), RSA (multiply) |
| Somewhat HE (SHE) | Limited add + multiply | Yes | SEAL BFV with small depth |
| Leveled HE (LHE) | Add + multiply up to fixed depth | Yes | SEAL BFV/CKKS with pre-set parameters |
| Fully HE (FHE) | Arbitrary computation | Emerging | TFHE, bootstrapping-enabled schemes |

**Critical Limitations**:
- Ciphertext expansion: encrypted data is 10-1000x larger than plaintext
- Computation overhead: 1000-1,000,000x slower than plaintext
- No branching: cannot evaluate `if (encrypted_value > threshold)`
- Noise growth: each operation adds noise; eventually decryption fails without bootstrapping
- Not a silver bullet: suitable only for specific computation patterns

**Architecture Pattern — Private ML Inference**:
```
  Client                           Server
  (data owner)                     (model owner)
       |                                |
  1. Encrypt input                      |
       |--- Encrypted input ----------->|
       |                           2. Run inference on
       |                              encrypted input
       |                              (HE-compatible model)
       |<-- Encrypted result -----------|
  3. Decrypt result                     |
       |                                |
  (Server never sees plaintext input or result)
```

**Frameworks**:

| Framework | Schemes | Languages | Maintainer |
|-----------|---------|-----------|-----------|
| Microsoft SEAL | BFV, BGV, CKKS | C++, C#, Python (wrapper) | Microsoft |
| TFHE | TFHE (Boolean FHE) | C++, Rust | Zama |
| OpenFHE | BFV, BGV, CKKS, TFHE, FHEW | C++ | DARPA-funded consortium |
| Lattigo | BFV, BGV, CKKS | Go | EPFL |
| Concrete | TFHE | Rust, Python | Zama |
| HElib | BGV, CKKS | C++ | IBM |

### 3.9 Pattern Selection Guide

```
DECISION TREE: Choosing a Privacy-Preserving Pattern

Q1: Do you need to publish/share the data itself?
  YES → Q2
  NO  → Q4

Q2: Can the data be aggregated without individual records?
  YES → Differential Privacy (aggregate statistics with formal guarantees)
  NO  → Q3

Q3: Is re-identification an acceptable residual risk?
  YES → Pseudonymization + k-anonymity
  NO  → Synthetic data generation with DP guarantees, or do not publish

Q4: Do you need to train an ML model?
  YES → Q5
  NO  → Q7

Q5: Can data be centralized under one trusted party?
  YES → DP-SGD training (Opacus) — add noise during training
  NO  → Q6

Q6: How many data holders?
  2-5 parties, structured data → Vertical/Horizontal Federated Learning
  Many parties, edge devices   → Cross-device Federated Learning + Secure Aggregation
  Need formal guarantees       → FL + DP + Secure Aggregation combined

Q7: Do you need to compute on data held by multiple parties?
  YES → Q8
  NO  → Data minimization + pseudonymization + access control

Q8: How complex is the computation?
  Simple aggregates (sum, count, mean)     → Secure Aggregation or PHE (Paillier)
  Moderate (statistics, simple ML)         → SMPC (SPDZ, CrypTen)
  Complex (deep learning inference)        → HE (CKKS) if low depth, else hybrid HE+MPC
  Arbitrary computation                    → FHE (TFHE) — expect extreme overhead
```

---

## 4. Privacy by Design Implementation Guide

### 4.1 Foundational Principles (Cavoukian + EDPB Guidelines 4/2019)

| # | Principle | GDPR Article | Technical Implementation |
|---|-----------|-------------|------------------------|
| 1 | Proactive not Reactive | Art. 25(1) "at the time of determination of means" | Threat modeling during design phase; DPIA before build |
| 2 | Privacy as Default | Art. 25(2) | Strictest privacy settings out-of-box; opt-in not opt-out |
| 3 | Privacy Embedded in Design | Art. 25(1) "implement appropriate technical and organisational measures" | Privacy controls in architecture, not bolted on |
| 4 | Full Functionality (Positive-Sum) | Recital 78 | Privacy AND functionality, not privacy OR functionality |
| 5 | End-to-End Security | Art. 5(1)(f), Art. 32 | Encryption lifecycle, secure deletion, key management |
| 6 | Visibility and Transparency | Art. 5(1)(a), Art. 12-14 | Auditable systems, privacy dashboards, clear notices |
| 7 | Respect for User Privacy | Art. 5(1)(a), Art. 12 | User-centric design, granular controls, easy exercise of rights |

### 4.2 GDPR Article-by-Article Technical Controls

```
ART. 5 — PRINCIPLES
──────────────────────────────────────────────────────────

Art. 5(1)(a) — Lawfulness, Fairness, Transparency
  CONTROLS:
  - Consent management platform with granular purpose selection
  - Layered privacy notices (short + full)
  - Processing activity register (Art. 30) as structured data
  - Algorithmic transparency: explainability layer for automated decisions
  - Privacy dashboard showing users what data is held and how it is used
  VERIFY: User can discover all processing purposes within 2 clicks

Art. 5(1)(b) — Purpose Limitation
  CONTROLS:
  - Purpose tags on every data field in schema
  - Technical enforcement: query engine filters data by requester's
    authorized purpose
  - Automated compatibility assessment for new purposes
  - Purpose-based access control (PBAC) — extends RBAC with purpose dimension
  VERIFY: Attempt to access data for unauthorized purpose → blocked and logged

Art. 5(1)(c) — Data Minimization
  CONTROLS:
  - API schema validation rejecting unexpected fields
  - Collection-time purpose justification (each field → purpose mapping)
  - Automated detection of unused collected fields (data hygiene audits)
  - Client-side computation where possible (age check, eligibility)
  VERIFY: Each data element has documented necessity justification

Art. 5(1)(d) — Accuracy
  CONTROLS:
  - Self-service data correction portal
  - Data quality monitoring (null rates, format validation, freshness)
  - Propagation of corrections across all systems (event-driven sync)
  - Staleness alerts: flag data not refreshed beyond threshold
  VERIFY: User correction propagates to all systems within 24 hours

Art. 5(1)(e) — Storage Limitation
  CONTROLS:
  - Automated retention enforcement (TTL, cron purge, lifecycle policies)
  - Purpose-expiry triggers: delete when purpose fulfilled
  - Anonymization pipeline: convert to aggregates at retention boundary
  - Backup retention alignment: backups purged on same schedule
  VERIFY: Query for records past retention → zero results, including backups

Art. 5(1)(f) — Integrity and Confidentiality
  CONTROLS:
  - Encryption: TLS 1.3 in transit, AES-256-GCM at rest
  - Field-level encryption for high-sensitivity data
  - Key management via HSM (FIPS 140-2 Level 3)
  - Integrity: HMAC on records, immutable audit logs
  - Access: RBAC + ABAC, MFA for admin access, just-in-time access
  VERIFY: Pen test confirms no plaintext PII in transit or at rest

ART. 6 — LAWFULNESS OF PROCESSING
──────────────────────────────────────────────────────────

  CONTROLS:
  - Consent service: granular, specific, informed, unambiguous
  - Consent receipt generation (Kantara specification)
  - Legitimate interest assessment (LIA) template and workflow
  - Legal basis tagging per processing activity in Art. 30 register
  - Withdrawal mechanism: as easy as giving consent
  VERIFY: Each processing activity has documented, valid legal basis

ART. 12-14 — TRANSPARENCY AND INFORMATION
──────────────────────────────────────────────────────────

  CONTROLS:
  - Machine-readable privacy policy (JSON-LD, P3P successor)
  - Layered notice: icon → short → full
  - Just-in-time notices at point of collection
  - Multi-language support matching user locale
  - Accessibility: WCAG 2.1 AA compliance for privacy notices
  VERIFY: Usability test — 80% of users understand what data is collected and why

ART. 15-20 — DATA SUBJECT RIGHTS
──────────────────────────────────────────────────────────

Art. 15 — Right of Access
  - Self-service data export (structured, machine-readable)
  - Identity verification before disclosure (prevent social engineering)
  - Automated response within 30 days (alert system for deadlines)

Art. 16 — Right to Rectification
  - Self-service edit for user-provided data
  - Propagation to all downstream systems
  - Audit trail of corrections

Art. 17 — Right to Erasure
  - Cascading delete across all systems, including backups within cycle
  - Erasure verification: automated check that data is removed
  - Exceptions engine: legal hold, regulatory retention override
  - Third-party notification of erasure requests (Art. 19)

Art. 18 — Right to Restriction
  - Processing restriction flag on records
  - Storage-only mode: data retained but not processed
  - Automated enforcement in processing pipelines

Art. 20 — Right to Portability
  - Export in structured, machine-readable format (JSON, CSV)
  - Direct transfer API to receiving controller
  - Scope: data provided by subject, processed by consent or contract

  IMPLEMENTATION PATTERN:
  ```python
  class DataSubjectRightsService:
      """Centralized DSR handler with deadline tracking."""

      def handle_request(self, request: DSRRequest) -> DSRResponse:
          self.verify_identity(request.subject_id, request.verification)
          self.log_request(request)  # Audit trail

          match request.right:
              case Right.ACCESS:
                  data = self.collect_all_data(request.subject_id)
                  return self.format_export(data, request.format)
              case Right.ERASURE:
                  self.check_exceptions(request.subject_id)
                  self.cascade_delete(request.subject_id)
                  self.notify_processors(request.subject_id)
                  self.verify_deletion(request.subject_id)
              case Right.PORTABILITY:
                  data = self.collect_provided_data(request.subject_id)
                  return self.structured_export(data)

          self.set_deadline_alert(request, days=30)
  ```

ART. 22 — AUTOMATED DECISION-MAKING
──────────────────────────────────────────────────────────

  CONTROLS:
  - Human-in-the-loop for decisions with legal/significant effects
  - Explainability layer: SHAP/LIME explanations for model decisions
  - Right to contest: escalation path to human reviewer
  - Bias monitoring: demographic parity, equalized odds metrics
  - Model cards documenting training data, performance, limitations
  VERIFY: User can request and receive human review of any automated decision

ART. 25 — DATA PROTECTION BY DESIGN AND DEFAULT
──────────────────────────────────────────────────────────

  CONTROLS:
  - Privacy requirements in user stories / acceptance criteria
  - Privacy-focused code review checklist
  - Automated PII detection in code (Privado, Nightfall)
  - Default settings: most privacy-protective option selected
  - Privacy unit tests: verify minimization, retention, access controls
  VERIFY: New features cannot ship without privacy review sign-off

ART. 28 — PROCESSOR OBLIGATIONS
──────────────────────────────────────────────────────────

  CONTROLS:
  - Vendor privacy assessment questionnaire (pre-contract)
  - DPA (Data Processing Agreement) template with Art. 28(3) clauses
  - Sub-processor approval workflow with notification mechanism
  - Contractual audit rights with annual exercise schedule
  - Processor security assessment (SOC 2 Type II, ISO 27001)
  VERIFY: No processor handles data without signed DPA and security assessment

ART. 32 — SECURITY OF PROCESSING
──────────────────────────────────────────────────────────

  CONTROLS:
  - Pseudonymization and encryption (as specified in Art. 32(1)(a))
  - Confidentiality, integrity, availability, resilience of systems
  - Ability to restore availability and access in timely manner
  - Regular testing (pen testing, red teaming, tabletop exercises)
  - Risk-appropriate security measures based on processing nature
  VERIFY: Annual pen test, quarterly vulnerability scan, incident response drill

ART. 33-34 — BREACH NOTIFICATION
──────────────────────────────────────────────────────────

  CONTROLS:
  - Automated breach detection (SIEM, anomaly detection, DLP)
  - Breach assessment workflow: risk to rights and freedoms
  - 72-hour notification pipeline to supervisory authority
  - Data subject notification templates (when high risk)
  - Breach register with all incidents (including non-notifiable)
  VERIFY: Tabletop exercise completes notification within 72 hours

ART. 35 — DPIA
──────────────────────────────────────────────────────────

  CONTROLS:
  - DPIA screening integrated into project intake process
  - DPIA template (see Section 1 of this document)
  - DPIA review triggers in change management
  - Published list of processing requiring DPIA
  VERIFY: No high-risk processing launched without completed DPIA

ART. 44-49 — INTERNATIONAL TRANSFERS
──────────────────────────────────────────────────────────

  See Section 5 (Cross-Border Data Transfer Assessment)
```

### 4.3 Privacy Engineering in the SDLC

```
PHASE          PRIVACY ACTIVITIES
─────────────  ────────────────────────────────────────────────
Requirements   - Privacy requirements elicitation
               - Data categories identification
               - Legal basis determination
               - DPIA screening

Design         - Data flow mapping (Section 2)
               - Threat modeling (STRIDE + LINDDUN)
               - Privacy pattern selection (Section 3)
               - DPIA (if triggered)
               - Privacy architecture review

Implementation - PII detection in code (static analysis)
               - Privacy unit tests
               - Consent flow implementation
               - Encryption implementation
               - Access control implementation

Testing        - Privacy-focused test cases
               - Data minimization verification
               - Retention enforcement testing
               - Rights exercise testing (access, erasure, portability)
               - Pen testing of privacy controls

Deployment     - Privacy configuration review
               - Default settings verification
               - Monitoring setup (DLP, access anomalies)
               - Privacy notice update

Operations     - DSR handling and SLA monitoring
               - Retention enforcement monitoring
               - Breach detection and response
               - Processor compliance monitoring
               - Periodic DPIA review
```

**LINDDUN Threat Model** (privacy-specific complement to STRIDE):

| Category | Threat | Example |
|----------|--------|---------|
| **L**inkability | Link actions/data to same individual | Cross-session tracking via fingerprinting |
| **I**dentifiability | Identify individual from data | Unique behavioral patterns in anonymized data |
| **N**on-repudiation | Subject cannot deny actions | Immutable logs linking user to sensitive actions |
| **D**etectability | Detect existence of data/actions | Side-channel revealing someone is in a database |
| **D**isclosure | Unauthorized access to personal data | SQL injection exposing user table |
| **U**nawareness | Subject unaware of data processing | Hidden tracking pixels, third-party analytics |
| **N**on-compliance | Failure to meet regulatory obligations | Missing consent records, ignored erasure requests |

---

## 5. Cross-Border Data Transfer Assessment Template

### 5.1 Legal Framework

Post-Schrems II (Case C-311/18), cross-border transfers from the EU/EEA require:

1. **Adequacy decision** (Art. 45) — European Commission deems country's protection adequate
2. **Appropriate safeguards** (Art. 46) — Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), codes of conduct, certifications
3. **Derogations** (Art. 49) — Narrow exceptions (explicit consent, contractual necessity, public interest)

For each transfer mechanism, a **Transfer Impact Assessment (TIA)** is required to evaluate whether the destination country's laws undermine the safeguards.

### 5.2 Transfer Assessment Template

```
============================================================
CROSS-BORDER DATA TRANSFER ASSESSMENT
============================================================

DOCUMENT CONTROL
  Version  : [X.Y]
  Date     : [YYYY-MM-DD]
  Assessor : [Name, Role]
  DPO Review: [Name, Date]

------------------------------------------------------------
SECTION 1: TRANSFER IDENTIFICATION
------------------------------------------------------------

1.1 Transfer Details
  - Exporter             : [Entity name, EU/EEA country]
  - Importer             : [Entity name, destination country]
  - Importer role        : Controller / Processor / Sub-processor
  - Data categories      : [List personal data transferred]
  - Special categories   : [Any Art. 9 data? YES/NO — if YES, list]
  - Data subjects        : [Who: employees, customers, etc.]
  - Volume               : [Records/subjects affected]
  - Frequency            : [One-time / continuous / periodic]
  - Transfer method      : [API, file transfer, database replication, SaaS access]
  - Purpose              : [Why data is transferred]

1.2 Transfer Mechanism
  [ ] Adequacy Decision (Art. 45) — specify decision:
  [ ] Standard Contractual Clauses (Art. 46(2)(c)) — specify module:
      [ ] Module 1: Controller to Controller
      [ ] Module 2: Controller to Processor
      [ ] Module 3: Processor to Processor
      [ ] Module 4: Processor to Controller
  [ ] Binding Corporate Rules (Art. 47)
  [ ] Code of Conduct (Art. 46(2)(e))
  [ ] Certification (Art. 46(2)(f))
  [ ] Derogation (Art. 49) — specify:
      [ ] Explicit consent (Art. 49(1)(a))
      [ ] Contractual necessity (Art. 49(1)(b))
      [ ] Public interest (Art. 49(1)(d))

------------------------------------------------------------
SECTION 2: TRANSFER IMPACT ASSESSMENT (TIA)
------------------------------------------------------------

2.1 Destination Country Legal Assessment

  Country: [Name]

  | Factor | Assessment | Evidence |
  |--------|-----------|----------|
  | Rule of law / independent judiciary | [Strong/Moderate/Weak] | [cite] |
  | Data protection legislation | [Exists/Partial/None] | [cite law] |
  | Government surveillance laws | [Targeted/Bulk/Indiscriminate] | [cite law] |
  | Law enforcement data access | [Judicial authorization required? Y/N] | [cite] |
  | Intelligence agency access | [Scope and oversight mechanisms] | [cite] |
  | Effective legal remedies for EU data subjects | [Available/Limited/None] | [cite] |
  | Independent supervisory authority | [Exists/Partial/None] | [cite] |
  | International commitments | [Relevant treaties/agreements] | [cite] |

2.2 Problematic Legislation Analysis

  | Law | Scope | Impact on Transfer | Likelihood of Access |
  |-----|-------|-------------------|---------------------|
  | [e.g., FISA 702] | [description] | [how it affects safeguards] | [assessment] |

2.3 Practical Assessment

  | Factor | Assessment |
  |--------|-----------|
  | Has importer received government access requests? | [Y/N, how many] |
  | Importer's ability to resist/challenge requests | [Strong/Moderate/Weak] |
  | Industry-specific access obligations | [Describe] |
  | Volume/nature of data making access likely | [Assessment] |
  | Importer's track record on data protection | [Assessment] |

------------------------------------------------------------
SECTION 3: SUPPLEMENTARY MEASURES
------------------------------------------------------------

3.1 Technical Measures

  [ ] End-to-end encryption (importer cannot access plaintext)
  [ ] Pseudonymization (importer receives only pseudonymized data;
      re-identification key held exclusively in EU)
  [ ] Split processing (sensitive attributes processed only in EU)
  [ ] Transport encryption (TLS 1.3)
  [ ] Encryption at rest (AES-256, keys held by exporter)
  [ ] Multi-party processing (no single party has full data)
  [ ] Anonymization before transfer

  Effectiveness assessment:
  [Do technical measures effectively prevent government access
  to personal data in intelligible form? YES/NO]

3.2 Contractual Measures

  [ ] Transparency obligations (notify exporter of access requests)
  [ ] Challenge obligations (challenge access requests legally)
  [ ] Warrant canary mechanism
  [ ] Data localization commitments
  [ ] Audit rights
  [ ] Enhanced data subject rights
  [ ] Prompt notification of inability to comply

3.3 Organizational Measures

  [ ] Data minimization (transfer only necessary data)
  [ ] Access control (limit personnel with access)
  [ ] Staff vetting and training
  [ ] Internal policies on government access
  [ ] Regular compliance monitoring
  [ ] Incident response procedures for unlawful access

------------------------------------------------------------
SECTION 4: OVERALL ASSESSMENT
------------------------------------------------------------

4.1 Can the transfer proceed?

  [ ] YES — Adequate protection ensured through:
      Transfer mechanism: [specify]
      Supplementary measures: [specify]
      Residual risk: [LOW/MEDIUM]

  [ ] YES WITH CONDITIONS — Transfer permitted subject to:
      [List conditions and monitoring requirements]

  [ ] NO — Supplementary measures cannot compensate for
      deficiencies in destination country legal framework.
      Alternative: [describe — e.g., process in EU, use
      different provider, anonymize before transfer]

4.2 Review Schedule
  Next review: [Date — maximum 12 months]
  Review triggers: [Legal changes, new surveillance law,
  adequacy decision change, Schrems III]

------------------------------------------------------------
SECTION 5: APPROVAL
------------------------------------------------------------

  | Role | Decision | Date |
  |------|----------|------|
  | DPO  | [Approve/Reject/Conditional] | [Date] |
  | Legal| [Approve/Reject] | [Date] |
  | CISO | [Approve/Reject] | [Date] |
```

### 5.3 Key Adequacy Decisions (as of 2026-03-14)

| Country/Framework | Status | Notes |
|------------------|--------|-------|
| EU-US Data Privacy Framework | Adequate (2023) | Self-certification required; monitor for challenges |
| UK | Adequate (2021, extended) | Sunset clause — monitor renewal |
| Japan | Adequate (2019) | Supplementary rules apply |
| South Korea | Adequate (2022) | |
| Canada (PIPEDA) | Adequate (partial, 2001) | Commercial sector only |
| Switzerland | Adequate (2000) | |
| Israel | Adequate (2011) | |
| New Zealand | Adequate (2012) | |
| Argentina | Adequate (2003) | |
| Uruguay | Adequate (2012) | |

---

## 6. Cookie Consent and Tracking Compliance Guide

### 6.1 Legal Framework

**ePrivacy Directive (2002/58/EC, Art. 5(3))**: Storing or accessing information on a user's terminal equipment requires:
- The user has been provided with **clear and comprehensive information** (in line with GDPR)
- The user has given **consent** (as defined by GDPR — freely given, specific, informed, unambiguous)

**Exception**: Cookies **strictly necessary** for the service explicitly requested by the user are exempt from consent requirements.

**GDPR overlay**: Consent for cookies must meet GDPR Art. 7 standards. Where cookies process personal data, GDPR applies in full.

### 6.2 Cookie Classification

| Category | Consent Required? | Examples | Retention Guidance |
|----------|------------------|---------|-------------------|
| **Strictly Necessary** | No | Session cookies, authentication, load balancing, CSRF tokens, user cookie preferences | Session or minimum necessary |
| **Functional/Preferences** | Yes | Language preference, UI customization, font size | Maximum 12 months |
| **Analytics/Performance** | Yes (or legitimate interest with opt-out in some jurisdictions) | Google Analytics, Matomo, A/B testing | Maximum 13 months (CNIL guidance) |
| **Marketing/Advertising** | Yes (explicit consent) | Ad targeting, retargeting, cross-site tracking, social media pixels | Maximum 13 months |

### 6.3 Valid Consent Requirements

```
VALID CONSENT CHECKLIST (GDPR Art. 4(11) + Art. 7 + EDPB Guidelines 05/2020)

[X] FREELY GIVEN
    - No pre-ticked boxes
    - No bundled consent (cookie wall = generally invalid)
    - Service access not conditional on non-essential cookie consent
    - Granular: separate consent per purpose
    - Refusing consent must be as easy as giving it

[X] SPECIFIC
    - Consent per purpose (analytics ≠ marketing)
    - Each third-party recipient identified
    - Clear description of each cookie's function

[X] INFORMED
    - Identity of controller
    - Purpose of each cookie category
    - Duration / retention period
    - Third parties receiving data
    - How to withdraw consent
    - Consequences of consent/refusal

[X] UNAMBIGUOUS
    - Affirmative action required (click, toggle, swipe)
    - Scrolling / continued browsing ≠ consent
    - Silence or inactivity ≠ consent

[X] DEMONSTRABLE
    - Record of: who consented, when, what was presented, what was chosen
    - Consent receipt stored with timestamp
    - Consent version tracking (re-consent on material changes)
```

### 6.4 Consent Banner Implementation

**Compliant Banner Architecture**:
```
LAYER 1 — INITIAL BANNER (no cookies set yet except strictly necessary)
┌─────────────────────────────────────────────────────────────────┐
│ We use cookies to improve your experience.                      │
│                                                                 │
│ [Accept All]  [Reject All]  [Customize]                        │
│                                                                 │
│ "Reject All" and "Accept All" must be equally prominent.        │
│ No dark patterns (color, size, position manipulation).          │
└─────────────────────────────────────────────────────────────────┘

LAYER 2 — CUSTOMIZATION PANEL (if user clicks "Customize")
┌─────────────────────────────────────────────────────────────────┐
│ Cookie Preferences                                              │
│                                                                 │
│ ☑ Strictly Necessary (always on, cannot be disabled)           │
│ ☐ Analytics & Performance                                       │
│     Used by: [list providers]                                   │
│     Purpose: [description]                                      │
│     Duration: [e.g., 13 months]                                 │
│ ☐ Functional                                                    │
│     Used by: [list providers]                                   │
│     Purpose: [description]                                      │
│ ☐ Marketing & Advertising                                       │
│     Used by: [list providers]                                   │
│     Purpose: [description]                                      │
│     Duration: [e.g., 13 months]                                 │
│                                                                 │
│ [Save Preferences]  [Reject All Non-Essential]                  │
│                                                                 │
│ Read our Cookie Policy | Privacy Policy                         │
└─────────────────────────────────────────────────────────────────┘

All non-essential toggles default to OFF.
```

**Technical Implementation Requirements**:

```python
class ConsentManager:
    """GDPR/ePrivacy-compliant consent management."""

    CATEGORIES = {
        "strictly_necessary": {"requires_consent": False, "default": True},
        "functional":         {"requires_consent": True,  "default": False},
        "analytics":          {"requires_consent": True,  "default": False},
        "marketing":          {"requires_consent": True,  "default": False},
    }

    def on_page_load(self, request):
        """Before ANY non-essential cookies are set."""
        consent = self.get_stored_consent(request)
        if consent is None:
            # No consent recorded — block all non-essential cookies/scripts
            self.block_non_essential()
            self.show_banner()
            return

        if consent.version < self.current_policy_version:
            # Policy changed — re-consent required
            self.block_non_essential()
            self.show_banner(reason="policy_update")
            return

        # Apply stored preferences
        for category, granted in consent.preferences.items():
            if granted:
                self.enable_category(category)
            else:
                self.block_category(category)

    def record_consent(self, user_id: str, preferences: dict):
        """Store consent with full audit trail."""
        consent_record = {
            "user_id": user_id,
            "timestamp": datetime.utcnow().isoformat(),
            "preferences": preferences,
            "policy_version": self.current_policy_version,
            "banner_text_hash": self.hash_banner_content(),
            "ip_country": self.get_country(request),  # Jurisdiction
            "user_agent": request.headers.get("User-Agent"),
        }
        self.consent_store.save(consent_record)

    def withdraw_consent(self, user_id: str, category: str):
        """Withdrawal must be as easy as granting consent."""
        self.block_category(category)
        self.delete_category_cookies(category)
        self.record_consent_change(user_id, category, granted=False)
        # Notify third parties to stop processing
        self.notify_processors(user_id, category, action="cease")
```

### 6.5 Tracking Technology Compliance Matrix

| Technology | ePrivacy Scope? | GDPR Scope? | Consent Required? | Notes |
|-----------|----------------|-------------|-------------------|-------|
| First-party cookies | Yes (Art. 5(3)) | If personal data | Yes, unless strictly necessary | |
| Third-party cookies | Yes | Yes (almost always personal data) | Yes | Being phased out by browsers |
| Local Storage / IndexedDB | Yes (Art. 5(3) — "information stored") | If personal data | Yes, unless strictly necessary | |
| Browser fingerprinting | Yes (EDPB: accessing device info) | Yes (pseudonymous identifier) | Yes | No "strictly necessary" exemption in practice |
| Server-side tracking | No (no device access) | Yes (if personal data processed) | Depends on legal basis | GDPR still applies |
| Pixel tags / web beacons | Yes (trigger cookie read/write) | Yes | Yes | Often set third-party cookies |
| ETags / cache-based tracking | Yes (information stored on device) | Yes | Yes | Persistent even after cookie clearing |
| CNAME cloaking | Yes | Yes | Yes | First-party DNS mask for third-party tracking; regulators increasingly hostile |
| Topics API (Privacy Sandbox) | Potentially (accessing interest data) | Yes | Under regulatory review | Google's third-party cookie replacement |
| Server-to-server data sharing | No device access | Yes | Depends on legal basis | Common in server-side tagging |

### 6.6 Jurisdiction-Specific Requirements

```
EUROPEAN UNION (GDPR + ePrivacy Directive)
  - Consent required for non-essential cookies
  - Consent must meet GDPR standard (Art. 4(11), Art. 7)
  - Cookie walls generally prohibited (EDPB Guidelines 05/2020)
  - Maximum cookie lifetime: no hard rule, but CNIL recommends 13 months
  - Re-consent: at least every 13 months (CNIL) or on policy change

FRANCE (CNIL)
  - Strictest EU interpretation
  - "Continue browsing" ≠ consent (2020 ruling)
  - "Reject All" must be on first layer, same prominence as "Accept All"
  - Maximum 25 months for consent cookie itself
  - €150M fine against Google (2022), €60M against Meta for violations

GERMANY (Bundesbeauftragte / State DPAs)
  - TTDSG (Telekommunikation-Telemedien-Datenschutz-Gesetz) since Dec 2021
  - Strict consent requirement aligns with ePrivacy Directive
  - Recognized PIMS (Personal Information Management Services) concept

UK (ICO)
  - UK GDPR + PECR (Privacy and Electronic Communications Regulations)
  - Similar to EU requirements post-Brexit
  - ICO guidance: analytics cookies require consent
  - Data (Use and Access) Act 2025 may adjust requirements — monitor

CALIFORNIA (CCPA/CPRA)
  - No cookie consent requirement per se
  - "Do Not Sell or Share My Personal Information" link required
  - Opt-out model (not opt-in) for sale/sharing
  - Global Privacy Control (GPC) signal must be honored
  - No dark patterns in opt-out process

BRAZIL (LGPD)
  - Consent is one of ten legal bases (not always required for cookies)
  - Legitimate interest available for analytics (with LIA)
  - Consent must be free, informed, unambiguous, for specific purpose

CANADA (PIPEDA / forthcoming CPPA)
  - "Meaningful consent" required
  - Implied consent may suffice for non-sensitive analytics
  - Express consent for marketing/advertising tracking
```

### 6.7 Common Violations and Enforcement Actions

| Violation | Regulatory Response | Fine Examples |
|-----------|-------------------|---------------|
| Pre-ticked consent boxes | Invalid consent, all processing unlawful | Planet49 (CJEU C-673/17) |
| Cookie wall (no access without consent) | Generally invalid, disproportionate | EDPB Guidelines 05/2020 |
| No "Reject All" on first layer | Dark pattern, consent not freely given | CNIL: Google €150M, Meta €60M (2022) |
| Cookies set before consent | Processing without legal basis | Multiple CNIL, Belgian DPA decisions |
| No way to withdraw consent | Art. 7(3) violation | Numerous enforcement actions |
| Vague purposes ("improve experience") | Consent not specific or informed | Various DPA guidance |
| Consent shared across unrelated services | Consent not specific | Google Spain (AEPD) |
| GPC signal ignored (California) | CCPA violation | Sephora $1.2M (2022, CA AG) |

### 6.8 Privacy-Respecting Analytics Alternatives

| Tool | Model | Cookie-Free Option | Self-Hosted? | GDPR Without Consent? |
|------|-------|-------------------|-------------|----------------------|
| Matomo | Open source | Yes (cookieless mode) | Yes | Possible with cookieless + anonymization |
| Plausible | Open source | Yes (no cookies by default) | Yes | Yes (no personal data processed) |
| Fathom | Commercial | Yes | No (but EU hosting) | Yes (no personal data processed) |
| Umami | Open source | Yes (no cookies) | Yes | Yes |
| PostHog | Open source | Configurable | Yes | Depends on config |
| Simple Analytics | Commercial | Yes | No (EU hosted) | Yes |

---

## Appendix A: Privacy Engineering Tool Reference

### A.1 Data Discovery and Classification

| Tool | Type | Capabilities |
|------|------|-------------|
| Privado | Open source | Static code analysis for data flow detection |
| DataFog | Open source | PII detection and redaction (text + images) |
| BigID | Commercial | Data discovery, classification, cataloging at scale |
| OneTrust | Commercial | Privacy management platform, DPIA, cookie consent |
| Nightfall | Commercial | Cloud DLP, PII detection in SaaS apps |
| Presidio | Open source (Microsoft) | PII detection and anonymization SDK |

### A.2 Anonymization and Pseudonymization

| Tool | Type | Techniques |
|------|------|-----------|
| ARX | Open source | k-anonymity, l-diversity, t-closeness, differential privacy |
| Amnesia | Open source | k-anonymity, km-anonymity |
| sdcMicro | Open source (R) | Statistical disclosure control |
| Kodex | Open source | Pseudonymization, anonymization, encryption pipelines |
| SDV (Synthetic Data Vault) | Open source | Synthetic data generation preserving statistical properties |
| Gretel.ai | Commercial | Synthetic data, transformation, classification |

### A.3 Differential Privacy

| Tool | Language | Maintainer | Focus |
|------|----------|-----------|-------|
| OpenDP | Rust/Python/R | Harvard | Modular DP framework, proof-oriented |
| Google DP | C++/Go/Java/Python | Google | Production aggregations, Beam integration |
| Opacus | Python (PyTorch) | Meta | DP-SGD for deep learning |
| diffprivlib | Python | IBM | Scikit-learn compatible DP |
| Tumult Analytics | Python (Spark) | Tumult Labs | Enterprise DP analytics |
| PipelineDP | Python | OpenMined/Google | DP on Apache Beam/Spark |

### A.4 Federated Learning

| Tool | Language | Focus |
|------|----------|-------|
| PySyft | Python | Remote data science, Datasite architecture |
| Flower | Python | Framework-agnostic FL |
| TensorFlow Federated | Python | TF ecosystem FL |
| FATE | Python | Industrial FL (WeBank) |
| APPFL | Python | Privacy-preserving FL (Argonne) |
| FedML | Python | Cross-platform FL |

### A.5 Secure Computation

| Tool | Type | Focus |
|------|------|-------|
| MP-SPDZ | MPC | Multi-protocol MPC framework |
| CrypTen | MPC | PyTorch-based secure computation (Meta) |
| Microsoft SEAL | HE | BFV/BGV/CKKS homomorphic encryption |
| OpenFHE | HE | Multi-scheme FHE (BFV/BGV/CKKS/TFHE) |
| Concrete | HE/FHE | TFHE compiler (Zama) |
| Lattigo | HE | Go-based HE library (EPFL) |
| ABY | MPC | Arithmetic/Boolean/Yao framework |

### A.6 Consent Management

| Tool | Type | Features |
|------|------|---------|
| Cookiebot | Commercial | Auto-scanning, consent management, compliance reports |
| OneTrust | Commercial | Enterprise consent, preference center, universal consent |
| Osano | Commercial | Consent management, vendor monitoring |
| Cookie Consent (Orestbida) | Open source | Lightweight, customizable consent banner |
| Klaro | Open source | Privacy-friendly consent manager |
| Tarteaucitron | Open source | French-origin consent manager |

---

## Appendix B: OWASP Privacy Controls Quick Reference

From OWASP User Privacy Protection Cheat Sheet:

| Control | Implementation | Priority |
|---------|---------------|----------|
| Strong cryptography | TLS 1.3, AES-256, bcrypt/argon2 for passwords | Critical |
| HSTS | `Strict-Transport-Security: max-age=31536000; includeSubDomains` | High |
| Certificate pinning | Pin leaf or intermediate cert hash in app | Medium |
| Panic modes | Stealth account wipe, decoy data under coercion | Context-dependent |
| Remote session invalidation | Active session list, individual session revocation | High |
| Tor/anonymity network support | .onion service, no IP-dependent features | Context-dependent |
| IP address leak prevention | Block third-party resource loading, proxy external content | High |
| Transparency | Honest disclosure of data practices and legal constraints | Critical |

---

## Appendix C: Identity Verification Without Privacy Harm

From OWASP Security Questions Cheat Sheet — security questions are **deprecated** per NIST SP 800-63.

**Preferred Alternatives**:

| Method | Privacy Impact | Security Level | Recommendation |
|--------|---------------|---------------|----------------|
| TOTP/HOTP (authenticator app) | Minimal (no PII) | High | Preferred |
| WebAuthn/FIDO2 (passkeys) | Minimal (public key only) | Very High | Strongly preferred |
| Email verification link | Low (email already known) | Medium | Acceptable |
| SMS OTP | Medium (phone number) | Medium (SS7 risk) | Acceptable with risk acknowledgment |
| Knowledge-based authentication | High (PII collection) | Low (guessable) | Avoid |
| Social login (OAuth) | Medium-High (data sharing) | Medium | Evaluate data shared |

If security questions must be used (legacy systems):
- Hash answers with bcrypt (treat as passwords)
- Case-insensitive comparison
- System-defined questions only (no user-authored)
- Require re-authentication before changing answers
- Never: mother's maiden name, DOB, birthplace, pet name (all publicly discoverable)

---

*End of NERF Privacy Engineering Deep Training Module*
