Anonymisation, pseudonymisation, differential privacy and the whole PET toolbox — taught the way the exam tests it: by what survives, what falls away, and where the golden line sits.
De-identification is a spectrum, not a switch. Drag the slider and watch the legal status change as the link to the individual weakens. The golden line in the middle is the single most-tested boundary in this domain.
The EDPB's Article 29 Working Party Opinion 05/2014 treats anonymisation as a result to be tested against three criteria, not a box to tick: singling out (can one individual be isolated?), linkage (can two records about the same person be connected?), and inference (can an attribute be deduced with significant probability?). If any criterion is reasonably achievable, the data is not truly anonymised.[WP29 05/2014]
Isolating one individual's record from the crowd — e.g., a row that is unique in the dataset. Countered by k-anonymity-style generalisation.
Connecting two or more records that belong to the same individual across tables or datasets. The Weld case and the AOL scandal both died here.
Deducing an individual's attribute with significant probability from remaining data — the modern form is membership inference against ML models.
In 1997, Massachusetts Governor William Weld's medical records were re-identified from "anonymised" insurance data using just three quasi-identifiers: birth date, ZIP code and sex. This lab rebuilds that attack. Toggle the protections and watch the rows light up.
| Age | District | Sex | Diagnosis |
|---|
| Age | District | Sex | Name |
|---|---|---|---|
| 34 | Clementi | M | Weld, W. |
| 38 | Clementi | M | Tan, K. |
| 31 | West Coast | F | Lim, S. |
| 36 | Jurong | M | Ng, B. |
| 33 | Clementi | F | Ong, M. |
| 39 | Bukit Batok | M | Goh, T. |
k-anonymity (Sweeney, 2002): every combination of quasi-identifiers appears in at least k records. The classic failure: homogeneity attacks — if all k records share the same sensitive value (e.g., all 3 people in a group have the same disease), knowing someone is in the group reveals the disease.[Sweeney 2002]
l-diversity (Machanavajjhala et al., 2007): requires at least l distinct sensitive values per group — blocks homogeneity.[l-diversity 2007]
t-closeness (Li et al., 2007): the group's sensitive-value distribution must sit within distance t of the whole dataset's — blocks skewness attacks, which l-diversity misses when the global distribution is itself skewed.[t-closeness 2007]
| Model | Guarantee | Attack it blocks | Limitation |
|---|---|---|---|
| k-anonymity | Each quasi-identifier group has ≥ k records | Record linkage / singling out | Homogeneity attack — group can share one sensitive value |
| l-diversity | Each group has ≥ l distinct sensitive values | Homogeneity attack | Skewness attack — skewed global distribution defeats "distinctness" |
| t-closeness | Group distribution ≈ global distribution (within t) | Skewness attack | Utility loss; hard to tune t; not a formal privacy guarantee |
Seven techniques, one goal: break the link to the individual. Each trades utility against residual risk — and none is a silver bullet. The exam wants you to recognise the technique from a description and know its weakness.
| Technique | What it does | Typical use | Key weakness |
|---|---|---|---|
| Aggregation | Combines records into groups; reports only group statistics | Official statistics; research disclosures | Small groups still leak individuals; loses record-level detail |
| Generalisation (banding) | Broadens values: age → age band; postcode → district | k-anonymity datasets; public health | Reduces precision; heavy generalisation destroys analytical value |
| Noise addition | Random perturbation so records distort but distributions survive | Statistical databases; location data | Deterministic attributes unaffected; can bias analysis |
| Data swapping | Exchanges attribute values between records | Census-style disclosure control | Original values reappear in combination; ordering attacks |
| Masking / redaction | Blurs parts of values (NRIC S****123A) | Screen redaction; test datasets | Partial identifiers often remain linkable — rarely anonymises alone |
| Hashing / keyed hashing | Replaces identifiers with digests; keyed adds a secret | Joining datasets without exposing raw IDs | Unkeyed hashes of low-entropy values are trivially reversed |
| k-anonymity (model) | Every record indistinguishable from ≥ k−1 others on quasi-identifiers | Published microdata | Fails on homogeneity and background-knowledge attacks |
PDPC's Guide to Basic Anonymisation (updated 2024) walks organisations through a 5-step process: (1) identify direct and indirect identifiers, (2) apply de-identification techniques, (3) assess re-identification risk, (4) determine residual risk, (5) decide on safeguards. PDPC also publishes a free Data Anonymisation Tool. The Advisory Guidelines (revised 2024) clarify that obligations persist where re-identification remains reasonably possible — the label "anonymised" is never enough.[PDPC 2024]
Click a card to flip. Each back face carries a definition plus an exam tip. Shuffle order in your head, not the deck — spaced repetition beats novelty tonight.
Pseudonymisation replaces direct identifiers with artificial identifiers so data can no longer be attributed to a data subject without the use of additional information — which must be kept separately and protected. That last clause is the whole exam: the key exists, so the link survives, so the data stays personal.[GDPR Art. 4(5); EDPB 01/2025]
| Technique | How it works | Reversibility | Exam note |
|---|---|---|---|
| Tokenisation | Identifier → random token in a secure mapping vault | Reversible via the vault | Most common enterprise pattern; the vault is the risk point |
| Encryption | Identifier encrypted; ciphertext is the pseudonym | Reversible with the key | Deterministic encryption allows matching across datasets — feature and risk |
| Keyed hash (HMAC) | Identifier hashed with a secret key | Recomputable with the key | Key management is everything; unkeyed = broken |
| Random pseudonyms | Fully random replacement, no mathematical link | Only via separately kept mapping | Destroy the mapping → becomes anonymisation |
The EDPB adopted Guidelines 01/2025 on Pseudonymisation on 16 January 2025. Key exam-relevant positions:[EDPB 01/2025]
Reiterated emphatically: pseudonymised data is personal data for any controller or processor holding the means of attribution, and remains in scope of GDPR (and by analogy PDPA).
Framed as a security and data-minimisation measure (Art. 32 and data-protection-by-design), not an exemption. It supports legitimate-interest balancing and compatible-purpose analysis.
Controllers must document the measures protecting the key, who has access, and the residual re-identification risk — the audit trail is what regulators will ask for.
Pseudonymising with the same key across datasets still permits linkage by the key-holder — a common mistake in research consortia and a documented exam scenario.
| Pseudonymisation | Anonymisation | |
|---|---|---|
| Reversible? | Yes — via separately held key/mapping | No — link destroyed irreversibly |
| Still personal data? | Yes — GDPR Art. 4(5); PDPA applies | No, if genuinely achieved (high bar) |
| Role in law | Safeguard / security measure (Art. 32); data-minimisation support | Exit from the regime; free reuse and sharing |
| Re-identification risk | Controlled by key security — but the key-holder can always link | Residual risk from linkage/inference; must be tested (motivated intruder) |
| Typical use | Analytics, research with follow-up, cross-dataset joins, test environments | Open-data publication, statistics, long-term archives |
PETs are the broader family: techniques that minimise personal data use while preserving functionality. From the mathematical (differential privacy) to the architectural (federated learning, secure enclaves). Expect scenario questions asking "which PET fits this constraint?"[AIGP BoK II.B; PDPC PET Guide 2023]
| PET | What it does | Protects against | Key tradeoff | Flagship example |
|---|---|---|---|---|
| Differential privacy (DP) | Adds calibrated noise so no single record materially changes outputs; governed by budget ε | Membership inference; singling out | Privacy–utility tradeoff; ε is a policy choice | US Census Bureau 2020 |
| Federated learning (FL) | Training moves to the data; only model updates leave devices | Centralisation of raw data | Gradients can leak — pair with DP + secure aggregation | On-device keyboard prediction (Gboard) |
| Synthetic data | Generative models produce statistically similar artificial records | Re-identification of source subjects | Can memorise outliers; inherits source bias | NHS synthetic data pilots |
| Secure multi-party computation (SMPC) | Parties compute jointly; each learns only the result | Disclosure of inputs during joint computation | Communication overhead; collusion analysis | Cross-bank fraud detection |
| Homomorphic encryption (HE) | Computation on encrypted data; result decrypts correctly | Disclosure to the computing party | High computational overhead | Encrypted cloud health analytics |
| Trusted execution environments (TEE) | Hardware-isolated enclaves; data protected even from host OS | Host compromise; insider access | Hardware trust assumptions; side channels | Confidential computing (SGX/SEV/Nitro) |
| Zero-knowledge proofs (ZKP) | Prove a statement ("age > 18") without revealing the value | Over-disclosure during verification | Computational cost; narrow use cases | Age verification, credential attestation |
| Anonymisation suite | §3 techniques: aggregation, generalisation, noise, k-anonymity family | Direct identification in published data | Utility loss; residual risk never zero | PDPC Data Anonymisation Tool |
| Pseudonymisation / tokenisation | Identifier replacement with separately held keys (§4) | Casual exposure of identifiers | Key-holder can always re-link; data stays in scope | NHS England pseudonymisation service |
No → keep raw data local: federated learning or secure enclaves so only outputs/updates move.
Yes → SMPC (joint compute, no input sharing) or HE (compute on encrypted data by an untrusted party).
Yes → differential privacy with documented ε. No → de-identification suite may suffice, but residual risk must still be assessed.
Yes → synthetic data for testing, augmentation, sharing. Verify fidelity per task — synthetic ≠ real for every use.
Yes → zero-knowledge proofs for attribute verification without revealing the value.
| Differential privacy | Federated learning | Synthetic data | |
|---|---|---|---|
| Core mechanism | Calibrated noise (formal ε guarantee) | Distributed training; only updates travel | Generate artificial records from distributions |
| What it protects | Any single record's influence on results | Raw data staying at source | Direct subject mapping in released data |
| Primary weakness | Utility loss; ε is a value judgment | Gradient leakage without DP/secure aggregation | Memorisation of outliers; inherited bias |
| Best-fit scenario | Statistical releases over large datasets | Model training across devices/organisations | Testing, augmentation, dataset sharing |
Five pairs the exam loves to blur. If you can fill these from memory, this domain is yours.
| Anonymisation | Pseudonymisation | |
|---|---|---|
| Reversible? | No — link destroyed | Yes — via separately held key |
| Still personal data? | No, if genuinely achieved | Yes — GDPR Art. 4(5) |
| Legal effect | Exits the regime | Safeguard; risk reduction; remains regulated |
| How to prove | Motivated intruder test / WP29 criteria | Key-security documentation and access control |
| Differential privacy | Federated learning | |
|---|---|---|
| Protects against | Individual-record influence on outputs (formal ε guarantee) | Centralisation / movement of raw data |
| Mechanism | Calibrated noise in queries or training | Distributed training; only updates shared |
| Key weakness | Utility loss; ε is a policy tradeoff | Gradient leakage; no formal guarantee alone |
| Flagship example | US Census 2020 disclosure avoidance | On-device keyboard prediction (Gboard) |
| k-anonymity | l-diversity | t-closeness | |
|---|---|---|---|
| Requirement | ≥ k records per quasi-identifier group | ≥ l distinct sensitive values per group | Group sensitive distribution within t of global |
| Blocks | Singling out / record linkage | Homogeneity attack | Skewness attack |
| Fails against | Homogeneity; background knowledge | Skewness; background knowledge | Background-knowledge extremes (partial) |
| Citation | Sweeney 2002 | Machanavajjhala 2007 | Li, Kifer, Machanavajjhala 2007 |
| SMPC | Homomorphic encryption | |
|---|---|---|
| Model | Parties jointly compute; each holds a share of the result | One party computes over encrypted data with the key held elsewhere |
| Data stays | Distributed among parties (secret-shared) | Encrypted at the computing party |
| Best for | Joint analytics without sharing inputs | Outsourced computation (cloud) on sensitive data |
| Overhead | Communication rounds | Computation cost |
| Personal data | Special-category / sensitive data | |
|---|---|---|
| GDPR regime | Art. 6 lawful basis | Art. 9 conditions (plus Art. 6) |
| Examples | Name, contact, location, IDs | Health, race/ethnicity, biometrics, religion, sexual orientation |
| AI Act hook | General training-data governance (Art. 10(2)) | Bias detection exception with safeguards incl. pseudonymisation (Art. 10(5)) |
| Exam significance | Baseline duties | Higher bar; pseudonymisation named as an enabling safeguard |
Six real exam-style scenarios. Choose the best-fitting technique — instant feedback, score at the end. This is the closest thing to the actual scenario questions.
TRUE / FALSE — instant feedback per question, score tallied at the bottom. Best score persists in this browser.
Tap each item as you master it. The goal: fill every box from memory, not recognition.