Pseudonymised data: is it still personal data after EDPS v SRB?

Pseudonymised data is personal data with the names swapped for codes and the key kept somewhere else. For whoever holds that key, it’s still personal data. In September 2025 the EU’s top court added a twist: for a company that receives the coded data and truly can’t link it back to anyone, it may not be personal data at all. But the company that sent it still had to tell people, when it collected the data, who would receive it.

This piece walks through that case, EDPS v SRB: what pseudonymisation means, who sent what to whom, what the court decided, what EU and UK regulators say now, and what it means for the hashed emails your website might send to ad platforms. It ends with a check you can run on your own forms.

What pseudonymised data is

The GDPR defines pseudonymisation in Article 4(5). It’s processing personal data so it can no longer be attributed to a specific data subject without the use of additional information, as long as that additional information is kept separately and protected by technical and organisational measures.

Think of a customer number in place of a name, or a hashed email in place of the real one. The list that links code to person is the key. Lock it away and the coded data is pseudonymised.

Recital 26 says such data should be considered to be information on an identifiable natural person. Recital 28 explains why the GDPR bothers with the idea at all: pseudonymisation can reduce the risks to the data subjects concerned. It’s a safety measure inside the rules. Our guide to personal data examples says the same: keep the key and it remains personal data.

Anonymised vs pseudonymised

Anonymised data is different. Recital 26 says the GDPR doesn’t apply to information rendered anonymous so the person is not or no longer identifiable. The test is whether anyone could identify them with the means reasonably likely to be used, counting cost, time and technology. That’s a high bar, and a hash or a code on its own doesn’t clear it.

US law has its own words. California defines “pseudonymize” in Civil Code section 1798.140(aa) almost as the GDPR does, under the US spelling pseudonymization. Its “deidentified”, in section 1798.140(m), is closer to anonymised: information that can’t reasonably be linked to a consumer, with public commitments and contracts on top. When a US vendor says de-identified data, ask which one it means.

The case: EDPS v SRB

The Single Resolution Board is the EU agency that handles failing banks. On 7 June 2017 it put Banco Popular Español into resolution. Afterwards it asked Deloitte to value whether shareholders and creditors would have been better off in normal insolvency, and then gave them a right to be heard. The facts here come from the Court of Justice’s judgment.

First, people registered with proof of identity and of their shares; the SRB published a privacy statement for the process on 6 August 2018. Then, from 6 November 2018, verified people answered a seven-question online form.

Each comment got a 33-digit globally unique identifier randomly generated when it arrived. Staff working on the comments couldn’t see the registration data or the key. Out of 23,822 comments from 2,855 people, the SRB sent the 1,104 about the valuation to Deloitte on 17 June 2019, on a secure server, codes included. The court records that it was only the SRB who was able, via that code, to link the comments to the data. Deloitte never saw the registration database.

Five complaints reached the European Data Protection Supervisor in late 2019: the privacy statement hadn’t said the answers would go to Deloitte. The EDPS agreed. Its revised decision of 24 November 2020 found Deloitte was a recipient of pseudonymous data and that the information duty had been infringed. It used no corrective powers. It recommended that future notices include all potential recipients of the information collected.

The SRB went to court. On 26 April 2023 the General Court annulled the EDPS’s decision, finding it should have looked at whether the comments were personal data from Deloitte’s side. The EDPS appealed.

The Court of Justice ruled on 4 September 2025. The case ran under Regulation 2018/1725, the data protection rules for EU bodies, but the court said its definition of personal data is essentially identical to the GDPR’s and must be read the same way.

What the court decided

Question	The court’s answer	Paragraphs
Do opinions in the comments “relate” to the people who wrote them?	Yes. Personal opinions are necessarily closely linked to that person.	58 to 60
Is pseudonymised data personal data for everyone?	No. It may not be personal for a recipient that can’t identify anyone with reasonable means.	72 to 86
From whose side do you judge the duty to name recipients?	The controller’s, at the moment of collection.	101 to 115

The court set the General Court’s judgment aside and ruled that the information was personal data. It sent the case back to the General Court on the SRB’s other argument, about good administration. I couldn’t find a ruling on that part yet.

Is pseudonymised data personal data after the ruling?

For whoever holds the key, yes, and nothing in the judgment changes that. The court notes that the SRB, as is usually the case for controllers who have pseudonymised data, had the additional information to put a name to each comment. In the end it held that the information was personal data.

For a recipient, it depends. The court held that pseudonymised data must not be regarded as constituting, in all cases and for every person, personal data. For Deloitte the comments might not be personal, but only if two things were true: Deloitte couldn’t lift the protections, and it couldn’t identify people including by recourse to other means of identification such as cross-checking with other factors.

The flip side is in the same judgment. If the data reaches someone who can reasonably attribute it, by cross-checking with data they already hold, then In such circumstances, pseudonymised data should be considered to be personal in nature. A means isn’t “reasonably likely” when identification is prohibited by law or would take a disproportionate effort.

Is an IP address personal data?

This is where the means test started. In Breyer, on 19 October 2016, the court held that a dynamic IP address logged by a website operator is personal data for that operator where the latter has the legal means which enable it to identify the data subject with the internet provider’s records.

IAB Europe, decided on 7 March 2024, applied the same idea to a code. The TC String, a string of letters that records a visitor’s consent choices and is shared with ad platforms, is personal data where it can, by reasonable means, be associated with an identifier such as the IP address. What the code looks like never decided it. Who can put a person behind it did.

Hashed email, IDs and pixels: what it means for a website

Ad platforms ask you to send customer details, hashed, so they can match them to their users.

• Google’s enhanced conversions take the email, name, address or phone number from your conversion tags, hash them with SHA256, and use them to match your customers to Google accounts that were signed in when they saw an ad, says Google’s help page.
• Meta’s pixel has advanced matching. Pass an email in the base code and Values will be hashed automatically by the pixel using SHA-256.
• For Meta’s Conversions API, the email field says “Hashing required”, and contact details are information that we use for matching purposes only, according to the parameter reference.

A platform that already holds the same email hashes it the same way and finds the person. Deloitte never had access to the data behind the SRB’s codes. An ad platform holds the data behind the hash, and cross-checking against data already at hand is what the court said makes pseudonymised data personal for the receiver.

The EDPB’s draft pseudonymisation guidelines note that if the transformation is just a SHA-256 hash of a name, you could apply this to all names you have elsewhere and see which hashes match. The FTC wrote in July 2024 that hashes aren’t “anonymous” and can still be used to identify users. Its BetterHelp complaint alleged hashed emails went to Facebook, and that BetterHelp knew Facebook would undo the hashing.

The same goes for IDs. An analytics client ID, a user ID or a customer number in a URL is a code whose key is your own database. Sent to a platform with the IP address and the page, it’s a record the platform may be able to link.

None of this removes what the GDPR asks before you send. Article 6(1) still says processing is lawful only if one of its bases applies. If the pixel or tag stores or reads anything on the visitor’s device, Article 5(3) of the ePrivacy Directive applies on top, and it asks for consent unless the storage is strictly necessary for a service the visitor asked for. Nobody fills in a form asking for ad matching. Our guides to the tracking pixel and to Google Analytics and the GDPR go through that part.

Your privacy notice still has to name the recipient

Most explainers skip this half of the judgment. It’s the half the SRB lost. The court held that for the duty to tell people about recipients, identifiability must be assessed at the time of collection of the data and from the point of view of the controller. The SRB had the key, so it had to say who would receive the data. What Deloitte could do later made no difference.

The timing matters, the court says, because it lets people decide whether to provide or, on the contrary, refuse to provide the personal data. For a website, that’s the moment someone fills in a form.

The GDPR has the same duty in Article 13(1)(e): when you collect data from someone, you give the recipients or categories of recipients of the personal data, if any. If your newsletter form hands a hashed email to Meta, Meta is a recipient. So is the newsletter tool, the CRM and anyone else who gets the address.

Processors and independent recipients both count. A processor works on your behalf, and the EDPB’s draft anonymisation guidelines say data that’s personal for you is personal for your processor too; that needs a data processing agreement. Whether an ad platform is your processor or acts for itself depends on its terms. Either way, it goes in the notice. Our privacy policy example shows where.

What the regulators say, and the change the EU is debating

The EDPB adopted its Guidelines 01/2025 on pseudonymisation on 16 January 2025, as a version for public consultation, before the judgment. Attributable pseudonymised data is personal, they say, and This statement also holds true if pseudonymised data and additional information are not in the hands of the same person. The EDPB’s pages still offer only that first version. Its newer Guidelines 02/2026 on anonymisation, adopted on 7 July 2026 and open for comments until 30 October 2026, take the judgment on board. Anonymity is to be assessed from each relevant party’s perspective, and SRB is their worked example of the recipients point.

In the UK, the ICO’s pseudonymisation guidance, published on 28 March 2025, already reads like the judgment: Pseudonymised data is personal data in the hands of someone who holds the additional information. Share it without the key, and it may be anonymous information in their hands. It quotes recital 26 of the UK GDPR, worded as in the EU text, and carries a banner saying it’s under review after the Data (Use and Access) Act.

Then there’s the EU’s digital omnibus. The Commission’s proposal of 19 November 2025 would have added to Article 4(1) that information is not necessarily personal data for every other person or entity. The Council’s mandate, agreed on 21 October 2026 and published as document 14756/26 the next day, strikes those sentences. The Council’s press release says it maintains the current definition of personal data. In its place the Council adds an Article 25a: Pseudonymised data shall not be considered personal data for third party if that third party is unable to identify the natural person. Passed to someone who can identify people, it’s personal data again, and it always is for a processor. That’s SRB written into law, if it survives. Parliament hasn’t adopted its position yet, and talks start after that. Our digital omnibus piece follows the file.

Smaller and larger companies

The rule is the same for every size of company. Both holdings turn on who holds the key and who can cross-check. Headcount doesn’t come into either.

What changes is what gets sent. A small shop typically has a newsletter tool, a contact form and an ad pixel with matching switched on by a plugin. A larger company may run customer lists through data clean rooms with several partners. Same two questions either way: can the receiver identify people, and does your notice name the receiver?

This isn’t legal advice. If you’re relying on data being anonymous in someone else’s hands, write down why, because under SRB that’s a claim about their means, not yours.

Check your own forms and notice from a browser

You need a laptop browser and your phone.

1. In your ad settings, or the plugin that installed them, look for “advanced matching”, “enhanced conversions” or “user-provided data”, and note which are on.
2. Open your site in a private window on a laptop. Open the browser’s developer tools (F12 on most), go to the Network tab and tick “Preserve log”.
3. Reject the cookie banner. Fill in your newsletter or contact form with an address you own and send it.
4. Type facebook, google, doubleclick and tiktok into the Network filter, one at a time, and look at what appears right after you sent the form. A SHA-256 hash is a 64-character string of letters and numbers. Seeing one in a parameter such as em after you clicked Reject is the first thing to fix.
5. Do it again in a fresh private window, this time clicking Accept. Note what goes and where.
6. On your phone, open your privacy notice. Search for each service you saw: Meta, Google, the newsletter tool, the CRM. Does the notice name them, or at least the categories, and say what each one gets?
7. Look at the form itself. Is there a line near the button that links to the notice, at the moment someone types their email?

If a service shows up in step 4 or 5 and not in step 6, you have the SRB’s problem: a recipient the notice doesn’t mention.

Peeky reads your public pages and your privacy notice for the recipients behind them. For services that receive data and aren’t named, the checks are EU-04 and, in the UK, UK-06. For the rest of what a notice has to say at collection, it’s EU-08.

Questions people ask

Is pseudonymised data personal data?

For whoever holds the key, yes. Recital 26 of the GDPR says data that could be attributed with additional information is information on an identifiable person. The EU Court of Justice added in EDPS v SRB that it isn't personal data in all cases and for every person: a recipient with no reasonable means to identify anyone may hold data that isn't personal for it.

What is pseudonymisation under GDPR?

Article 4(5) of the GDPR defines it as processing personal data so it can no longer be tied to a specific person without additional information, provided that information is kept separately and protected. In practice you swap names for codes and lock the list that links the codes back to people. It's a safety measure that lowers risk, not a way out of the GDPR.

Are anonymised data considered personal data?

No. Recital 26 of the GDPR says the rules don't apply to information rendered anonymous so the person is no longer identifiable. The bar is high: nobody should be able to identify the person with means reasonably likely to be used. The EDPB's draft guidelines on anonymisation, open for comments until 30 October 2026, say to assess it from each relevant party's point of view.

Does pseudonymised data include names and addresses?

Not the pseudonymised set itself. The point is to take out or replace what identifies people, which the ICO describes as techniques that replace, remove or transform identifying information. Names and addresses usually sit in the separate additional information, the key, which is kept apart under its own protections. So a quiz line saying pseudonymised data usually includes names and addresses has it backwards.

Is a hashed email personal data?

For an ad platform that holds the same addresses, yes in practice. Google says hashed data sent through enhanced conversions is used to match your customers to Google accounts. The FTC put it plainly in 2024: hashes aren't anonymous and can still identify people. Treat a hashed email as personal data, with a lawful basis and a notice that names who gets it.