skip to content

Under PCI DSS v4.0.1, a retailer replaces its stored PANs with tokens: which systems can leave scope, and which must stay?

level: middleimportance: should knowfreq 45%

answer

  1. index tokens in Requirement 3.5.1
  2. whoever can get the PAN back
  3. the vault and its callers
  4. encryption alone rarely descopes

basics

~20 s

Under PCI DSS v4.0.1, systems holding only tokens, unable to detokenize or impact the CDE, can leave scope. The token vault, detokenization paths, systems capturing the PAN before tokenization and anything able to impact them stay in scope.

solid answer

~50 s

PCI DSS v4.0.1 Requirement 3.5.1 lists **index tokens** as one way to render stored PAN unreadable, alongside keyed one-way hashes of the full PAN, truncation and strong cryptography with key management. Tokenization shrinks scope because a system that only holds tokens no longer stores, processes or transmits cardholder data - but Section 4's test still decides: it leaves scope only if it has no unrestricted connectivity to the CDE and could not impact it, which means no ability to call detokenization. What stays: the **token vault** that maps tokens to PANs, every service and person allowed to detokenize, the point-of-sale and web systems where the PAN arrives before it is tokenized, key management for the vault, and systems that can impact those. If a provider runs the tokenization, the retailer manages it under Requirement 12.8.

go deeper

for a junior

Recall the four methods Requirement 3.5.1 accepts for stored PAN, and that masking on screen is a separate display rule.

for a middle

Explain why a token-only system can leave scope while the vault, detokenization callers and capture points stay, using Section 4's connectivity and impact test.

for a senior

Hunt the leftovers: old exports, logs and backups still holding PANs, and services quietly granted detokenization, which undo the scope reduction you promised the assessor.

for a principal

Decide where tokenization happens and who may detokenize as a platform-wide policy, because every new consumer of real PANs expands the assessed environment.

## Where tokens appear in PCI DSS v4.0.1 **Requirement 3.5.1** says the PAN is rendered unreadable anywhere it is stored, using any of these approaches: 1. **One-way hashes** based on strong cryptography of the *entire* PAN - since 31 March 2025 these must be **keyed** cryptographic hashes with key management (Requirement 3.5.1.1). 2. **Truncation** - removing a segment of the PAN; hashing cannot be used to replace the truncated segment. 3. **Index tokens** - the glossary defines an index token as "a random value from a table of random values that corresponds to a given PAN". 4. **Strong cryptography** with associated key-management processes and procedures. The requirement covers primary storage (databases, flat files, spreadsheets) and non-primary storage such as backups and audit, exception or troubleshooting logs. ## Why tokenization reduces scope Rendering the PAN unreadable satisfies Requirement 3.5.1, but scope is decided by Section 4: a component is in the CDE if it stores, processes or transmits cardholder data or has unrestricted connectivity to one that does, and it is in scope if it could impact that data's security. An index token is not derived from the PAN, so a system that holds only tokens and **cannot turn them back into PANs** no longer handles cardholder data. Whether it leaves scope depends on the rest of the test. | Component after tokenization | Position | |---|---| | Token vault (the token-to-PAN table) | Stores PAN: in the CDE | | Detokenization service and every caller allowed to use it | Process or retrieve PAN: in scope | | Point-of-sale and web systems that capture the PAN before tokenization | Process and transmit PAN: in scope | | Key management protecting the vault | Could impact PAN security: in scope | | Order history, analytics or loyalty stores holding only tokens, with no detokenization access | Candidates to leave scope, if isolated and unable to impact the CDE | A token that some system can exchange for a PAN at will leaves that system's scope unchanged. ## The contrast with encryption The standard is explicit that **encryption alone is generally insufficient** to take cardholder data out of scope. Encrypted cardholder data stays in scope when it sits on a system or in an environment that also holds the decryption key, when it is not isolated from the encryption, decryption and key-management processes, or when the entity can reach the key. The same logic governs tokens: the question is always who can get the PAN back. (Whether to tokenize or encrypt as a wider data-governance choice is outside this question.) ## Truncation and masking are different tools - **Truncation** removes digits permanently; there is no "un-truncation" without recreating the PAN from another source. - **Masking** (Requirement 3.4.1) hides digits only when displayed - at most the BIN and last four digits for those without a business need to see more - while the full PAN may still be stored. Masking does not satisfy 3.5.1. - **Correlation risk:** if hashed and truncated versions of the same PAN, or different truncation formats of it, exist in one environment, Requirement 3.5.1 demands controls so they cannot be correlated to reconstruct the PAN. ## What the retailer still has to do - **Find every copy.** The annual scope confirmation under **Requirement 12.5.2** must identify all locations where account data is stored, including locations outside the defined CDE and file backups. Tokenizing the main database achieves nothing if old exports and logs still hold PANs. - **Retire legacy storage** under the retention and secure-deletion process of **Requirement 3.2.1**. - **Manage the provider** under **Requirement 12.8** if a third party runs the vault, including the responsibility split in 12.8.5. - **Leave SAD out of it.** Tokenizing is no route to keeping the card verification code; Requirement 3.3.1 bars storing SAD after authorization in any form. The standard names the PCI SSC's *Tokenization Product Security Guidelines* as further reading; like all information supplements, it does not replace or extend the standard's requirements.

  • Under PCI DSS v4.0.1, does a reporting database holding only tokens but able to call the detokenization API stay in scope?
    Yes. Its ability to obtain PANs means it effectively processes cardholder data, or at minimum could impact the security of the vault. Only systems that hold tokens and have no path to detokenize, and that are isolated from the CDE, can argue they fall outside scope.
  • Under PCI DSS v4.0.1, can a retailer keep a truncated PAN and a hash of the same PAN side by side?
    Only with additional controls that stop the two versions being correlated to reconstruct the PAN, as Requirement 3.5.1 requires. The guidance notes that keyed cryptographic hashes with key management under 3.5.1.1 are a valid control against such correlation.

An index token works like a cloakroom ticket: the ticket in a guest's pocket is worthless to a thief because the coat is behind the counter. But the counter, and everyone allowed to hand coats back, still needs guarding.

saying these in an interview costs you the question

  • Once PANs are tokenized, the whole retail environment is out of PCI DSS scope.
  • Encrypting the PAN database removes it from PCI DSS scope just like tokenization.
  • Masking the PAN on screens satisfies the requirement to render stored PAN unreadable.
  • The token vault can be scoped out because it sits behind a firewall.
  • Tokenizing the card verification code makes it acceptable to keep after authorization.