Pseudonymisation: what it is, what the GDPR requires and how to do it properly

Pseudonymisation is the security measure the GDPR mentions most often, and also the one that is misunderstood most often. Some organisations assume a dataset without names is anonymous. Others assume pseudonymised data is always, and for everyone, personal data. Both assumptions are wrong, and since September 2025 the Court of Justice of the European Union (CJEU), the European Data Protection Board (EDPB) and national supervisory authorities have all had their say on where the line runs.

This article is written for compliance leads, data protection officers (DPOs) and IT managers who need to decide when pseudonymisation is the right tool, which technique will hold, and what still applies once the pseudonyms are in place. We cover the definition in the regulation, EDPB Guidelines 01/2025, the judgment in Case C-413/23 P and the reaction from supervisory authorities. You will finish with a six-step process and a fully worked fictional example.

The short answer: what is pseudonymisation?

Pseudonymisation is the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information, provided that the additional information is kept separately and protected by technical and organisational measures. That is the wording of Article 4(5) GDPR, lightly shortened.

In practice it means replacing direct identifiers such as name, national ID number, email or customer number with a pseudonym, and storing the key or lookup table that can reverse the pseudonym somewhere else, behind strict access control. The data keeps its value for analysis, testing and research, but whoever works with it cannot see who it is about.

Three consequences follow. Pseudonymised data is, as a rule, still personal data for whoever holds the key, so the GDPR continues to apply. Pseudonymisation is not anonymisation, and your documentation must not conflate the two. And pseudonymisation is a safeguard, not a legal basis, so you still need a ground under Article 6 for the processing the pseudonyms are part of.

Three concepts that often get mixed up

Searches for pseudonymisation tend to bundle three things that belong to different categories. Before going deeper, we sort them out.

The key point in the table is that anonymisation takes data out of the GDPR's scope, while pseudonymisation keeps it inside. That is also why the regulation can recommend pseudonymisation as a security measure: it presupposes that the rules still apply. Our article on anonymisation of personal data explores the boundary in more detail.

Where does the GDPR mention pseudonymisation?

Pseudonymisation appears in several articles and recitals of the regulation, and each occurrence has its own function. Knowing them matters, because they explain what the measure actually does for you and what it does not exempt you from.

Note what is missing from the list. Pseudonymisation does not exempt you from the record of processing activities in Article 30, from the information duties in Articles 13 and 14, from the data processing agreement in Article 28 or from the need for a legal basis under Article 6. We return to that below.

Is pseudonymised data personal data?

This is the question that has dominated the discussion since 2025, and the answer is now more nuanced than most older articles suggest. There are three sources you need to know.

EDPB Guidelines 01/2025

The EDPB adopted Guidelines 01/2025 on pseudonymisation on 16 January 2025 and ran a public consultation until 14 March 2025. A final version had not been published when this article was written in September 2026, so the consultation draft remains the most authoritative European document on the subject.

The starting point in the guidelines is clear: pseudonymised data that could be attributed to a natural person by the use of additional information is personal data, and this holds even where the additional information is in the hands of someone other than the person processing the pseudonyms. The guidelines also introduce three terms worth adopting in your own documentation: the pseudonymisation domain (the people and systems within which pseudonyms must not be attributable to individuals), the pseudonymising transformation (the technique itself) and the pseudonymisation secrets (keys and lookup tables). The annex contains ten worked examples ranging from internal analytics and research to supplementary measures for third-country transfers.

The CJEU judgment in Case C-413/23 P

On 4 September 2025 the Court of Justice delivered its judgment in Case C-413/23 P, EDPS v SRB. The Single Resolution Board had transferred 1,104 pseudonymised comments from Banco Popular shareholders and creditors to Deloitte without telling the individuals that Deloitte was a recipient. The case was decided under Regulation (EU) 2018/1725, which applies to EU institutions, but its definitions mirror the GDPR's.

The Court held three things. Personal opinions expressed in a comment are personal data about the person who wrote them. Pseudonymised data must not be regarded as personal data in all cases and for every person, because pseudonymisation may, depending on the circumstances, effectively prevent persons other than the controller from identifying the data subject (paragraph 86). And the controller's information obligation must be assessed at the time of collection and from the controller's own perspective, regardless of what the recipient can or cannot do later (paragraphs 112 to 115). The SRB should therefore have named Deloitte as a recipient, even if Deloitte may have been unable to re-identify anyone.

The judgment is not a free pass. If it cannot be ruled out that the recipient has means reasonably likely to link the pseudonyms to individuals, for example by cross-checking against its own data, the data is personal data for that recipient (paragraph 85). Because the information duty did not depend on Deloitte's position, the Court gave final judgment on that plea and upheld the EDPS decision against the SRB. Only a separate plea about the SRB's right to good administration was sent back to the General Court.

How supervisory authorities responded

National regulators moved quickly to limit over-reading of the judgment. The Danish Data Protection Agency (Datatilsynet) published a first note on the day of the judgment and a clarification on 22 October 2025 after a large number of enquiries. Its position is that data pseudonymised by a controller remains personal data for as long as a processor handles it on the controller's behalf and under its instructions, because the assessment is made from the controller's perspective and the controller holds the key. The processor's own ability to re-identify is irrelevant in that set-up, so a data processing agreement under Article 28 is still required, even where the processor only ever sees pseudonyms.

In the UK, the ICO's anonymisation guidance, published on 28 March 2025, takes a similar line: pseudonymised data is personal data in the hands of the organisation that can re-identify it, and whether it is personal data for a recipient depends on that recipient's realistic means. The UK GDPR is a separate legal regime, so treat the ICO's view as persuasive rather than binding if you operate under the EU GDPR.

What this means in practice

For you as a controller, the judgment changes little: you hold the key, the data is personal data, and every obligation applies. The judgment matters in two situations. The first is when you receive pseudonymised data from another controller without a key, without any right to obtain it and without other data to cross-reference. There, after a documented assessment, you may conclude that the data is not personal data for you. The second is when you disclose data, where the judgment stresses that the duty to inform data subjects applies regardless of what the recipient can do.

The European Commission's Digital Omnibus proposal of November 2025 would have written this relative approach directly into Article 4(1). The EDPB and EDPS criticised the drafting in their joint opinion of February 2026, and Council compromise texts have since amended and relocated the language. Negotiations on the GDPR part of the package were still ongoing when this article was written, so do not build your assessments on the Omnibus yet.

Pseudonymisation vs anonymisation

The difference is legally decisive, because anonymous data falls outside the GDPR while pseudonymised data, as a rule, does not. It is also practically decisive, because anonymisation is far harder to achieve than most teams expect.

A dataset with names removed but date of birth, postcode and gender retained is not anonymous. At best it is pseudonymised, and often not even that if there is no protected key. The classic mistake in staff surveys and HR analytics is to promise anonymity where only pseudonymisation is in place. The EDPB's own topic page puts it plainly: pseudonymisation reduces the linkability of data to an individual without aiming to cut the link entirely, while anonymisation makes data unlinkable to any individual.

Pseudonymisation techniques

The choice of technique determines how robust your pseudonymisation is against attack and how usable it is in operation. ENISA's report Pseudonymisation techniques and best practices from 2019 and the EDPB guidelines describe the same core techniques. Here they are, set side by side.

Beyond the technique you also choose a policy. Deterministic pseudonymisation gives the same person the same pseudonym every time, which is necessary if you need to follow individuals over time, but also makes unauthorised linkage of datasets easier. Randomised pseudonymisation produces a new pseudonym per dataset or per transaction. The EDPB singles out transaction pseudonyms as well suited to limiting the damage from unauthorised disclosure. Choose the weakest linkage your purpose allows.

How to implement pseudonymisation in six steps

Pseudonymisation is not purely an IT project. It is a decision about who is allowed to know what, supported by technology. The process below follows the structure of the EDPB guidelines and suits most organisations of 50 employees and upwards.

Step 1: Define the purpose and the pseudonymisation domain

Write down which risk the pseudonymisation is meant to reduce and who must be unable to link the data to individuals. Is it the analytics team, an external supplier, a research group or everyone outside a core HR team? The domain determines everything that follows. Anchor the decision to the processing activity the data belongs to, so the documentation lands in your record of processing.

Step 2: Map identifiers and quasi-identifiers

Direct identifiers are easy: name, national ID number, email, phone number, customer number. Quasi-identifiers are harder: date of birth, postcode, job title, rare diagnoses, free text. A combination of three or four quasi-identifiers frequently points to a single person. Decide for every column whether it is pseudonymised, generalised (year of birth instead of date of birth) or dropped.

Step 3: Choose the technique and the policy

Use the table above. If you need to reverse the pseudonym, choose encryption or a lookup table. If you only need to link records without reversing, choose a keyed hash. If you need neither linkage nor reversal, consider whether anonymisation is the right goal, or use randomised pseudonyms. Avoid unkeyed hashes for national ID numbers, email addresses and any other identifier that can be guessed.

Step 4: Protect the secrets

Keys and lookup tables must sit in a different system from the pseudonyms, with access for named roles, logging of every use and a fixed procedure for key rotation. Consider a key management system or a trusted third party as key holder if you share data with several parties. Write down the reversal procedure: who may request it, who approves it and how it is logged.

Step 5: Add organisational measures

Technology only holds if the organisation holds. That means a written prohibition on re-identification attempts for everyone in the domain, contractual clauses with suppliers and research partners, awareness training for staff who work with the pseudonyms, and a risk assessment documenting why the re-identification risk in the domain is insignificant. Remember that pseudonymisation at a processor still requires a data processing agreement.

Step 6: Document, test and repeat

Document the technique, domain, key holders and risk assessment so you can demonstrate compliance under Article 5(2). Test the re-identification risk with the data the domain actually has access to, not with an idealised dataset. Schedule an annual review, because datasets, technology and threats all change. If the pseudonymisation supports a new system or a high-risk processing operation, it belongs in your data protection impact assessment under Article 35.

A worked example: pseudonymising customer data for external analytics

Harbourline Retail Ltd, the analytics agency Fjord Insight and Mette Kjær are fictional. We invented them for this article, and they are neither customers nor a case study.

Harbourline is an online retailer with 120 employees and 85,000 active customers across three EU countries. Mette Kjær is its compliance lead and has received a request from marketing: they want an external agency, Fjord Insight, to analyse purchasing patterns over three years and build customer segments. The agency will not contact customers, only return segments to Harbourline.

Mette defines the domain as Fjord Insight plus everyone outside Harbourline's data platform team. She reviews the 14 columns in the extract. Customer number, name, email and address are direct identifiers. Date of birth, postcode and last purchase date are quasi-identifiers. She decides that the customer number is replaced by a pseudonym calculated as an HMAC with a key that exists only in Harbourline's key vault. Name, email and address are dropped entirely. Date of birth becomes a five-year age band, postcode is truncated to its outward code, and purchase dates are rounded to the week. Ten columns remain, and in the test run no combination points to fewer than 20 customers.

Fjord Insight receives no key, no right to obtain it and a contractual prohibition on attempting re-identification or combining the data with other sources. Segments come back carrying pseudonyms, which Harbourline's data platform team translates back to customer numbers using the key. Two people have access to the key, and every translation is logged.

Then comes the legal assessment. For Harbourline the dataset is personal data, because it holds the key. Fjord Insight processes on Harbourline's behalf and under its instructions, so following the Danish regulator's October 2025 clarification and the EDPB's position, the data is personal data in that relationship too, and Mette puts a data processing agreement in place. Analytics is a new purpose compared with order fulfilment, so she carries out a compatibility assessment under Article 6(4), in which the pseudonymisation and data minimisation weigh in favour of compatibility. She updates the privacy notice so that the agency appears as a category of recipient, because the duty to inform applies regardless of the agency's ability to re-identify.

The arithmetic in the security assessment looks like this. Without pseudonymisation, a leak at the agency would expose 85,000 customers with name, email and full purchase history, a breach with a probable duty to communicate under Article 34 and a real risk of targeted phishing. With pseudonymisation and minimisation, a leak contains age bands, partial postcodes and weekly purchase patterns and no key. Mette concludes that the breach would still need to be notified to the supervisory authority within 72 hours under Article 33, because it is personal data for Harbourline, but that communication to customers under Article 34(3)(a) could be omitted if the assessment shows the data is genuinely unintelligible to whoever obtained it. She writes the reasoning down in advance so it is ready if the breach ever happens.

Had the agency needed to select customers for a campaign itself, pseudonymisation would have made no sense, because the linkage would then have to sit with the agency. The point of the example is that pseudonymisation works best once you have decided who does not need to know who the customers are.

What pseudonymisation does not solve

Pseudonymisation is a good tool, and it gets better when you know its limits. These are the ones we see overlooked most often.

It does not remove the GDPR. For the controller holding the key, every obligation applies: legal basis, record of processing, information duties, data subject rights, data processing agreements and breach notification. It is a layer on top of compliance, not a substitute for it.

It does not by itself protect against linkage attacks. A pseudonymised dataset with precise timestamps, location data or rare attributes can often be linked to individuals through other datasets. The CJEU's own case law shows how far identifiability reaches: in the SRB case the Court confirmed that free-text opinions with no names attached were still personal data about their authors, because the authors could be identified from the surrounding information.

It is no stronger than its key management. If the key sits in the same database as the pseudonyms, or every developer has access to it, the Article 4(5) requirement of separate storage is not met.

It is not anonymisation. If data is to be published or shared widely without GDPR obligations, anonymisation is what you need to assess, and it demands a different and stricter body of work. The EDPB's draft Guidelines 02/2026 on anonymisation, open for consultation until 30 October 2026, are the place to start.

And it is not free. Pseudonymisation costs utility, development time and the operation of key vaults. The GDPR requires appropriate measures under Article 32, not pseudonymisation of everything. A risk assessment that concludes encryption and access control are sufficient for a given processing operation is a fully legitimate conclusion, as long as it is reasoned and documented. Our article on information security risk management shows how one method can serve several obligations.

How .legal supports your work with pseudonymisation

Pseudonymisation needs to be documented in three places: on the processing activity, in the risk assessment and in the agreements with whoever receives the data. In the .legal compliance platform those three are connected. In the GDPR module you record pseudonymisation as a technical measure directly on the processing activity it protects, so your Article 30 record shows data categories, recipients and the safeguards that apply in one view. Data mapping gives you an overview of which systems hold keys and which only ever see pseudonyms.

In the risk management module you document the re-identification risk assessment and the data protection impact assessment a new analytics processing operation may require. Data processing agreements and the contractual ban on re-identification at suppliers live in vendor management, and the annual review of keys and domain becomes a recurring task in compliance task management. The platform does not pseudonymise your data for you. It makes sure the decisions to do so can be found, justified and demonstrated when a regulator or a customer asks.

Book a demo if you would like to see how measures, risks and supplier agreements attach to the same processing activity.