PCI Tokenization Explained: How Tokens Reduce PCI DSS Scope and What Stays In

PCI tokenisation (often spelt tokenization) replaces a card’s primary account number (PAN) with a substitute value, a token, that is useless outside the tokenisation system. If your systems store and pass around tokens instead of card numbers, and can never turn a token back into a PAN, those systems can fall outside PCI DSS scope. Tokenisation does not make PCI DSS go away: the point where the card number is captured, the system that issues tokens and every system or person that can de-tokenise all stay in scope.

This page looks at tokenisation from the assessor’s side: what it takes out of scope, what it leaves in and what a Qualified Security Assessor (QSA) needs to see before accepting the claim. For the other ways to reduce PCI scope, such as hosted payment pages and segmentation, see our scoping guide.

How does PCI tokenisation work?

1. Capture. The card number is entered on a payment page, terminal or phone line. Ideally your payment provider captures it directly, so it never touches your systems.
2. Tokenise. The tokenisation system generates a token and keeps the link between token and PAN in a secured vault. Vaultless designs derive the token cryptographically instead.
3. Use the token. Your systems store only the token and use it for refunds, repeat payments, customer records and reporting.
4. De-tokenise when needed. When a payment needs the real PAN, the token goes back to the tokenisation system, which looks up the PAN inside its own secure environment.

There are four common models:

PCI SSC publishes a separate Token Service Provider standard for the organisations that generate and issue EMV payment tokens. It applies to those token service providers, not to the merchants that use network tokens, and it has no bearing on gateway or in-house tokens.

Building your own token vault in the cloud? Our guide to AWS PCI compliance explains why the vault, its KMS keys and any service that can de-tokenise stay in your CDE.

Is tokenised data in PCI scope?

A token on its own is not cardholder data (see what PCI DSS treats as account data). Systems that only store, process or transmit tokens can therefore be out of scope, provided two conditions hold: the tokens cannot be used to recover the PAN, and those systems are isolated from the tokenisation system and the cardholder data environment (CDE).

Two cases need care. First, the PCI SSC’s Tokenization Guidelines information supplement warns that tokens which can themselves be used to make a payment, which it calls high-value tokens, may fall within PCI DSS scope even though they reveal no PAN; how your QSA treats them depends on who can use the token and how. Second, vaultless tokens derived from the PAN by format-preserving encryption are, in effect, encrypted PAN, so the keys and everything that can reach them stay in scope.

Does tokenisation make you PCI compliant?

No. Tokenisation shrinks the part of your estate that PCI DSS applies to; it does not validate anything. Our free PCI compliance check shows which SAQ your tokenised set-up is likely to need. You still need to:

• validate every year through your SAQ or Report on Compliance;
• manage the tokenisation provider as a third-party service provider, with a written agreement, an annual check of its compliance status and a written split of responsibilities (12.8.2, 12.8.4, 12.8.5);
• secure the capture point, de-tokenisation access and any remaining CDE;
• confirm your scope at least every 12 months and after significant change (12.5.2).

Which SAQ you complete depends on how card data is captured rather than on tokenisation itself: a merchant whose provider captures the card and returns a token may qualify for a short SAQ, while one that receives PANs on its own servers before tokenising them will not. Our guide to which PCI SAQ applies sets out the eligibility rules, and our guide to choosing a PCI compliant payment gateway covers what to ask a provider about its tokens.

PCI tokenization vs encryption: what is the difference?

Encryption transforms the PAN with an algorithm and a key, and anyone with the key can reverse it. Tokenisation swaps the PAN for an unrelated value that only the tokenisation system can exchange back. That is why their effect on scope differs: PCI SSC’s FAQ states that “encryption alone is insufficient to render the cardholder data out of scope” (PCI SSC FAQ 1086).

The two work together. Encryption protects the PAN on its way to the tokenisation system and inside the vault, and tokens replace it everywhere else. For card-present payments, point to point encryption protects the card from the terminal onwards and is often paired with tokens for storage. Where you do store PANs, our guide to PCI DSS Requirement 3 covers the rules for protecting them.

What do the PCI SSC tokenization guidelines say?

The PCI SSC has published two tokenisation documents. Both are guidance rather than standards, and both predate PCI DSS v4.0, so read them alongside the current standard:

Your QSA assesses you against PCI DSS v4.0.1, not against either supplement. Requirement numbers quoted in them come from older versions of the standard, so map them before you rely on them: the rule on rendering stored PAN unreadable, for example, is now Requirement 3.5.1. Both documents are free from the PCI SSC document library.

What evidence does a QSA ask for when you rely on tokenisation?

An assessor will not accept “we use tokens” as a scope statement. Expect to provide:

1. The provider’s Attestation of Compliance, current and naming the tokenisation and de-tokenisation services you use, not only the payment gateway.
2. A responsibility matrix showing which requirements the provider manages and which you manage (12.8.5).
3. A data-flow diagram (1.2.4) showing where the PAN enters, where it is tokenised, where tokens travel and every de-tokenisation path.
4. Evidence that no PANs remain in token-only systems: data discovery results across databases, file shares, logs and backups, which also supports your scope confirmation (12.5.2).
5. De-tokenisation access records: who and what can de-tokenise, approved under Requirement 7 and logged under Requirement 10.
6. For in-house tokenisation: how tokens are generated, how the vault is secured and your key management procedures (3.6, 3.7). The vault is a CDE and is assessed in full.
7. Segmentation test results if you rely on segmentation to keep token-only systems out of scope (11.4.5).

What are the most common tokenisation mistakes?

• Tokenising too late. The PAN passes through your web server or application before reaching the tokeniser, so those systems stay in scope.
• Leaving the history behind. Old PANs survive in pre-tokenisation databases, spreadsheets, support tickets and backups.
• Broad de-tokenisation rights. Finance, customer service or reporting tools that can retrieve full PANs pull themselves back into scope.
• Card numbers in logs. Debug logging or error messages capture the PAN before it is tokenised.
• Channels that bypass the flow. Phone and email orders keyed into systems outside the tokenisation path.
• Treating vaultless tokens as out of scope by default. Tokens produced by format-preserving encryption, a common vaultless method, are encrypted PAN; key access decides scope.
• Not reading the provider’s AOC. An expired attestation, or one that omits the tokenisation service, leaves a gap in your evidence.

How can Sovereign Secure help?

Sovereign Secure Ltd is a PCI SSC-approved Qualified Security Assessor company, and also holds the Council’s Qualified PIN Assessor and Card Production Security Assessor approvals. We are a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.

Our PCI DSS consultancy runs data-flow workshops that find everywhere card data is stored, processed or transmitted, then designs scope reduction, including tokenisation, before any assessment. Where we both advise and assess, advisory and assessment work are kept separate, as PCI SSC expects of a QSA company; consultancy does not make an assessment easier, and you are free to use a different QSA.

What should you do next?

Tell us how you take payments, which provider tokenises for you and which systems still see card numbers, through the enquiry form or on +44 161 523 5276. We will tell you what tokenisation can realistically take out of your scope and what evidence your assessment will need.