Anonymization and Pseudonymization

Encryption at Rest and in Transit covered protecting data from someone who should never see it at all. This article covers a different problem: reducing what a value reveals even to someone who is authorized to query it.

The distinction that actually matters#

Pseudonymization replaces an identifying field with an artificial stand-in, kept reversible via a separately stored mapping: customer_id: 42 becomes customer_id: a1b2c3d4, recoverable by anyone with access to the lookup table connecting the two. Data anonymization removes identifying information with the intent that it can never be reversed, by anyone, under any circumstance.

Techniques for each#

Anonymization typically combines several approaches:

Generalization:  exact age 34 -> age bucket "30-39"Suppression:     drop a field entirely (a rare zip code that,                  combined with other fields, would re-identify someone)Perturbation:    add statistical noise to a value, preserving                  aggregate patterns while obscuring individual values

This is the same generalization logic behind k-anonymity — reducing precision until an individual record is indistinguishable from enough others that it can no longer be picked out.

Pseudonymization is usually simpler mechanically:

Tokenization:  replace the value with a random token,               store the mapping separately, access-controlledHashing:       deterministic function of the original value —               but see the caution below before trusting this alone

The hashing trap#

Hashing an identifier with a hash function looks like anonymization and frequently is not one. A hash of an email address or a phone number is deterministic — the same input always produces the same output — which means anyone who can guess or enumerate likely inputs can hash each guess and compare against the hashed value to reverse it:

Guessed inputs:         Hashed:"john@example.com"  ->  a3f5...  (matches the target hash — reversed)"jane@example.com"  ->  9c1e..."bob@example.com"    -> 7d42...

A phone number has only ten billion possible values — entirely enumerable on ordinary hardware in a short time. A hash is only meaningful protection when the input space itself is large and unguessable; for a small or structured input space, hashing without a per-value secret salt is closer to a lookup table than genuine anonymization.

Choosing between them#

Pseudonymization fits data still needed for legitimate operational or analytical use, where an authorized process occasionally needs to reverse it — a support agent looking up a masked customer by their real ID, with the mapping itself protected by Access Control Models. Anonymization fits data being published, shared externally, or retained past the point any legitimate use requires re-identification at all — public research datasets, aggregate analytics exports.

Common mistakes#

Treating a hash of a guessable value as anonymization#

Covered above — this is the single most common way teams believe they have anonymized data that a moderately motivated attacker can reverse in minutes.

Storing the pseudonymization mapping without strong access control#

A mapping table protected no more carefully than the pseudonymized data itself defeats the purpose entirely — the same mistake Encryption at Rest and in Transit warns about storing an encryption key alongside the data it protects.

Assuming anonymized data can never be re-identified, regardless of what else exists#

PII Classification and Sensitivity covers exactly this risk: an anonymized dataset combined with a separate, auxiliary dataset can still re-identify individuals, the same linkage attack behind Sweeney's original k-anonymity finding. Anonymization is a property of a dataset in isolation, not a permanent guarantee against every possible future combination.

Further reading#

• Data anonymization and Pseudonymization — full definitions of both techniques, including their regulatory treatment.
• K-anonymity — the formal model behind the generalization technique described above.
• Personal data — why pseudonymized data remains inside this category under GDPR.

See also#