Pseudonymisation.

What pseudonymisation actually does

Pseudonymisation is a data protection technique, not a status the data reaches. You take the fields that point straight at a person, the name, the email, the national identity number, and you swap them for a token: a random identifier, a coded reference, an encrypted value. The mapping that turns the token back into the real identity, the key, is held separately and protected with its own technical and organisational measures. Anyone working with the pseudonymised dataset can analyse, share or test against it without seeing who the records belong to, while the organisation keeps the ability to re-identify when it has a legitimate reason to.

The GDPR names this technique explicitly and treats it as a recommended safeguard. It appears as a way to meet data protection by design and by default, as a measure that can lower the residual risk of a processing activity, and as a factor that supervisory authorities weigh favourably when they assess whether you have done enough. Using it is a signal that you took security and minimisation seriously. That is the goodwill the short definition points to, and it is real, but it does not change the legal nature of the data.

Pseudonymisation is not anonymisation

This is the conflation that gets organisations into trouble. Because a pseudonymised record no longer carries a visible name, people assume it has left the scope of the regulation. It has not. Pseudonymisation is reversible by design: the key exists, so the data can be linked back to an identifiable person, so it remains personal data and every obligation still applies. Anonymisation is the opposite bargain. It is irreversible, the link to the individual is destroyed so thoroughly that re-identification is no longer reasonably possible by any means likely to be used, and only then does the data fall outside the GDPR entirely.

What practitioners actually do

In practice pseudonymisation is an engineering and governance discipline rather than a single switch. The point of separating the key is defeated if the same team, system or backup holds both the tokens and the mapping, so the controls around the key matter as much as the tokenisation itself.

• Replace direct identifiers with tokens, using methods such as keyed hashing, encryption or a lookup table of random references.
• Store the re-identification key separately, under stricter access control than the working dataset, ideally owned by a different team.
• Guard against indirect re-identification, where rare combinations of remaining fields (a postcode plus a birth date plus a job title) single someone out even without a name.
• Document the technique in the record of processing and the DPIA, and treat the pseudonymised data as personal data for breach assessment, retention and subject rights.

Done well, pseudonymisation lets analytics, research and software testing run on realistic data while shrinking the blast radius of a breach, because an attacker who gets the tokens without the key holds far less. Done carelessly, with the key reachable or the indirect identifiers ignored, it offers the appearance of protection without the substance, and the organisation still carries every obligation it thought it had escaped.