Pseudonymisation¶

Replacing direct identifiers with a token and keeping the additional information separately is one common form of what Article 4(5) calls pseudonymisation, which asks for the separation and for measures keeping it in place rather than for any particular technique. The data stays personal data for the party holding the key. Whether it is personal data for whoever receives it is a separate question, and the answer is not a property of the file. It depends on what else the recipient can reach.

The key stays behind¶

A holder splits one table in two. The records go out keyed by an opaque token. The mapping from token to person stays behind.

# Holder
for person in table:
    token = random_id()
    key_table[token] = person.name
    released[token] = person.attributes      # name removed

send(released) to recipient
keep(key_table)

# Recipient, told the file is anonymous
for record in released:
    # the token means nothing without the key
    # but the record still carries the attributes that came with it
    candidates = anything else the recipient holds, matched on those attributes
    if exactly one candidate:
        the record is attributable, and no key was needed

The key is one route to a person and not the only one. A record with enough other detail narrows to one candidate when it is matched against another source, and a recipient who was told the file was anonymous is then holding personal data without ever being given the thing the holder meant to withhold. Pseudonymisation removes one attribution path; a linkage attack looks for another. Which paths exist is a property of the recipient.

What settles it is what the recipient already holds to match the file against. Whether the file was pseudonymised does not.

Whose hands it lands in¶

greenhouse-attacks’ pseudonymisation.py pseudonymises 100,000 generated records, holds the key back, and asks the same release what it identifies in several pairs of hands. The token is drawn independently of the row, so nothing in it narrows anybody. Attributable below means that a released record matches exactly one person in the recipient’s data on the columns they hold, and that no other released record shares that combination.

One file, one key withheld, and the answer runs from nobody to everybody depending on who is holding it. A recipient with a customer list is in a different position from one with an electoral roll, and the file itself does not reveal which position applies.

One standard disclosure-control technique is to coarsen the released columns, and in this experiment it does little until it goes much further than most releases go:

Thirteen columns at six groups each leave almost everybody attributable. The large drop arrives between three groups and two. By that point the categories are substantially coarser, so the release has discarded a good deal of information as well; how much analytical value survives is a separate question, and not one these numbers answer.

In this experiment, cutting columns out of the release reduces attribution faster than coarsening the ones that stay:

One file, two holders¶

The Court of Justice took this up in EDPS v SRB, decided on 4 September 2025, on a transfer of pseudonymised comments from the Single Resolution Board to Deloitte under the regulation that applies the same rules to EU institutions. It confirmed that pseudonymised data “must not be regarded as constituting, in all cases and for every person, personal data”, because pseudonymisation may, depending on the circumstances, “effectively prevent persons other than the controller from identifying the data subject in such a way that, for them, the data subject is not or is no longer identifiable”.

That makes identifiability relative. One file, two holders, two answers, because the means of identification reasonably available to each can differ.

The same judgment sets a limit on reading that relativity too freely. On whether the Board should have told people their comments would be passed on, the Court held that identifiability “must be assessed at the time of collection of the data and from the point of view of the controller”, and that the duty to inform applied before any transfer, whether or not the comments were personal data once Deloitte held them. What the recipient can reach settles what the recipient is processing. It does not settle what the sender owed the people it collected from.

Breyer drew the same kind of distinction for dynamic IP addresses. The question was not whether a website operator could identify the subscriber from the address alone, but whether it had means reasonably likely to be used for obtaining the rest from the access provider. The data did not change. The holder did.

For anyone releasing a dataset this is the uncomfortable part: identifiability turns partly on the means reasonably likely to be available to the recipient, and a controller does not always know what a recipient’s information environment holds. A recipient with an electoral roll, a customer list or a second release from the same population is in a different position from one with nothing, and the file is identical in both cases.

Sending fewer columns¶

Cutting columns reduces attribution faster than coarsening the ones sent. An attribute that stays behind cannot be matched against anything, and the count falls away sharply once the release drops below eight columns. Deciding what the recipient needs is therefore the first question to settle.

Generalising the attributes comes second, and reduces the count by less than is usually assumed. Publishing an age band instead of a date of birth and a region instead of a postcode does reduce the number of records standing alone, but thirteen columns at six groups each still leave 99% attributable. The protection arrives where the categories are coarse enough that most of the analytical value has gone with them. A release of this kind is making that trade whether or not it says so.

A contractual undertaking not to re-identify does not make the data non-personal. It restricts what that recipient is permitted to do, which is a different kind of protection: a contract binds the party who signed it, and says nothing about what another party could do with the file if it reaches them later.

Last reviewed: 2026-09-20.