Privacy Engineering — A Module
What this is. Privacy as an engineering discipline, not a legal afterthought: data classification and inventory, data-flow mapping and minimization, lawful basis and purpose limitation, retention and deletion (DSARs / right-to-erasure), cross-border transfer, de-identification (anonymization vs pseudonymization, k-anonymity, differential privacy), and Privacy by Design. It turns GDPR/CCPA-style requirements into tested controls over data flows — the same "compliance as engineering" stance as Phase 15, applied to personal data.
Why it's its own module. Security protects data from unauthorized access; privacy governs authorized collection and use — should we hold this, for what purpose, how long, and can it be re-identified? Those are distinct questions with their own failure modes (over-collection, purpose creep, weak anonymization, illegal transfer) that the security phases don't cover.
Prerequisites. Phase 00 (data minimization, redaction), Phase 02 (crypto), Phase 15 (compliance as engineering). Everything is offline and reasons over data-flow and dataset metadata — no real personal data.
Learning Objectives
By the end you can, without notes:
- Distinguish security vs privacy, and PII / sensitive PII / PHI / PCI and the obligations each triggers.
- Map a data flow (collection → processing → storage → sharing → deletion) and apply data minimization and purpose limitation.
- Explain lawful basis, retention limits, and DSAR / right-to-erasure, and detect violations (over-collection, over-retention, no lawful basis).
- Reason about cross-border transfer restrictions (adequacy / safeguards).
- Distinguish anonymization vs pseudonymization and measure re-identification risk with k-anonymity (and the ideas of l-diversity and differential privacy).
- Apply Privacy by Design and DPIA thinking to a feature before it ships.
The privacy lens (read the WARMUP)
SECURITY asks: can an UNAUTHORIZED party access this data?
PRIVACY asks: should we hold it at all? for what purpose? how long? can it be re-identified?
collect minimum -> bind to a purpose -> retain briefly -> delete on request -> de-identify well
See WARMUP.md for the full from-zero treatment.
Labs
| Lab | Builds | Focus |
|---|---|---|
| Lab 01 — PII Data-Flow Analyzer | flag over-collection, no lawful basis, over-retention, PII in logs, unsafe cross-border transfer | governance |
| Lab 02 — k-Anonymity / Re-identification Evaluator | compute k-anonymity over quasi-identifiers; rate re-identification risk; anonymization vs pseudonymization | de-identification |
| Lab 03 — Differential Privacy | Laplace mechanism, sensitivity, ε-budget composition, randomized response | de-identification |
| Lab 04 — k-Anonymity Generalization | achieve a target k by hierarchical generalization + suppression | de-identification |
Pure Python (stdlib + pytest), lab.py/solution.py/test_lab.py/README.md each.
cd lab-02-k-anonymity-evaluator
LAB_MODULE=solution pytest -q
pytest -q
Safety
Offline; the labs reason over synthetic data-flow records and a synthetic dataset's quasi-identifiers. No real personal data, and the de-identification lab demonstrates measuring re-identification risk to prevent it (Phase 00 minimization).