Is pseudonymization reversible?

It often permits authorized attribution using additional information, although the exact mechanism varies.

Is a hashed email address always anonymous?

No. Predictability, matching attacks, and linked information can undermine that claim.

Can pseudonymization still be useful without guaranteeing anonymity?

Yes. It can limit routine exposure and reduce risk when combined with suitable controls and a clear purpose.

AI Glossary / Governance, ethics and safety / Intermediate

Pseudo-anonymization (pseudonymization)

Definition

Pseudonymization is processing that replaces or separates identifying information so that records cannot be attributed to a particular person without additional information, which is protected separately. The supplied term includes the informal wording pseudo-anonymization, but pseudonymization is the clearer established term. It reduces some identification risks while preserving useful relationships in data; it is not automatically anonymization.

What it means

A dataset may replace a customer's name with an artificial identifier so analysts can study repeated interactions without seeing the name. A separate mapping can reconnect the identifier to the person for an authorized purpose. That separation changes who can identify someone and under what conditions. It does not erase every identifying clue in the remaining data. Rare events, precise locations, or combinations of attributes can still reveal identity. The privacy assessment must therefore consider the whole dataset, available additional information, access arrangements, and likely recipients rather than only whether a name column was removed.

How it works

A pseudonymization design identifies the data and threat model, chooses a suitable transformation, and controls the additional information needed for attribution. Approaches can include managed random identifiers, tokenization, or appropriate cryptographic constructions. The design also decides whether the same person should have the same identifier across records or purposes. Stable identifiers enable linkage, which can be useful but can increase exposure. Separating a mapping in another worksheet is not meaningful protection if the same users can freely open it. Access restrictions, key management, logging, and data minimization are part of the safeguard, not optional decorations.

Three practical examples

A service-quality team studies repeat support contacts using protected customer tokens while a separate authorized function maintains identity mappings.
Researchers receive coded records with unnecessary direct identifiers removed and a controlled process for any permitted recontact.
A development team uses purpose-specific identifiers to reduce unnecessary linking between unrelated analytical datasets. These are design examples; whether a particular implementation adequately protects people requires a contextual assessment.

Think of it this way

Think of assigning participants numbered badges while keeping the attendance list in a controlled office. The badges let organizers connect activities without displaying everyone's name. The analogy is limited because people may still be recognizable from other details, and a stable badge can connect many activities over time. Pseudonymization therefore requires attention to both the key and the information left visible.

Worked example

Suppose three fictional support records belong to one person. Replacing the person's name with token T742 in all three records allows an analyst to count three contacts without receiving the name. A protected mapping links T742 to the customer account. If the analyst also receives an exact home address in each record, the token offers little protection against direct identification from that field. If the same token is reused in an unrelated purchase dataset, someone with both files can link the records even without learning the name. The example shows three separate properties: removal of one identifier, retention of within-dataset linkage, and possible cross-dataset linkage. None by itself establishes anonymity. Choosing separate purpose-specific tokens can reduce unnecessary linkage, but the remaining attributes and authorized workflows still require review.

Illustrative case study

Fictional case: Birch Analytics prepares customer-service data for model evaluation. Its first export removes names but retains account numbers and detailed free-text notes. Reviewers identify these as potential routes to identity and redesign the export, mapping access, and text handling. They describe the result as a risk-reduced analytical dataset rather than claiming that all privacy concerns have disappeared. This invented case illustrates why pseudonymization is a system of transformations and controls, not a single find-and-replace operation.

Common misconceptions and mistakes

Pseudonymized does not mean publicly shareable. Data that can be re-attributed remains subject to relevant personal-data considerations; precise legal classification can depend on context, including who holds the data and what identification means are available. Hashing is not an automatic anonymity guarantee. Predictable inputs can sometimes be guessed and hashed again, and other linked fields may identify people. Deleting a mapping also does not prove anonymity if other routes remain. Encryption, pseudonymization, and anonymization have different purposes and should not be used as interchangeable labels.

Business use

Specify the intended recipients, permitted linkage, and circumstances for any re-attribution. Keep mapping information or keys under appropriately separate controls and review access periodically. Minimize unnecessary identifiers and inspect free text and rare attribute combinations. Assess whether stable tokens are needed across time or systems. Test the design against plausible re-identification routes and document residual limitations. Plan retention and deletion across both transformed data and additional information. For regulated uses, obtain a context-specific legal assessment; applying a technical label does not determine compliance or remove all obligations.

Check your understanding

Names are replaced with tokens, but the mapping file is available to every analyst in the same folder. Has meaningful separation been established?

Answer: Not for those analysts. The design has changed the visible label while leaving straightforward attribution available. Access to the additional information needs appropriate control.

Related terms

Anonymization
De-identification
Tokenization
Personal data
Key management
encryption
re-identification
linkage risk
data minimization
purpose limitation

Learn next

Draw the transformed dataset, mapping information, and authorized users as separate boxes. Mark every possible linking path, including other attributes and datasets. Decide which links are needed and which can be removed or restricted, then document the remaining risks.

Sources

EDPB, anonymisation and pseudonymisation overview: https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en EDPS and AEPD, hash functions and identification-risk assessment: https://www.edps.europa.eu/data-protection/our-work/publications/papers/introduction-hash-function-personal-data EDPB, explanation of GDPR pseudonymisation definition: https://www.edpb.europa.eu/news/edpb-adopts-pseudonymisation-guidelines-and-paves-the-way-to-improve-cooperation-with_en

Previous: Pruning Next: Pseudocolumn