Pseudonymisation vs anonymisation: decide whether the identity link survives
A practical GDPR guide to telling pseudonymised personal data from anonymous information, testing identifiability, choosing controls, and recording the decision.
A product team has removed names and email addresses from a customer dataset. The remaining rows contain a customer number, purchase history, approximate location, and dates. The team wants to send the file to an analyst and call it anonymous.
The first question is simpler than the team's spreadsheet: does anyone still have a reasonably likely way to connect a row to a person? If the answer is yes, the data remains personal data for that person or organisation. The right label is usually pseudonymised data, not anonymous data.
That distinction decides what happens next. Pseudonymisation reduces the risk of using personal data while preserving a controlled identity link. Anonymisation is a documented conclusion that people are no longer identifiable in the relevant circumstances. One is a security and privacy control inside the data-protection perimeter; the other can move the resulting information outside it once the legal threshold is met.
Start with the identity link
The GDPR gives pseudonymisation a precise meaning. It is processing personal data so that the data can no longer be attributed to a specific person without additional information, provided that the additional information is kept separately and protected by technical and organisational measures. 1
A token, key, lookup table, salt, or protected source database can be that additional information. If it can reconnect the record to a person, the connection has been controlled, not destroyed.
Anonymisation has a different endpoint. Recital 26 describes anonymous information as information that does not relate to an identified or identifiable person, including personal data rendered anonymous so that the person is no longer identifiable. The test considers all means reasonably likely to be used, including the cost and time required for identification, available technology, and technological developments. 1
That gives a practical rule:
- Pseudonymisation: the organisation keeps or can obtain an identity link, so the data remains personal data in the relevant hands.
- Anonymisation: the identity link and other reasonably likely routes to identification have been removed or made sufficiently remote for the relevant recipient and context.
The words "de-identified" and "anonymous" do not settle the question. They describe a result only when the organisation can explain what information was changed, which means of identification were considered, and why those means are no longer reasonably likely.
What pseudonymisation is for
Pseudonymisation is useful when the work needs data about the same person across records but does not need the person's name at every step.
A loyalty programme might replace a customer's name with a random token in an analytics environment. The business can calculate repeat purchases and product preferences without placing names in every query. A separate service can hold the mapping between the token and the customer account for tasks such as correcting an account, responding to a rights request, or investigating a fraud alert.
The identity link still exists. That is the point: the organisation has traded routine exposure for controlled re-linking.
The ICO describes this as risk reduction and improved security, rather than a way to make the law stop applying. It also says pseudonymisation can support data protection by design, general analysis, research, and some compatible further processing, but it does not automatically make a new purpose lawful. 2
That makes pseudonymisation a design decision with two parts:
- Reduce ordinary exposure. Most analysts, developers, and support staff work with a token rather than a direct identifier.
- Control exceptional re-linking. A smaller, authorised group can use the additional information for a defined reason, under stronger controls.
The GDPR expressly recognises pseudonymisation as a measure that can reduce risks to data subjects. Article 32 also lists pseudonymisation and encryption among examples of measures that may be appropriate to the risk. Neither reference turns pseudonymisation into a safe harbour: the organisation still has to assess the processing, choose proportionate measures, and demonstrate compliance. 1
Why removing names proves very little
Identifiability is wider than knowing a person's name. A person can be distinguished from others by a combination of attributes: a rare age range, a small location, a distinctive purchase, an unusual date, or a sequence of events. The ICO treats singling out and linkability as central indicators. A person may be identifiable even when the dataset does not contain a direct identifier. 3
Consider a dataset with these fields:
- age band: 60–69;
- postcode district: one small rural area;
- treatment month: February 2026;
- treatment type: a rare procedure; and
- a free-text note describing an unusual incident.
Deleting the name does not prevent a local colleague, a journalist, or a recipient with another dataset from isolating the row. The row may be unique even if every individual field appears harmless.
The same problem appears in ordinary product data. A table containing a device identifier, precise timestamps, and a sequence of locations may identify a person through another service's logs or public posts. A stable hash of an email address can make the value look opaque while still allowing matching against a guessed or known list of email addresses. A token that appears in several systems can make records easier to link, which may be exactly what the analyst needs and exactly why the data remains personal.
The ICO calls this the mosaic or jigsaw effect: separate pieces of data may identify someone when combined. Its guidance also warns that an inference about an identifiable person can itself be personal data. 3
The same dataset can have different status in different hands
The question "is this anonymous?" is incomplete until the organisation names the relevant perspective.
Suppose a retailer creates a tokenised purchase dataset. The retailer keeps the mapping table in a separate identity service. For the retailer, the dataset is personal data: the organisation has a means of reconnecting the token to the customer. An independent recipient may have no access to the mapping table and no reasonably likely way to obtain it. The information may be anonymous in that recipient's hands, depending on what else the recipient can access.
The EDPB's Guidelines 02/2026 on Anonymisation, adopted on 7 July 2026 for public consultation, makes this perspective explicit. It says the assessment should consider each relevant entity's capabilities and offers three technical criteria: No Record Isolation, No Linkage, and No Inference. It also explains that means may include access through another party when that chain of access is reasonably likely. 4
This is not a licence to treat a processor as a separate anonymous-data environment. A processor acts on the controller's behalf, so the controller's ability to identify remains relevant to the processing relationship. Joint controllers also remain within the same data-protection analysis. The perspective question is most useful when assessing a disclosure to a separate organisation with its own purposes and means, not when a contract tries to rename an in-scope processing operation.
It also means that a release decision should describe the recipient and release model. A dataset prepared for internal use, a named research partner, a closed industry group, and the public internet present different identification conditions. A conclusion reached for one audience cannot be copied into the next release without checking the new audience's available means.
A decision screen for the project review
Use the following sequence before choosing a technique or approving a data release.
1. State what the work must do
Write down whether the activity needs to:
- reconnect events to a person later;
- correct, suppress, or delete a person's record;
- answer a rights request or investigate an incident;
- link the same person across systems or time; or
- produce only group-level statistics with no person-level action.
If the purpose requires a controlled identity link, design for pseudonymisation. The link may be hidden from most users, but it remains part of the processing. If the purpose only needs aggregate patterns, test whether anonymous information can meet the objective before retaining identifiable detail.
This first step prevents a common category error: choosing a technique before deciding whether re-linking is a requirement or a defect.
2. Map every route back to a person
List more than the obvious lookup table. Include:
- token-to-identity mappings;
- encryption keys, salts, and peppers;
- the original source database;
- stable identifiers reused by another system;
- exports, logs, backups, and test data;
- vendor-held data or a processor's support access; and
- public, commercial, or partner datasets that could fill the missing fields.
Ask who can access each route, under what approval, and through which technical or contractual path. If the organisation holds the additional information separately, that separation reduces risk; it does not remove the data from scope.
3. Test the three identification paths
For an anonymity claim, ask three concrete questions:
- Can someone isolate a record? Can a row or small group be distinguished from the rest of the dataset using rare values or a unique combination of attributes?
- Can someone link records? Can the data be connected to another dataset, service, public source, or earlier release to build a person's trail?
- Can someone infer something about a person? Can analysis of the remaining fields reveal a new fact, category, or prediction about someone who can be identified directly or indirectly?
These questions correspond to the EDPB's three criteria and the ICO's guidance on singling out, linkability, and inference. They are more useful than asking whether the file "looks anonymous" because they force the reviewer to test the mechanisms that create identifiability. 34
4. Apply the reasonably likely test in context
The GDPR does not require an organisation to defend against every imaginable theory of identification. It requires an assessment of means reasonably likely to be used. Consider:
- the precision, uniqueness, and volume of the data;
- the identity and capability of the recipient;
- additional information already available or realistically obtainable;
- the time, cost, and expertise required;
- technical developments that make an attack easier; and
- access by insiders, contractors, third parties, or malicious actors.
The ICO recommends a motivated-intruder test as a starting point. The question is not whether a curious person can invent a remote possibility. It is whether a reasonably competent and motivated person with plausible resources could identify someone in this release model. The EDPB similarly says that means should be understood broadly, including a chain in which a recipient could hire or obtain help from another party. 34
5. Decide what happens when the claim fails
If the assessment finds that a person can still be identified or treated differently through reasonably likely means, keep treating the data as personal data. The fallback is not to keep the word "anonymous" and add a confidentiality clause.
The project may instead:
- reduce precision or remove rare attributes;
- aggregate records into groups large enough for the purpose;
- limit the recipient, access path, or release volume;
- use pseudonymisation and keep a separate identity service;
- change the purpose so person-level linkage is unnecessary; or
- stop the release until the legal, technical, and organisational controls are in place.
The decision belongs to the facts of the processing. A restriction can reduce risk, but it does not turn personal data into anonymous information by declaration alone.
Match the technique to the job
Pseudonymisation techniques include hashing, encryption, and tokenisation. They are implementation options for controlling the identity link, not proof that the result is anonymous. 2
Tokenisation replaces an identifier with a randomly generated token and stores the mapping separately. It works well when the organisation needs stable linkage across systems, but the mapping service becomes a high-value target. Access to it should be narrow, logged, and justified.
Encryption-based pseudonymisation protects the identity link through keys. The key-management design matters as much as the algorithm: a dataset and its decryption key in the same broadly accessible environment do not provide much separation.
Hashing can support matching, but predictable identifiers such as email addresses may be vulnerable to guessing or dictionary attacks. The ICO advises against hashes without additional data such as a salt, pepper, or encryption key, and against outdated algorithms such as MD5 and SHA-1 for this protective use. The choice still depends on the data, attacker, required consistency, and ability to protect the secret. 2
For any of these techniques, keep the additional information separate and protected. The ICO recommends measures such as distinct storage or network segmentation, strict access control, encryption, access logging, appropriate key handling, secure backups, and secure destruction when the information is no longer needed. 2
Anonymisation uses a different test. It may involve aggregation, generalisation, masking, noise, or a combination of techniques, but no technique guarantees the legal result by itself. The output must be assessed against the data, purpose, recipient, and available means of identification.
The conversion process also matters. The ICO says applying anonymisation techniques to personal data is itself processing, so the organisation needs a defined purpose, a lawful basis, and safeguards while it transforms the data. The resulting information falls outside data-protection law only after it meets the anonymous-information threshold. 5
Failure modes that should stop sign-off
The missing name test
The team removes names and phone numbers, then approves the dataset. It has tested direct identification while ignoring unique combinations, public sources, and person-level inferences. Run the isolation, linkage, and inference tests instead.
The hidden-key mistake
The organisation keeps a lookup table and calls the export anonymous because the recipient does not receive the table. The export may be less identifiable in the recipient's hands, but the organisation holding the table still processes personal data. Use the term pseudonymised and control the mapping.
The irreversible-hash assumption
A stable hash of a small or predictable identifier space can be tested against guesses. A hash can be an appropriate control, but "hashed" is not a synonym for "anonymous." Record the attacker model and protect any salt, pepper, or key.
The one-release assessment
A dataset passes review in isolation, then becomes identifiable after another release, a new public dataset, or a change in technology. Anonymity is a context-dependent conclusion. Set a review trigger for new recipients, new fields, new linkage opportunities, and material changes in attack capability.
The purpose shortcut
The team says pseudonymisation makes a new analytics purpose compatible with the original collection purpose. It does not. Pseudonymisation is one safeguard among the factors used to assess further processing; it does not replace the purpose, lawfulness, transparency, or compatibility analysis. 2
The undefined label
"De-identified" can mean masked, tokenised, aggregated, or simply stripped of names. The ICO warns that the term is not a defined synonym for anonymous information or pseudonymous data. Replace the label with a description of the transformation, the remaining fields, the identity-link map, and the risk conclusion. 5
The record a reviewer can use
A short record should let a new reviewer reconstruct the decision without asking the original project team to explain its shorthand. Capture:
- Purpose and required utility: what the activity must produce and whether person-level linkage or action is required.
- Data boundary: fields, granularity, identifiers, derived attributes, systems, recipients, and release model.
- Identity-link map: additional information, keys, lookup tables, source systems, and who can access them.
- Technique and controls: transformation, separation, encryption, access roles, logging, key management, backups, and destruction.
- Identification assessment: record isolation, linkage, inference, additional information, attacker paths, cost, time, technology, and recipient perspective.
- Legal status: pseudonymised personal data, or anonymous information for a named recipient and context, with the reasoning that supports the conclusion.
- Processing safeguards: lawful basis, transparency, purpose compatibility, retention, and any DPIA or other risk record required for the activity.
- Review trigger: the event that reopens the decision, such as a new release, new field, new data source, new technology, or a change in the identity-link controls.
The final check is direct: does the work need the identity link, who can reach it, and what can a recipient isolate, link, or infer? If the answers are recorded, the team has made a data-protection decision. If the only evidence is a file with the names removed, it has changed the appearance of the data without establishing its legal boundary.
References
- 1Regulation (EU) 2016/679, Article 4(5) and Recital 26
data.europa.eu
- 2ICO, Pseudonymisation
ico.org.uk
- 3
- 4EDPB, Guidelines 02/2026 on Anonymisation
edpb.europa.eu
- 5ICO, Introduction to anonymisation
ico.org.uk
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.