Pseudonymisation vs Encryption Under the GDPR

Pseudonymisation and encryption are the only two technical measures that the GDPR names explicitly in Article 32(1)(a), and they are often confused. Both transform personal data so that it is harder to use without a secret. But they solve different problems, have different legal consequences, and fail in different ways. Encryption protects confidentiality: without the key, the data is unintelligible. Pseudonymisation separates identity from the rest of the data so that the dataset can still be used, joined and analysed without revealing who each record belongs to. This guide sets out what the regulation says, which techniques work, and where teams commonly get it wrong.

What the GDPR says

Pseudonymisation: Article 4(5)

Article 4(5) defines pseudonymisation as processing personal data in such a manner that it can no longer be attributed to a specific data subject without the use of additional information, provided that this additional information is kept separately and is subject to technical and organisational measures to ensure non-attribution. Two conditions matter for engineers: the additional information (a key, a lookup table, a token vault) must be kept separately, and it must itself be protected.

Pseudonymised is not anonymous: Recital 26

Recital 26 draws the line that shapes everything else. Pseudonymised data that could be attributed to a person using additional information is still personal data. Only anonymous information, which does not relate to an identified or identifiable person, falls outside the scope of the GDPR. Identifiability is judged by the means reasonably likely to be used, by the controller or by another person, to identify the individual. In practice this means a pseudonymised dataset remains in scope: it still needs a lawful basis, retention limits, security and an entry in your record of processing. For the criteria for real anonymisation, the Article 29 Working Party's Opinion 05/2014 on anonymisation techniques identifies three risks to test against: singling out, linkability and inference. See also the glossary entry on anonymisation.

Where the two measures appear

Recital 28 notes that pseudonymisation can reduce risks to data subjects and help controllers and processors meet their obligations, while making clear it is not intended to preclude other measures. The EDPB's Guidelines 01/2025 on pseudonymisation, adopted in January 2025 and put to public consultation, confirm that pseudonymised data remains personal data and describe how pseudonymisation can support data protection by design, security and the balancing test for legitimate interests. They also introduce the concept of a "pseudonymisation domain": the set of people or systems from which the pseudonymised data should not be attributable to individuals. Defining that domain explicitly (for example, "the analytics team and the data warehouse") is a useful design step.

Encryption: protecting confidentiality

Encryption is a confidentiality control. In practice security teams deploy it in three layers:

• In transit. TLS for all external and internal service traffic, including database connections and log shipping.
• At rest. Disk, volume or storage-service encryption. It protects against lost media and some infrastructure-level threats, but not against an attacker who authenticates to the application or database, because the platform decrypts transparently.
• Application or field level. Encrypting specific columns or documents with keys the database cannot access. This protects against database-level compromise and privileged storage administrators.

The strength of encryption is entirely a question of key management. Keys should be generated and stored in a key management service or hardware security module, separated from the data they protect, rotated, access-controlled by role and logged on use. If the key sits in the same compromised environment as the ciphertext, the data is not unintelligible to the attacker and Article 34(3)(a) will not help you. For breach handling, see our guide on breach notification within 72 hours.

Pseudonymisation techniques

Why plain hashing fails

A common first attempt is to replace an email address or national ID with its SHA-256 hash. It feels irreversible, but it is not. Email addresses, phone numbers, customer numbers and national identifiers have low entropy or predictable formats. An attacker, or a curious analyst, can hash every plausible value (every phone number in a country, every email in a leaked list) and look up matches. The hash is also stable across organisations, so two datasets pseudonymised the same way can be joined trivially. A plain unsalted hash of such identifiers should be treated as reversible.

Keyed hashing (HMAC)

Keyed hashing solves both problems. An HMAC with a secret key produces a stable pseudonym (so joins within your domain still work) that cannot be recomputed by anyone without the key. The key is the Article 4(5) "additional information" and must be kept separately.

import hmac
import hashlib
import unicodedata

def normalise_email(value: str) -> str:
    """Normalise before hashing so the same person maps to one pseudonym."""
    return unicodedata.normalize("NFKC", value).strip().lower()

def pseudonymise(value: str, key: bytes, context: str) -> str:
    """
    Keyed pseudonym using HMAC-SHA256.
    - key: secret retrieved at runtime from a KMS/secret manager,
      never stored with the pseudonymised dataset.
    - context: domain separation label (e.g. "analytics-v1") so the same
      identifier yields different pseudonyms in different domains.
    """
    message = f"{context}:{value}".encode("utf-8")
    return hmac.new(key, message, hashlib.sha256).hexdigest()

# Example usage (key loaded from a secret manager in real code)
# key = secret_manager.get("pseudonymisation/analytics-v1")
# pid = pseudonymise(normalise_email("Alice@Example.com"), key, "analytics-v1")

Design notes:

• Use a different key or context label per pseudonymisation domain, so datasets shared with different recipients cannot be linked.
• Plan key rotation: rotating the key changes every pseudonym, so treat it as a re-pseudonymisation event with a migration plan.
• Restrict who can call the pseudonymisation service. If anyone can submit a candidate email and get its pseudonym back, they can reverse pseudonyms by enumeration, just as with plain hashes.
• Pseudonymise identifiers, but also review quasi-identifiers (postcode, date of birth, job title) that allow re-identification by combination.

Tokenisation with a vault

Tokenisation replaces an identifier with a random token and stores the mapping in a protected vault. Unlike HMAC, tokens carry no mathematical relationship to the original value, and re-identification is possible only through the vault, which can enforce authorisation, purpose checks and logging on every lookup. Tokenisation suits cases where controlled re-identification is a business need (for example, support staff resolving a flagged case), at the cost of operating a highly available, well-protected vault.

Choosing a technique

For transfers outside the EEA, pseudonymisation where the re-identification information stays in the EEA is one of the supplementary measures discussed in the EDPB's Recommendations 01/2020; our international transfers guide covers when that is effective.

Common mistakes

• Treating pseudonymised datasets as out of scope and skipping retention, access control or the record of processing.
• Storing the HMAC key or token vault in the same database, bucket or account as the pseudonymised data, which breaks the "kept separately" condition of Article 4(5).
• Relying on storage-level encryption as the only control, then assuming Article 34(3)(a) applies to a breach through the application layer.
• Leaving free-text fields untouched, so names and emails survive inside notes and comments.
• Forgetting logs, caches, search indexes and analytics exports, which often hold the original identifiers.

ENISA has published technical reports on pseudonymisation techniques (2019 and 2021) that are worth reading alongside the EDPB guidelines when designing a scheme. For the underlying concept in brief, see the glossary entry on pseudonymisation.

Scope of this guide

This article is technical guidance for security and IT teams choosing and implementing pseudonymisation and encryption. It is not legal advice. Whether a dataset is anonymous, whether a measure meets Article 34(3)(a) in a given breach, and how pseudonymisation affects your lawful basis should be confirmed with your DPO or legal counsel.