Anonymisation, pseudonymisation, differential privacy and the full PET toolbox — what each technique is, how they compare, and the exam traps that separate them.
Every technique in this module answers one question: how do we reduce the link between data and an identifiable individual, and what obligations remain after we do? The spectrum runs from fully identified data at one end to (ideally) irreversible anonymisation at the other — with pseudonymisation and the privacy-enhancing technologies in between.[AIGP BoK II.B]
De-identification is not one thing. It is a spectrum of techniques with different strengths, different re-identification risks, and — critically — different legal status. The exam tests whether you know exactly where each technique sits and what obligations survive it.[AIGP BoK II.B]
| Position | What it means | Legal status | Example |
|---|---|---|---|
| Identified data | Direct identifiers present (name, NRIC, email, phone) | Personal data — full regime applies | Customer CRM records |
| De-identified (generic term) | Direct identifiers removed or altered by any technique | Depends on the technique and residual risk — not automatically out of scope | Any dataset after an ID-stripping pass |
| Pseudonymised | Identifiers replaced with keys; re-linkage possible with the key | Still personal data — GDPR Art. 4(5); PDPA applies likewise[GDPR; EDPB 01/2025] | Research database keyed by patient ID held separately |
| Anonymised | Identifiers removed and re-identification reasonably prevented, irreversibly | Out of scope of GDPR/PDPA if genuinely achieved[GDPR R26; PDPC] | Aggregated statistics with no residual link |
The EDPB's Article 29 Working Party Opinion 05/2014 (still the standard reference) treats anonymisation as a result to be tested against three criteria, not a box to tick: singling out (can one individual be isolated in the dataset?), linkage (can two records about the same individual be connected?), and inference (can a value about an individual 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.
Connecting two or more records that belong to the same individual across tables or datasets.
Deducing an individual's attribute with significant probability from the remaining data.
Singapore's PDPC Guide to Basic Anonymisation (first published 2018, updated 2024) walks organisations through a 5-step anonymisation process: (1) identify direct and indirect identifiers, (2) apply de-identification techniques, (3) assess re-identification risk, (4) determine the residual risk of re-identification, and (5) decide on the appropriate data-sharing safeguards. PDPC also publishes a free Data Anonymisation Tool based on the guide.[PDPC 2024]
The PDPC's Advisory Guidelines on the PDPA for Selected Topics (revised 2024) clarify that data protection obligations continue to apply to anonymised data if re-identification remains reasonably possible — in practice, organisations are expected to assess residual risk rather than rely on the label "anonymised".[PDPC AG 2024]
Anonymisation techniques remove or distort the link between data and individuals. Each one 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.[WP29 05/2014; ISO 20889]
| Technique | What it does | Typical use | Key weakness |
|---|---|---|---|
| Aggregation | Combines records into groups and reports only group statistics (totals, averages) | Official statistics; research disclosures | Small group sizes still leak individuals; loses record-level detail[WP29; ISO 20889] |
| Generalisation (incl. banding / binning) | Broadens attribute values: exact age → age band; postcode → district; job title → industry sector | k-anonymity datasets; public health data | Reduces data precision; heavy generalisation can destroy analytical value[Sweeney 2002; PDPC] |
| Noise addition | Adds random perturbation to values so individual records are distorted but distributions survive | Statistical databases; location data | Deterministic attributes (age, gender) unaffected; can bias downstream analysis |
| Data swapping / permutation | Exchanges attribute values between records to break the record-to-person link | Census-style disclosure control | Original values may still appear in combination elsewhere; ordering attacks |
| Masking / redaction | Removes or blurs parts of values (e.g., NRIC S****123A; names → initials) | Screen redaction; test datasets | Partial identifiers often remain linkable — masking alone rarely anonymises |
| Hashing / keyed hashing | Replaces identifiers with hash digests; keyed hashing adds a secret so values can't be brute-forced | Joining datasets without exposing raw IDs | Unkeyed hashes of low-entropy values (names, NRICs) are trivially reversed[WP29] |
| k-anonymity (model) | Ensures every record is indistinguishable from at least k−1 others on quasi-identifiers | Published microdata | Fails on homogeneity and background-knowledge attacks (see l-diversity, t-closeness) |
k-anonymity (Sweeney, 2002): a dataset satisfies k-anonymity if every combination of quasi-identifiers (attributes like age, gender, postcode that can link back to a person) appears in at least k records. The classic failure: homogeneity attacks — if all k records share the same sensitive value (e.g., all 5 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): extends k-anonymity by requiring at least l "well-represented" distinct values for each sensitive attribute within each group — so a group can't be homogeneous on the sensitive value.[l-diversity 2007]
t-closeness (Li et al., 2007): goes further — the distribution of sensitive values in each group must be close (within distance t) to the distribution in the whole dataset. This 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[Sweeney 2002] |
| l-diversity | Each group has ≥ l distinct sensitive values | Homogeneity attack | Skewness attack — skewed global distribution defeats "distinctness"[l-diversity 2007] |
| t-closeness | Group distribution of sensitive values ≈ global distribution (within t) | Skewness attack | Utility loss; hard to tune t; not yet a formal privacy guarantee |
A hospital wants to publish a research table with columns Age band, District, Disease. Before k-anonymity, a row "34, Clementi, HIV+" with no other 34-year-old Clementi resident in the table is immediately linkable to exactly one person via the voter register.
If all 5 rows show HIV+, k-anonymity is satisfied but privacy is destroyed — the homogeneity attack. l-diversity would require ≥2 distinct diseases; t-closeness would require the group's disease mix to resemble the hospital's overall mix.[l-diversity; t-closeness]
Scenario: "the dataset satisfies k-anonymity but all records in a group share the same sensitive value" → the correct response is l-diversity (or t-closeness for skewness). Recognise the attack from the symptom description.
Pseudonymisation replaces direct identifiers with artificial identifiers (pseudonyms) so that data can no longer be attributed to a data subject without the use of additional information — which must be kept separately and subject to technical and organisational measures. 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 replaced by a random token stored in a secure mapping table (vault) | Reversible via the vault | Most common enterprise pattern; the vault is the risk point[EDPB 01/2025] |
| Encryption | Identifier encrypted with a key; ciphertext serves as pseudonym | Reversible with the key | Distinct from tokenisation: deterministic encryption allows matching across datasets — a feature and a risk |
| Keyed hash (HMAC) | Identifier hashed with a secret key; the digest is the pseudonym | Recomputable with the key | Without the key, low-entropy identifiers are brute-forceable; key management is everything[EDPB; WP29] |
| Random pseudonyms | Fully random replacement, no mathematical link to the original | Only via a separately kept mapping | Strongest form if the mapping is destroyed → becomes anonymisation |
The EDPB adopted Guidelines 01/2025 on Pseudonymisation on 16 January 2025 (public-consultation version). 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 technical and organisational measures protecting the key, the categories of persons with 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[GDPR; EDPB] | No, if genuinely achieved (high bar)[GDPR R26] |
| Role in law | Safeguard / security measure (Art. 32); data-minimisation support; lawful-basis enabler | Exit from the regime; enables free reuse and sharing |
| Re-identification risk | Controlled by key security — but the key-holder can always link | Residual risk from linkage/inference attacks; must be tested (motivated intruder) |
| Typical use | Analytics, research with follow-up, cross-dataset joins, test environments | Open-data publication, statistics, long-term archives |
Privacy-Enhancing Technologies (PETs) are the broader family: techniques and tools that minimise personal data use while preserving functionality. They range from the mathematical (differential privacy) to the architectural (federated learning, secure enclaves). The AIGP BoK groups them under data governance in the development lifecycle — expect scenario questions asking "which PET fits this constraint?"[AIGP BoK II.B; PDPC PET Guide]
| PET | What it does | Protects against | Key tradeoff / limitation | Flagship example |
|---|---|---|---|---|
| Differential privacy (DP) | Adds calibrated noise to queries or training so no single record materially changes outputs; governed by privacy budget ε | Membership inference; singling out; any individual-record disclosure | Privacy–utility tradeoff; ε is a policy choice; noisy small datasets are useless[Dwork 2006; BoK] | US Census Bureau 2020 disclosure avoidance |
| Federated learning (FL) | Training moves to the data; only model updates (gradients) leave devices/organisations | Centralisation of raw data; exfiltration of the corpus | Gradients can leak information (gradient-inversion attacks) — pair with DP and secure aggregation[McMahan 2017; BoK] | On-device keyboard prediction (Gboard) |
| Synthetic data | Generative models produce statistically similar artificial records; no direct 1:1 subject mapping | Re-identification of source subjects (if generation is sound) | Can memorise and regurgitate outliers; inherits source bias; utility varies by task[PDPC Synthetic] | Healthcare data-sharing pilots (e.g., UK NHS synthetic data initiatives) |
| Secure multi-party computation (SMPC) | Multiple parties compute jointly on their combined data; each learns only the result, never others' inputs | Disclosure of inputs during joint computation | Communication/compute overhead; party-collusion analysis; hard to scale[Yao 1982] | Cross-bank fraud-network detection without sharing customer data |
| Homomorphic encryption (HE) | Computation performed directly on encrypted data; result decrypts to the correct answer | Disclosure to the computing party (even if compromised) | High computational overhead; complex to implement correctly[Gentry 2009] | Encrypted analytics on cloud-hosted health data |
| Trusted execution environments (TEE / secure enclaves) | Hardware-isolated enclaves where code and data are protected even from the host OS | Host compromise; insider access to data in use | Hardware trust assumptions; side-channel attacks historically[IAPP; TEE] | Confidential computing on cloud platforms (SGX/SEV/Nitro) |
| Zero-knowledge proofs (ZKP) | Prove a statement is true (e.g., "age > 18") without revealing the underlying value | Over-disclosure of attributes during verification | Computational cost; narrower use cases (verification, not analytics) | Age-verification and credential attestation |
| Anonymisation / de-identification suite | The §2 techniques: aggregation, generalisation, noise, swapping, k-anonymity family | Direct identification in published data | Utility loss; residual linkage/inference risk (never zero)[WP29] | PDPC Data Anonymisation Tool |
| Pseudonymisation / tokenisation | Identifier replacement with separately held keys (§3) | Casual exposure of identifiers in analytics | Key-holder can always re-link; data remains in scope[GDPR; EDPB] | NHS England pseudonymisation service |
| Differential privacy | Federated learning | Synthetic data | |
|---|---|---|---|
| Core mechanism | Calibrated noise in outputs/training (formal ε guarantee) | Distributed training; only model updates travel | Generate artificial records from learned distributions |
| What it protects | Any single record's influence on results | Raw data staying at source | Direct subject mapping in released datasets |
| Primary weakness | Utility loss; ε is a value judgment[Dwork 2006] | Gradient leakage without DP/secure aggregation[McMahan 2017] | Memorisation of outliers; inherited bias[PDPC Synthetic] |
| Best-fit scenario | Statistical releases and queries over large datasets | Model training across devices/organisations | Testing, augmentation, dataset sharing |
A query is differentially private if its output distribution barely changes whether or not any single individual is in the dataset. Add the right amount of random noise and an attacker literally cannot tell if "your" record contributed — the strongest known defence against linkage and inference attacks.
ε bounds the information leaked per query. Lower ε = stronger privacy, noisier answers. Budgets accumulate across queries — run too many and the guarantee erodes. ε is set by the organisation; it is a policy decision, not a technical constant. Some systems also track a δ parameter for rare bad events.
Central DP: noise added by the trusted curator after collecting data (US Census 2020). Local DP: noise added on-device before anything leaves the user (Apple's keyboard/health analytics) — stronger protection, much noisier.
"A government wants to publish census statistics such that no individual's data can be inferred, with a tunable privacy guarantee" → differential privacy. "A hospital consortium wants to train a model without moving patient records" → federated learning (with DP as a complement).[Dwork 2006; US Census]
PDPC's proposed guide (2023) classifies synthetic data as a PET and walks through generation approaches — statistical models, generative models (GANs, diffusion), and agent-based simulation — plus the key governance steps: fidelity validation, re-identification risk assessment of the generator, and disclosure controls on the model itself.
"Synthetic data is always privacy-safe" → false. The safety depends on generator design, fidelity controls, and re-identification testing.[PDPC Synthetic 2023]
Every de-identification decision is a bet against re-identification. The exam wants you to recognise the four canonical attack classes and understand that residual risk is measured against a motivated intruder, not a casual browser.[WP29 05/2014; AIGP BoK II.B]
Joining a de-identified dataset with another source (voter register, social media, commercial data) on shared quasi-identifiers to re-identify records.
Example: the 1997 Weld medical-record case — birth date + ZIP + sex joined to the voter list.[Sweeney 2002]
Isolating one individual's record from a dataset even without a second source — unique attribute combinations make rows identifiable in isolation.
Countered by k-anonymity (group size ≥ k).[WP29]
Deducing a sensitive attribute with high probability from statistical or aggregate outputs — even when no record is directly exposed.
Membership inference against ML models is the modern form.[WP29; Shokri 2017]
Recovering identities behind pseudonyms — via the stolen key, brute-forcing weak hashes, or behavioural matching.
Why key management and unkeyed-hash prohibition are governance requirements.[EDPB 01/2025]
| Factor | Why it raises risk | Mitigation |
|---|---|---|
| Rare attribute combinations | Unique rows are singling-out bait | Generalisation; k-anonymity; suppression of small groups |
| Rich external data environments | More public datasets = more linkage fuel | Motivated-intruder test against current data landscape |
| Low-entropy identifiers (names, NRICs, dates) | Brute-forceable even when hashed unkeyed | Keyed HMAC; tokenisation; never publish unkeyed hashes[WP29] |
| Longitudinal data | Multiple releases about the same individuals multiply linkage surfaces | Consistent release policy; disclosure-control review per release |
| High-dimension data (location, text) | Location traces and free text are near-unique signatures | Spatial generalisation; differential privacy for queries; careful text handling |
| Key/mapping compromise | Pseudonymisation collapses instantly if the vault leaks | Separate storage, role-based access, audit logging, encryption at rest[EDPB 01/2025] |
"We hashed the NRICs, so the dataset is anonymous" → false: unkeyed hashing is not anonymisation, keyed hashing is pseudonymisation. Either way, obligations remain.[WP29; EDPB]
De-identification is not just a technical topic — every major regime has a position on it, and the exam tests where each regime draws its lines. Singapore and the EU agree on the core: pseudonymised = in scope, truly anonymised = out.[GDPR; PDPA; EU AI Act]
| Regime | Position on anonymisation | Position on pseudonymisation | Key instrument |
|---|---|---|---|
| EU GDPR | Recital 26: principles don't apply to anonymous info; bar is "reasonably likely means" of re-identification | Art. 4(5) definition; Art. 32 security measure; EDPB 01/2025 guidance | GDPR Art. 4(5), Art. 32, Recital 26[GDPR] |
| Singapore PDPA | PDPC Guide to Basic Anonymisation: 5-step process; obligations persist if re-identification reasonably possible | Not a defined term in the Act; treated as a safeguard — data remains personal data | PDPC Guide to Basic Anonymisation (2024); Advisory Guidelines for Selected Topics[PDPC] |
| EU AI Act | Art. 10(5): special-category data for bias detection/monitoring in high-risk systems may be processed "subject to appropriate safeguards for the fundamental rights and freedoms" — including technical measures such as pseudonymisation | Art. 10(5) explicitly names pseudonymisation among permitted safeguards; Art. 10(3) requires special-category processing "strictly necessary" and "appropriate safeguards" | EU AI Act Art. 10(3), (5)[EU AI Act] |
| ISO/IEC 27559:2022 | Framework for de-identification: risk assessment, governance, and lifecycle management of de-identified data | Complements 27559 with the de-identification technique catalogue in ISO/IEC 20889:2018 | ISO/IEC 27559:2022; ISO/IEC 20889:2018[ISO 27559; ISO 20889] |
| EU AI Act (data governance for high-risk AI) | Anonymisation listed among techniques relevant to training-data governance | — | EU AI Act Art. 10(2)(b) (training data governance practices incl. de-biasing) |
| Consequence | Pseudonymised (in scope) | Anonymised (out of scope) |
|---|---|---|
| Lawful basis needed? | Yes — consent, legitimate interests, business improvement, etc. | No |
| Purpose limitation applies? | Yes — repurposing requires a new/compatible basis | No — free reuse, sharing, sale |
| Data-subject rights (access, erasure)? | Yes — and the controller must be able to link data to the subject (or justify why not) | No — no identifiable subject exists |
| Breach notification? | Yes, if a breach compromises the data/key | Generally no |
| DPIA trigger reduction? | Pseudonymisation reduces risk and can lower DPIA scope — but doesn't eliminate the need | N/A — out of the data-protection analysis entirely |
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)[GDPR] |
| Legal effect | Exits the regime | Safeguard; risk reduction; remains regulated |
| How to prove | Motivated intruder test / WP29 criteria | Key-security documentation and access control[EDPB] |
| 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[AIGP BoK II.B] |
| 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))[EU AI Act] |
| Exam significance | Baseline duties | Higher bar; pseudonymisation named as an enabling safeguard |
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.
Instant feedback per question; score tallied at the bottom. Best score persists in this browser via localStorage.