Privacy Engineering — Tokenisation and k-Anonymity

Last updated: April 29, 2026

An Indian healthtech wanted to publish anonymised research data — patient records with names removed but dates, ages, PIN codes retained. The privacy engineer ran a re-identification analysis: 87% of records were uniquely identifiable from those three fields alone. Sweeney’s seminal research on US data showed similar; her techniques apply to Indian datasets. They didn’t publish. This module covers privacy engineering — the technical discipline of making data actually anonymous (or accepting that it isn’t).

What privacy engineering is

Privacy engineering is the technical practice of building systems that protect personal data by design. Beyond policy and consent — the actual data structures, algorithms, and architectures.

The anonymisation spectrum

Tokenisation

Replace sensitive identifier with a token. The token is meaningless without the mapping, which is held separately. Common for payment-card data (RBI tokenisation framework).

# Example: tokenise PAN (Permanent Account Number)
Original: AAAPL1234C
Token: TKN-7d8f9a2b-c1234

# Token vault stores mapping
# Application uses token; only specific privileged service can detokenise
# Token is reversible; "anonymisation" claim doesn't apply

k-anonymity in practice

k-anonymity ensures every record’s quasi-identifiers (attributes that, combined, could identify a person) match at least k-1 others. Implementation:

• Generalisation — DOB > year of birth; PIN > first 3 digits; age > 5-year band
• Suppression — remove records that are too unique

For typical use cases, k=5 or k=10 is the bar. Below k=5, re-identification is too easy.

Differential privacy

Mathematically rigorous: noise added to query results so that the presence or absence of any single record cannot be detected from output.

# Example: differentially-private count query
# True count: 1247 patients with diabetes
# Noise added (Laplace mechanism, epsilon=0.1):
# Returned count: 1252 (random small offset)
# Adversary cannot determine whether a specific patient is in dataset

# Tools: Google Differential Privacy library, OpenMined, IBM Diffprivlib

Used in Apple’s iOS telemetry, US Census 2020, various ML training pipelines.

Privacy-preserving ML

• Federated learning — model trained across distributed clients; only model updates aggregated, raw data never leaves clients
• Secure multi-party computation (MPC) — multiple parties jointly compute on data without revealing to each other
• Homomorphic encryption — computation on encrypted data; results decrypted only by data owner

Each is computationally expensive; appropriate for high-sensitivity use cases (banking analytics, healthcare research, government).

The healthtech case revisited

For their research-data publication, the engineer’s options:

• Generalise quasi-identifiers to achieve k=10 (year-of-birth instead of DOB; first 3 digits of PIN; 10-year age band) — preserves research value at acceptable privacy
• Differential privacy on aggregate queries — researchers query the dataset; noisy answers returned; raw records never exposed
• Synthetic data generation — generate statistically-similar synthetic dataset; researchers work on synthetic, not real
• Secure enclave hosting — researchers connect to controlled environment; cannot extract raw data, only summaries

They chose synthetic data + differential-privacy aggregate access. Research published; no individual identifiable.

Indian compliance mapping

• DPDP Act — anonymised data falls outside DPDP scope; if re-identifiable, full DPDP applies
• NIST Privacy Framework — referenced increasingly
• GDPR analogue — for Indian SaaS serving EU; same anonymisation standards
• RBI tokenisation framework — payment card data tokenisation mandate

Common mistakes

• “Anonymised” data with quasi-identifiers — easy to re-identify
• Static k-anonymity — appropriate when published, broken if combined with other datasets
• Differential privacy budget mismanaged — too many queries reduce privacy guarantee
• Synthetic data with same join keys — research utility lost

Try this in your organisation

1. Identify a dataset you treat as “anonymised”. List the quasi-identifiers.
2. Estimate k-anonymity: if you released this, how many people would be uniquely identifiable?
3. If >5%, the data is not anonymous — it is pseudonymous at best.
4. Privacy engineering converts this from policy claim to technical reality.

Privacy engineering matters because policy alone fails. “We anonymise data” is meaningless without the technical implementation. For Indian organisations under DPDP, the difference between anonymised (out of scope) and pseudonymised (in scope) is operationally significant.