Use field encryption when systems must read the real value occasionally and you can manage keys, tokenization when most systems never need the real value, and pseudonymization when you want analysis on records without direct identifiers. All three leave the data personal under GDPR, so each is a safeguard, not an exit from the rules.
What each one does
Encryption transforms a value with a key. Anyone with the key can recover it, and the ciphertext travels with the record. Where it lives is up to you: application layer, database column or storage layer.
Tokenization swaps the real value for a random token and stores the mapping in a separate vault. The token has no mathematical link to the original, so stealing the main database yields nothing without vault access.
Pseudonymization is the GDPR term in Article 4(5): processing so data "can no longer be attributed to a specific data subject without the use of additional information", kept separately with safeguards. Encryption and tokenization are both ways to achieve it, as is replacing a name with an internal ID.
A decision guide
Ask these in order.
- Does anyone need the real value routinely? If a support agent must see the full email daily, tokens add friction. Encrypt and control decryption by role.
- Do systems only need to match records? If they just join on a customer, use a token or internal pseudonymous ID. Never copy the real value.
- Is the goal analysis? Use pseudonymous IDs and drop fields you do not need. Consider generalising dates and locations.
- Is the field subject to external rules? Payment card numbers, for example, have their own standards. Follow them and do not invent a scheme.
- Will you have to delete on request? Tokenization makes erasure simple: delete the vault entry and every token becomes meaningless. Encryption can do the same by destroying a per record key, but it needs a key per person or tenant and careful design.
Trade offs worth knowing
- Searchability. Encrypted fields cannot be searched or sorted without extra design. Deterministic encryption allows equality lookups but leaks which records match.
- Format. Some systems demand a field that looks like the original. Format preserving options exist but need expert review.
- Availability. A token vault is a dependency. If it is down, flows that detokenize stop.
- Key and vault security. All three shift the risk to the key or the vault. Protect those more than the data store.
- Blast radius. One key for the whole database means one compromise exposes everything. Scope keys by tenant or data class.
Still personal data
The mapping or key means you can re-identify, which means the data stays in scope of GDPR. What you gain is risk reduction and, under Article 25 and Article 32, evidence of appropriate safeguards. You do not gain permission to keep data forever.
Quick check
Is a token personal data?
Yes while a vault, key or other link lets you or someone else re-identify the person.
Which is best for right to erasure?
Tokenization, or encryption with a key per person, both make deletion a single step. Plain shared key encryption does not.
Sources
Last reviewed: 19 October 2026.
