CIPHER Privacy Engineering Deep Training
CIPHER 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
- Complete DPIA Template with Worked Example
- Data Flow Mapping Methodology
- Privacy-Preserving Architecture Patterns Catalog
- Privacy by Design Implementation Guide
- Cross-Border Data Transfer Assessment Template
- 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:
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):
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 | 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:
# 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 | 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 CIPHER Privacy Engineering Deep Training Module