Tokenization is usually described as the way out of PCI DSS scope. That is half right. Replacing stored card numbers with tokens can take whole systems out of scope, but only the systems that hold tokens and nothing else, and only if they cannot get back to the card number.
What tokenization removes from your scope depends on three things: where the token is created, who runs the system that maps tokens back to card numbers, and who is allowed to ask for that mapping. Get those right and the reduction is real. Get one wrong and you have added a component to your scope rather than removed several.
This article covers what a token is in PCI DSS terms, which systems leave scope and which stay, the main ways to run tokenization, and the design details an assessor checks. For where tokenization sits among other scope reduction options, see reducing your PCI DSS scope.
What a token is, and how it differs from the alternatives
A token is a substitute value that stands in for a primary account number (PAN). Your systems store and pass the token. The tokenization system keeps the relationship between tokens and PANs, usually in a secured store called a vault, and returns the PAN only to authorized requests.
Requirement 3.5.1 lists the ways stored PAN can be rendered unreadable: one-way hashes based on strong cryptography of the entire PAN, truncation, index tokens, and strong cryptography with associated key management. Tokens are one option among four. They differ from the others in where the secret lives.
Encryption keeps the PAN in your system in encrypted form. Whoever holds the key can recover it, so the system stays in your scope.
Hashing cannot be reversed, but under 4.0 the hash must be a keyed cryptographic hash (3.5.1.1), and the key needs protecting.
Truncation removes digits permanently. It suits display and matching, not repeat charging.
Tokens carry no recoverable PAN at all. The PAN exists only in the tokenization system.
That last property is the one that makes scope reduction possible. The Council published an information supplement on tokenization guidelines that sets out how it thinks about scope for tokenized environments. It is supplementary guidance rather than the standard, and worth reading before you design.
Which systems leave scope, and which stay
Think of the environment in three parts.
The tokenization system stays in scope. Token generation, the vault and the detokenization service store and process PAN, so they are part of the cardholder data environment wherever they run.
Anything that can detokenize stays in scope. A system that can submit a token and receive a PAN has access to cardholder data. That includes services, scripts, staff and support tools with detokenization rights.
Systems that hold only tokens may leave scope. They can, if they cannot detokenize, cannot connect to the tokenization system in a way that would affect its security, and never see PAN at any other point.
The third condition is the one designs miss. If your application server receives the card number from the browser and then sends it to a tokenization service, your server processes PAN. Storing only the token afterward removes the storage, not the processing. The server stays in scope.
Who runs the tokenization system
Where tokenization happens determines how much of the third group you can actually achieve.
| Model | Who holds the PAN | What usually stays in your scope |
|---|---|---|
| In-house tokenization | You, in a vault you operate | The vault, the tokenization service, every system that can detokenize, and the systems that capture PAN before it is tokenized |
| Payment provider tokens, captured on your servers | The provider, after your servers pass it on | Your capture path, because PAN transits it |
| Payment provider tokens, captured in the provider's own fields or page | The provider only | Your management of the provider, and the page or script that loads the provider's fields |
| Network tokens from a card brand token service | The token service, with tokens restricted to specific uses | Depends on how you obtain them and whether your systems ever see the PAN |
The provider model with capture in the provider's own payment fields gives the largest reduction, because PAN never reaches your systems. The trade-off is portability. Provider tokens usually work only with the provider that issued them, so moving providers means a migration of card data between compliant providers, arranged in advance.
Tokens that can make payments
Not all tokens are equal in risk. A token that your systems can submit to your payment provider to charge a card is valuable to an attacker even though it is not a PAN. The Council's tokenization guidance calls out tokens that can be used to initiate transactions, and says they may need additional controls.
In practice, protect a reusable payment token as you would protect credentials. Limit which systems can use it to transact, log its use, and keep it out of places where it serves no purpose, such as analytics exports. Ask your assessor how they treat such tokens in your design before you assume they sit outside every requirement.
The design details an assessor checks
When an assessor reviews a tokenized environment, they look past the diagram to the mechanics.
Detokenization access
Who and what can detokenize, and how is that controlled? Expect questions on least privilege under Requirement 7, authentication under Requirement 8 and logging under Requirement 10 for the detokenization path. The guidance in managing privileged access applies directly to anyone holding detokenization rights.
Tokens that look like card numbers
Format-preserving tokens are convenient, because they fit existing database fields. If they also pass the Luhn check, they are hard to tell apart from real PANs, both for your data discovery tools and for your assessor. Prefer a token format that cannot be mistaken for a PAN, or document clearly how to tell them apart.
Correlation with truncated PAN
Requirement 3.5.1 notes that where hashed and truncated versions of the same PAN are both present, additional controls must prevent them from being correlated to reconstruct the original. Apply the same thinking to tokens that embed digits of the PAN. Limit the digits a token reveals, and do not store forms side by side that together reveal more than any one of them.
The history you tokenized away from
Tokenizing new transactions does not clean up the PAN you stored before. Until legacy tables, backups and exports are tokenized or deleted, those locations are still in scope.
Questions to ask a tokenization provider
Before you rely on a provider's tokenization to reduce scope, get written answers to these:
Does your Attestation of Compliance list the tokenization service we use?
Where is the PAN captured: in your fields, or on our servers?
Which of our systems, if any, can detokenize, and how is that restricted?
Can our tokens be used to initiate transactions, and what limits apply?
How do we migrate card data to another provider if we leave?
Which PCI DSS requirements do you manage, which do we, and which are shared?
The last answer belongs in the record that requirement 12.8.5 asks you to keep. The PCI DSS framework page lists the requirements that remain yours once a provider takes the rest.
How TrustLynce helps
TrustLynce keeps tokenization and payment providers in a vendor inventory with risk tiers, attestation dates and reassessment reminders. Detokenization access can be included in scheduled user access reviews, so the list of who can recover a PAN is checked, dated and attributed.