Pseudonymization is the processing of personal data so that it can no longer be attributed to a specific person without additional information, provided that this additional information is kept separately and protected by technical and organizational measures. In privacy engineering, it is a core safeguard that lowers risk while keeping data useful for analysis, testing and linking records over time.
The decisive point is that pseudonymized data remains personal data. Whoever holds the key or the lookup table can reverse the process, so the GDPR treats pseudonymization as a risk-reduction measure, not as a way to leave data protection law behind.
How pseudonymization works
Pseudonymization replaces direct identifiers, such as names, email addresses or national ID numbers, with pseudonyms: values that carry no meaning on their own. The link between pseudonym and identity is stored in a separate mapping table or derived from a secret key, and only authorized parties can use it.
A typical pipeline has four steps: identify which fields are direct identifiers, choose a pseudonym generation method, separate the re-identification secret from the data set and control who can access that secret. Indirect identifiers such as birth date, postcode and job title usually stay in the data, which is why re-identification risk does not fall to zero.
The table summarizes the main techniques for generating pseudonyms.
| Technique | How it works | Reversible by | Main risk |
|---|---|---|---|
| Lookup table | Random value stored next to each identity | Holder of the table | Table leakage |
| Keyed hash (HMAC) | Hash of identifier with a secret key | Holder of the key, by recomputation | Key leakage or reuse |
| Plain hash | Hash without a secret | Anyone who can guess inputs | Dictionary attacks on small input spaces |
| Deterministic encryption | Identifier encrypted with a fixed key | Key holder, by decryption | Key management failure |
| Tokenization | Vault issues tokens for values | Token vault operator | Vault compromise |
A plain hash of an email address or phone number is weak pseudonymization. The input space is small and structured, so an attacker can hash candidate values and match them. A keyed hash with a secret of at least 256 bits stored outside the data environment is the usual minimum.
Deterministic and randomized pseudonyms
The choice between deterministic and randomized pseudonyms depends on whether records must be linked. Deterministic schemes always map the same person to the same pseudonym, which enables joins and longitudinal studies but also makes linkage attacks easier.
| Scope | Same person gets | Benefit | Drawback |
|---|---|---|---|
| Global deterministic | One pseudonym everywhere | Easy linking across data sets | Highest linkage risk |
| Domain-specific | Different pseudonym per data set or recipient | Limits cross-recipient linking | Joins need the key holder |
| Per-record random | New pseudonym each time | Strong unlinkability | No longitudinal analysis |
Domain-specific pseudonyms are a good default when data is shared with several external recipients: each recipient sees a different value for the same person, so two recipients cannot simply merge their copies.
Pseudonymization compared with anonymization and masking
Pseudonymization is often confused with anonymization, but the legal and technical consequences differ sharply. Anonymization is irreversible for anyone using reasonably likely means, while pseudonymization is reversible by design.
| Technique | Reversible | Still personal data | Typical purpose |
|---|---|---|---|
| Pseudonymization | Yes, with separate information | Yes | Analytics, research, internal sharing |
| Anonymization | No | No | Open data, statistics |
| Data masking | Usually no | Often yes, depending on residual data | Test environments, screen display |
| Differential privacy | Not applicable, adds noise to outputs | Outputs usually not | Aggregate statistics with formal guarantees |
In practice, these techniques are combined rather than chosen exclusively. A research data set might be pseudonymized for linkage, generalized to reduce indirect identifiers and released only as differentially private aggregates.
Why pseudonymization matters under the GDPR
The GDPR names pseudonymization explicitly as a measure for data protection by design in Article 25 and for security of processing in Article 32. It can support a finding that further processing is compatible with the original purpose, and it is an expected safeguard for scientific research and statistics.
Pseudonymization also reduces the impact of a breach. If attackers obtain a pseudonymized data set without the key, the risk to individuals is lower, which affects the breach assessment. It does not, however, remove the duty to provide data subject rights, keep records or rely on a legal basis.
Common pitfalls in pseudonymization
Most failures come from weak separation or from underestimating indirect identifiers. The following table lists typical problems.
| Pitfall | Effect | Remedy |
|---|---|---|
| Key stored in the same database | Separation exists only on paper | Keep keys in a separate vault with own access control |
| Unsalted hashes of emails | Easy re-identification by guessing | Use a keyed hash with a strong secret |
| Rare attribute combinations kept | Individuals singled out | Generalize or suppress quasi-identifiers |
| Free-text fields left untouched | Names hidden in comments | Scan and redact unstructured text |
| Data labeled anonymous | Rights and obligations ignored | Treat output as personal data |
The short version
Pseudonymization means swapping a person’s name for a code so that people working with the data do not see who it is about. The key that turns the code back into a name is locked away somewhere else.
It is like a cloakroom where coats are stored under numbers. The staff handling the coats do not know whose coat is whose, but the ticket list still exists. Because someone can always match the numbers back to people, the information is still treated as personal and must still be protected.
Where it makes a difference
A hospital network wants to study readmission rates across five sites with an external university team. Instead of exporting patient records, the data office replaces each patient number with a keyed hash generated with a secret held only by the hospital’s information security unit.
Names, addresses and phone numbers are removed, birth dates are reduced to the year of birth and postcodes to the first two characters. The researchers receive a data set in which the same patient keeps the same pseudonym across admissions, so readmissions can be counted without anyone outside the hospital knowing who the patients are.
When the study finds a group at unusually high risk, the hospital uses its key to identify those patients internally and invite them to a follow-up program. The university never gains the ability to re-identify anyone, and the agreement treats the shared data as personal data with strict access rules.