Pseudonymization replaces identifiers so that data can no longer be tied to a person without extra information that is kept separately. Anonymization changes data so that nobody can identify the person by any means reasonably likely to be used. Under the GDPR, pseudonymized data is still personal data and anonymous data is not. This article covers the legal texts, the techniques and the tests for each, and what each one changes for compliance.
Opsware builds pseudonymization services, key and token vaults, and de-identified analytics datasets as part of its data science and Python and Node development work.
The article is written for privacy leads, DPOs and the engineers who implement the controls. It cites the GDPR, guidance from the European Data Protection Board (EDPB) and its predecessor, ENISA's technical report, and the Court of Justice's September 2025 ruling on pseudonymized data. This is a practitioner's summary, not legal advice.
Pseudonymization vs anonymization at a glance
| Pseudonymization | Anonymization | |
|---|---|---|
| What it does | Replaces or transforms identifiers; the link back is kept separately | Removes the link to the person for good |
| Reversible? | Yes, for whoever holds the key or lookup table | No, by design |
| Status under the GDPR | Personal data (Recital 26) | Not personal data; the GDPR does not apply (Recital 26) |
| Typical techniques | Keyed hashing (HMAC), encryption, tokenization, random IDs, counters | Aggregation, k-anonymity, l-diversity, noise addition, differential privacy |
| Data utility | High: records stay linked across tables and over time | Lower: individual records are generalized, aggregated or perturbed |
| Test | Can the data be attributed to a person without the additional information? | Can anyone single out, link or infer, using means reasonably likely to be used? |
| Main use | Security and data minimization inside processing you still do | Publishing or sharing data you no longer need to tie to people |
What the GDPR says
Article 4(5) of the GDPR defines pseudonymization as processing personal data "in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person."
The definition has three parts. You transform the data, you keep the additional information (a key or a mapping table) apart from the people who work with the transformed data, and you put controls in place so that those people cannot re-attach the data to a person. Swapping names for IDs while the mapping table sits in the same database meets the first part only.
The GDPR has no article that defines anonymization. Recital 26 covers both terms. It says pseudonymized data that "could be attributed to a natural person by the use of additional information" is information on an identifiable person. It also says the data protection principles do not apply to anonymous information, meaning data "rendered anonymous in such a manner that the data subject is not or no longer identifiable." To decide whether someone is identifiable, Recital 26 asks you to account for "all the means reasonably likely to be used, such as singling out, either by the controller or by another person." Those means are judged by objective factors, such as the cost and time of identification and the technology available.
Recital 28 says pseudonymization can reduce the risks to the people concerned and help controllers and processors meet their obligations. It also says pseudonymization does not replace other data protection measures. Recital 29 says pseudonymization can be applied within the same controller, as long as the additional information is kept separately and the controller names the people authorized to hold that information.
Why pseudonymized data is still personal data
The EDPB set out its reading in Guidelines 01/2025 on pseudonymisation, adopted on January 16, 2025 for public consultation. The consultation ran from January 17 to March 14, 2025. As of October 30, 2026 the EDPB page still lists only that consultation version, so treat the text as the Board's draft view.
The guidelines make four points that matter for implementation:
- Pseudonymized data that could be attributed to a person with additional information is personal data. The guidelines say this is true even "if pseudonymised data and additional information are not in the hands of the same person" (paragraph 22).
- Erasing your key or mapping table does not make the data anonymous. The data becomes anonymous "only if the conditions for anonymity are met" (paragraph 22). Dates, locations and rare attributes left in the rows can still identify people.
- The GDPR does not impose a general duty to pseudonymize. Depending on the risks, a controller may need it to meet data minimization, data protection by design or the security duty, and some EU or national laws require it.
- Pseudonymization alone "will normally not be a sufficient measure" for data protection by design or for security. It works together with access control, logging and the other measures in Article 32.
The guidelines also introduce the pseudonymization domain. This is the group of people or systems that must not be able to attribute the data, for example an analytics team, a vendor or a research partner. You define the domain, then keep the key and the original data outside it. If people inside the domain can reach the key, pseudonymization gives little protection.
Whose point of view counts: the SRB ruling
On September 4, 2025 the Court of Justice decided EDPS v SRB (C-413/23 P). The Single Resolution Board, an EU agency, had sent comments from shareholders and creditors to the consultancy Deloitte. It replaced the names with alphanumeric codes and kept the key itself. The case arose under Regulation 2018/1725, which applies to EU institutions, but its definitions of personal data and pseudonymization match the GDPR's.
The Court held that pseudonymized data is not personal data in every case and for every person. For a recipient that has no means reasonably likely to be used to re-identify the people, the data may not be personal data. The technical and organizational measures around the key are part of that assessment. For the controller that holds the key, the data remains personal data.
The Court also held that the controller's duty to tell people who will receive their data is judged from the controller's point of view, at the time the data is collected. So the SRB's duty to name Deloitte as a recipient did not depend on whether the data was personal data in Deloitte's hands. The Court set aside the General Court's judgment and sent the case back for the remaining plea.
The SRB ruling follows the reasoning in Breyer (C-582/14, 2016), where dynamic IP addresses were personal data for a website operator that had legal means to obtain the subscriber's identity from the internet provider. The EDPB's draft guidelines, written before the ruling, take a broader view of when data stays personal in a recipient's hands. A Commission proposal from November 2025 would write a recipient-based test into the GDPR's definition of personal data. As of October 2026 it has not been adopted, and reports say the Council removed that change from its text.
The SRB ruling changes little for the controller that pseudonymizes. You still hold personal data, you still name recipients in your privacy notice, and you still answer requests. The ruling can matter for the recipient. A recipient with no realistic way to get the key may be able to show that it processes no personal data. That conclusion depends on facts, such as contracts, access controls and whatever outside data the recipient holds, so the recipient should document it.
Pseudonymization techniques
ENISA's report Pseudonymisation techniques and best practices (November 2019) describes five basic techniques for a single identifier:
| Technique | How it works | Additional information to protect | Weak points |
|---|---|---|---|
| Counter | Each new identifier gets the next number | The mapping table | Order of numbers can reveal the order of records; the full table must be stored |
| Random number generator | Each identifier gets a random value (this is what most tokenization services do) | The mapping table | Collisions unless values are long; the table grows with the data |
| Cryptographic hash | Pseudonym = hash of the identifier | None | Anyone can hash a list of known values and match them; ENISA calls it weak |
| Message authentication code (keyed hash, such as HMAC) | Pseudonym = keyed hash of the identifier | The secret key | Robust while the key stays secret; one-way, so you need the original value to look up a person |
| Encryption | Pseudonym = encrypted identifier | The secret key, which also decrypts | Anyone with the key can recover every identifier |
The EDPB guidelines add three practical points. First, the transformation must use a secret, so that someone inside the domain who knows a person's identifier cannot compute the pseudonym and find that person's rows. The EDPB's example is a plain SHA-256 hash of a name, which anyone can match by hashing names they already hold. Second, keyed one-way functions are generally preferred over encryption, because the output cannot be turned back into the identifier even by someone who has the key. Someone with the key can still compute the pseudonym of a known identifier, so the key must stay secret. Encryption fits cases where authorized users must be able to reverse the pseudonyms easily. Third, lookup tables are personal data, so the token vault needs the same protection as the original records.
ENISA also describes three policies for how often a value gets the same pseudonym:
- Deterministic: the same identifier always gets the same pseudonym, in every dataset. You can join tables, and so can anyone else who has both tables.
- Document-randomized: each occurrence of a value within a dataset gets a different pseudonym. If you pseudonymize the same dataset again, you get the same output.
- Fully randomized: every occurrence gets a new pseudonym every time. This gives the most protection and allows no joins.
Another option is a separate key per recipient or per project. Records stay joinable inside one domain, and two recipients cannot match their copies against each other.
Anonymization techniques and the three re-identification tests
The Article 29 Working Party, which preceded the EDPB, set the tests in Opinion 05/2014 on anonymisation techniques. A robust anonymization process addresses three risks:
- Singling out: isolating some or all records that identify one person.
- Linkability: linking at least two records about the same person or group, in one dataset or across datasets.
- Inference: deducing, with significant probability, the value of an attribute from other attributes.
The opinion groups the techniques into randomization (noise addition, permutation, differential privacy) and generalization (aggregation, k-anonymity, l-diversity, t-closeness). Its summary table rates them against the three risks:
| Technique | Singling out still a risk? | Linkability still a risk? | Inference still a risk? |
|---|---|---|---|
| Pseudonymization | Yes | Yes | Yes |
| Noise addition | Yes | May not | May not |
| Substitution | Yes | Yes | May not |
| Aggregation or k-anonymity | No | Yes | Yes |
| L-diversity | No | Yes | May not |
| Differential privacy | May not | May not | May not |
| Hashing or tokenization | Yes | Yes | May not |
No single technique clears all three risks in every case, so the opinion recommends combining techniques and deciding case by case. The opinion states that pseudonymization "is not a method of anonymisation." It also says anonymization is itself processing of personal data, so it must be compatible with the purpose for which the data was collected. It also warns that anonymized data can carry residual risk, so the assessment should be repeated as new data and techniques appear.
For machine learning, the EDPB's Opinion 28/2024 on AI models applies the same idea to trained models. A model trained on personal data is anonymous only if the likelihood of extracting personal data from it, directly or through queries, is insignificant, taking into account all the means reasonably likely to be used.
What each changes for compliance
Pseudonymization keeps you inside the GDPR but lowers the risk and supports several duties. Anonymization takes the output out of scope, but the process of anonymizing is still processing.
| Duty | Pseudonymized data | Anonymized data |
|---|---|---|
| GDPR applies | Yes | No, once anonymous; the anonymization step itself is covered |
| Data protection by design (Art. 25) | Named as an example measure in Art. 25(1) | No duty for the anonymous output; anonymizing data you no longer need is one way to meet Art. 25 for the original data |
| Security (Art. 32) | Art. 32(1)(a) names "the pseudonymisation and encryption of personal data" | No duty for the anonymous output |
| Research and statistics (Art. 89) | Art. 89(1) names pseudonymization as a safeguard. If the purpose can be met with data that does not identify people, you must use that data instead | Preferred where the purpose allows it |
| Further processing (Art. 6(4)) | Art. 6(4)(e) lists encryption or pseudonymization as a factor in the compatibility test | No compatibility test for the output |
| Legitimate interest | EDPB: the risk reduction can support a balancing test under Art. 6(1)(f) | No legal basis needed for the output |
| Data subject requests | Apply. Art. 11 relieves you only if you can show you cannot identify the person. Even then, the person can give you extra information that identifies them, and their rights apply again | Do not apply |
| Breaches | Still a personal data breach. Strong pseudonymization can lower the risk assessment; unauthorized reversal is itself a breach | Not a personal data breach, unless the data turns out to be re-identifiable |
| Transfers outside the EEA | Chapter V applies; the EDPB treats pseudonymization as a possible supplementary measure | Chapter V does not apply |
| Retention | Storage limitation applies | No limit under the GDPR |
Requests. If you pseudonymize with a key you hold, you can still find a person's rows. Compute the keyed hash of their user ID, or look them up in the token table, and the access and deletion requests reach those rows. The EDPB adds that if someone can show you the pseudonym that belongs to them, you should be able to identify them, so their rights apply. Pseudonymizing a store does not replace deleting from it. The article "Access and deletion requests against LLM logs and vector stores" covers deletion from trace stores.
Breaches. The EDPB says effective pseudonymization can be weighed when deciding whether a breach must be notified to the authority under Article 33 or communicated to people under Article 34. The attacker can still analyze the rows they took, so the controller has to assess what those rows reveal. If the key leaks with the data, the protection is gone. Article 34(3)(a) lets you skip telling people when the data was unintelligible to the attacker. Its example of such a measure is encryption, and pseudonymization is not named there.
Worked examples
Product analytics with a keyed hash
A SaaS company sends events to its warehouse with user_id replaced by an HMAC-SHA-256 of the ID. The key sits in a key management service that the analytics team cannot read. Analysts can count retention by cohort and join events across tables. The data is pseudonymized, so it is personal data for the company. A deletion request is handled by computing the HMAC of the user's ID and deleting the matching rows.
A vendor that receives coded records
A lender sends a scoring vendor loan records with names and account numbers replaced by random tokens. The token table stays with the lender, and the contract bars the vendor from trying to re-identify anyone. For the lender this is personal data, and its privacy notice must name the vendor or the category of recipient. After the SRB ruling, the vendor may be able to argue that the records are not personal data in its hands. That argument fails if the records include details the vendor could match to people, such as exact birth dates and postcodes.
Hashed emails for ad matching
A retailer uploads SHA-256 hashes of customer emails to an ad platform. The hashes have no key. The platform holds its own users' emails and can hash them and match them, which is the purpose of the upload. The uploaded hashes are personal data for both parties, as in the EDPB's plain-hash example.
Deleting the key to anonymize
A research team finishes a study and destroys the mapping table, then plans to keep the dataset forever as anonymous. The rows still hold date of birth, postcode, sex and hospital visit dates. Those fields can single out many people, and linking them to another dataset can identify them. Per the EDPB, deleting the key does not make the data anonymous. The team needs to generalize or remove those fields and test the result against the three risks.
Published statistics
A city publishes monthly counts of service requests by district. Cells under a minimum size are suppressed, and no row-level data is released. This kind of aggregation removes the singling-out risk. The city should still check that combining tables, such as district counts with age-band counts, does not reveal small groups.
Decision table: which one to use
| You need to | Use | Status of the result |
|---|---|---|
| Analyze behavior over time and still act on individuals (support, billing, deletion) | Pseudonymization with a keyed hash or token vault | Personal data |
| Let engineers debug with production data without seeing who it is | Pseudonymization plus masking of free text; a key the engineers cannot read | Personal data |
| Send records to a vendor or research partner that must not identify anyone | Pseudonymization with a recipient-specific key, a contract barring re-identification, and fewer fields | Personal data for you; possibly not for the recipient |
| Recover the original values later on an authorized request | Encryption, or a token vault with access logs | Personal data |
| Publish data or share it openly | Anonymization: aggregation, suppression, or differential privacy | Anonymous if it passes the three tests |
| Keep data past its retention period for statistics | Anonymization and a documented re-identification test | Anonymous if it passes the three tests |
| Train or evaluate models without keeping identities | Pseudonymization of the inputs; anonymization only if extraction and inference tests pass | Usually personal data |
Record the choice for each dataset in your record of processing activities, with the technique, where the key is stored and who can access it. The guide "Data mapping and discovery" covers how to find the datasets, and "GDPR Article 32 and security controls for personal data" covers the controls around the key store.
US terms are different
US laws use different terms for similar ideas. The HIPAA Privacy Rule de-identifies health information through either Safe Harbor, which removes 18 listed identifiers, or Expert Determination (45 CFR 164.514(b)). The CCPA defines both "deidentified" and "pseudonymize" in Civil Code section 1798.140, with its own conditions for each. Data that meets a US de-identification standard is not automatically anonymous under the GDPR's Recital 26 test.
Frequently asked questions
What is the difference between pseudonymization and anonymization?
Pseudonymization replaces identifiers and keeps the means to re-link them separately, so the process can be reversed by whoever holds the key or table. Anonymization removes the link to the person so that nobody can re-identify them with means reasonably likely to be used. Under the GDPR, pseudonymized data is personal data and anonymous data is not.
Is pseudonymized data personal data under the GDPR?
Yes, for any party that can attribute it to a person using additional information, which always includes the controller that holds the key. Recital 26 says so, and the EDPB's Guidelines 01/2025 repeat it. The Court of Justice ruled in September 2025 that it may not be personal data for a recipient with no means reasonably likely to be used to re-identify people.
Is hashing pseudonymization or anonymization?
A plain hash is at most pseudonymization, and a weak one, because anyone with a list of likely values can hash them and match the results. A keyed hash such as HMAC, with the key kept separately, is a robust pseudonymization technique according to ENISA. Neither is anonymization.
Is tokenization the same as pseudonymization?
Tokenization with a vault is a form of pseudonymization: a random value replaces the identifier, and the vault keeps the mapping. The vault is personal data and needs the same protection as the original records.
Does deleting the key make pseudonymized data anonymous?
Not by itself. The EDPB says the data becomes anonymous only if the conditions for anonymity are met. Remaining fields such as birth dates, postcodes and rare attributes can still allow singling out, linking or inference.
Do data subject rights apply to pseudonymized data?
Yes. If you hold the key you can find a person's records and must answer access and deletion requests. Article 11 applies only if you can show you cannot identify the person, and even then the person can provide extra information, such as their pseudonym, that lets you identify them.
Sources
- GDPR: Regulation (EU) 2016/679, Articles 4(5), 6(4), 11, 25, 32, 34, 89 and Recitals 26, 28 and 29
- EDPB: Guidelines 01/2025 on pseudonymisation (version for public consultation, adopted January 16, 2025); Opinion 28/2024 on AI models
- Article 29 Working Party: Opinion 05/2014 on anonymisation techniques (WP216, April 10, 2014)
- ENISA: Pseudonymisation techniques and best practices (November 2019)
- Court of Justice: C-413/23 P, EDPS v SRB (September 4, 2025); C-582/14, Breyer (October 19, 2016)
- US: 45 CFR 164.514 (HIPAA de-identification)
Need this built?
If you want a pseudonymization service, a token vault or a de-identified analytics dataset built and documented, tell us about your project, and we will reply with questions or a rough plan.