Pseudonymisation versus anonymisation as engineering techniques

What it is

Pseudonymisation replaces direct identifiers with tokens while keeping a way back: a lookup table, or a keyed function such as HMAC (RFC 2104 specifies HMAC as keyed-hashing for message authentication; the property relied on here, a consequence of the key, is that without it the mapping cannot be recomputed from candidate inputs). The data stays one record per person and can be re-linked by whoever holds the key or table. Anonymisation aims to remove the association between records and people so that nobody can restore it. NIST SP 800-188 describes de-identification as any process of removing the association between identifying data and the data subject, lists the techniques as removing identifiers, transforming quasi-identifiers and generating synthetic data, and names re-identification studies as a way to gauge the risk that remains.

Why it matters

The two are often confused, and the confusion is expensive in one direction: treating pseudonymised data as anonymous. A pseudonymised dataset still has one row per person, still carries quasi-identifiers (dates, locations, rare values) and can be linked to other data. Which label applies determines which protections the system is expected to give the data; renaming a column does not change it.

How to apply

• For pseudonyms use HMAC with a secret key, not a plain hash: a plain hash of an email address or phone number is reversed by hashing candidates. Keep the key in the secrets store, plan re-keying before rotation, and record which datasets use which key.
• Use a separate key per purpose so that two datasets cannot be joined on the pseudonym unless that is intended.
• For releases, prefer aggregates: counts and sums over groups with a minimum group size, small cells suppressed, quasi-identifiers coarsened (age bands, regions, months) before release, and a documented check of disclosure risk as NIST SP 800-188 describes.
• For analysis that needs record-level data, keep it pseudonymised inside an access-controlled environment rather than releasing an extract labelled anonymised.
• Document per dataset which technique was applied, which fields remain, and who holds the means of re-identification.

Pitfalls

Unkeyed hashes; sequential pseudonyms that reveal order of arrival; pseudonyms reused across purposes; free-text fields left in an otherwise pseudonymised table; names removed but exact timestamps and coordinates kept. Believing that aggregation alone anonymises: repeated queries with slightly different filters can isolate one person by differencing, which is the problem differential privacy was designed to address.