A token is not a PAN. Tokenization replaces the primary account number with a surrogate value, usually stored in a card data vault at a gateway or processor, so your CRM, loyalty program, and refund tools can keep a handle on the card without keeping the card number. That can shrink the cardholder data environment (CDE) you have to protect. It does not erase PCI DSS. The PCI Security Standards Council's Tokenization Guidelines (August 2011) are explicit: tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance. They may simplify validation by reducing how many of your systems still store, process, or transmit account data.
A token is not a PAN
PCI SSC's glossary defines the PAN as the unique payment card number that identifies the issuer and the cardholder account. Cardholder data, at a minimum, is the full PAN. It may also include name, expiration date, and service code when those travel with the PAN. Sensitive authentication data is the other pile: card verification codes, full track data, PIN. You may process SAD to get an approval. You do not store it after authorization.
A token is a surrogate. De-tokenization is the reverse: turning the token back into the PAN. The Council's 2011 guidelines put the security of a token on one test: it should be infeasible to recover the original PAN from the surrogate value alone. If the token still maps back to a PAN from a system you can reach, it is not a vacation from scope. It is a pointer into a vault that is still in the CDE.
Format does not decide this. A token can look like a card number, a random alphanumeric string, or a format-preserving value that keeps the first six and last four digits and replaces the middle. PCI SSC's 2011 examples include all three. A value that still looks like a card number can still be a token. A value that does not look like a card number can still be in scope if you can redeem it.
Three tokens merchants mix up
PCI SSC FAQ 1384 (April 2016) splits the word into three jobs. Mixing them is how a sales deck over-promises scope reduction.
Acquiring tokens are created by the acquirer, the merchant, or a merchant service provider after the cardholder presents the PAN. They are proprietary. They cannot be used for new authorizations. They can be used for card-on-file and recurring charges. This is the vault most gateways sell you.
Issuer tokens are virtual card numbers created by the issuer. They look like PANs, so you may never know you received one.
Payment Tokens are created by Token Service Providers registered with EMVCo. The cardholder presents the Payment Token instead of the PAN. During that transaction, the merchant and acquirer do not receive the corresponding PAN. PCI SSC FAQ 1326 (May 2015) says a Payment Token used as EMVCo specifies, sitting outside the TSP's token data environment, is not Account Data and is not in scope for PCI DSS. That does not bless your whole network. If the same system also stores a real PAN, or is connected to systems that do, those systems stay in scope.
A wallet tap can be a Payment Token. A gateway token in your CRM is almost always an acquiring token. Ask which one you were sold.
How vaulting actually shrinks the CDE
The CDE is the people, processes, and systems that store, process, or transmit cardholder data or SAD, plus anything with unrestricted connectivity to those systems (PCI SSC glossary). Scope follows the data. The 2011 guidelines describe the useful shape:
- Capture the PAN at the point of interaction or in a hosted field you do not serve.
- Send it to a card data vault.
- Get a token back.
- Store the token in merchant systems that need a handle for refunds, repeats, and reporting.
- Delete the PAN from every merchant system that is not the vault.
The vault, the mapping table, de-tokenization, and anything that can ask the vault for a PAN remain in the CDE. Systems that hold only tokens, that cannot redeem them, and that are segmented from the vault may fall out of the CDE. That is the cut. It is not automatic. PCI SSC says you still have to verify that PAN is not retrievable from any system you took out of scope.
PAN exists only long enough to reach the vault or hosted field.
PAN storage, token mapping, and de-tokenization. Always in the CDE.
Out of the CDE only if they hold tokens with no path back to the PAN.
The same guidelines tell you how to keep the cut real: replace PAN storage with tokens wherever you can; limit PAN to capture and the vault; minimize how many of your systems see the PAN before it is tokenized; do not keep PAN in the same environment as the tokens outside the vault; delete leftover PAN after the token is issued; prefer a vault that will not hand the PAN back to you for refunds and repeats. If your help desk can click "reveal card number," those workstations are still in the CDE.
The gateway is the pipe that often hosts that vault. Confirm the AOC covers the vaulting service you actually use, not a sibling product with a similar logo.
What tokenization does not erase
Outsourcing card entry, or vaulting after capture, does not remove the merchant's PCI DSS obligation. PCI SSC FAQ 1092 (June 2025) is blunt: PCI DSS still applies when a third party stores, processes, or transmits the data for you. You remain responsible for the provider's compliance for the services they offer, a written agreement that names those responsibilities (Requirement 12.8.2), and annual monitoring of the provider's status (Requirement 12.8.4). You still validate, typically on an SAQ. Confirm the path with your acquirer.
What usually remains on you:
- The capture path. A hosted iframe or redirect can shrink what you touch. A page you serve that collects the PAN does not. PCI DSS 4.0 for merchants is the current document: v4.0.1, with the former future-dated requirements mandatory since 31 March 2025 (PCI Security Standards Council). Payment-page script controls still matter if your site can affect the checkout.
- Paper. Receipts, imprints, and reports that show more than a masked PAN are still cardholder data.
- Anything that can de-tokenize. Admin tools, support consoles, batch files, backups.
- The questionnaire. A vault does not file the SAQ. A PCI line on the statement is a processor program, not a Council invoice and not proof the vault cut your scope.
Bob Russo, then general manager of PCI SSC, said on 12 August 2011 that tokenization should not be viewed as an alternative to PCI DSS. It is a layer, used with the standard, not instead of it.
Token versus encryption, truncation, and masking
These four words get sold as synonyms. They are not.
Encryption renders PAN unreadable with strong cryptography (PCI DSS Requirement 3.5.1). PCI SSC FAQ 1086 (March 2026) is equally blunt: encryption alone is not enough to take the data out of PCI DSS scope. If you hold the ciphertext and a path to the key, you still hold account data.
Hashing is one-way. PCI SSC FAQ 1089 (March 2026) says the hashing process and the systems that perform it are in scope. A hashed PAN moved into a separate environment can fall out of scope there. If you need the PAN back, hashing is the wrong tool.
Truncation permanently removes digits. PCI SSC FAQ 1091 (June 2022) starts from a baseline of at most the first 6 and last 4 digits retained, with brand-specific tables if you need more. FAQ 1117 (September 2021) says systems that store only truncated PANs, segmented from the CDE, and that do not otherwise handle account data, may be out of scope. The system that did the truncating is not.
Masking is display. FAQ 1146 (July 2025) assigns masking to Requirement 3.4.1 (screens, receipts, printouts) and truncation to Requirement 3.5.1 (stored PAN). A receipt that shows only the last four can still sit on a terminal that stored the full PAN. Masking is not truncation.
Format-preserving tokens that keep the BIN and last four and replace the middle sit in a gray band. FAQ 1117 says whether those values are out of scope depends on the implementation and is an assessor call. If the middle can be reversed in the same environment, it is still in scope.
A rubric, not a product list
Judge a vault on the data path, not the brochure.
- Where does the PAN first appear, and who can see it? Hosted field, iframe, encrypted POI, or your own form.
- Who holds the vault? Name the legal entity. Get their current AOC for the vaulting service, dated, against PCI DSS v4.0.1.
- Can anyone in your company request the PAN back? If yes, those people and those systems stay in the CDE.
- Are old copies gone? Databases, logs, email, exports, backups from before the vault.
- Which SAQ does the acquirer want this year? Tokenization is an input to that answer. It is not the answer.
Do the five questions in writing. Then file the questionnaire that matches how you actually take cards. A token is a scope tool. Used cleanly, it cuts where the PAN lives. It is not a PCI vacation.
FAQ
Does tokenization make me PCI compliant? No. The PCI Security Standards Council's Tokenization Guidelines (August 2011) say tokenization does not eliminate the need to maintain and validate PCI DSS. It may reduce how many of your systems sit in the cardholder data environment.
If my gateway vaults the card, do I still need an SAQ? Yes. PCI SSC FAQ 1092 (June 2025) says outsourcing storage, processing, or transmission does not remove the merchant's obligation. You still validate, typically on an SAQ your acquirer assigns, and you still monitor the provider.
What is the difference between a token and a truncated card number? A token is a surrogate that maps back to the PAN inside a vault. Truncation permanently removes digits. A truncated PAN that meets PCI SSC FAQ 1091, stored alone on a segmented system, may be out of scope. A token you can redeem is not.
Are mobile-wallet payment tokens in PCI scope for my shop? A Payment Token used as EMVCo specifies, sitting outside the Token Service Provider's environment, is not Account Data (PCI SSC FAQ 1326, May 2015). Systems that still store, process, or transmit a real PAN remain in scope.
Can I store gateway tokens in my CRM? Yes. That is the usual point of an acquiring token. The CRM is out of the CDE only if it cannot de-tokenize, is segmented from the vault, and holds no leftover PAN.
Is encryption the same as tokenization for PCI scope? No. Encryption alone does not take cardholder data out of PCI DSS scope (PCI SSC FAQ 1086, March 2026). Tokenization can, for systems that hold only tokens with no path back to the PAN.
Sources
- PCI Security Standards Council, Information Supplement: PCI DSS Tokenization Guidelines, August 2011
- PCI Security Standards Council, "PCI Security Standards Council Releases PCI DSS Tokenization Guidelines," 12 August 2011
- PCI SSC glossary (PAN, cardholder data, CDE, truncation, masking)
- PCI Security Standards Council, PCI Data Security Standard overview
- PCI Security Standards Council, PCI Security Standards
- PCI SSC FAQ 1384, "What is the difference between 'acquiring tokens', 'issuer tokens', and 'Payment Tokens'?", April 2016
- PCI SSC FAQ 1326, "How does PCI DSS apply to EMVCo Payment Tokens?", May 2015
- PCI SSC FAQ 1092, "Does PCI DSS apply to merchants who outsource all payment processing operations and never store, process or transmit cardholder data?", June 2025
- PCI SSC FAQ 1086, "How does encrypted cardholder data impact PCI DSS scope?", March 2026
- PCI SSC FAQ 1089, "How can hashing be used to protect Primary Account Numbers (PAN)...", March 2026
- PCI SSC FAQ 1091, "What are acceptable formats for truncation of primary account numbers?", June 2022
- PCI SSC FAQ 1117, "Are truncated Primary Account Numbers (PAN) required to be protected in accordance with PCI DSS?", September 2021
- PCI SSC FAQ 1146, "What is the difference between masking and truncation?", July 2025
Questions about how this applies to your business?
Talk it through