Tokenisation vs Encryption Under UK GDPR: Which Protects Personal Data Better, and When?

Ask ten engineers how to protect personal data in a database and most will say "encrypt it". They are not wrong, but the answer hides an important question: protected from whom, and at what point? Encryption at rest protects against a stolen disk. It does very little against an attacker who compromises the application, because the application decrypts data to use it. Tokenisation takes a different approach, removing sensitive values from systems that do not need them at all.

This article compares the two under UK GDPR, explains where each is the stronger control, and looks at a newer use case: keeping personal data out of AI prompts.

How encryption works in practice

Encryption transforms data using a key, so that only someone with the key can recover it. It appears at several layers: storage encryption on disks and cloud volumes, transport encryption with TLS, database encryption such as transparent data encryption, and application-level or field-level encryption, where specific fields are encrypted before being stored.

The weakness is not the algorithm. Modern algorithms such as AES-256 are sound. The weakness is that the keys must be available wherever data is used. If an attacker controls the application or a privileged account, they can usually read the data as the application does. Storage-level encryption, in particular, is transparent to anyone with legitimate database access, including an attacker using stolen credentials.

How tokenisation works

Tokenisation replaces a sensitive value, such as a National Insurance number, card number or email address, with a surrogate token. The original value is held in a separate, tightly controlled vault, or derived using cryptography whose keys are held only in the tokenisation service. Downstream systems, such as analytics, CRM or support tools, work with tokens and never see the original data. Format-preserving tokens keep the same length and format as the original, so existing schemas and validation logic continue to work.

The security benefit is architectural. A breach of a system holding only tokens exposes tokens, not personal data, provided the tokenisation service itself is not also compromised.

What UK GDPR says

Article 32 of the UK GDPR requires appropriate technical and organisational measures for security, and names pseudonymisation and encryption as examples. Both are therefore recognised controls, but neither is mandatory in every case. The ICO's guidance on encryption expects organisations to have a policy on its use and to consider it for personal data, particularly on portable devices and in transit.

A key point is that pseudonymised data is still personal data under UK GDPR, because it can be re-identified using additional information. Tokenised data held by the organisation that controls the vault is pseudonymised, not anonymised. Tokenisation reduces risk; it does not take data out of scope of the law.

Breach notification

Under Article 34, if a personal data breach is likely to result in a high risk to individuals, you must tell them, unless measures such as encryption have rendered the data unintelligible to anyone not authorised to access it. Strong encryption with uncompromised keys, or tokens with an uncompromised vault, can therefore change the outcome of a breach significantly. You still need to assess and record the breach, and consider whether to notify the ICO within 72 hours, so this is risk reduction, not an exemption from process.

Where tokenisation is the stronger control

• Analytics and data warehouses: analysts rarely need real identities. Tokens preserve joins and counts without exposing people.
• Payment card data: the PCI Security Standards Council recognises tokenisation as a way to reduce the systems in scope of PCI DSS, because systems holding only tokens may not store cardholder data.
• Third-party and offshore processing: sending tokens rather than personal data reduces transfer and processor risk.
• AI and LLM workflows: staff paste customer data into AI tools, and applications send records to external model APIs. Redacting or tokenising personal data before the prompt leaves your boundary, then re-identifying the response if needed, keeps raw personal data away from third-party models. Our article on shadow AI explains why this matters.

Where encryption remains essential

• Data in transit: always use TLS.
• Backups, laptops and removable media.
• Systems that genuinely need the original values to function, protected with field-level encryption and strict key management.
• The token vault itself, which must be encrypted, isolated and closely monitored.

Key management decides the outcome

Whichever you choose, key management is where security is won or lost. Keep keys in a hardware security module or a managed key service, separate key administration from data administration, rotate keys, and log every use. Destroying keys can also support erasure, since data encrypted under a destroyed key becomes unrecoverable, though you must still manage copies and backups carefully.

Choosing an approach: a practical decision path

Start by mapping where each category of personal data is stored, processed and sent, including copies in analytics platforms, backups, logs and third-party services. For each location, ask whether the system needs the real value to do its job. If it does not, tokenisation removes the data from that system altogether, which shrinks the number of places an attacker can find it and the number of systems in scope for audits. If it does, protect the real value with field-level encryption, strict access control and logging.

Consider performance and integration. Vault-based tokenisation adds a lookup when data must be re-identified, which matters for high-volume transactional systems. Vaultless, cryptographic tokenisation avoids a central lookup table but places more weight on key protection. Format-preserving approaches reduce changes to existing schemas but should be implemented using recognised, reviewed algorithms rather than custom schemes.

Record your reasoning in your data protection impact assessments and records of processing. The ICO expects security measures to be appropriate to risk, and a documented rationale for where you used tokenisation, encryption or both is good evidence of that judgement.

How Pyralink helps

PyraLink™ Privacy Harmonize is a free, open-source tool that helps DPOs and privacy teams compare privacy frameworks, see where they overlap, track the controls they already have and close the gaps. For organisations with strict data residency needs, our article on air-gapped and sovereign AI deployment covers the architectural options.

Frequently asked questions

What is the difference between tokenisation and encryption?

Encryption transforms data with a key so that anyone holding the key can recover it. Tokenisation replaces sensitive values with surrogate tokens and keeps the originals in a separate, controlled service, so systems that hold only tokens never see the real data.

Is tokenised data still personal data under UK GDPR?

Usually yes. If the organisation can re-identify individuals using the token vault or keys, the data is pseudonymised and remains personal data.

Does encryption mean we do not have to report a data breach?

Not automatically. Encryption that renders data unintelligible can mean you do not need to inform affected individuals, but you must still assess and record the breach and decide whether to notify the ICO within 72 hours.

Does tokenisation reduce PCI DSS scope?

It can. The PCI Security Standards Council recognises that systems holding only tokens, and not cardholder data, may be removed from PCI DSS scope, depending on the implementation.

How can we stop personal data being sent to AI tools?

Redact or tokenise personal data before prompts leave your environment, combined with policies, approved tools and data loss prevention controls.

Sources: ICO: Encryption guidance; ICO: A guide to data security; UK GDPR Article 32 (legislation.gov.uk); UK GDPR Article 34 (legislation.gov.uk); PCI Security Standards Council: Document library.