When Is a Hash Personal Data? The CJEU's SRB Ruling and Analytics Identity
The CJEU's EDPS v SRB judgment made identifiability a relative, contextual test. Here is what that means for hash-based analytics — and why a daily-rotating salted hash survives both the court's reading and the EDPB's stricter one.
The question every analytics vendor dodges is simple to ask and hard to answer: is the identifier in your database personal data? On 4 September 2025 the CJEU gave the most consequential answer in years, and it reframed the entire test around context rather than the data in isolation.
What EDPS v SRB actually decided
The case — EDPS v SRB, C-413/23 P — came out of the Banco Popular resolution. The Single Resolution Board collected comments from shareholders, replaced each author's identity with an alphanumeric code, and sent the coded comments to Deloitte as an independent valuer. Deloitte held no key to reverse the codes and had no other route to the authors.
The CJEU held that pseudonymised data is not automatically personal data for every party that touches it. Whether a dataset is personal data is assessed relative to the holder — from the position of the specific recipient, accounting for the technical, organisational, and legal means realistically available to them.
This is the relative (or contextual) identifiability test, and it is the operative reading of Recital 26's "means reasonably likely to be used." Data that is personal in the controller's hands can be non-personal in the hands of a recipient who genuinely cannot re-identify anyone.
The tension with the EDPB
The court did not give vendors a free pass. The EDPB's Guidelines 01/2025 on pseudonymisation take a deliberately stricter line: pseudonymised data remains personal data as long as anyone — the controller or some third party — retains the means to re-identify. The February 2026 EDPB stakeholder report on anonymisation and pseudonymisation is the board working through exactly this gap between its position and the court's.
For developers the practical reading is conservative. Do not assume a hashed value is out of GDPR scope just because your service cannot reverse it. The right question is whether re-identification is reasonably likely for anyone holding the additional information — and whether that additional information still exists at all.
Why most analytics hashes fail the test
Hashing an identifier is not anonymisation. A SHA-256 of an email address is deterministic: the same email always yields the same digest. Anyone with a list of candidate emails can hash them and match. The hash is a stable, linkable key — pseudonymisation at best, and personal data under either the court's reading or the EDPB's, because the means to re-identify are trivially available.
The same trap catches a hashed IP, a hashed device ID, or any digest of an input drawn from a small, enumerable space. Determinism plus a guessable input equals re-identification. The hash function changes the bytes, not the linkability.
What makes a hash genuinely defensible
Two properties move a hash from "pseudonymised personal data" toward "not reasonably re-identifiable": a secret salt that is never stored alongside the data, and an input that cannot be exhaustively guessed and does not persist across time. Monoid's identity model is built on exactly that:
SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)
The raw IP and User-Agent live only in Worker memory long enough to compute the digest; D1 stores the hash, never the inputs. The SALT_SECRET is held server-side and never written next to the data, so a rainbow-table or brute-force attack against the stored hashes has no anchor. And because the date is an input, the digest for the same visitor rotates every midnight UTC. There is no stable cross-day key to correlate against.
Run that construction through both tests. Under the CJEU's relative standard, no recipient of the stored hashes — including Monoid querying its own D1 — holds the means reasonably likely to re-identify, because the salt is segregated and the input is non-enumerable. Under the EDPB's stricter "anyone" standard, the additional information needed (raw IP plus UA plus the secret salt for that specific date) is not retained anywhere after the request completes. The means to re-identify are not merely restricted; they cease to exist.
How to audit your own stack
The ruling gives you a concrete checklist to apply to any analytics you rely on:
- Is the hashed input enumerable? An email, a phone number, or a raw IP can be hashed and matched against a candidate list. If the input space is small, the hash is reversible in practice.
- Is a secret salt segregated from the stored data? A hash without a salt, or with a salt sitting in the same store, offers no real barrier to re-identification.
- Does the identifier persist across sessions? A stable key that links a person's activity over weeks is personal data under every reading. A key that rotates daily cannot accumulate a profile.
The CJEU did not declare pseudonymisation a safe harbour, and the EDPB is making sure no one reads it that way. The durable position is the one that needs neither interpretation to win: a salted, daily-rotating hash over a non-enumerable input is not reasonably re-identifiable by anyone, because the material required to reverse it was never kept.
Comments
Loading comments…