Pseudonymized data after EDPS v SRB: what changed in Europe

The guidance, the judgment, and the working rule for teams that hold the mapping

A conservative default while the guidance is revised

If your team replaces customer names with codes like PERSON_001 and keeps the table that turns the codes back into names, treat the aliased file as personal data under the GDPR. Both the guidelines and the judgment support that rule for the side holding the mapping. The EDPB's guidelines state it for everyone who touches the data, and the Court of Justice judgment that qualified those guidelines states it for the sender: the party holding the mapping is processing personal data on every reading, the board's and the Court's alike (executive summary, p. 4; judgment para. 76).

Staying inside the GDPR does not make aliasing pointless. Classification and risk are separate questions, and pseudonymisation reduces what a mis-addressed email or an over-broad share can expose — a reduction the regulation credits in specific articles, covered below. What changed during 2025, and what remains genuinely unsettled, is the recipient's side: whether an aliased file counts as personal data for a party who has no realistic way to reverse the codes. The sections below follow that shift in order.

The timeline: draft guidelines, the judgment, pending revisions

In January 2025 the European Data Protection Board adopted its first guidance devoted entirely to a technique the GDPR has defined, and named as a safeguard, since 2016. Within a year a Court of Justice judgment had rejected the guidance's strictest claim, and the board's revision is still in progress.

The guidelines are still the version adopted for consultation on 16 January 2025: the board spent a 12 December 2025 stakeholder event weighing the SRB judgment, and the revised final text sits in its 2026–2027 work programme alongside the anonymisation draft — which already takes the Court's side. Until that final text lands, the conservative default above is the stable ground.

The Digital Omnibus would move the line again — if it passes

The last two rows of that timeline are a live legislative fight, and it is worth knowing about because it targets the exact sentence this post turns on.

The Commission's Digital Omnibus, proposed on 19 November 2025, would add a paragraph to Article 4(1) stating that information "shall not be personal for a given entity where that entity cannot identify the natural person to whom the information relates, taking into account the means reasonably likely to be used by that entity," and that such information "does not become personal for that entity merely because a potential subsequent recipient" could identify the person. A proposed new Article 41a would let the Commission specify, by implementing act, the criteria under which pseudonymised data stops being personal data for certain entities. The Commission presents both as codifying the Court's case law, the SRB judgment in particular.

The two European data protection authorities disagree that this is mere codification. In Joint Opinion 2/2026, adopted 10 February 2026, the EDPB and EDPS conclude that the amendment "goes far beyond a targeted modification of the GDPR, a 'technical amendment' or a mere codification of CJEU jurisprudence," and "strongly urge the co-legislators to not adopt the proposed changes to the definition of personal data" (para. 21). On the implementing-act power they are equally direct, suggesting Article 41a be deleted from the proposal (para. 25), on the reasoning that deciding what counts as personal data belongs to supervisory authorities and courts rather than to an implementing act. They also argue the open questions the SRB judgment raises are better handled by the guidance the board is already preparing than by rewriting the definition (para. 19).

None of this is law. The Digital Omnibus is a proposal in negotiation between the Parliament and the Council, either of which can change or drop any part of it, and the file was still open when this post was last reviewed. For a team holding a mapping, nothing in it changes the working rule. Every version of the relative test — the Court's, the Commission's draft, the board's reading — agrees that the party who can reverse the codes is processing personal data. What is being fought over is the recipient's side of the line, which was already the unsettled half.

Two terms, two GDPR statuses

"We anonymized it" is one of the most overclaimed sentences in data work, and the guidelines draw the line it usually blurs.

For the party holding the mapping, the file remains personal data on both the EDPB's and the Court's reading.

On the second row, the January guidelines go further than the relative wording above. Paragraph 22 states that pseudonymised data "which could be attributed to a natural person by the use of additional information, is to be considered information on an identifiable natural person," and is therefore personal — and that this "holds true if pseudonymised data and additional information are not in the hands of the same person." The same paragraph closes an escape hatch: deleting every copy of the mapping does not automatically produce anonymous data — the output must independently meet the conditions for anonymity, and a table with names aliased but birth dates and job titles intact rarely does. In the guidelines' January text, a file of PERSON_001s is personal data as long as anyone, anywhere, holds the information to turn it back. The judgment in the timeline softened that claim for recipients; for the sender who keeps the mapping, it stands.

If the choice in front of you is between erasing values and aliasing them, that is a separate and more practical decision; Redaction vs. pseudonymization: which keeps your spreadsheet useful? compares the two.

Who holds the mapping, and what a recipient can reasonably do

Paragraph 5 compresses effective pseudonymisation into three actions, and the rest of the guidelines elaborate on them:

• Transform the data so it can no longer be attributed to a person without additional information (paras. 5, 16–18); consistent aliasing is one of the transformations Article 4(5), quoted at paragraph 16, anticipates.
• Keep the additional information — mapping tables "matching pseudonyms with the identifying attributes they replace," or cryptographic keys — separately, away from whoever is to be prevented from re-identifying, and undisclosed to the people processing the aliased data (paras. 5, 20).
• Apply technical and organisational measures scoped by a risk assessment: define the "pseudonymisation domain" — who must be unable to attribute the data — and weigh the means they could reasonably use (paras. 35–38, 42).

The second action is the one the Court tested. In EDPS v SRB (C-413/23 P, judgment of 4 September 2025), the Single Resolution Board had aliased shareholder comments with alphanumeric codes and passed them to Deloitte while keeping the key. (The case ran under Regulation 2018/1725, the EU institutions' own regulation, whose definition of personal data is essentially identical to the GDPR's.) Classification, the Court held, is relative to who holds the data. For the SRB, which kept the additional information, the comments remained personal (para. 76); for Deloitte, the separation measures may "have the effect that, for that company, those comments are not personal in nature" (para. 77) — pseudonymised data "must not be regarded as constituting, in all cases and for every person, personal data" (para. 86). The Court's own presuppositions do the tempering: Deloitte must be unable to lift those measures, and they must genuinely prevent attribution, "including by recourse to other means of identification such as cross-checking with other factors" (para. 77). No general exit, then — the assessment runs case-by-case, and the sender who keeps the mapping is still processing personal data, with transparency duties judged at collection (para. 112).

Two limits matter when applying the guidelines. The GDPR imposes no general obligation to pseudonymise — the executive summary says so directly. And pseudonymisation alone is rarely enough; paragraph 44 notes it is "often most effective when complemented by additional measures." In return, the risk reduction can support a legitimate-interests basis under Art. 6(1)(f) and counts toward data protection by design (Art. 25) and security of processing (Art. 32). Trilateral Research's practical commentary walks the January text in more depth — written before the SRB judgment, which has since answered some of its open questions.

Strip the legal language and the separation requirement is a filing rule: the alias table is the key to the whole exercise, so it cannot live next to the data it unlocks. The judgment raises the stakes on this rule, because whether a recipient can reasonably re-identify anyone depends on how far the mapping sits from their reach. The classic failure is mundane — mapping.xlsx in the same shared folder as export_aliased.xlsx, readable by everyone the aliasing was supposed to protect against. A recipient who can open the mapping holds the additional information, and the file in their hands is personal data on any reading, the Court's included.

One way to implement the separation is to keep the mapping off servers entirely. Data Alias runs its parsing, detection, and aliasing inside the browser tab, so the mapping never exists on our servers. How that works, and how to check it with an offline test, is documented in How browser-local file processing works—and how to verify it. By default the mapping is discarded with the session on reset or refresh. When it needs to outlive the session — next month someone asks which customer PERSON_017 was — there are two options, both on your side of the line. You can download the mapping as a CSV, an explicit and clearly labeled act since that file contains the original values by design, and later feed it to the restore page, which reverses a safe copy against it in the browser. Or you can keep mappings in the opt-in vault, stored in your own browser and encrypted with a key derived from a passphrase that is never stored. Either way the separation is physical: the aliased copy travels, and the means of reversing it stays with you. These are implementation details rather than legal conclusions. Using this tool, or any equivalent, does not by itself change your legal position. Whether a given setup meets paragraph 5 depends on handling no tool can see — who can reach the mapping file once it is exported, what else the table contains, and what the recipient could reasonably do with it.

Aliases do not remove every identifier

Swapping names for codes does not by itself satisfy the conditions for anonymity. A table that keeps exact dates, rare job titles, and small-team locations can still point to one person once a recipient cross-checks it against other information — the same "other means of identification" the Court told recipients to account for. Treat those fields as part of the pseudonymisation work, not as leftovers.

Detection is the other gap. A pseudonymisation measure covers only the values that were actually transformed, and pattern-based detection misses some of them. What automatic PII detection misses in spreadsheets lists the recurring cases; review before export is part of the measure itself.

When to involve legal review

For everyday work, the reading above supports three habits: alias before sharing, keep the mapping where recipients cannot reach it, and treat any file you can reverse as personal data. Some decisions need more than habits. Bring in your DPO or counsel when pseudonymisation is load-bearing in your processing — when a legitimate-interests assessment depends on it, when an aliased dataset leaves the organization and the recipient's status under the judgment matters, when someone proposes to treat an aliased file as anonymous, when the final guidelines land and your setup was built on the January text, or when the Digital Omnibus concludes and the definition it settles on differs from the one you planned against.

A pseudonymized copy is also no substitute for permission. If your organization requires approval before data goes to an external analyst or AI service, aliasing the file does not grant it — the copy you can reverse is still personal data, and whether it stops being personal for the recipient turns on facts a review has to establish. The paragraph numbers above are for exactly that conversation. This post is a practitioner's reading of moving parts; it is not legal advice.