<!-- 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 Regulations Deep Training
## Comprehensive Reference for MODE: PRIVACY

> Training data compiled 2026-03-14. Synthesized from GDPR official text, CCPA/CPRA
> statutory provisions, HIPAA Security Rule, OWASP privacy guidance, EDPB guidelines,
> noyb enforcement tracker, and privacy engineering literature.

---

## Table of Contents

1. [GDPR Article-by-Article Key Requirements](#1-gdpr-article-by-article-key-requirements)
2. [CCPA/CPRA Rights and Obligations](#2-ccpacpra-rights-and-obligations)
3. [HIPAA Safeguards](#3-hipaa-safeguards)
4. [DPIA Methodology](#4-dpia-methodology)
5. [Privacy by Design Principles](#5-privacy-by-design-principles)
6. [Data Subject Rights Implementation](#6-data-subject-rights-implementation)
7. [Breach Notification Procedures](#7-breach-notification-procedures)
8. [Cross-Border Transfer Mechanisms](#8-cross-border-transfer-mechanisms)
9. [Privacy Engineering Patterns](#9-privacy-engineering-patterns)
10. [US State Privacy Law Landscape](#10-us-state-privacy-law-landscape)
11. [Enforcement Trends and Notable Fines](#11-enforcement-trends-and-notable-fines)
12. [GDPR Compliance Checklist](#12-gdpr-compliance-checklist)
13. [Quick Reference Tables](#13-quick-reference-tables)

---

## 1. GDPR Article-by-Article Key Requirements

### Chapter 1: General Provisions (Art. 1-4)

| Article | Title | Key Requirement |
|---------|-------|-----------------|
| Art. 1 | Subject-matter and objectives | Protects fundamental rights of natural persons regarding personal data processing |
| Art. 2 | Material scope | Applies to automated processing and structured filing systems; excludes purely personal/household activity, law enforcement (LED), and national security |
| Art. 3 | Territorial scope | Applies to: (a) establishments in EU regardless of where processing occurs; (b) non-EU entities offering goods/services to EU residents or monitoring their behavior |
| Art. 4 | Definitions | 26 key definitions including personal data, processing, controller, processor, consent, personal data breach, pseudonymization |

**Art. 4 Critical Definitions:**
- **Personal data**: Any information relating to an identified or identifiable natural person
- **Processing**: Any operation performed on personal data (collection, recording, storage, alteration, retrieval, consultation, use, disclosure, erasure, destruction)
- **Controller**: Determines purposes and means of processing
- **Processor**: Processes data on behalf of controller
- **Consent**: Freely given, specific, informed, unambiguous indication of agreement
- **Pseudonymization**: Processing so data cannot be attributed to a specific subject without additional information kept separately
- **Personal data breach**: Security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data

### Chapter 2: Principles (Art. 5-11)

#### Art. 5 — Principles Relating to Processing of Personal Data

Seven foundational principles that govern ALL processing:

1. **Lawfulness, fairness, transparency** — Processing must have legal basis, be fair to the data subject, and be transparent about what data is collected and how it is used
2. **Purpose limitation** — Data collected for specified, explicit, legitimate purposes; not further processed incompatibly (archiving in public interest, scientific/historical research, statistics are compatible)
3. **Data minimization** — Adequate, relevant, and limited to what is necessary for the purpose
4. **Accuracy** — Personal data must be accurate and kept up to date; inaccurate data must be erased or rectified without delay
5. **Storage limitation** — Kept in identifiable form no longer than necessary for the purpose; longer storage permitted only for archiving, research, or statistics with safeguards
6. **Integrity and confidentiality** — Processed with appropriate security including protection against unauthorized/unlawful processing, accidental loss, destruction, or damage
7. **Accountability** — Controller must demonstrate compliance with all principles above

> **NERF Implementation Note**: Accountability is the meta-principle — it shifts the burden of proof to the controller. "We think we're compliant" is insufficient; demonstrable evidence is required.

#### Art. 6 — Lawfulness of Processing

Six legal bases (exactly one required for any processing):

| Legal Basis | Key Condition | Common Use |
|-------------|---------------|------------|
| **(a) Consent** | Freely given, specific, informed, unambiguous; withdrawable at any time | Marketing, cookies, newsletter |
| **(b) Contract** | Necessary for performance of a contract with the data subject | E-commerce order fulfillment |
| **(c) Legal obligation** | Required by EU or Member State law | Tax records, AML/KYC |
| **(d) Vital interests** | Necessary to protect life of data subject or another person | Emergency medical situations |
| **(e) Public task** | Necessary for task in public interest or official authority | Government services |
| **(f) Legitimate interests** | Necessary for legitimate interests of controller/third party, balanced against data subject rights | Fraud prevention, network security, direct marketing (with opt-out) |

> **NERF Note**: Consent is NOT the default or preferred basis. Use contract or legitimate interests where appropriate. Consent creates ongoing management burden and withdrawal rights.

#### Art. 7 — Conditions for Consent

- Controller must demonstrate consent was given
- Consent request must be clearly distinguishable, intelligible, easily accessible, plain language
- Withdrawal must be as easy as giving consent
- Consent is NOT freely given if performance of contract is conditional on consent for unnecessary processing (anti-bundling)

#### Art. 8 — Child's Consent (Information Society Services)

- Direct offer to a child: consent valid only if child is at least **16 years old** (Member States may lower to minimum 13)
- Below threshold: consent must be given/authorized by holder of parental responsibility
- Controller must make **reasonable efforts** to verify parental consent (considering available technology)

#### Art. 9 — Special Categories of Personal Data

**Processing PROHIBITED by default** for:
- Racial or ethnic origin
- Political opinions
- Religious or philosophical beliefs
- Trade union membership
- Genetic data
- Biometric data (for identification purposes)
- Health data
- Sex life or sexual orientation

**Exceptions** (Art. 9(2)): explicit consent, employment/social security law, vital interests, legitimate activities of foundations/associations, data manifestly made public, legal claims, substantial public interest, health/social care, public health, archiving/research/statistics.

> **NERF Note**: "Special category" is broader than most developers expect. Health data includes fitness tracker output. Biometric data includes facial recognition templates. Political opinions include inferred political leanings from browsing behavior.

#### Art. 10 — Criminal Conviction Data

Processing only under control of official authority or when authorized by EU/Member State law with appropriate safeguards. No comprehensive register of criminal convictions may be kept outside official authority control.

#### Art. 11 — Processing Not Requiring Identification

If purposes do not require identification, controller is not obliged to maintain or acquire additional information solely to identify data subjects. Data subject rights (Art. 15-20) do not apply if controller demonstrates inability to identify the subject, unless the subject provides additional information enabling identification.

### Chapter 3: Rights of the Data Subject (Art. 12-23)

#### Art. 12 — Transparency and Modalities

- Information must be provided in **concise, transparent, intelligible, easily accessible form** using **clear and plain language** (especially for children)
- Responses to data subject requests: **without undue delay**, at latest **within one month** (extendable by two further months for complex/numerous requests, with explanation)
- **First copy free**; reasonable fee for further copies or manifestly unfounded/excessive requests
- Controller must verify identity of requester

#### Art. 13 — Information at Collection (Direct)

When collecting data directly from the subject, must provide at the time of collection:
- Controller identity and contact details
- DPO contact details (if applicable)
- Processing purposes and legal basis
- Legitimate interests pursued (if Art. 6(1)(f))
- Recipients or categories of recipients
- Intent to transfer to third country and safeguards
- Retention period (or criteria to determine it)
- All data subject rights
- Right to withdraw consent (if applicable)
- Right to lodge complaint with supervisory authority
- Whether provision is statutory/contractual/necessary requirement and consequences of non-provision
- Existence of automated decision-making including profiling (Art. 22) — meaningful information about logic, significance, and envisaged consequences

#### Art. 14 — Information When Data Not From Subject

Same requirements as Art. 13 plus:
- Categories of personal data obtained
- Source of the data (including whether from publicly accessible sources)
- Must provide within reasonable period (max **one month**), or at first communication/disclosure

#### Art. 15 — Right of Access

Data subject has right to obtain:
- Confirmation of whether data is being processed
- Access to the personal data itself
- Processing purposes, data categories, recipients, retention period, rights information, source, automated decision-making details
- For international transfers: appropriate safeguards (Art. 46)
- **Copy of data** (first copy free; reasonable fee for additional copies)
- Must not adversely affect rights/freedoms of others (trade secrets, IP, etc.)

#### Art. 16 — Right to Rectification

Right to obtain rectification of inaccurate data **without undue delay**. Right to have incomplete data completed (including via supplementary statement).

#### Art. 17 — Right to Erasure ("Right to Be Forgotten")

Controller must erase personal data without undue delay when:
- Data no longer necessary for original purpose
- Consent withdrawn (and no other legal ground)
- Data subject objects (Art. 21) and no overriding legitimate grounds
- Data unlawfully processed
- Legal obligation requires erasure
- Data collected in relation to Art. 8 (child's consent for information society services)

**Exceptions**: freedom of expression/information, legal obligation, public health, archiving/research/statistics, legal claims.

If data has been made public: controller must take **reasonable steps** (including technical measures) to inform other controllers to erase links/copies.

#### Art. 18 — Right to Restriction of Processing

Data subject can require restriction when:
- Accuracy contested (for verification period)
- Processing unlawful but subject opposes erasure
- Controller no longer needs data but subject needs it for legal claims
- Subject has objected (Art. 21) pending verification of legitimate grounds

Restricted data may only be stored; processing requires consent, legal claims, protection of another person's rights, or important public interest. Subject must be informed before restriction is lifted.

#### Art. 19 — Notification Obligation

Controller must communicate any rectification, erasure, or restriction to each recipient, unless impossible or involving disproportionate effort. Must inform data subject of recipients if requested.

#### Art. 20 — Right to Data Portability

Data subject has right to receive their data in a **structured, commonly used, machine-readable format** and transmit to another controller, where processing is:
- Based on consent (Art. 6(1)(a) or Art. 9(2)(a)) or contract (Art. 6(1)(b)), AND
- Carried out by automated means

Right to have data transmitted **directly** between controllers where technically feasible. Must not adversely affect rights of others.

> **NERF Implementation Note**: Portability applies only to data PROVIDED by the data subject (not derived/inferred data) and only for consent/contract bases. Common formats: JSON, CSV, XML. Build export APIs from day one.

#### Art. 21 — Right to Object

- Data subject may object to processing based on public interest (Art. 6(1)(e)) or legitimate interests (Art. 6(1)(f)) at any time
- Controller must cease unless demonstrating **compelling legitimate grounds** overriding subject's interests/rights/freedoms, or for legal claims
- **Direct marketing**: absolute right to object; processing must cease immediately; no balancing test
- Must be brought to attention explicitly, clearly, and separately from other information at latest at first communication

#### Art. 22 — Automated Individual Decision-Making

Data subject has right NOT to be subject to decisions based **solely on automated processing** (including profiling) that produce **legal effects** or **similarly significantly affect** them.

**Exceptions**: necessary for contract, authorized by law with safeguards, based on explicit consent.

When exceptions apply: controller must implement **suitable measures** to safeguard rights including at minimum the right to obtain human intervention, express their point of view, and contest the decision.

Automated decisions must NOT be based on special category data (Art. 9) unless Art. 9(2)(a) or (g) applies with suitable measures.

#### Art. 23 — Restrictions

EU or Member State law may restrict scope of rights (Art. 12-22) and related obligations when necessary and proportionate to safeguard: national security, defense, public security, criminal prevention/investigation, other important public interests, judicial independence, regulatory functions, data subject protection, enforcement of civil claims.

### Chapter 4: Controller and Processor (Art. 24-43)

#### Art. 24-25 — Controller Responsibility and Privacy by Design

- **Art. 24**: Controller must implement appropriate technical and organizational measures, demonstrate compliance, review and update as necessary. Adherence to approved codes of conduct (Art. 40) or certification (Art. 42) as element of demonstrating compliance.
- **Art. 25**: Data protection by design and by default — covered in detail in [Section 5](#5-privacy-by-design-principles).

#### Art. 26 — Joint Controllers

When two or more controllers jointly determine purposes/means: must determine respective responsibilities via transparent arrangement. Arrangement must designate contact point. Data subject may exercise rights against each joint controller.

#### Art. 27 — EU Representative

Controllers/processors not established in EU (but subject to GDPR per Art. 3(2)) must designate a representative in a Member State where data subjects are located. Exceptions: occasional processing, no large-scale special category data, public authorities.

#### Art. 28 — Processor Requirements

- Controller must use only processors providing **sufficient guarantees** of appropriate measures
- Processor must not engage another processor without prior **specific or general written authorization** from controller
- Processing governed by **contract or legal act** specifying:
  - Subject-matter and duration
  - Nature and purpose
  - Type of personal data and categories of subjects
  - Controller's obligations and rights
- Processor obligations: process only on documented instructions, ensure confidentiality, implement Art. 32 security, assist with data subject rights, assist with DPIA, delete/return data after service ends, make available information for audits

#### Art. 30 — Records of Processing Activities

**Controllers** must maintain records containing:
- Controller/joint controller/representative/DPO identity
- Processing purposes
- Data subject and data categories
- Recipient categories
- Third-country transfers and safeguards
- Retention time limits
- Security measures description

**Processors** must maintain records containing:
- Processor and controller identity
- Processing categories carried out
- Third-country transfers
- Security measures description

Exemption: organizations with fewer than 250 employees UNLESS processing is likely to result in risk, is not occasional, or includes special categories/criminal conviction data.

> **NERF Note**: The 250-employee exemption is practically useless — almost all processing either "is not occasional" or "could result in risk." Maintain ROPA regardless of organization size.

#### Art. 32 — Security of Processing

Covered in detail below. Key measures:
- Pseudonymization and encryption
- Ongoing confidentiality, integrity, availability, resilience
- Timely restoration after incidents
- Regular testing/assessment of security effectiveness

#### Art. 33-34 — Breach Notification

Covered in detail in [Section 7](#7-breach-notification-procedures).

#### Art. 35-36 — DPIA and Prior Consultation

Covered in detail in [Section 4](#4-dpia-methodology).

#### Art. 37-39 — Data Protection Officer

**DPO required when** (Art. 37):
- Processing by public authority/body (except courts)
- Core activities require regular and systematic monitoring of data subjects on a large scale
- Core activities consist of large-scale processing of special categories (Art. 9) or criminal conviction data (Art. 10)

**DPO position requirements** (Art. 38):
- Involved properly and in a timely manner in all data protection matters
- Must be given resources necessary to carry out tasks and maintain expertise
- Must not receive instructions regarding exercise of tasks
- Must not be dismissed or penalized for performing tasks
- Reports directly to highest management level
- Data subjects may contact DPO regarding all issues related to their data processing
- Bound by secrecy/confidentiality
- May fulfill other tasks if no conflict of interest

**DPO tasks** (Art. 39):
- Inform and advise controller/processor and employees
- Monitor compliance with GDPR, other data protection provisions, and policies
- Advise on and monitor DPIA (Art. 35)
- Cooperate with supervisory authority
- Act as contact point for supervisory authority
- Have due regard to risk in all tasks

### Chapter 5: International Transfers (Art. 44-50)

Covered in detail in [Section 8](#8-cross-border-transfer-mechanisms).

### Chapter 8: Remedies, Liability, and Penalties (Art. 77-84)

#### Art. 77 — Right to Lodge Complaint

Every data subject has right to lodge complaint with supervisory authority (particularly in Member State of habitual residence, place of work, or place of alleged infringement).

#### Art. 78-79 — Judicial Remedies

- Art. 78: Right to judicial remedy against supervisory authority (binding decision or failure to handle complaint within 3 months)
- Art. 79: Right to judicial remedy against controller or processor (courts of Member State where controller/processor has establishment, OR where data subject has habitual residence)

#### Art. 80 — Representation

Data subject may mandate a body/organization/association (non-profit, statutory objectives in public interest, active in data protection) to lodge complaint, exercise rights, and claim compensation on their behalf.

#### Art. 82 — Right to Compensation

- Any person who has suffered **material or non-material damage** as result of GDPR infringement has right to receive compensation from controller or processor
- Controller liable for damage caused by processing infringing GDPR
- Processor liable only for obligations specifically directed at processors or acting outside/contrary to controller instructions
- Controller/processor exempt only if they prove they are **not in any way responsible** for the event giving rise to damage

#### Art. 83 — Administrative Fines

**Two-tier fine structure:**

| Tier | Maximum Fine | Violations |
|------|-------------|------------|
| **Tier 1** | Up to **EUR 10 million** or **2% of total worldwide annual turnover** (whichever is greater) | Controller/processor obligations (Art. 8, 11, 25-39, 42-43); certification body obligations; monitoring body obligations |
| **Tier 2** | Up to **EUR 20 million** or **4% of total worldwide annual turnover** (whichever is greater) | Processing principles and consent (Art. 5-7, 9); data subject rights (Art. 12-22); international transfers (Art. 44-49); Member State law obligations (Ch. IX); non-compliance with supervisory authority orders |

**Criteria for determining fine amounts:**
- Nature, gravity, and duration of infringement
- Intentional vs. negligent character
- Mitigation actions taken
- Degree of responsibility (technical/organizational measures in place)
- Previous infringements
- Degree of cooperation with supervisory authority
- Categories of personal data affected
- How infringement became known to authority (self-report vs. complaint)
- Compliance with previous orders
- Adherence to approved codes of conduct or certification
- Aggravating/mitigating factors (financial benefits gained or losses avoided)

---

## 2. CCPA/CPRA Rights and Obligations

### Applicability Thresholds

CCPA/CPRA applies to **for-profit businesses** conducting business in California that meet ANY of:
- Gross annual revenue exceeding **$25 million**
- Buy, sell, or share personal information of **100,000+** California residents, households, or devices annually
- Derive **50%+** of annual revenue from selling or sharing California residents' personal information

### Consumer Rights

| Right | Source | Key Details |
|-------|--------|-------------|
| **Right to Know** | CCPA original | Request disclosure of collected PI categories, specific pieces, sources, business purposes, third-party recipients. Free, max 2x/year. |
| **Right to Delete** | CCPA original | Request deletion with exceptions (legal compliance, transaction completion, security, internal uses compatible with expectations). |
| **Right to Opt-Out of Sale/Sharing** | CCPA + CPRA | "Do Not Sell or Share My Personal Information" link required. GPC (Global Privacy Control) is a valid opt-out signal. No account creation required. 15 business day response. 12-month wait before re-soliciting opt-in. |
| **Right to Non-Discrimination** | CCPA original | Cannot deny goods/services, charge different price, or provide different quality for exercising rights. Financial incentives permitted with notice and consent. |
| **Right to Correct** | CPRA (2023) | Request correction of inaccurate personal information. |
| **Right to Limit Use of Sensitive PI** | CPRA (2023) | Restrict use/disclosure of sensitive personal information to purposes necessary for providing requested goods/services. |
| **Right to Access Information About Automated Decision-Making** | CPRA (2023) | Access meaningful information about the logic involved in automated decisions and likely outcomes. |

### Personal Information Categories

**General PI**: Name, alias, postal address, unique personal identifiers, online identifiers, IP address, email address, account name, SSN, driver's license, passport number, purchase records, browsing/search history, geolocation data, audio/electronic/visual/thermal/olfactory information, professional/employment information, education information, inferences drawn to create consumer profiles.

**Sensitive PI** (CPRA addition):
- Government IDs (SSN, driver's license, state ID, passport)
- Financial account credentials (account number + access code/password)
- Precise geolocation
- Racial or ethnic origin
- Religious or philosophical beliefs
- Union membership
- Contents of mail, email, and text messages (unless business is intended recipient)
- Genetic data
- Biometric data for identification
- Health information
- Sex life or sexual orientation data

### Business Obligations

- **Notice at collection**: Disclose categories collected and purposes before or at collection
- **Privacy policy**: Updated at least every 12 months; describe rights, categories collected/sold/shared in prior 12 months, retention periods
- **Response timelines**: 45 calendar days (extendable by 45 additional days with notice)
- **Submission methods**: At least two methods (toll-free number if applicable + web form)
- **Identity verification**: Verify consumer identity before responding to requests
- **Opt-out compliance**: Honor within 15 business days
- **Service provider/contractor agreements**: Written contracts specifying permitted uses of PI, prohibiting selling/sharing, requiring compliance, granting audit rights
- **Data minimization** (CPRA): Collection, use, retention, sharing must be reasonably necessary and proportionate to disclosed purposes

### CPRA Additions (Effective 2023)

- **California Privacy Protection Agency (CPPA)**: New enforcement agency with rulemaking, investigation, and enforcement authority
- **Cybersecurity audits**: Required for businesses whose processing presents significant risk
- **Risk assessments**: Required before processing that presents significant risk to consumer privacy
- **Automated decision-making technology (ADMT)**: Consumers can opt out of ADMT for significant decisions; businesses must provide pre-use notice and access to logic/outcomes

### Child Protections

- Under 13: Parent/guardian must opt IN before personal information can be sold/shared
- Ages 13-15: Child must affirmatively opt IN
- Under 16: Opt-in required (cannot rely on failure to opt out)

### Enforcement and Penalties

| Mechanism | Scope | Penalty |
|-----------|-------|---------|
| **CPPA/AG enforcement** | All CCPA/CPRA violations | Up to $2,500 per violation (unintentional); $7,500 per intentional violation or violation involving a minor |
| **Private right of action** | Data breaches only (nonencrypted/nonredacted PI: name + SSN/DL/financial account/medical/health insurance/biometric) | $100-$750 per consumer per incident OR actual damages (whichever greater) |
| **Cure period** | Pre-suit requirement | 30-day written notice and cure opportunity (AG/CPPA enforcement only; CPRA eliminated cure period for CPPA enforcement) |

### Key CCPA/CPRA vs. GDPR Differences

| Dimension | GDPR | CCPA/CPRA |
|-----------|------|-----------|
| Scope | All data controllers/processors handling EU residents' data | For-profit businesses meeting revenue/volume thresholds in California |
| Legal basis | 6 legal bases required | No legal basis requirement; opt-out model |
| Default stance | Opt-in (consent/legal basis required) | Opt-out (processing allowed until consumer objects) |
| Private action | Full range of violations | Data breaches only |
| Maximum penalty | EUR 20M / 4% global turnover | $7,500 per violation |
| Data portability | Broad (consent + contract bases) | Limited to "specific pieces" disclosure |
| DPO requirement | Mandatory in specified cases | No DPO requirement |
| Cross-border transfers | Extensive transfer mechanisms | No equivalent provisions |
| Sensitive data | Prohibited by default with exceptions | "Right to limit" (opt-out model) |

---

## 3. HIPAA Safeguards

### Overview

The HIPAA Security Rule (45 CFR Part 160 and Subparts A and C of Part 164) establishes national standards for protecting electronic protected health information (ePHI). Applies to **covered entities** (health plans, health care clearinghouses, health care providers conducting electronic transactions) and their **business associates**.

### Administrative Safeguards (45 CFR 164.308)

The administrative safeguards are the most extensive component and represent roughly half of the Security Rule's requirements.

| Standard | Implementation Specifications | Required/Addressable |
|----------|------------------------------|---------------------|
| **Security Management Process** | Risk analysis | Required |
| | Risk management | Required |
| | Sanction policy | Required |
| | Information system activity review | Required |
| **Assigned Security Responsibility** | Designate security official | Required |
| **Workforce Security** | Authorization/supervision procedures | Addressable |
| | Workforce clearance procedures | Addressable |
| | Termination procedures | Addressable |
| **Information Access Management** | Access authorization policies | Addressable |
| | Access establishment and modification | Addressable |
| | Isolating healthcare clearinghouse functions | Required |
| **Security Awareness and Training** | Security reminders | Addressable |
| | Protection from malicious software | Addressable |
| | Log-in monitoring | Addressable |
| | Password management | Addressable |
| **Security Incident Procedures** | Response and reporting | Required |
| **Contingency Plan** | Data backup plan | Required |
| | Disaster recovery plan | Required |
| | Emergency mode operations plan | Required |
| | Testing and revision procedures | Addressable |
| | Applications and data criticality analysis | Addressable |
| **Evaluation** | Periodic technical/nontechnical evaluation | Required |
| **Business Associate Contracts** | Written contracts/arrangements | Required |

> **NERF Note on Required vs. Addressable**: "Addressable" does NOT mean optional. Covered entities must assess whether each addressable specification is reasonable and appropriate. If YES, implement it. If NO, document why and implement an equivalent alternative measure. The decision and rationale must be documented.

### Physical Safeguards (45 CFR 164.310)

| Standard | Implementation Specifications | Required/Addressable |
|----------|------------------------------|---------------------|
| **Facility Access Controls** | Contingency operations | Addressable |
| | Facility security plan | Addressable |
| | Access control and validation | Addressable |
| | Maintenance records | Addressable |
| **Workstation Use** | Policies for proper workstation use | Required |
| **Workstation Security** | Physical safeguards restricting access | Required |
| **Device and Media Controls** | Disposal (of ePHI media) | Required |
| | Media re-use | Required |
| | Accountability (hardware/media movement records) | Addressable |
| | Data backup and storage | Addressable |

### Technical Safeguards (45 CFR 164.312)

| Standard | Implementation Specifications | Required/Addressable |
|----------|------------------------------|---------------------|
| **Access Control** | Unique user identification | Required |
| | Emergency access procedure | Required |
| | Automatic logoff | Addressable |
| | Encryption and decryption | Addressable |
| **Audit Controls** | Hardware/software/procedural mechanisms recording and examining access | Required |
| **Integrity** | Mechanism to authenticate ePHI | Addressable |
| **Person or Entity Authentication** | Verify identity of persons seeking access | Required |
| **Transmission Security** | Integrity controls | Addressable |
| | Encryption | Addressable |

> **NERF Note**: Encryption being "addressable" under HIPAA is a frequent source of confusion and risk. While technically a covered entity could document why encryption is not "reasonable and appropriate," in practice the lack of encryption is the primary factor in breach notifications (the safe harbor under the Breach Notification Rule applies only to encrypted data). Treat encryption as effectively required.

### Risk Analysis Requirements

The HIPAA Security Rule risk analysis (45 CFR 164.308(a)(1)(ii)(A)) is the foundation of all other safeguards:

1. **Scope**: All ePHI created, received, maintained, or transmitted by the organization
2. **Data collection**: Identify all systems that create, receive, maintain, or transmit ePHI
3. **Threat identification**: Identify and document reasonably anticipated threats
4. **Vulnerability identification**: Identify and document vulnerabilities that could be exploited by threats
5. **Current controls**: Assess effectiveness of current security measures
6. **Likelihood determination**: Assess probability of threat occurrence
7. **Impact analysis**: Determine potential impact of threat exploitation
8. **Risk level determination**: Assign risk levels based on likelihood and impact
9. **Documentation**: Document the complete risk analysis and update periodically

### HIPAA Penalty Tiers (HITECH Act, as amended)

| Tier | Culpability | Minimum per Violation | Maximum per Violation | Annual Maximum |
|------|------------|----------------------|----------------------|----------------|
| 1 | Lack of knowledge | $137 | $68,928 | $2,067,813 |
| 2 | Reasonable cause (not willful neglect) | $1,379 | $68,928 | $2,067,813 |
| 3 | Willful neglect, corrected within 30 days | $13,785 | $68,928 | $2,067,813 |
| 4 | Willful neglect, NOT corrected | $68,928 | $2,067,813 | $2,067,813 |

> Amounts adjusted for inflation. Criminal penalties: up to $250,000 and 10 years imprisonment for obtaining/disclosing PHI with intent to sell, transfer, or use for commercial advantage, personal gain, or malicious harm.

### Breach Notification Rule (45 CFR 164.400-414)

- **Individual notification**: Without unreasonable delay, no later than **60 days** after discovery
- **HHS notification**: Breaches affecting 500+ individuals — notify HHS contemporaneously with individual notice; breaches affecting fewer than 500 — annual log submission
- **Media notification**: Breaches affecting 500+ individuals in a state/jurisdiction — notify prominent media outlets
- **Safe harbor**: Notification NOT required if PHI was encrypted per NIST standards and the encryption key was not compromised

---

## 4. DPIA Methodology

### When a DPIA Is Required (Art. 35 GDPR)

A DPIA is **mandatory** when processing is "likely to result in a high risk to the rights and freedoms of natural persons," particularly when using new technologies.

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

**Additional high-risk indicators** (EDPB/WP29 guidance — two or more triggers generally require DPIA):
- Evaluation or scoring (profiling, predicting)
- Automated decision-making with legal or significant effect
- Systematic monitoring
- Sensitive data or data of highly personal nature
- Data processed on a large scale
- Matching or combining datasets
- Data concerning vulnerable subjects (children, employees, patients, elderly)
- Innovative use or application of new technological/organizational solutions
- When processing prevents data subjects from exercising a right or using a service/contract

**DPIA NOT required when:**
- Processing is not "likely to result in a high risk"
- Similar processing already covered by existing DPIA
- Processing has legal basis in EU or Member State law, and DPIA was performed during legislative process
- Processing is on the supervisory authority's "no DPIA required" list

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

At minimum:
1. **Systematic description** of envisaged processing operations and purposes, including legitimate interest if applicable
2. **Necessity and proportionality assessment** — are the processing operations necessary? Is the data minimized? Is retention limited?
3. **Risk assessment** — assessment of risks to rights and freedoms of data subjects (identify risks, assess likelihood and severity)
4. **Mitigation measures** — safeguards, security measures, and mechanisms to ensure protection and demonstrate compliance

### DPIA Process (Step-by-Step)

```
Phase 1: SCREENING
├── Identify processing activity
├── Apply high-risk criteria checklist
├── Document decision (DPIA needed / not needed with rationale)
└── If DPIA needed → proceed to Phase 2

Phase 2: DESCRIPTION
├── Document processing operations (data flows, systems, purposes)
├── Identify data categories and data subjects
├── Map data flows (collection → processing → storage → sharing → deletion)
├── Identify recipients and transfers
├── Document retention periods
└── Document legal basis and purposes

Phase 3: NECESSITY AND PROPORTIONALITY
├── Is processing necessary for the stated purpose?
├── Could the purpose be achieved with less data?
├── Could the purpose be achieved with less intrusive means?
├── Is data quality ensured?
├── Is retention limited to what is necessary?
├── How are data subject rights facilitated?
└── Document findings

Phase 4: RISK IDENTIFICATION AND ASSESSMENT
├── Identify risks to data subjects (NOT organizational risks)
│   ├── Unauthorized access / disclosure
│   ├── Unwanted modification / loss of integrity
│   ├── Disappearance / loss of availability
│   ├── Re-identification of pseudonymized data
│   ├── Discrimination / social disadvantage
│   ├── Financial loss
│   ├── Reputational damage to individuals
│   ├── Physical harm
│   ├── Loss of confidentiality of data protected by professional secrecy
│   └── Inability to exercise rights
├── Assess likelihood: Remote | Possible | Likely
├── Assess severity: Negligible | Limited | Significant | Maximum
└── Calculate risk level matrix

Phase 5: MITIGATION
├── Identify measures to reduce risks
│   ├── Technical measures (encryption, access controls, pseudonymization, backups)
│   ├── Organizational measures (policies, training, audit, DPO, contracts)
│   ├── Legal measures (consent mechanisms, contracts, legitimate interest assessments)
│   └── Governance measures (monitoring, review cycles, incident response)
├── Assess residual risk after mitigation
├── If residual risk remains HIGH → Art. 36 prior consultation with supervisory authority
└── Document all measures and residual risk

Phase 6: SIGN-OFF AND REVIEW
├── DPO review and advice
├── Data subject consultation (where appropriate and not undermining commercial confidentiality)
├── Controller sign-off
├── Publish/share DPIA summary where appropriate
└── Schedule periodic review (at minimum when risk changes)
```

### Risk Assessment Matrix

| | Negligible Impact | Limited Impact | Significant Impact | Maximum Impact |
|---|---|---|---|---|
| **Remote likelihood** | Low | Low | Medium | Medium |
| **Possible likelihood** | Low | Medium | High | High |
| **Likely** | Medium | High | High | Very High |

> **NERF Note**: Art. 36 prior consultation with the supervisory authority is required when the DPIA indicates that processing would result in HIGH residual risk in the absence of measures taken by the controller to mitigate the risk. This is effectively a regulatory review gate.

---

## 5. Privacy by Design Principles

### Art. 25 GDPR Requirements

**Data Protection by Design** (Art. 25(1)):
- Implement appropriate technical and organizational measures **at the time of determining the means for processing** AND **at the time of processing itself**
- Consider: state of the art, implementation cost, nature/scope/context/purposes of processing, risks of varying likelihood and severity
- Measures must implement data protection principles (Art. 5) effectively
- Pseudonymization specifically cited as an example measure

**Data Protection by Default** (Art. 25(2)):
- By default, only personal data **necessary for each specific purpose** is processed
- Applies to: amount of data collected, extent of processing, period of storage, accessibility
- Personal data must NOT be made accessible to an indefinite number of persons without individual intervention

### Cavoukian's Seven Foundational Principles

Originally developed by Ann Cavoukian (Ontario Information and Privacy Commissioner), adopted by GDPR and EDPB:

| # | Principle | Implementation |
|---|-----------|---------------|
| 1 | **Proactive not Reactive; Preventative not Remedial** | Anticipate and prevent privacy-invasive events before they occur. Do not wait for risks to materialize. |
| 2 | **Privacy as the Default Setting** | No action required from the individual to protect privacy. Maximum privacy is the default. |
| 3 | **Privacy Embedded into Design** | Privacy is integral to the system architecture, not bolted on as an add-on. |
| 4 | **Full Functionality — Positive-Sum, not Zero-Sum** | Accommodate all legitimate interests. Avoid false dichotomies (privacy vs. security). Both are achievable. |
| 5 | **End-to-End Security — Full Lifecycle Protection** | Strong security measures throughout the entire data lifecycle: collection, use, retention, disclosure, disposal. |
| 6 | **Visibility and Transparency — Keep it Open** | Assure all stakeholders that the system operates according to stated promises. Subject to independent verification. |
| 7 | **Respect for User Privacy — Keep it User-Centric** | Architects must keep the interests of the individual uppermost. Strong defaults, appropriate notice, user-friendly options. |

### EDPB Guidelines on Data Protection by Design and Default (Guidelines 4/2019)

Key design elements:
- **Transparency**: Clear communication about data processing
- **Lawfulness**: Built-in legal basis verification
- **Fairness**: Avoid deceptive patterns, ensure autonomy
- **Purpose limitation**: Technical enforcement of purpose boundaries
- **Data minimization**: Collect minimum necessary; default to not collecting
- **Accuracy**: Automated and manual correction mechanisms
- **Storage limitation**: Automated deletion/anonymization schedules
- **Integrity and confidentiality**: Encryption, access control, audit logging
- **Accountability**: Logging, documentation, audit trails

### Practical Privacy by Design Patterns

```
ARCHITECTURE LEVEL
├── Data flow mapping and classification at design time
├── Privacy threat modeling (LINDDUN methodology)
├── Separation of concerns (identity vs. data vs. metadata)
├── Decentralized architectures where possible
├── Purpose-bound data stores
└── Privacy-aware API design (field-level access control)

DATA LEVEL
├── Minimize collection (question every field)
├── Pseudonymize at ingestion
├── Encrypt at rest and in transit (AES-256, TLS 1.3)
├── Implement retention policies as code (automated purge)
├── Tokenize sensitive fields
└── Aggregate before analytics where possible

APPLICATION LEVEL
├── Consent management built into user flows
├── Granular privacy preferences
├── Self-service data export (portability)
├── Self-service data deletion
├── Activity logging for transparency
├── Privacy dashboards for users
└── Cookie/tracker consent with reject-all default

PROCESS LEVEL
├── DPIA as part of feature development workflow
├── Privacy review in code review checklists
├── Privacy-specific test cases
├── Regular data inventory audits
├── Vendor privacy assessments
└── Privacy training for all developers
```

---

## 6. Data Subject Rights Implementation

### Technical Implementation Patterns

#### Right of Access (Art. 15)

```
IMPLEMENTATION REQUIREMENTS:
├── Unified data subject profile view
├── Data export endpoint (structured, machine-readable)
├── Include ALL data: collected, derived, inferred, profiled
├── Include processing metadata (purposes, recipients, retention)
├── Identity verification before disclosure
├── Response within 1 month (extendable to 3)
├── First copy free; reasonable fee for additional
└── Redact third-party data that would adversely affect their rights

TECHNICAL APPROACH:
├── Central data catalog mapping all personal data stores
├── API endpoint: GET /api/v1/subjects/{id}/data
├── Format: JSON primary, CSV/PDF secondary
├── Authentication: multi-factor identity verification
├── Audit logging of all access requests
└── Automated redaction of third-party data
```

#### Right to Erasure (Art. 17)

```
IMPLEMENTATION REQUIREMENTS:
├── Delete from ALL systems (primary, backups, caches, logs, analytics)
├── Propagate to processors and recipients
├── Handle exceptions (legal obligation, public interest, legal claims)
├── Verify legal basis for retention before refusing
├── Notify all recipients per Art. 19
├── If data made public: take reasonable steps to inform other controllers
└── Response within 1 month

TECHNICAL APPROACH:
├── Soft delete → hard delete pipeline with grace period
├── Cascading delete across all data stores
├── Backup exclusion lists (exclude erased subjects from restore)
├── Log anonymization (replace identifiers with hash)
├── Third-party deletion API calls to processors
├── Erasure verification and certification
└── Maintain minimal record of erasure request itself (for accountability)

CHALLENGES:
├── Distributed systems: eventual consistency of deletion
├── Backups: immutable backup formats vs. erasure obligation
├── Blockchain: immutability conflicts with erasure right
├── Machine learning: model retraining after data removal
├── Derived data: what counts as "personal data" in aggregates?
└── Log retention: security logs vs. privacy requirements
```

#### Right to Data Portability (Art. 20)

```
SCOPE:
├── Only data PROVIDED by the data subject (not derived/inferred)
├── Only consent (Art. 6(1)(a)) or contract (Art. 6(1)(b)) bases
├── Only automated processing
├── Machine-readable, structured, commonly used format
└── Direct controller-to-controller transfer where feasible

TECHNICAL APPROACH:
├── Export API: GET /api/v1/subjects/{id}/portable-data
├── Formats: JSON (primary), CSV, XML
├── Include: profile data, activity data, content data, preferences
├── Exclude: derived analytics, risk scores, internal classifications
├── Direct transfer: standardized API for controller-to-controller
└── Data Transfer Project (DTP) compatibility recommended
```

#### Right to Object and Automated Decision-Making (Art. 21-22)

```
DIRECT MARKETING OBJECTION:
├── Absolute right — no balancing test
├── Must cease ALL direct marketing processing immediately
├── Include suppression list (do NOT delete — suppress)
├── Propagate to all marketing systems and processors
└── Pre-populate unsubscribe/opt-out in all communications

AUTOMATED DECISION-MAKING:
├── Identify all solely automated decisions with legal/significant effects
├── Provide meaningful information about logic involved
├── Implement human review mechanism
├── Enable data subject to express their point of view
├── Enable data subject to contest the decision
├── Document safeguards and human intervention procedures
└── Special category data: additional restrictions apply
```

### Request Processing Workflow

```
1. RECEIVE REQUEST
   ├── Multi-channel intake (web form, email, in-app, letter)
   ├── Assign unique reference number
   ├── Timestamp receipt
   └── Acknowledge receipt to data subject

2. VERIFY IDENTITY
   ├── Proportionate verification (match to account, government ID, etc.)
   ├── Do NOT collect more data than necessary for verification
   ├── If unable to verify: inform subject of additional info needed
   └── Clock starts when identity is verified

3. ASSESS REQUEST
   ├── Determine which right(s) are being exercised
   ├── Check for exceptions/restrictions
   ├── Assess feasibility and complexity
   ├── If extension needed (complex/numerous): notify within 1 month with reasons
   └── If manifestly unfounded/excessive: charge reasonable fee OR refuse (with justification)

4. FULFILL REQUEST
   ├── Execute the requested action
   ├── Notify recipients per Art. 19
   ├── Propagate to processors
   ├── Document actions taken
   └── Verify completion

5. RESPOND TO DATA SUBJECT
   ├── Within 1 month (extendable to 3 months with notice)
   ├── Same channel as request (or as specified by subject)
   ├── Inform of actions taken
   ├── Inform of right to lodge complaint with supervisory authority
   └── Inform of right to judicial remedy
```

---

## 7. Breach Notification Procedures

### GDPR Breach Notification

#### Art. 33 — Notification to Supervisory Authority

**Timeline**: Without undue delay, and where feasible, **not later than 72 hours** after becoming aware.

**"Becoming aware"**: When the controller has a reasonable degree of certainty that a security incident has occurred leading to personal data being compromised. Processors must notify controllers without undue delay.

**Exception**: No notification required if the breach is **unlikely to result in a risk** to the rights and freedoms of natural persons.

**Required content** of notification:
1. Nature of the breach — categories and approximate numbers of data subjects and records affected
2. Name and contact details of DPO or other contact point
3. Likely consequences of the breach
4. Measures taken or proposed to address the breach, including mitigation of adverse effects

**Late notification**: If not made within 72 hours, must be accompanied by reasons for delay.

**Phased reporting**: Information may be provided in phases without undue further delay if not available simultaneously.

**Documentation**: Controller must document ALL breaches — facts, effects, and remedial action taken — regardless of whether notification was required (Art. 33(5)). This documentation enables supervisory authority to verify compliance.

#### Art. 34 — Communication to Data Subject

**When required**: When breach is likely to result in a **high risk** to rights and freedoms of natural persons.

**How**: In clear and plain language, describing:
- Nature of the breach
- DPO/contact details
- Likely consequences
- Measures taken/proposed

**Exceptions** (no communication required when):
1. Controller implemented appropriate technical/organizational measures (especially encryption) rendering data unintelligible to unauthorized persons
2. Controller took subsequent measures ensuring high risk is no longer likely to materialize
3. It would involve disproportionate effort (in which case: public communication or similar measure)

### Breach Assessment Decision Tree

```
SECURITY INCIDENT DETECTED
│
├── Does it involve personal data?
│   ├── NO → Not a personal data breach (handle per InfoSec policy)
│   └── YES ↓
│
├── Is it a breach? (unauthorized access, disclosure, loss, alteration, destruction)
│   ├── NO → Document and monitor
│   └── YES ↓
│
├── Is it likely to result in a risk to rights/freedoms?
│   ├── NO → Document only (Art. 33(5)), no notification required
│   │         (e.g., encrypted data with secure key, data immediately recovered)
│   └── YES ↓
│
├── NOTIFY SUPERVISORY AUTHORITY within 72 hours (Art. 33)
│
├── Is it likely to result in HIGH risk to rights/freedoms?
│   ├── NO → Authority notification only
│   └── YES ↓
│
└── NOTIFY DATA SUBJECTS without undue delay (Art. 34)
    (unless encryption/mitigation/disproportionate effort exception applies)
```

### Risk Assessment Factors for Breach Severity

- **Type of breach**: Confidentiality (unauthorized disclosure), integrity (unauthorized alteration), availability (loss/destruction)
- **Nature and sensitivity of data**: Special categories, financial data, location data, children's data = higher risk
- **Ease of identification**: Can individuals be identified from the breached data alone or combined with other data?
- **Severity of consequences**: Discrimination, identity theft, financial loss, reputational damage, physical harm
- **Volume**: Number of individuals affected
- **Special characteristics of individuals**: Children, vulnerable persons, employees
- **Special characteristics of controller**: Medical institution, government body
- **Number of affected individuals relative to total**: Percentage matters for systemic assessment

### CCPA Breach Notification

- Notice to consumers: "in the most expedient time possible and without unreasonable delay"
- No specific hour deadline (unlike GDPR's 72 hours)
- AG notification required if breach affects 500+ California residents
- Private right of action for breaches involving nonencrypted/nonredacted PI with statutory damages of $100-$750 per consumer per incident

### HIPAA Breach Notification

- Individual notice: within **60 days** of discovery
- HHS notice: 500+ individuals — contemporaneous with individual notice; <500 — annual submission
- Media notice: 500+ individuals in a state/jurisdiction
- Safe harbor: encrypted data per NIST standards with secure key

### Breach Notification Comparison

| Element | GDPR | CCPA/CPRA | HIPAA |
|---------|------|-----------|-------|
| Authority notification | 72 hours | "Without unreasonable delay" | 60 days (HHS) |
| Individual notification | "Without undue delay" (high risk) | "Most expedient time possible" | 60 days |
| Encryption safe harbor | Yes (Art. 34(3)(a)) | Yes (for private action) | Yes (NIST encryption) |
| Documentation requirement | All breaches | Reasonable security measures | 6-year retention |
| Media notification | No specific requirement | No (AG notification >500) | 500+ in state/jurisdiction |

---

## 8. Cross-Border Transfer Mechanisms

### GDPR Chapter 5: General Principle (Art. 44)

ANY transfer of personal data to a third country or international organization may only take place if the controller/processor complies with the conditions in Art. 44-49. All provisions of the GDPR must be complied with, and the level of protection must not be undermined.

### Adequacy Decisions (Art. 45)

The European Commission may determine that a third country/territory/sector provides an **adequate level of protection**. Transfers to adequate countries require no further authorization.

**Current adequacy decisions** (as of 2026):
- Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, United Kingdom, Uruguay
- **EU-U.S. Data Privacy Framework** (DPF) — adopted July 2023, replacing Privacy Shield (invalidated by Schrems II). Status uncertain following political developments; monitor for updates.

**Adequacy assessment factors**:
- Rule of law, human rights, general and sectoral legislation
- Independent supervisory authority existence and functioning
- International commitments
- Reviewed at least every 4 years

> **NERF Note**: The EU-US DPF status must be monitored continuously. Schrems I invalidated Safe Harbor. Schrems II invalidated Privacy Shield. The DPF faces ongoing legal challenges. Always have a fallback transfer mechanism.

### Standard Contractual Clauses — SCCs (Art. 46(2)(c))

Pre-approved contractual terms adopted by the European Commission that provide appropriate safeguards for international transfers.

**Current SCCs** (adopted June 2021, Decision 2021/914):

Four modules:
| Module | Transfer Type |
|--------|--------------|
| Module 1 | Controller → Controller |
| Module 2 | Controller → Processor |
| Module 3 | Processor → Sub-processor |
| Module 4 | Processor → Controller |

**Key SCC requirements**:
- Data importer must comply with SCC obligations
- Transfer Impact Assessment (TIA) required — assess whether the law of the destination country impairs the data importer's ability to comply
- Supplementary measures if TIA reveals inadequacy (encryption, pseudonymization, split processing, etc.)
- Data subjects are third-party beneficiaries
- Supervisory authority and courts may order suspension/termination
- Data importer must notify exporter of any government access requests
- Mandatory for non-adequate countries without BCRs or other mechanisms

**Transfer Impact Assessment (TIA) — required per Schrems II and SCC Clause 14**:
1. Identify the specific transfer(s)
2. Verify the relevant legal framework of destination country
3. Assess whether the destination country's laws/practices impair SCC effectiveness (particularly government surveillance laws)
4. Identify supplementary measures if needed
5. Document the assessment
6. Re-evaluate at appropriate intervals

### Binding Corporate Rules — BCRs (Art. 47)

Approved internal codes of conduct for multinational groups allowing intra-group international transfers.

**BCR requirements**:
- Legally binding on every member of the group
- Expressly confer enforceable rights on data subjects
- Specify data protection principles, data subject rights, mechanisms for ensuring compliance
- Include complaint handling and dispute resolution
- Include cooperation with supervisory authorities
- Include reporting of changes
- Include DPO or equivalent role
- Approved by competent supervisory authority through consistency mechanism (Art. 63)

**BCR types**:
- **BCR-C**: For controllers (Art. 47)
- **BCR-P**: For processors (WP257 guidance)

**Advantages**: Once approved, cover all intra-group transfers without individual SCC execution.
**Disadvantages**: 12-24+ month approval process, expensive, complex to maintain.

### Derogations for Specific Situations (Art. 49)

When NO adequacy decision, SCCs, or BCRs are in place, transfers may occur based on:

| Derogation | Condition | Notes |
|------------|-----------|-------|
| **Explicit consent** | Informed of risks due to absence of adequacy/safeguards | Cannot be the basis for systematic/routine transfers |
| **Contract with data subject** | Necessary for performance | Occasional transfers only |
| **Contract in interest of data subject** | Between controller and another party | Occasional transfers only |
| **Public interest** | Important reasons recognized by law | |
| **Legal claims** | Establishment, exercise, or defense of legal claims | |
| **Vital interests** | Necessary to protect vital interests when subject incapable of consent | |
| **Public register** | Transfer from a register open to public consultation | |
| **Compelling legitimate interests** | Not repetitive, limited number of subjects, compelling interests not overridden, suitable safeguards, notification to supervisory authority | Last resort; heavily scrutinized |

> **NERF Critical Note**: Derogations are meant for occasional, non-systematic transfers. Using Art. 49 for routine data flows is non-compliant. Always establish a primary mechanism (adequacy, SCCs, or BCRs) for ongoing transfers.

### Post-Schrems II Supplementary Measures

Following the CJEU Schrems II ruling (C-311/18) and EDPB Recommendations 01/2020:

**Technical supplementary measures**:
- End-to-end encryption (where data importer does not need plaintext access)
- Pseudonymization (where additional data for re-identification remains in EU)
- Split or multiparty processing (no single entity in third country has complete data)
- Transport encryption in transit (TLS 1.3+)
- Encryption at rest with keys held in EU

**Contractual supplementary measures**:
- Data importer warrant that laws do not impair SCC compliance
- Data importer commitment to challenge access requests and exhaust legal remedies
- Data importer transparency reporting on government access requests
- Obligation to notify data exporter of inability to comply

**Organizational supplementary measures**:
- Internal policies for transfers assessment
- Designation of responsible teams
- Regular reassessment of third-country legal landscape
- Documentation and record-keeping

---

## 9. Privacy Engineering Patterns

### Data Minimization Patterns

```
COLLECTION MINIMIZATION
├── Question every data field: "Is this necessary for the stated purpose?"
├── Progressive disclosure: collect data only when needed in the user journey
├── Ephemeral processing: process and immediately discard where possible
├── Client-side processing: compute on-device, transmit only results
├── Aggregation at source: collect aggregates instead of individual records
└── Purpose-bound collection: technical enforcement of purpose limitations

STORAGE MINIMIZATION
├── Automated retention policies: delete/anonymize at expiration
├── Tiered storage: full data → pseudonymized → aggregated → deleted
├── Minimal backup retention: align backup lifecycle with retention policy
├── Log minimization: rotate, truncate, anonymize logs aggressively
├── Cache expiration: set appropriate TTLs on cached personal data
└── Database-level TTL indexes (e.g., MongoDB TTL indexes, Cassandra TTL)

ACCESS MINIMIZATION
├── Role-based access control (RBAC): principle of least privilege
├── Attribute-based access control (ABAC): context-sensitive access
├── Purpose-based access control (PBAC): access tied to processing purpose
├── Field-level encryption: encrypt sensitive fields within records
├── Data masking: mask PII in non-production environments
├── Query-level restrictions: prevent bulk extraction
└── Just-in-time access: temporary elevated permissions with audit trail
```

### Pseudonymization

**Definition** (Art. 4(5) GDPR): Processing so that personal data can no longer be attributed to a specific data subject without use of additional information, provided that additional information is kept separately and subject to technical and organizational measures.

**Key property**: Pseudonymized data IS still personal data under GDPR (unlike anonymous data). However, pseudonymization is recognized as a safeguard that:
- Reduces risk (relevant for DPIA, breach assessment, security of processing)
- Is a recommended measure under Art. 25 (by design) and Art. 32 (security)
- May support legitimate interest balancing (Art. 6(1)(f))

**Techniques:**

| Technique | Description | Reversibility | Use Case |
|-----------|-------------|---------------|----------|
| **Tokenization** | Replace identifiers with random tokens; mapping table stored separately | Reversible via mapping table | Payment processing, cross-system linking |
| **Hash-based** | One-way hash of identifiers (with salt/pepper) | Computationally irreversible (with proper salt) | Log anonymization, deduplication |
| **Encryption-based** | Encrypt identifiers; key stored separately | Reversible with key | Secure storage, backup encryption |
| **Key-coded** | Replace with sequential/random codes; key held by trusted third party | Reversible via key holder | Clinical trials, research |
| **Masking** | Partially obscure data (e.g., ****1234) | Irreversible (partial data loss) | Display purposes, receipts |

**Implementation requirements:**
- Additional information (mapping tables, keys) must be kept separately
- Technical and organizational measures must ensure non-attribution
- Access to re-identification data must be strictly controlled
- Regular assessment of re-identification risk

### Anonymization

**Definition**: Processing data so that data subjects are no longer identifiable, even by the controller. Truly anonymous data falls OUTSIDE the scope of GDPR entirely.

**Criteria** (WP29 Opinion 05/2014 on Anonymization Techniques):
- **Singling out**: Not possible to isolate a record relating to an individual
- **Linkability**: Not possible to link records relating to the same individual
- **Inference**: Not possible to deduce information about an individual

**Techniques:**

| Technique | How It Works | Strengths | Weaknesses |
|-----------|-------------|-----------|------------|
| **k-Anonymity** | Each record indistinguishable from at least k-1 others on quasi-identifiers | Simple, intuitive | Vulnerable to homogeneity and background knowledge attacks |
| **l-Diversity** | Each equivalence class has at least l "well-represented" values for sensitive attributes | Addresses k-anonymity homogeneity weakness | Computationally expensive; does not protect against skewness |
| **t-Closeness** | Distribution of sensitive attribute in any equivalence class is within distance t of overall distribution | Strong privacy guarantees | Significant utility loss; complex to implement |
| **Generalization** | Replace specific values with broader categories (age → age range, zip → region) | Simple, preserves structure | Utility loss proportional to generalization level |
| **Suppression** | Remove records or values that cannot be adequately generalized | Eliminates outlier risk | Data loss; potential bias in remaining dataset |
| **Data swapping/permutation** | Exchange values between records | Preserves aggregate statistics | Individual-level analysis invalid |
| **Noise addition** | Add random values to numerical data | Preserves distributions | Reduces precision; may introduce bias |
| **Synthetic data generation** | Generate new data with same statistical properties | No real individuals at risk | Complex; may not capture all relationships |

> **NERF Warning**: True anonymization is extremely difficult to achieve and verify. Many "anonymized" datasets have been re-identified (Netflix Prize, NYC taxi data, Massachusetts GIC, Australian Medicare). When in doubt, treat data as pseudonymized (still personal data under GDPR) rather than claiming anonymization.

### Differential Privacy

**Core concept**: A mechanism satisfies epsilon-differential privacy if the output of any analysis is approximately the same whether or not any single individual's data is included in the dataset.

**Formal definition**: A randomized algorithm M satisfies (epsilon)-differential privacy if for any two adjacent datasets D1, D2 (differing in one record) and any set of outputs S:

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

**Key parameters:**
- **Epsilon (ε)**: Privacy budget. Lower ε = stronger privacy, more noise, less utility. Typical values: 0.1 (strong) to 10 (weak).
- **Delta (δ)**: Probability of privacy failure. Should be cryptographically small (e.g., 1/n²).
- **Sensitivity**: Maximum change in query output from adding/removing one record. Determines noise magnitude.

**Mechanisms:**
| Mechanism | Noise Distribution | Use Case |
|-----------|-------------------|----------|
| **Laplace mechanism** | Laplace noise proportional to sensitivity/ε | Numerical queries (count, sum, average) |
| **Gaussian mechanism** | Gaussian noise (requires (ε,δ)-DP) | Numerical queries; often tighter bounds |
| **Exponential mechanism** | Selects output from a set with probability proportional to utility score | Non-numerical queries (mode, median, categorical) |
| **Randomized response** | Each respondent randomly lies with probability p | Survey data, local DP |

**Deployment models:**
- **Central DP**: Trusted curator adds noise to query results. Requires trust in the data holder.
- **Local DP**: Each individual randomizes their own data before submission. No trust required but higher noise. Used by Apple (iOS usage stats), Google (RAPPOR/Chrome).
- **Shuffled DP**: Intermediate shuffler breaks link between individuals and their reports. Privacy amplification through shuffling.

**Privacy budget composition:**
- Each query against a dataset consumes some privacy budget
- **Sequential composition**: Total privacy loss is sum of individual losses (ε_total = Σ ε_i)
- **Parallel composition**: Queries on disjoint subsets: ε_total = max(ε_i)
- **Advanced composition**: Tighter bounds using Rényi divergence or concentrated DP

**Tools and libraries:**
- Google DP library (C++, Go, Java)
- OpenDP (Rust/Python, Harvard initiative)
- IBM diffprivlib (Python, scikit-learn compatible)
- TensorFlow Privacy (ML-specific)
- PyDP (Python wrapper for Google DP)
- Tumult Analytics (Spark-based)

### Homomorphic Encryption

**Core concept**: Encryption scheme allowing computation on ciphertexts, producing encrypted results that, when decrypted, match the result of operations performed on plaintexts.

**Types:**

| Type | Operations Supported | Performance | Practical Use |
|------|---------------------|-------------|---------------|
| **Partially HE (PHE)** | One type of operation (addition OR multiplication) unlimited times | Fast | Voting, simple aggregation |
| **Somewhat HE (SHE)** | Both addition and multiplication, limited depth | Moderate | Shallow circuits |
| **Leveled HE** | Both operations up to predetermined depth | Moderate | Known-depth computations |
| **Fully HE (FHE)** | Arbitrary computation (addition AND multiplication, unlimited) | Very slow (10,000-1,000,000x overhead) | Any computation (but impractical for many) |

**Schemes:**
- **BGV/BFV**: Integer arithmetic, batch processing via SIMD
- **CKKS**: Approximate arithmetic on real/complex numbers (ML-friendly)
- **TFHE**: Boolean circuit evaluation, fast bootstrapping

**Libraries:**
- Microsoft SEAL (C++/.NET)
- HElib (IBM, C++)
- TFHE (C/C++)
- Lattigo (Go)
- OpenFHE (C++)
- Concrete (Zama, Rust/Python)
- TenSEAL (Python, built on SEAL, ML-focused)

**Practical limitations:**
- Computational overhead: 10,000x-1,000,000x for FHE
- Ciphertext expansion: encrypted data is 10-10,000x larger
- Noise management: operations accumulate noise; bootstrapping is expensive
- Limited practical use cases currently: secure aggregation, private set intersection, simple ML inference
- Active research area; performance improving rapidly

> **NERF Assessment**: FHE is not yet practical for general-purpose computing. Focus on PHE/SHE for specific use cases (e.g., encrypted aggregation of health data, private voting, simple ML inference). For most privacy engineering needs, combine pseudonymization + access controls + differential privacy rather than relying on HE.

### Secure Multi-Party Computation (SMPC)

**Core concept**: Multiple parties jointly compute a function over their inputs while keeping those inputs private from each other.

**Techniques:**
- **Secret sharing**: Split data into shares distributed among parties; computation on shares; no single party sees the original data (e.g., Shamir's Secret Sharing, additive sharing)
- **Garbled circuits**: One party garbles a boolean circuit; the other evaluates it obliviously (Yao's protocol)
- **Oblivious transfer**: Receiver obtains one of multiple items from sender without sender knowing which was selected

**Use cases:**
- Private set intersection (two parties find common elements without revealing their full sets)
- Joint analytics across organizations without sharing raw data
- Privacy-preserving auctions
- Collaborative ML training across institutions

**Libraries/Frameworks:**
- MP-SPDZ (Python/C++)
- CrypTen (PyTorch-based, Facebook)
- ABY/ABY3 (mixed protocol frameworks)
- MOTION (C++)
- Sharemind (commercial)

### Federated Learning

**Core concept**: Train ML models across decentralized data sources without exchanging raw data. Each participant trains locally and shares only model updates (gradients).

**Architecture:**
```
FEDERATED AVERAGING (FedAvg):
1. Server sends global model to selected clients
2. Each client trains on local data for E epochs
3. Each client sends model updates (gradients/weights) to server
4. Server aggregates updates (weighted average)
5. Server updates global model
6. Repeat until convergence
```

**Privacy enhancements:**
- **Secure aggregation**: Server sees only aggregated updates, not individual contributions
- **Differential privacy**: Add noise to individual updates before aggregation
- **Gradient compression/sparsification**: Reduce information in transmitted updates
- **Client selection**: Random sampling of participants per round

**Challenges:**
- Gradient inversion attacks: reconstruct training data from gradients
- Model poisoning: malicious clients inject backdoors
- Non-IID data: heterogeneous data distributions across clients degrade model quality
- Communication efficiency: repeated model transmission is bandwidth-intensive

**Frameworks:**
- TensorFlow Federated (Google)
- PySyft (OpenMined)
- FATE (WeBank)
- Flower (Adap)
- FedML

### Privacy-Preserving Analytics Patterns

```
PATTERN: AGGREGATE BEFORE EXPORT
├── Perform all individual-level analysis within the data boundary
├── Export only aggregated/summary statistics
├── Apply k-anonymity thresholds (suppress cells with < k individuals)
└── Add differential privacy noise to released statistics

PATTERN: PURPOSE-BOUND DATA STORES
├── Separate data stores per processing purpose
├── Technical access controls enforce purpose limitation
├── Each purpose store has its own retention policy
├── Cross-purpose queries require explicit authorization
└── Audit logging of all cross-purpose access

PATTERN: PRIVACY PROXY / DATA GATEWAY
├── All access to personal data goes through privacy proxy
├── Proxy enforces access policies, purpose limitation, minimization
├── Proxy handles pseudonymization/anonymization transparently
├── Proxy logs all access for accountability
└── Applications never access raw personal data directly

PATTERN: ZERO-KNOWLEDGE PROOFS FOR AUTHENTICATION
├── Prove possession of attribute without revealing value
├── Example: prove age ≥ 18 without revealing birthdate
├── Example: prove membership in a group without revealing identity
├── ZK-SNARKs, ZK-STARKs, Bulletproofs
└── Increasing practical deployment (identity verification, credentials)

PATTERN: ON-DEVICE PROCESSING
├── Process data on user's device; transmit only results
├── Apple's on-device ML (CoreML, Neural Engine)
├── Google's federated learning in Gboard
├── Firefox's privacy-preserving telemetry
└── Reduces data collection, transfer, and storage risk
```

---

## 10. US State Privacy Law Landscape

### Comprehensive State Privacy Laws (Enacted as of 2026)

| State | Law | Effective | Key Features |
|-------|-----|-----------|--------------|
| **California** | CCPA/CPRA | Jan 2020 / Jan 2023 | Most comprehensive; dedicated enforcement agency (CPPA); private right of action for breaches |
| **Virginia** | VCDPA | Jan 2023 | No private right of action; AG enforcement only; controller obligations |
| **Colorado** | CPA | Jul 2023 | Universal opt-out mechanism required; AG + DA enforcement |
| **Connecticut** | CTDPA | Jul 2023 | Recognizes global opt-out signals; broad consumer rights |
| **Utah** | UCPA | Dec 2023 | Business-friendly; higher thresholds; AG enforcement only |
| **Iowa** | ICDPA | Jan 2025 | Narrow scope; no opt-out of profiling |
| **Indiana** | IDPA | Jan 2026 | Consumer rights; 90-day cure period |
| **Tennessee** | TIPA | Jul 2025 | Affirmative defense for NIST framework compliance |
| **Montana** | MCDPA | Oct 2024 | Lower applicability threshold (50,000 consumers) |
| **Texas** | TDPSA | Jul 2024 | No revenue threshold; applies to businesses operating in TX |
| **Oregon** | OCPA | Jul 2024 | Includes nonprofit organizations |
| **Delaware** | DPDPA | Jan 2025 | Lower threshold (35,000 consumers); broad scope |
| **New Hampshire** | NHPA | Jan 2025 | Standard consumer rights model |
| **New Jersey** | NJDPA | Jan 2025 | Broad definition of personal data |
| **Nebraska** | NDPA | Jan 2025 | No revenue threshold |
| **Maryland** | MODPA | Oct 2025 | Strong data minimization requirements |
| **Minnesota** | MCDPA | Jul 2025 | Includes profiling protections |
| **Rhode Island** | RIDPA | Jan 2026 | Standard model with universal opt-out |
| **Kentucky** | KIPA | Jan 2026 | Standard model; 90-day cure period |

> **NERF Note**: The US state privacy landscape is rapidly evolving. Federal privacy legislation has been proposed repeatedly but not enacted as of 2026. Organizations operating nationally should build to the most restrictive standard (generally California CPRA + Maryland MODPA for minimization) to achieve compliance across all states.

### Common State Privacy Law Provisions

**Consumer Rights** (present in most state laws):
- Right to access/know
- Right to delete
- Right to correct
- Right to data portability
- Right to opt out of: sale, targeted advertising, profiling

**Business Obligations** (typical):
- Privacy notice/policy
- Data protection assessments for high-risk processing
- Processor contracts
- Reasonable security measures
- Purpose limitation
- Data minimization (varies in strength)
- Respond to consumer requests within 45 days

---

## 11. Enforcement Trends and Notable Fines

### Largest GDPR Fines (as of 2026)

| Company | Amount | Authority | Year | Violation |
|---------|--------|-----------|------|-----------|
| Meta (Ireland) | EUR 1.2 billion | Irish DPC | 2023 | Unlawful EU-US data transfers (Art. 46) |
| Amazon (Luxembourg) | EUR 746 million | CNPD | 2021 | Targeted advertising without valid consent |
| Meta/Instagram (Ireland) | EUR 405 million | Irish DPC | 2022 | Children's data processing violations |
| Meta/Facebook (Ireland) | EUR 390 million | Irish DPC | 2023 | Invalid legal basis for behavioral advertising |
| Google (France) | EUR 325 million | CNIL | 2025 | Inserting ads in Gmail, tracking cookies without consent |
| TikTok (Ireland) | EUR 345 million | Irish DPC | 2023 | Children's privacy, transparency failures |
| Criteo (France) | EUR 40 million | CNIL | 2026 | GDPR non-compliance (upheld by Conseil d'Etat) |
| Microsoft (Austria) | Order to cease | Austrian DPA | 2026 | Unlawful tracking cookies on student devices |

### Key Enforcement Trends (2024-2026)

1. **Cross-border transfer scrutiny**: Post-Schrems II enforcement continues. EU-US DPF faces challenges. Transfer Impact Assessments heavily scrutinized.
2. **Children's data**: Significant focus on minor protection. Age verification, parental consent, and default privacy settings for children.
3. **Cookie consent**: Mass enforcement of cookie consent requirements. Dark patterns in consent interfaces increasingly penalized.
4. **Data broker regulation**: California leading with data broker registration and automated deletion requirements.
5. **AI and automated decision-making**: CPRA ADMT regulations adopted. EDPB guidance on AI and GDPR compliance.
6. **Right to erasure implementation**: EDPB Coordinated Enforcement Action examining actual implementation of erasure across organizations.
7. **Legitimate interest challenges**: noyb systematically challenging use of legitimate interest for behavioral advertising.

### noyb Enforcement Statistics (2026)

- **884** total cases filed across EU
- **441** pending cases
- **EUR 2+ billion** in fines resulting from noyb-initiated complaints
- **5,408** supporting members
- Focus areas: cookie consent, data transfers, direct marketing, children's data, platform tracking

---

## 12. GDPR Compliance Checklist

### 1. Lawful Basis and Transparency

- [ ] Conduct information audit: document what data you process, who has access, purposes, third parties, data locations, protection measures, and deletion timelines
- [ ] Identify and document legal basis for each processing activity (Art. 6)
- [ ] If relying on consent: ensure freely given, specific, informed, unambiguous; provide easy withdrawal
- [ ] If relying on legitimate interests: conduct and document Legitimate Interest Assessment (LIA)
- [ ] Publish clear, accessible privacy policy/notice meeting Art. 13/14 requirements
- [ ] Review privacy notices annually and after any processing changes

### 2. Data Security

- [ ] Implement data protection by design and by default in all products/systems (Art. 25)
- [ ] Apply encryption at rest and in transit (Art. 32)
- [ ] Apply pseudonymization where feasible (Art. 32)
- [ ] Create and enforce internal security policies (email, passwords, 2FA, device encryption, VPN)
- [ ] Provide additional training for personnel handling personal data
- [ ] Conduct DPIA before high-risk processing (Art. 35)
- [ ] Establish breach notification process: 72 hours to authority, prompt communication to subjects (Art. 33-34)
- [ ] Regularly test and assess effectiveness of security measures (Art. 32(1)(d))

### 3. Accountability and Governance

- [ ] Designate a compliance lead or team responsible for GDPR
- [ ] Appoint DPO if required (Art. 37) — public authority, large-scale monitoring, or large-scale special category processing
- [ ] Maintain Records of Processing Activities (Art. 30)
- [ ] Execute Data Processing Agreements with all processors (Art. 28)
- [ ] If outside EU: designate EU representative (Art. 27)
- [ ] Implement and document data retention schedules
- [ ] Conduct regular compliance audits

### 4. Data Subject Rights

- [ ] Enable right of access with data export capability (Art. 15)
- [ ] Implement right to rectification process (Art. 16)
- [ ] Implement right to erasure with exception handling (Art. 17)
- [ ] Implement right to restriction of processing (Art. 18)
- [ ] Implement right to data portability (structured, machine-readable format) (Art. 20)
- [ ] Implement right to object (especially absolute right for direct marketing) (Art. 21)
- [ ] Review and document any automated decision-making; implement human review mechanisms (Art. 22)
- [ ] Respond to all requests within 1 month (extendable to 3 with notice)
- [ ] Verify identity of requesters proportionately

### 5. International Transfers

- [ ] Map all international data flows
- [ ] Verify adequate transfer mechanism for each flow (adequacy, SCCs, BCRs, derogation)
- [ ] Conduct Transfer Impact Assessment for SCC-based transfers
- [ ] Implement supplementary measures where required
- [ ] Monitor adequacy decisions and regulatory developments
- [ ] Document all transfer mechanisms and assessments

---

## 13. Quick Reference Tables

### Lawful Basis Selection Guide

```
Is processing necessary for a contract with the data subject?
  → YES: Art. 6(1)(b) Contract

Is processing required by law?
  → YES: Art. 6(1)(c) Legal obligation

Is someone's life at risk?
  → YES: Art. 6(1)(d) Vital interests

Is the controller a public authority performing official functions?
  → YES: Art. 6(1)(e) Public task

Does the controller have a legitimate interest that doesn't override
the data subject's rights? (Conduct LIA to determine)
  → YES: Art. 6(1)(f) Legitimate interests

None of the above? The data subject must freely consent.
  → Art. 6(1)(a) Consent
```

### Data Subject Request Response Times

| Regulation | Standard Response | Extension | Maximum Total |
|------------|------------------|-----------|---------------|
| GDPR | 1 month | +2 months (complex/numerous) | 3 months |
| CCPA/CPRA | 45 days | +45 days (with notice) | 90 days |
| HIPAA (access) | 30 days | +30 days (with notice) | 60 days |

### Breach Notification Timelines

| Regulation | To Authority | To Individuals | To Media |
|------------|-------------|---------------|---------|
| GDPR | 72 hours | "Without undue delay" (high risk) | N/A |
| CCPA | "Without unreasonable delay" | "Most expedient time possible" | AG if 500+ CA residents |
| HIPAA | 60 days (500+: contemporaneous; <500: annual) | 60 days | 500+ in state/jurisdiction |

### Privacy Engineering Technique Selection

| Need | Technique | Privacy Guarantee | Performance Impact |
|------|-----------|-------------------|-------------------|
| Query results without individual exposure | Differential Privacy | Mathematical (ε-DP) | Low-Moderate (noise addition) |
| Reduce re-identification risk, maintain utility | Pseudonymization | Organizational (reversible with key) | Minimal |
| Remove personal data entirely | Anonymization (k-anon, l-div) | Statistical (quasi-identifiers) | Low (preprocessing) |
| Compute on encrypted data | Homomorphic Encryption | Cryptographic | Very High (10,000x+) |
| Multi-party joint computation | Secure MPC | Cryptographic | High (communication overhead) |
| Train ML without centralizing data | Federated Learning | Architectural (data stays local) | Moderate (communication rounds) |
| Prove attribute without revealing value | Zero-Knowledge Proofs | Cryptographic | Moderate |
| Generate useful data without real individuals | Synthetic Data Generation | Statistical (no real subjects) | One-time generation cost |

### GDPR vs. CCPA/CPRA vs. HIPAA Comparison

| Dimension | GDPR | CCPA/CPRA | HIPAA |
|-----------|------|-----------|-------|
| **Scope** | Any entity processing EU residents' data | For-profit, CA business, meeting thresholds | Covered entities + business associates |
| **Data covered** | Personal data (any identifiable info) | Personal information (broadly defined) | Protected Health Information (PHI/ePHI) |
| **Legal basis required** | Yes (6 bases) | No (opt-out model) | Treatment, payment, operations + authorizations |
| **Consent model** | Opt-in (except legitimate interests) | Opt-out (sale/sharing) | Written authorization for non-TPO uses |
| **Breach notification** | 72 hours to authority | "Expedient" to individuals | 60 days to individuals/HHS |
| **Max penalty** | EUR 20M / 4% turnover | $7,500/violation | $2.07M/category/year |
| **Private action** | Yes (compensation for damage) | Breaches only ($100-750/incident) | No (AG enforcement only) |
| **DPO/privacy officer** | Required in specified cases | Not required | Security official required |
| **Data minimization** | Core principle (Art. 5(1)(c)) | CPRA addition (proportionate) | Minimum necessary standard |
| **Cross-border transfers** | Extensive framework (Ch. 5) | No equivalent | BAA required; no transfer framework |

---

*End of NERF Privacy Regulations Deep Training Document*
*Last updated: 2026-03-14*
*Sources: GDPR official text (gdpr-info.eu), gdpr.eu guidance, California OAG, CPPA, OWASP, EDPB, noyb, IAPP*
