Warmup Guide — Privacy Engineering from First Principles

Zero-to-expert primer for the Privacy Engineering module. It builds privacy as an engineering discipline: security vs privacy, the data taxonomy (PII/PHI/PCI), data-flow mapping and minimization, lawful basis and purpose limitation, retention and deletion (DSAR/erasure), cross-border transfer, de-identification (anonymization vs pseudonymization, k-anonymity, differential privacy), and Privacy by Design / DPIA. Builds on Phase 00 (minimization) and Phase 15 (compliance as engineering). Offline, over data-flow and dataset metadata — no real personal data.

Table of Contents

Chapter 1: Security vs Privacy

Zero background. They overlap but ask different questions. Security asks: can an unauthorized party access this data? (confidentiality, integrity, availability). Privacy asks: should we have this data at all, for what purpose, for how long, who do we share it with, and can the individual control it? You can be perfectly secure and badly violate privacy — e.g., an airtight database that collects far more than needed, keeps it forever, and sells it. Privacy engineering is the discipline of building systems that handle personal data appropriately, by design.

Why an engineer owns this. Privacy obligations (GDPR, CCPA/CPRA, HIPAA, and dozens of national laws) are requirement specifications that become tested controls over data flows — exactly the "compliance as engineering" stance of Phase 15, but the subject is personal data. The engineer maps the flows, enforces minimization and retention in code, builds the deletion pipeline, and proves it.

The relationship to security. Privacy needs security (you can't keep a deletion promise if an attacker copied the data), and security needs privacy (the less you collect and keep, the smaller the breach — data you don't have can't leak; Phase 00). They reinforce each other; neither replaces the other.

Misconception to kill now. "We encrypt it and restrict access, so privacy is handled." That's security. Privacy is also: did we have a lawful basis to collect it, is it the minimum needed for a stated purpose, are we keeping it only as long as necessary, can the person get it deleted, and is it truly de-identified if we claim so? An encrypted over-collection is still a privacy violation.

Chapter 2: The Data Taxonomy — PII, Sensitive PII, PHI, PCI

You can't govern what you haven't classified. The categories and what each triggers:

  • PII (Personally Identifiable Information) — data that identifies a person directly (name, email, phone, government ID, account ID) or indirectly in combination (the quasi-identifiers of Chapter 8). GDPR's broader term is personal data: any information relating to an identifiable person (including IP address, device ID, cookies, location).
  • Sensitive / special-category data — a higher-protection subset: health, biometrics, genetics, race/ethnicity, religion, sexual orientation, political views, precise geolocation, children's data. Processing it usually requires stronger lawful basis and controls.
  • PHI (Protected Health Information) — health data under HIPAA (US) with specific safeguards.
  • PCI (cardholder data) — payment card data under PCI DSS (Phase 15): a contractual regime where scope minimization (don't store the PAN; tokenize) is the central move.

Why classification drives everything. The category sets the lawful basis, retention, transfer rules, breach-notification thresholds, and de-identification bar. A data inventory ("data map") tagging every field with its category and purpose is the foundation control — and the input to Lab 01.

Misconception to kill now. "It's not PII, it's just an IP/device ID/cookie." Under GDPR those are personal data (identifiers that single out a person), and combinations of non-identifying fields (ZIP + birthdate + sex) re-identify individuals (Chapter 8). "Not PII" is a claim you must prove, not assume.

Chapter 3: Data-Flow Mapping and Minimization

Map the flow. For each piece of personal data, trace its lifecycle: collection (where it enters, with what consent) → processing (who/what uses it, for what) → storage (where, encrypted, how long) → sharing (processors, third parties, regions) → deletion (when, how, verified). You cannot govern, secure, or honor a deletion request for data whose flow you haven't mapped. This is the privacy analog of the Phase 03 data-flow diagram.

Data minimization — the core principle (and the highest-leverage control). Collect and keep the least data needed for the stated purpose, and no more. Minimization shrinks every downstream obligation and the breach blast radius simultaneously — data you don't have can't be breached, subpoenaed, or misused (Phase 00). Concretely: don't collect fields "just in case," don't log full request bodies with PII, don't copy production PII into analytics/dev, and drop data the moment its purpose is served.

Misconception to kill now. "Collect everything now; we might need it later." Speculative collection is a liability, not an asset: it expands consent, retention, transfer, and breach obligations and the attack surface, for data you may never use. Minimization is the cheapest privacy and security control.

Chapter 4: Lawful Basis, Purpose Limitation, and Retention

Lawful basis. Under GDPR, every processing of personal data needs a lawful basis — consent, contract, legal obligation, vital interests, public task, or legitimate interests. No basis = unlawful processing. (Consent must be freely given, specific, informed, and revocable — pre-ticked boxes don't count.)

Purpose limitation. Data collected for one stated purpose may not be silently repurposed. Collecting an email "to send your receipt" and then using it for marketing or selling it to a partner is purpose creep — a violation even though you "had" the data. Each new purpose needs its own basis.

Retention limitation. Keep personal data only as long as necessary for its purpose, then delete or anonymize it. "Keep forever" violates the storage-limitation principle. A retention schedule per data category, enforced by an automated deletion pipeline, is the control — and over-retention is a classic finding (Lab 01).

Misconception to kill now. "We have the data, so we can use it for X." Having data lawfully for one purpose doesn't authorize a new purpose, and it doesn't authorize keeping it past need. Lawful basis and purpose are per use, and retention is time-bounded.

Chapter 5: Subject Rights — DSAR and the Right to Erasure

Data Subject Rights. Privacy laws give individuals rights over their data: access (a DSAR — Data Subject Access Request: "give me everything you hold on me"), rectification, erasure ("right to be forgotten"), portability, restriction, and objection. These are engineering requirements: you must be able to find all of a person's data across every system (back to the data map, Chapter 3) and return or delete it within a legal deadline (e.g. ~30 days under GDPR).

Why erasure is hard (the engineering reality). "Delete the user" must reach every copy: primary DB, replicas, caches, search indexes, analytics warehouses, logs, backups, and third-party processors — and prove it. Data scattered without a map makes erasure impossible to honor, which is itself a violation. Backups are the classic snag (you can't always surgically delete from an immutable backup — the accepted practice is documented suppression on restore).

Misconception to kill now. "We deleted the row." Erasure means all copies — replicas, caches, indexes, analytics, logs, backups, and processors — verifiably, within the deadline. A row delete that leaves the data in five other stores is not erasure.

Chapter 6: Cross-Border Transfer

The restriction. Many regimes restrict moving personal data across borders. GDPR permits transfer out of the EEA only with a safeguard: an adequacy decision (the destination country is deemed to protect data adequately), Standard Contractual Clauses (SCCs), Binding Corporate Rules, or specific derogations. Transferring EU personal data to a non-adequate country with no safeguard is unlawful (the Schrems II ruling tightened this and invalidated Privacy Shield).

Why an engineer cares. Data residency and transfer are architecture decisions: where your databases, replicas, CDNs, analytics, and SaaS processors physically run determines whether a transfer is occurring. "Our analytics processor stores EU users' data in a non-adequate region without SCCs" is a real finding (Lab 01) — and data localization requirements (some countries mandate in-country storage) constrain your deployment topology.

Misconception to kill now. "Data in the cloud has no location." It always has a physical region, and routing EU personal data to a non-adequate region without a safeguard is an unlawful transfer. Region and processor choice is a privacy control.

Chapter 7: De-identification — Anonymization vs Pseudonymization

The crucial distinction. Both reduce identifiability, but the legal and technical line is sharp:

  • Pseudonymization replaces identifiers with a token/key (e.g., a user_id instead of a name) but the mapping still exists somewhere, so the data can be re-linked. It is a strong security measure and reduces risk — but pseudonymized data is still personal data under GDPR (the obligations remain). Most "anonymized" datasets are really pseudonymized.
  • Anonymization irreversibly removes the ability to identify anyone, such that re-identification is not reasonably possible — then the data falls outside personal-data law. True anonymization is hard, because removing the obvious identifiers is not enough: quasi-identifiers remain.

The re-identification trap (why "we removed names" fails). Latanya Sweeney showed that ~87% of Americans are uniquely identified by just {ZIP code, birth date, sex} — none of which is a "name." She re-identified the Massachusetts governor's medical record from a "de-identified" release by joining it with voter rolls. Netflix and AOL "anonymized" datasets were re-identified the same way. So anonymization must address the combination of quasi-identifiers (Chapter 8), not just direct identifiers.

Misconception to kill now. "We removed the names, so it's anonymous." Removing direct identifiers leaves quasi-identifiers (ZIP, birthdate, sex, job title, timestamps) that uniquely fingerprint people when combined or joined with another dataset. "Anonymized" is a measured property (Chapter 8), not "we deleted the name column."

Chapter 8: k-Anonymity, l-Diversity, and Differential Privacy

k-anonymity — measuring re-identification risk. A dataset is k-anonymous (with respect to its quasi-identifiers) if every record is indistinguishable from at least k−1 others on those quasi-identifiers — i.e., the smallest equivalence class (group of records sharing the same quasi-identifier values) has size ≥ k. k = 1 means at least one person is unique and trivially re-identifiable; higher k means each person hides in a crowd of k. You achieve it by generalization (ZIP 02138 → 021**, age 37 → 30–40) and suppression (dropping outlier records). Computing the minimum equivalence-class size = the achieved k is exactly Lab 02.

l-diversity — k-anonymity's blind spot. k-anonymity hides who you are but not necessarily your sensitive value: if all k records in your group share the same diagnosis, an attacker who locates your group learns your diagnosis anyway (a homogeneity attack). l-diversity requires each equivalence class to contain at least l distinct sensitive values. (t-closeness refines this further.)

Differential privacy — the modern, rigorous answer. Instead of transforming a dataset, DP adds calibrated noise to query results / aggregates so that the output is provably almost the same whether or not any single individual is in the data (the privacy loss is bounded by a parameter ε — smaller ε = more privacy, more noise). It gives a mathematical guarantee that k-anonymity can't, and underlies modern releases (US Census 2020, Apple/Google telemetry). The tradeoff is the privacy/accuracy budget.

Misconception to kill now. "k-anonymity makes it safe." k-anonymity bounds identity disclosure but not attribute disclosure (homogeneity → use l-diversity) and degrades as more quasi-identifiers or auxiliary datasets are added; for strong guarantees over queries, differential privacy is the rigorous tool.

Chapter 9: Privacy by Design and the DPIA

Privacy by Design (PbD). Build privacy in from the start, not bolted on: minimize collection by default, default to the most private setting, be transparent, give users control, and secure the lifecycle. It's the privacy sibling of "shift left" (Phase 03) — the cheapest place to fix a privacy problem is the design review, before any personal data is collected.

The DPIA (Data Protection Impact Assessment). For high-risk processing (large-scale sensitive data, profiling, monitoring), GDPR requires a DPIA: describe the processing and purpose, assess necessity and proportionality, identify risks to individuals, and define mitigations — the privacy analog of the Phase 03 threat model, producing decisions and a residual-risk record (not a checkbox).

Misconception to kill now. "We'll do a privacy review before launch." Bolting privacy on at the end means re-architecting (you already collected too much, in the wrong region, with no deletion path). PbD and the DPIA move the decision to design time, where it's cheap.

Lab Walkthrough Guidance

Four labs turn privacy into runnable analysis (synthetic metadata):

  1. Lab 01 — PII Data-Flow Analyzer. Over data-flow records (field, category, purpose, lawful basis, retention, region, logged), flag over-collection (no purpose), no lawful basis, over-retention, PII in logs, and unsafe cross-border transfer (Chapters 2–6).
  2. Lab 02 — k-Anonymity / Re-identification Evaluator. Over a dataset's quasi-identifier rows, compute the achieved k (smallest equivalence class), rate re-identification risk, check an l-diversity condition on a sensitive attribute, and distinguish anonymization from pseudonymization (Chapters 7–8).
  3. Lab 03 — Differential Privacy. Implement the Laplace mechanism with count/bounded-sum sensitivity and clipping, an ε-budget with sequential composition, and randomized response — DP's per-query, auxiliary-data-proof guarantee (Chapter 8).
  4. Lab 04 — k-Anonymity Generalization. Achieve a target k by raising quasi-identifier generalization levels and suppressing residual small classes — the privacy/utility tradeoff in code (Chapters 7–8).
LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

  1. Explain security vs privacy and why an encrypted over-collection is still a violation.
  2. Classify data (PII/sensitive/PHI/PCI) and say what each triggers.
  3. Map a data flow and apply minimization and purpose limitation.
  4. Explain lawful basis, retention limits, and the DSAR/erasure engineering challenge.
  5. Explain cross-border transfer restrictions and why region/processor choice is a control.
  6. Distinguish anonymization from pseudonymization and explain the quasi-identifier re-identification trap.
  7. Compute k-anonymity, explain l-diversity's fix for homogeneity, and what differential privacy adds.

Common Mistakes

  • Equating "secure" with "private" (encrypted over-collection is still a privacy violation).
  • Collecting/retaining "just in case"; logging full PII; copying production PII to analytics/dev.
  • Repurposing data beyond its collected purpose; no lawful basis; no retention schedule.
  • "Deleting the row" but leaving copies in replicas/caches/indexes/analytics/backups/processors.
  • Transferring personal data to a non-adequate region without SCCs/adequacy.
  • Calling pseudonymized data "anonymous"; "we removed names" while quasi-identifiers re-identify people.
  • Trusting k-anonymity against attribute disclosure (homogeneity) or strong query privacy (use l-diversity / DP).

Interview Q&A

Q: What's the difference between security and privacy? A: Security keeps unauthorized parties out (CIA). Privacy governs authorized collection and use — should we hold this, for what purpose, how long, shared with whom, and can the person control it? You can be secure and still violate privacy by over-collecting, repurposing, over-retaining, or transferring data — so privacy adds minimization, purpose limitation, retention, subject rights, and de-identification on top of security.

Q: Anonymization vs pseudonymization — why does it matter? A: Pseudonymization swaps identifiers for tokens but the re-linking mapping still exists, so the data is still personal data (obligations remain) — a security measure, not an exit from the law. Anonymization irreversibly prevents re-identification, so the data leaves personal-data scope — but it's hard, because removing names leaves quasi-identifiers (ZIP+birthdate+sex uniquely identify ~87% of Americans) that re-identify by joining with other datasets. Most "anonymized" data is really pseudonymized.

Q: What is k-anonymity and its limitation? A: A dataset is k-anonymous on its quasi-identifiers if every record shares those values with at least k−1 others — the smallest equivalence class has size ≥ k, so each person hides among k. You achieve it by generalizing and suppressing. Its limit is attribute disclosure: if everyone in your group shares the sensitive value (homogeneity), the attacker learns it anyway — that's what l-diversity fixes, and differential privacy gives a rigorous bounded guarantee over query results.

Q: A user invokes their right to erasure. What does "delete me" actually require? A: Finding all of their data across every system — primary DB, replicas, caches, search indexes, analytics/warehouse, logs, backups, and third-party processors — and deleting (or documented-suppressing for immutable backups) within the legal deadline, with proof. It's only feasible if you have a data map (every field, where it lives, why) — which is why minimization and inventory are prerequisites, not afterthoughts.

References

  • GDPR (esp. Arts. 5, 6, 9, 17, 25, 35, Ch. V transfers); CCPA/CPRA; HIPAA; PCI DSS (Phase 15).
  • Sweeney, "k-Anonymity" and the Massachusetts re-identification; Machanavajjhala et al., "l-Diversity"; Dwork, "Differential Privacy"; the Netflix Prize and AOL re-identification cases.
  • NIST SP 800-122 (PII), NIST Privacy Framework; ENISA pseudonymization guidance; ISO/IEC 27701.
  • Phase cross-references: P00 (minimization/redaction), P02 (crypto), P15 (compliance as engineering).