Pseudonymization after SRB and Deloitte

Identifiability is relative; consent is not

TL;DR: Pseudonymization reduces risk, but it never replaces consent. If a recipient can reasonably re-identify, treat it as personal data; if not, prove why and keep it that way.

The most helpful way to read the recent ruling (CJEU, Case C-413/23 P) is this: the same dataset can be personal for one recipient and non-personal for another only when the second recipient is objectively unable to re-identify anyone. That means no lawful or practical route to keys, lookups, or auxiliary data, and controls that make re-identification unreasonable in time, cost, and effort. The assessment is recipient-specific, but it is not subjective. You do not lower the threshold because a recipient is non-technical. You ask what this recipient, as an organization, can reasonably do or obtain. If they can get keys, purchase or query linking datasets, or ask the sender to perform joins, then the data is personal for them. Only when those routes are blocked in law and in practice does the same dataset cease to be personal in that recipient’s hands. This is a narrow, factual conclusion - not a license to relax duties at collection, and it does not excuse weak governance or vague promises.

The decision clarified three things that matter in day-to-day operations. First, opinions in submissions are personal data because they relate to the author. Second, pseudonymized data is not automatically personal for everyone; the answer depends on the recipient’s real capability to re-identify. Third, transparency is judged at collection from the controller’s perspective. What you say to people up front still anchors everything that follows.

“If a consultancy receives coded comments without any keys or lookups and cannot lawfully or practically cross-link them, those comments may be non-personal for that consultancy while remaining personal for the sender.”

Mini example: same dataset, different outcomes

• Personal for the recipient: You share survey feedback where the “respondent ID” is a stable hash of the email. An external analytics vendor can join that hash against its own customer emails (or ask you for a keyed join), so re-identification is reasonable. Treat it as personal data for that vendor.
  
  
• Not personal for the recipient (while safeguards hold): You send the same feedback to an independent consultancy as coded comments with no keys or lookups, and contracts/tech controls prevent joins. Re-identification isn’t reasonable for that consultancy, so the dataset may be non-personal in their hands. Keep it that way with separation, logging, rotation, and release-testing.

The consent point that many still miss

Consent cannot be retrofitted. If you want to use data for a purpose, and especially if you want to share it, you need to earn that permission at the moment of collection. You also need to keep the promise. That means four practical things.

1. Tell people clearly what you will use their data for and who will receive it. Name the recipients where possible; do not hide behind generic categories.
2. Separate consents for distinct purposes. Analysis is not the same as marketing. Onward sharing with a specific partner is not the same as internal use.
3. Make withdrawal real. If someone changes their mind, stop the processing that was based on consent and stop new disclosures based on that consent.
4. Version what you said. Keep a record of the exact wording and the choices at the time you collected the data. You cannot prove compliance without this.

Pseudonymization does not neutralize a weak consent story. If the sender is relying on consent for the original collection, the sender must get that consent right at the start. If the sender later shares the data in a form that is no longer personal for the recipient, the sender’s original transparency and purpose limitation still apply.

“If you collected for ‘internal analysis’ only, you cannot rely on later pseudonymization to justify sharing with an external analytics partner. Get separate, granular consent or change your lawful basis.”

With that baseline clear, here’s how to build what you promised at collection - without weakening your pseudonymization claims.

Why identifiability is a technical test

Law frames identifiability; engineering decides it. That is why the ruling is practical. The only meaningful question is whether this recipient, with the safeguards and auxiliary data they can access, can reasonably re-identify the person. If yes, treat it as personal data and apply the full regime. If no, then for that recipient and that specific processing operation, you may be outside personal data. That status lasts only while those facts remain the same.

Two realities make sloppy pseudonymization unsafe. First, AI-assisted linkage has made correlation cheap. Second, stable hashed identifiers create a trail. The moment one record ties back to a person, the rest of the hashed trail becomes linkable. Hashing is useful, but it does not make data anonymous. If you want anonymity, build for anonymity.

The engineering patterns that actually work

The following patterns help, together with their limits. Use them as design choices, not as marketing labels.

When the recipient will still be in personal data

• Tokenization with a lookup table kept by the sender. Treat tokens as personal inside your organization. Share only where the recipient’s role justifies access to the token stream.
• HMAC or keyed hashing for de-duplication or joins. Useful for workflow. Still personal, and the key space is part of your risk model.
• Pseudonymized telemetry for product analytics. Rotate identifiers, reduce precision, and set hard retention caps. Assume personal unless you can prove non-identifiability for that recipient.

When the recipient may be outside personal data

• Tokenization with hard key separation and a contractual and technical prohibition on lifting safeguards. Prove that the recipient cannot access keys, lookup tables or auxiliary data that would make re-identification reasonable.
• Aggregation with k-anonymity family targets. Design groups large enough to prevent singling-out. Re-evaluate when data refreshes.
• Differential privacy for published statistics. Excellent for counts and rates. Do not try to publish row-level data under the same claim.
• Synthetic data for development and demos. Validate against membership inference and linkage tests. Treat failures as a trigger to fall back to personal data handling.

Controls that turn claims into facts

• Separate trust zones. Store keys, lookup tables and raw identifiers in a different environment with separate administrators.
• Least privilege and logging. Prove that the recipient cannot escalate to lift safeguards. Keep tamper-evident audit trails.
• Rotation and minimization. Rotate salts and identifiers, drop fields, and reduce temporal and spatial precision where it does not harm the purpose.
• Testing as part of release. Run linkage and singling-out tests before each share or publication. Treat identifiability as a regression risk that can reappear.
• Crypto agility. Plan for parameter updates and post-quantum options. Do not build yourself into a corner.
• Supplier due diligence. Assess the recipient’s actual data estate and incentives. The test is what they can do, not what you hope they will not do.

DSARs, onward sharing, and record-keeping

The sender’s transparency duties bite at collection. If you will send data to a partner for analysis, say so. If the partner cannot identify people and will not receive keys or auxiliary data, say that too, but do not skip the disclosure. The partner’s obligations then depend on whether the partner can identify the person. If the partner can, it is personal data and they must act like it. If the partner cannot, document why not and maintain that state of affairs with technical and contractual controls.

DSAR quick case: A free-text comment (“My manager Anna…”) is the author’s personal data. You redact third-party names where necessary, but you don’t reject the request just because the text was pseudonymized.

For subject access requests, treat opinions and free-text comments as personal data of the author. Apply redaction and balancing where other people’s rights are involved. Do not use pseudonymization as a reason to ignore the request. Use it to scope what you can disclose safely.

Having grounded DSARs in the recipient test, let’s reconcile the two authorities shaping identifiability in 2025 - EDPB guidance and the CJEU’s SRB/Deloitte judgment.

EDPB vs. CJEU on Pseudonymization: Two Ways to Say the Same Thing

They are largely aligned. Both use a recipient-specific, “means reasonably likely” test. The EDPB Guidelines 01/2025 on Pseudonymization gives the structure (a pseudonymization domain where attribution must be prevented). The CJEU applies the same logic to say the same dataset can be non-personal for a recipient who cannot reasonably re-identify - without relaxing the sender’s duties at collection or ignoring foreseeable onward recipients.

What the EDPB actually says

• Context matters. Ask whether attribution is reasonably likely in the concrete scenario, not in the abstract.
• Pseudonymization domain. Define who/what is inside the domain (people, systems, controls) and make sure linking is blocked in that domain.
• Before transmission. Map the recipient’s practical means to re-identify and put contract + technical controls between them and any keys/lookups.

What the CJEU actually held (SRB/Deloitte)

• No blanket rule. Pseudonymized data are not automatically personal “for everyone.” Assess identifiability from the recipient’s perspective and their reasonably likely means (including joins/lookups).
• Controller duties remain. At collection, if you can attribute, you are in personal data and must meet the full regime (transparency, purpose, lawful basis, naming recipients).
• Facts drive outcomes. If a recipient cannot lawfully or practically access keys or linking datasets, the same data may be non-personal in their hands - while staying personal for you.

So… aligned or divergent?

Aligned in substance. The EDPB’s “domain + reasonably likely means” framework dovetails with the CJEU’s recipient-specific test. The perceived conflict comes from old shorthand (“pseudonymized data remain personal data”) being read universally. Both insist on documented, contextual analysis - not absolutism.

In practice (why this matters right here)

• Document the recipient test. For each share, record what the recipient could realistically use to re-identify and why that route is blocked in law and in practice.
• Condition any “non-personal for recipient” claim. State the preconditions (no keys/lookups, no feasible joins, controls in place) and when you’ll re-check.
• Keep collection promises intact. Your notices/consents reflect your capability to attribute and must name recipients - even if some recipients cannot re-identify.

With the concepts aligned, the implementation stays the same - jump to “Consent anchored design” for how to ship it.

Why consent is required at collection (GDPR + ePrivacy 5(3))

At the moment of collection, GDPR requires lawfulness, fairness and transparency (Art. 5(1)(a)), and a lawful basis such as consent for specified purposes (Art. 6(1)). Where consent is relied on, it must meet the GDPR definition - freely given, specific, informed and unambiguous - and be as easy to withdraw as to give (Arts. 4(11), 7(3)). Separately, the ePrivacy Directive Art. 5(3) requires prior consent before storing or accessing information on a user’s device (e.g., cookies, local storage, SDKs) unless it is strictly necessary for the service requested. In practice: if a tag/SDK writes or reads on the device (and isn’t strictly necessary), you need explicit consent before it runs; and if you rely on consent for processing, you must earn it at collection and be able to prove it later.

With the legal baseline clear, here’s the consent build pattern that meets GDPR and ePrivacy in practice.

Consent anchored design

Here’s the build pattern behind that consent promise.

• Layered notice. A clear summary in the first layer that names the purposes and recipients, with a deeper layer for detail.
• Granular choices. A checkbox for each materially different purpose. No forced bundling into one consent.
• Named recipients. If you know who you will use, say so. If you truly do not, define the classes narrowly and commit to publishing a live list.
• Durable records. Store the exact text and options shown at the time of collection and the user’s choice. Keep a consent ledger with timestamps and scope.
• Revocation that works. Make it one click to withdraw. Stop new processing that depends on consent. Communicate withdrawals to downstream processors.
• Purpose limitation in code. Bind data flows to purpose tags and block uses that are not explicitly consented. Treat this as a deployment gate, not a policy.

From theory to execution

If you send data

1. Rewrite your collection wording to reflect actual purposes and actual recipients. Do it in plain language.
2. For each recipient, write a short identifiability assessment that a security engineer can sign and a lawyer can understand. Keep it with the data map.
3. Decide where pseudonymization is good enough and where you need true anonymization or aggregation. Build the missing controls.
4. Do a tabletop exercise on withdrawal. Prove that you can stop a consent-based flow end-to-end.
5. Remove the words anonymous and anonymized wherever they are not strictly true. Replace them with the pattern you actually use.

If you receive data

1. Declare whether you can identify people with the data and resources you have. If the answer is yes, comply as a controller or processor as appropriate.
2. If the answer is no, lock in that answer with technical controls and contracts that prevent you from lifting safeguards.
3. Refuse data you do not need. It is easier to prove non-identifiability when you do not collect extra fields in the first place.

Consent requirements are fixed at collection, identifiability is relative

Pseudonymization can reduce risk. It does not replace consent, purpose limitation or transparency. Identifiability is relative and changes as capabilities and datasets evolve. Build for both truths at once. If you want the freedom to share, you have to win it at collection with honest wording and real choices, and then protect it with engineering that would stand up in a courtroom and in a code review.

Win consent at collection; defend non-identifiability with evidence.

Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io