Anonymization vs pseudonymization: GDPR rules and examples

What is pseudonymization? What is anonymization?

Preparing records for a buyer or a license? Check what they're worth first: a free valuation needs only company-level answers, so no personal data moves.

The GDPR defines pseudonymisation in Article 4(5) as processing personal data so that it "can no longer be attributed to a specific data subject without the use of additional information", provided that information is kept separately and protected by technical and organisational measures. In practice the additional information is usually a secret key or a table matching codes to the identifiers they replaced (EDPB).

The GDPR has no article defining anonymous information. Recital 26 says data protection rules do not apply to it: information that does not relate to an identifiable person, or personal data "rendered anonymous in such a manner that the data subject is not or no longer identifiable". To judge that, it counts all the means reasonably likely to be used, such as singling out, by the controller or anyone else, with regard to cost, time and the technology available.

The UK GDPR uses the same wording (Article 4). The ICO puts the difference simply: anonymization reduces the amount of personal data you hold, while pseudonymization reduces the risks of the personal data you hold. Its own example is a retailer. Customer transactions stripped of names, emails and phone numbers, then aggregated and noised, can go to outside consultants as anonymous data. The same retailer giving each loyalty-card customer a token, with identities stored separately, is pseudonymizing.

Source: GDPR (Regulation (EU) 2016/679) Article 4 as adopted, on legislation.gov.uk

Anonymization vs pseudonymization: the differences

The two are often confused, and the ICO warns that datasets are commonly called anonymized when they are really pseudonymized. The practical differences:

Source: ICO: Introduction to anonymisation

Is pseudonymized data still personal data when you share it?

This is the question that matters when records go to another company, and the authorities do not give the same answer.

• The EDPB: pseudonymized data that could be attributed to a person with additional information is personal, and that holds "if pseudonymised data and additional information are not in the hands of the same person". Even if the key is erased, the data counts as anonymous only if the conditions for anonymity are met (Guidelines 01/2025). The guidelines were adopted on 16 January 2025 as a version for public consultation (EDPB).
• The ICO: pseudonymized data shared without the additional information "may be anonymous information in their hands", judged by asking what the recipient can reasonably do. That approach does not apply when the recipient is your processor or joint controller. A recipient that can re-identify people in data it was told is anonymous must treat it as personal data and tell the provider (ICO).
• The EU Court of Justice, 4 September 2025 (C-413/23 P, EDPS v SRB): pseudonymised data "must not be regarded as constituting, in all cases and for every person, personal data". The case applied the data protection regulation for EU institutions. For the duty to inform people, the Court held that identifiability is assessed at the time of collection and from the controller's point of view, so that duty applies before any transfer (CJEU press release).

Source: Court of Justice of the EU: press release on Case C-413/23 P, EDPS v SRB (4 September 2025)

How to share pseudonymized data safely

The three views agree on one point: while you hold the key, the records are personal data in your hands. Whether the copy is personal data for the recipient depends on what the recipient can reasonably do with it. These steps help whichever view applies:

• Have a lawful basis for the disclosure and tell people about it before anything is sent. The Court placed the duty to inform at collection, before any transfer.
• Never deliver the key or lookup table with the data, and limit who inside the company can use it.
• Treat indirect identifiers too. A recipient that knows someone's role, team or start date may recognise them without any key.
• Assess identifiability from the recipient's side and write it down: what other data could it reasonably combine with yours?
• Ban re-identification and onward disclosure in the contract, and require deletion at the end. See the data licensing agreement guide.

How to anonymize data: techniques with examples

The ICO names two main families of anonymization techniques, generalisation and randomisation, and says masking alone is not anonymization. Pseudonymization techniques are mostly hashing, encryption and tokenisation (ICO). The examples use typical company records:

Source: ICO: How do we ensure anonymisation is effective?

Re-identification risk and the motivated intruder test

Anonymous does not mean impossible to identify. The ICO asks whether the risk of identification is "sufficiently remote", judged by what is reasonably likely rather than any hypothetical chance, and it treats identifiability as a spectrum. Three things can make a record identifiable: singling out one person, linking records across datasets and inferring facts about someone. Pseudonymized data still allows the first two, which is why it is not anonymous (Article 29 Working Party).

The motivated intruder test asks whether a reasonably competent person, with resources such as the internet, libraries and public documents and using investigative techniques such as asking people who know the subject, could identify someone. The ICO lists investigative journalists, estranged partners, stalkers, industrial spies and researchers among the people to imagine.

Company records carry an extra risk: people who already know the subjects. The ICO's example is an employee who works out that an absence statistic relates to a colleague on long-term sick leave. To run the test on a sample:

• Pick a random sample of the prepared records and try to identify people using only public sources.
• Repeat as an insider would: could a colleague, customer or partner recognise someone from a role, date, place or unusual event?
• Check small groups. The ICO cites the NHS standard for publishing health and social care data, which sets k at five for strong anonymization: every record shares its characteristics with at least four others.
• Write down the result, and review it when the data, the recipient or public sources change. The ICO says to review these assessments periodically.

Source: ICO: How do we ensure anonymisation is effective?

Before any records leave the company

Decide before anything is exported, because the technique depends on the use. Check what the records are worth first: a free valuation takes six questions about the business and no files, so no personal data moves while you decide whether licensing is worth the preparation.

• List the systems and record types at company level, such as ticketing, CRM, chat, email, code and call recordings, with the years covered. The data inventory template gives the columns.
• Mark which records name customers, staff or third parties, and which are about the company rather than people, such as procedures, templates and code.
• Decide whether the use needs records linked over time. If it does, pseudonymize with a keyed hash or random tokens and keep the key. If it does not, anonymize or aggregate.
• Budget human review for free text and recordings; they are the slow part.
• If the company is closing, export before cancelling systems: see exporting company records before closing and the closing checklist.

Pseudonymization and de-identification under the CCPA, HIPAA and other laws

Other laws use different words for similar ideas, and their tests differ:

• California: the CCPA defines "pseudonymize" in almost the same words as the GDPR. It excludes "deidentified" information from personal information only if the business takes reasonable measures against re-identification, publicly commits not to re-identify it and contractually obligates recipients to comply (Civil Code 1798.140).
• US health data: HIPAA's Safe Harbor and Expert Determination methods are covered in how to de-identify company data before licensing, with the 18 identifiers and a technique table.
• Australia: information is de-identified where there is no reasonable likelihood of re-identification in the release context, and de-identified information is not personal information under the Privacy Act (OAIC). See the Privacy Act guide.
• UK: the ICO does not use "de-identified" as a synonym for anonymous, and re-identifying de-identified personal data without the controller's consent is an offence under section 171 of the Data Protection Act 2018 (ICO). The ICO notes its anonymisation guidance is under review after the Data (Use and Access) Act. See licensing company data under UK GDPR.

Source: California Civil Code section 1798.140 (CCPA definitions, including "deidentified" and "pseudonymize")

What this means before you license company records

Buyers of company records usually want the patterns in the work, not the identities of the people in it. That makes the choice between the two techniques a question of what the buyer needs:

• Pseudonymized copies keep records linked, so a buyer can follow one customer's tickets over time without knowing who the customer is. In your hands they remain personal data, so the lawful basis, notice and transfer rules in GDPR, CCPA and licensing company data still apply.
• Anonymized or aggregated copies carry the least legal weight but lose detail. Test them before release, as above.
• Agree in writing who prepares the copy, to what standard, and when any raw or pseudonymized copies are deleted.
• Public prices for licensed company records are in the deals tracker. For a closed or closing company, see selling company data after closing.

Anonymization and pseudonymization checklist

Before records leave the company:

• Name the purpose, and whether records must stay linked to one person over time.
• Remove direct identifiers everywhere, including free text, attachments, metadata and file names.
• Treat indirect identifiers: role, team, location, dates, working hours and length of service.
• Pseudonymize with a keyed hash or random tokens, not plain hashes, and store the key separately with access limited.
• For anything shared outside, generalize, aggregate or add noise until no one stands out.
• Run a motivated intruder test on a sample, including an insider's view.
• Document the method, the test result and who approved release, and set a review date.
• In the contract: no re-identification, no onward disclosure without the same terms, deletion at the end.

Next step

Decide what the records are for before choosing a technique: linked records mean pseudonymization and a lawful basis; statistics and outside copies should be anonymized. You can find out whether licensing is worth that work before preparing anything. Get a free valuation from company-level answers.

Origin Data Partners is independent and is not affiliated with any AI data buyer. We help owners compare buyers and find the best fit for their records. See what your data is worth.