Tokenisation vs Encryption: Scope Reduction, Key Risk and When to Use Each

Encryption and tokenisation both make sensitive data useless to a thief, but they fail in different ways and change your compliance scope in different ways, so choosing the wrong one costs either security or years of audit effort. Encryption transforms data with a key and anyone holding the key can reverse it; tokenisation replaces data with a surrogate value and keeps the original in a separate vault or derives it under strict control. This guide compares them for payment card data and personal data: how each works, where the risk concentrates, what PCI DSS and GDPR say, and how to decide. It is for data security architects, payment and privacy teams, and it goes deeper on the choice than the Tokenisation and Data Masking Guide and the Encryption Guide.

Key takeaways

• Encryption protects data in place; tokenisation removes it. Encrypted data stays sensitive wherever it goes because the key can reverse it; a well-designed token carries no recoverable value, so systems holding only tokens can fall out of scope.
• Risk concentrates in different places. With encryption it sits in the keys and every system that can decrypt; with tokenisation it sits in the token vault and the de-tokenisation service, which the PCI SSC calls the most attractive target for attackers.
• PCI DSS accepts both, scope treats them differently. Requirement 3.5.1 lets you render stored PAN unreadable with index tokens or strong cryptography, but the PCI SSC tokenisation guidelines say only systems isolated from the vault, keys and de-tokenisation can leave scope.
• Under GDPR both are usually pseudonymisation. The EDPB and ICO treat encrypted and tokenised personal data as still personal data for whoever can reverse it; neither is anonymisation.
• Most mature designs use both. Encrypt in transit and at rest everywhere, tokenise the specific high-value fields so downstream systems never see them.

How each works

Encryption

Encryption applies a cryptographic algorithm and key to plaintext to produce ciphertext. Symmetric algorithms such as AES-256-GCM are used for data at rest and bulk data; asymmetric algorithms and TLS protect data in transit. The output length and format usually differ from the input, unless format-preserving encryption is used. Anyone with the key and access to the ciphertext can recover the data, so security reduces to key management: generation, storage (often in an HSM or KMS), access control, rotation and destruction. See the Cryptographic Key Management Guide and the Envelope Encryption and KMS Integration Patterns Guide.

Tokenisation

Tokenisation replaces a sensitive value with a surrogate token. The PCI SSC Tokenization Guidelines (Information Supplement v2.0, 2011) describe three generation methods:

• Reversible cryptographic tokens: generated from the PAN with an algorithm and key. The guidelines note these are effectively encrypted PAN and may remain subject to PCI DSS.
• One-way non-reversible tokens: generated with a hash function and a secret salt. Hashed and truncated versions of the same PAN can be correlated, so extra controls are needed.
• Index, sequence or random tokens: not mathematically derived from the PAN, mapped to it in a token vault. These are what most people mean by vaulted tokenisation.

Tokens may be single-use or multi-use, and many are format-preserving (same length, last four digits kept) so existing systems accept them. Vaultless designs generate tokens cryptographically, often with format-preserving encryption, which makes them closer to encryption in risk terms. Payment network tokens are a separate scheme: EMVCo describes EMV Payment Tokens issued by registered token service providers and restricted so a token should not be usable beyond a specific merchant, device or payment scenario. See the Network Tokenisation for Payments Guide.

Side-by-side comparison

Scope reduction: what PCI DSS actually allows

PCI DSS v4.0.1 Requirement 3.5.1 requires stored PAN to be rendered unreadable using one of: one-way hashes based on strong cryptography of the entire PAN, truncation, index tokens, or strong cryptography with associated key-management processes. Both encryption and tokenisation satisfy it. The difference is scope.

• Tokenisation system: the PCI SSC guidelines are explicit that the tokenisation system, including the token vault, is part of the cardholder data environment and always in scope, as are components that generate tokens, redeem PANs or can access the tokenisation system.
• Systems holding tokens: may be out of scope only if recovering the PAN from the token is computationally infeasible, the systems are segmented from the vault, keys and de-tokenisation, and no cardholder data remains on them.
• High-value tokens: tokens that can themselves initiate a transaction can be monetised and carry the same value to an attacker as the PAN. The guidelines say they may remain in scope and need additional fraud controls; confirm with your acquirer.
• Encrypted PAN: stays cardholder data. Systems that store or process it remain in scope unless the entity holding it has no access to the decryption keys, which in practice usually means a third-party design such as P2PE; see the PCI Point-to-Point Encryption Guide.
• Never return PAN: if scope reduction is the goal, the guidelines say the tokenisation service should not return PAN to the merchant environment.

See the PCI DSS Scoping and Network Segmentation Guide and the PCI DSS Requirement 3 Key Management Guide.

Personal data under GDPR and UK GDPR

GDPR Article 4(5) defines pseudonymisation as processing so that data can no longer be attributed to a specific person without additional information kept separately and protected. The EDPB's draft Guidelines 01/2025 on Pseudonymisation (public consultation January to March 2025) describe the two main transformation classes as cryptographic algorithms, including encryption, and lookup tables, which is what a token vault is. Key points for the choice:

• Still personal data: the EDPB states pseudonymised data remains personal data. The ICO says encryption "is typically a pseudonymisation technique" and should not be treated as anonymisation.
• Protect the secret: keys and lookup tables are the "additional information". The EDPB notes lookup tables are themselves personal data and must be stored separately and protected; if an attacker can easily obtain them, the security benefit may be negligible.
• Breach notification: the ICO notes that if encryption makes breached data unintelligible to unauthorised people, you may not need to tell the individuals, although you still assess whether to report to the regulator. The same reasoning applies to tokens whose vault was not compromised.
• Article 32: both encryption and pseudonymisation are named as examples of appropriate security measures.

See the Pseudonymisation Techniques Guide.

When to use each

Small organisations taking card payments usually get the biggest scope reduction by using a payment provider's hosted fields or tokens so PAN never touches their systems, rather than running their own vault. Large organisations with many systems that consume the same identifiers often run a central tokenisation service, which then needs the controls of a tier-zero system; see Securing the tokenisation and data masking platform itself.

Key and vault risk

Each approach moves risk; neither removes it.

• Encryption keys: held in an HSM or KMS, with separation of duties between key custodians and data administrators. Applications that call decrypt are effectively holding the data; their service account credentials are as sensitive as the plaintext.
• Token vault: the PCI SSC guidelines recommend segmenting the tokenisation system, strong authentication and separation of duties, logging and alerting on de-tokenisation requests, keeping token generation keys inside the system and planning incident response for vault or key compromise. See the tokenisation platform compromise playbook.
• Format-preserving encryption: NIST SP 800-38G Rev. 1 second public draft (February 2025, checked November 2026) specifies only FF1 and states FF3 is no longer specified, following published cryptanalysis. Treat FF3 and FF3-1 implementations as a migration item and confirm the final text when published. See Format Preserving Encryption.
• Distinguishing tokens from real values: format-preserving tokens can look like real PANs. The PCI SSC guidelines recommend a way to tell them apart, for example a reserved range or failed Luhn check, so that discovery scans and auditors are not misled.

Each option in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

Tokenisation

Threat model. The PCI SSC Tokenization Guidelines (version 2.0, August 2011) note that the card data vault "often presents the most attractive target for attackers". The threat model is an attacker who reaches the vault or a de-tokenisation interface, or abuses tokens that can themselves start transactions.

Failure modes. The guidelines warn that hashed tokens paired with truncated PANs can make reconstruction relatively trivial, that format-preserving tokens can be confused with real PANs and cause mis-scoping, and that key compromise can expose all current and future tokens generated with those keys.

Controls. Segment the tokenisation system as part of the CDE, require strong authentication for tokenising and de-tokenising, log access and alert on abnormal mapping requests, and verify scope at least annually.

Decision criteria. Choose tokenisation when most systems only need a reference to sensitive data, not the data itself.

Worked scenario. A retailer tokenises PANs at capture. Its analytics platform holds only tokens, so a compromise there exposes nothing recoverable, while the vault sits in a small, monitored segment.

Encryption

Threat model. Encryption protects data wherever it travels, but anyone holding the key and an access path can decrypt. The threat model is key theft or misuse (T1552) and applications that decrypt more than they need.

Failure modes. Keys stored beside data; broad decrypt permissions; and reliance on FF3 or FF3-1 format-preserving encryption, which the February 2025 second public draft of SP 800-38G Rev. 1 no longer specifies following a tweak schedule weakness.

Controls. Separate key management (SC-12), least-privilege decrypt rights, key rotation and logging of key use.

Decision criteria. Choose encryption when systems genuinely need the data back, or for data in transit and backups.

Worked scenario. A claims system encrypts records at rest with keys in a separate service. A stolen database backup is unreadable, and key use logs show no decrypt calls from unexpected hosts.

Where identity fits

In both models the people and services allowed to decrypt or de-tokenise are the real perimeter around the data. A payment service's de-tokenisation API key, a batch job's KMS role or a data pipeline's service account grants the same access as reading the plaintext table. Treat these as privileged non-human identities: one owner each, least-privilege scopes (de-tokenise only the fields needed, ideally returning masked values by default), short-lived credentials from a secrets manager, and alerts on unusual volumes. See the API Key Management Guide.

Detection and measurement

• Log sources: KMS or HSM decrypt and key-use events, de-tokenisation API logs (caller, field, volume), data discovery scan results and access logs on systems that should hold only tokens.
• Alerts: bulk de-tokenisation outside normal patterns, decrypt calls from new principals, PAN patterns found in log files or out-of-scope systems, and changes to key policies.

Common failure patterns

• Encrypting and calling it descoped: encrypted PAN stored with the keys reachable from the same environment remains in scope.
• Tokens that are really ciphertext: vaultless tokens generated with a key held in the merchant environment, which the PCI SSC guidelines treat as encrypted PAN.
• De-tokenisation everywhere: many applications given de-tokenise rights "for convenience", rebuilding the original exposure through the API.
• Clear values left behind: source systems, logs and backups still holding the original after tokenisation went live.
• Keys stored beside data: encryption keys in the same database, config file or repository as the ciphertext.
• Treating pseudonymised data as anonymous: sharing tokenised or encrypted personal data on the assumption GDPR no longer applies.

Framework mapping

Practitioner checklist

• Classify which fields need protection and whether downstream systems ever need the original value.
• Encrypt all data in transit and at rest as a baseline, independent of tokenisation.
• Tokenise high-value fields that many systems store but few need to see.
• Keep vault, token generation keys and de-tokenisation segmented and in scope.
• Limit decrypt and de-tokenise rights to named service identities with owners.
• Run discovery scans to prove no clear values remain in descoped systems, logs or backups.
• Make tokens distinguishable from real values and document the scheme for assessors.
• Replace FF3 or FF3-1 format-preserving encryption and track the final SP 800-38G Rev. 1.
• Do not treat tokenised or encrypted personal data as anonymous.

Standards and references

• PCI SSC: Information Supplement, PCI DSS Tokenization Guidelines
• EDPB: Guidelines 01/2025 on Pseudonymisation
• ICO: Encryption and data protection
• NIST: SP 800-38G Rev. 1 (2nd Public Draft) Methods for Format-Preserving Encryption
• EMVCo: EMV Payment Tokenisation
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Tokenisation and Data Masking Guide · Encryption Guide · PCI DSS 4.0 Guide · Data Masking and Tokenisation Buyer's Guide · Pseudonymisation Techniques Guide