Tokenization and PCI DSS scope: what tokens take out of scope

Does tokenization take systems out of PCI DSS scope?

Tokenization does not remove the need to maintain and validate PCI DSS compliance, but it can take specific systems out of scope. Under the PCI SSC's 2011 *PCI DSS Tokenization Guidelines*, the test is whether a system can retrieve or access the primary account number (PAN). If it cannot, and it is not connected to the cardholder data environment (CDE), it may be removed from the requirements. The answer therefore depends on three questions: can any system in the flow retrieve PAN, where does the token vault sit, and is the tokenization service outsourced or run on your own infrastructure. The organization owns its controls and decides its scope. A Qualified Security Assessor (QSA) is the only party who can issue the Report on Compliance (ROC) or the Attestation of Compliance (AOC) that confirms the result.

Start by mapping every place PAN is captured, processed, stored or transmitted, including the point of capture and every de-tokenization point. The token vault is part of the CDE and must be segmented from out-of-scope networks, so it is usually the system that keeps the scope in place. For each system you want to exclude, document how you verified that it cannot reach the vault, that it holds no PAN, and that no de-tokenization call exists in its code path. Then test those claims, including firewall rules and API permissions, rather than relying on architecture diagrams alone. Confirm with your QSA how they expect this evidence to be presented before you change the environment.

Conditions a token-only system must meet to leave scope

A system that only ever sees tokens can leave PCI DSS scope, but only after the organization proves it has no path to PAN. Each condition below is a claim an assessor will test, and each one needs evidence that is kept current, not a design diagram alone.

No connection to the CDE

The token-only system must have no network path, shared credential, integration or data feed into the cardholder data environment. Verify this by reviewing firewall rules, routing tables, API integrations and service accounts, then testing from the candidate system that the CDE cannot be reached. Repeat the review after every change, because a new reporting job or log forwarder can quietly reconnect the two environments.

Verified inability to retrieve PAN

The organization must confirm that the system cannot retrieve or access PAN or other account data, not merely that it is not designed to. The Tokenization Guidelines require that PAN cannot be retrieved from the system before it is removed from scope. Ask for a documented data-flow analysis, a review of stored fields, caches and logs, and a test showing that tokens resolve to nothing usable outside the vault.

Segmentation from the token vault

The token vault is part of the CDE and must be separated from networks that are out of scope. Segmentation should be enforced with controls the assessor can inspect, such as restrictive network policies between the vault and the token-only system. The assessor will typically test whether segmentation actually blocks traffic, so a logical diagram without tested rules does not satisfy this condition.

No de-tokenization path

No process, API, user role or batch job may return a token to its original PAN from the out-of-scope system. Inventory every de-tokenization point, including customer service tools, reconciliation jobs, refund workflows and analytics exports. If any such point exists, the environment that uses it falls back into scope, so ask the vendor and your own teams to show access logs and role definitions for the vault.

Outsourced versus on-premises tokenization: who carries which requirements

When the merchant runs its own tokenization system inside its own infrastructure, the merchant owns every applicable PCI DSS requirement for that system. The tokenization service, the token vault and any de-tokenization path are treated as part of the cardholder data environment, so they must be built, hardened, monitored and assessed like any other CDE component. The Tokenization Guidelines note that a merchant running an on-premises solution is fully responsible for all applicable requirements.

Full control scope: The merchant carries requirements covering network security, secure configuration, encryption, access control, logging and vulnerability management for the vault and its supporting systems.
Vault segmentation: The token vault must be segmented from networks that are out of scope, and the merchant must show that those networks cannot reach it.
Retrieval testing: Before any system is treated as out of scope, the merchant must confirm it is not connected to the CDE and cannot retrieve or access PAN.
Internal evidence: Assessors expect the merchant's own records for configurations, access reviews, scan results and key management.
Ongoing effort: Patching, monitoring and change control for the vault recur every year and grow with the environment.

Confirm with your QSA which systems the assessment will treat as in scope, and ask for the segmentation test method in writing.

EMV payment tokens and the SSC's three tokenization documents

The PCI SSC publishes three tokenization documents, and they do different jobs. The first is the 2015 Token Service Provider requirements for EMV Payment Tokens, which set requirements that apply to token service providers issuing EMVCo Payment Tokens. The second is the 2015 Tokenization Product Security Guidelines, which are advisory and have no validation program, so no assessor certifies a product against them. The third is the 2011 PCI DSS Tokenization Guidelines, which give general guidance on acquiring tokens but contain no implementation requirements. Before you rely on any of them in a scope decision, confirm with the PCI SSC which document applies to your token type, since the SSC's FAQ on token types maps each document to its purpose.

An EMVCo Payment Token defined and used under the EMV Payment Tokenisation Specification is not account data for a merchant or acquirer when it sits outside the token service provider's token data environment. That is the central scope point. The token can be stored, logged and passed between systems without bringing those systems into PCI DSS scope on the token's account. The boundary does not hold for everything nearby, however. Any system that also handles PAN, or that connects to systems that do, stays in scope. In practice this means a checkout server that receives a payment token but still receives the PAN at some step, or an order database holding both values, must be assessed as cardholder data environment. Ask your token provider to document exactly which data elements leave its environment and which do not, and test that each interface carries only the token.

The practical consequence is that the three documents and the EMV specification answer different questions. The Tokenization Guidelines tell you how tokenization affects validation, the Token Service Provider requirements tell a token issuer what it must meet, and the Product Security Guidelines describe what a tokenization product should do without a certificate attached. None of them removes your own obligations. Your team still owns the decision to treat a system as out of scope, and an assessor will test that decision against the actual data flows. Keep a written record of each token type in use, the systems that receive it, and the evidence that PAN never reaches them, and review that record whenever a payment channel or token provider changes.

How the scope decision is validated in a PCI DSS assessment

This sequence turns a tokenization design into a scope decision that an independent assessor can test, and it ends with a signed Attestation of Compliance that the organization owns. Each step produces a document or check that the next step relies on.

Define the tokenization design and data flows
The organization, with its architects and any tokenization provider, documents where PAN is captured, where tokens are created, where they are stored and where de-tokenization happens, if it happens at all. The output is a data-flow diagram and a written description of the tokenization model, whether outsourced or on premises. The step is complete when every point where PAN enters or leaves a system appears on the diagram, and the team can explain which party operates each component.
Map every system that touches PAN or tokens
Using the data-flow diagram as the starting point, the team inventories each system component that captures, processes, stores or transmits PAN, including the token vault, the capture point, de-tokenization services, logs, backups and any system that performs hashing. The output is a system inventory that marks each component as CDE, connected to the CDE, or candidate for out-of-scope status. The step is complete when the inventory has an owner and a classification for every component.
Verify token-only systems cannot retrieve PAN
For each system proposed as out of scope, the team tests whether it is connected to the CDE and whether it can retrieve or access PAN or other account data, including through APIs, shared credentials, replicated databases and administrative consoles. The output is a written verification record with the test method, the evidence reviewed and the sign-off of the person accountable for the system. The step is complete only when the record shows that no path to PAN exists. If any path exists, the system stays in scope.
Segment the CDE and test the boundary
The team implements network segmentation between the token vault and the CDE on one side and out-of-scope networks on the other, then tests whether the segmentation works as designed. Testing commonly includes attempts to reach the CDE from out-of-scope segments and a review of firewall and access rules. The output is segmentation test results and a list of any remediation items, with each item closed and retested before the next step. Confirm with your assessor how they expect segmentation to be tested, because the method affects the evidence they will request.
Document the scope in the scope statement
The organization records the final scope decision in a written scope statement that lists the in-scope and out-of-scope systems, the tokenization model, the responsible party for each component and the basis for each out-of-scope decision. The output is the scope document, reviewed and approved by management and linked to the diagrams, inventories and verification records from earlier steps. The step is complete when another person can follow the chain from a system name to the evidence that supports its classification.
Assessor validates the scope decision
A Qualified Security Assessor, or the organization completing a Self-Assessment Questionnaire where that route applies, reviews the scope statement and the supporting evidence, samples the verification and segmentation results, and confirms that the out-of-scope systems are supported. The output is the assessor's finding within a Report on Compliance, or the questionnaire responses for an SAQ. Where the assessor finds a gap, the organization remediates and the assessor retests. Ask your assessor early which evidence they expect, since their findings define what counts as validated.
Sign the Attestation of Compliance
Once the assessment is complete, an authorized officer of the organization signs the Attestation of Compliance that accompanies the ROC or SAQ. The attestation states the scope the assessment covered and the validation result, and it is the document the organization presents to acquirers, payment brands and customers. The output is a signed AOC with a date, which the organization must keep current for its next assessment. Because the signature represents the organization's own statement, the officer should confirm the scope statement matches the assessed environment before signing.

What to have in place before a QSA tests the tokenization scope

A QSA will not accept a tokenization scope claim on description alone. The cards below list the records to assemble before fieldwork, and each one says how to check that the record actually supports the scope you are claiming.

Current data-flow and network diagrams

Diagrams must show where PAN enters, where the token is created, which systems hold the token and where de-tokenization happens. Walk each arrow against the live environment, not the design document. Any system that appears on a flow but not on the diagram, or on the diagram but not in the flow, is a scoping gap. Check that the diagrams carry a date and an owner, and that they were updated after the last significant change.

PAN discovery result

A discovery run across the systems in the claimed out-of-scope area shows whether any stored card number exists outside the vault. Ask for the tools, search patterns, locations scanned and the date of the run. A clean result on a narrow search does not prove absence, so confirm that backups, logs, file shares and mailboxes were included. Record any hit and its remediation before the QSA arrives.

Documented de-tokenization access

Every point where a token is exchanged back for PAN is a point where the CDE expands. List each de-tokenization service, the role or system account allowed to call it, and the business reason. Confirm that access is restricted by need to know, that calls are logged, and that the list matches the access reviews. If the list has an entry you cannot explain, treat that system as in scope until you can.

Segmentation test evidence

The token vault is part of the CDE, so the boundary between it and out-of-scope networks has to be proven. Keep the test plan, the test scope, the source and destination of each attempted connection, and the results showing that blocked paths stay blocked. Ask whether the test was run from the out-of-scope side, since a test run only from inside the CDE does not show the boundary holds. Repeat the test after any change to the firewall or network design.

Provider AOCs for outsourced tokenization

When a third party generates or stores tokens, its current Attestation of Compliance is part of your evidence, not a substitute for it. Check that the AOC covers the tokenization service you use, that the validity period includes the assessment window, and that the service description matches your integration. Confirm what the provider's responsibility matrix assigns to you, because the Tokenization Guidelines keep the merchant responsible for PCI DSS controls wherever PAN is captured or de-tokenized.

Written responsibility records

Each control that applies to the CDE, the token vault, the capture point and any de-tokenization path needs a named owner on your side and, where outsourced, a named owner at the provider. Keep the agreement terms, the responsibility matrix and the annual review of each provider's status. Ask whether any control is listed as shared but has no owner on one side, since those gaps are where assessors usually write findings.

Who owns the controls, who prepares evidence and who issues the report

The organization that accepts card payments owns the scope decision and the controls that protect cardholder data. Tokenization does not transfer that responsibility to a vendor. The organization must decide which systems can be treated as out of scope, confirm that each one cannot retrieve PAN, and keep the decision current as systems change. Under the PCI SSC Tokenization Guidelines, PCI DSS controls still apply wherever PAN is captured, processed, stored or transmitted, so the organization remains accountable for the point of capture and any de-tokenization points, even when tokenization is outsourced.

Scope decision: Record which systems are in scope, which are out of scope, and the reasoning for each boundary.
Vendor management: Maintain written agreements and annual monitoring of every service provider that shares cardholder data, as Requirement 12 expects.
Ongoing control operation: Run segmentation checks, access reviews and log reviews for the in-scope environment, including the token vault if it is on premises.
Assessment cooperation: Provide the assessor with the data-flow diagrams, inventories and evidence needed to test the scope claim.
Attestation: Sign the Attestation of Compliance or the assessor's report only after the validation is complete.

Check whether your team can name the person who signs off on each scope boundary and when that sign-off was last reviewed.

Where tokenization projects lose their scope benefit

A tokenization project removes systems from PCI DSS scope only when the systems that remain can no longer retrieve PAN. The cards below describe the paths where that condition quietly fails, from forgotten de-tokenization routes to changes that reopen scope after assessment. Each one is a check to run before the scope statement is signed.

Forgotten de-tokenization paths

A de-tokenization call is often built for one purpose, such as a refund or a customer service lookup, and then reused by a reporting job, an export or an integration nobody documented. Each path that returns PAN to a system brings that system back into scope, even if the vault itself is well protected. Map every API, batch job, admin screen and support tool that can request a clear PAN value, and confirm which of them still need it. Treat the list as incomplete until a test request from each system has been traced end to end.

Logs and backups still holding PAN

Tokenization removes PAN from the production database, but the same number can persist in application logs, debug traces, error messages, message queues and database backups created before the cutover. These copies are often forgotten because they sit outside the payment application. Search log stores, backup catalogs and retained snapshots for unmasked card numbers, and set retention so that legacy copies age out or are purged under a documented procedure. Any system where PAN is found is in scope until it is cleaned.

Token service connected to the wider network

The tokenization system is part of the cardholder data environment, so it must be segmented from networks that are out of scope. In practice, a token service often shares a subnet, a directory service, a monitoring agent or a management jump host with general corporate systems. Each shared connection can give an out-of-scope host a route to the vault or its keys. Document the data flows into and out of the token service, test that the segmentation controls block unauthorized paths, and confirm the result with your assessor before relying on it.

Unverified provider scope claims

A tokenization provider may describe its service as removing the merchant from scope, but the guidance says the merchant must still manage the service providers it shares cardholder data with and must verify that a system cannot retrieve PAN before treating it as out of scope. Ask for the provider's current attestation of compliance, the responsibility matrix and the scope of its service, and check that the matrix matches how your systems actually call the service. Where the provider does not cover a function, such as capture at the point of entry, that function stays with you.

Significant change reopening scope

A scope conclusion is valid for the environment as it was assessed. Under the SSC's guidance on significant change, a new integration, a new de-tokenization consumer, a changed token format or a migration to a new vault can alter which systems hold or can retrieve PAN. Such changes should trigger a review of the scope statement and the segmentation tests before the change goes live. Build this check into change management so that the reduced scope is re-verified each time the token architecture moves.

Questions buyers ask about tokenization and PCI DSS scope

Does tokenization remove PCI DSS entirely from my environment?

No. Tokenization does not remove the need to maintain and validate PCI DSS compliance. According to the PCI SSC Tokenization Guidelines, it may simplify validation by reducing the number of system components the requirements apply to. The token vault, the systems that capture PAN and any de-tokenization points stay in scope. Your assessor will still expect evidence for every system that can see or retrieve card data, so plan for a smaller scope, not an absent one.

Can a token-only system be declared out of PCI DSS scope?

Only after you verify it. A system can be treated as out of scope when it is not connected to the cardholder data environment and cannot retrieve or access PAN or other account data. Verification means testing the connection paths, data flows and access rights, then documenting the result for the assessor. If the merchant can retrieve PAN from that environment, the environment is in scope. Segmentation between the token vault and out-of-scope networks must also be demonstrated, not assumed.

What does outsourced tokenization still require from my organization?

Outsourcing moves some work to the provider but not the accountability. PCI DSS controls still apply wherever PAN is captured, processed, stored or transmitted, including at the point of capture and at any de-tokenization points. You must manage the service providers you share cardholder data with, keep their responsibility evidence and monitor their compliance status. The PCI SSC Tokenization Guidelines are clear that the merchant remains responsible for the parts it controls. Ask the provider to state in writing which requirements it covers and which remain yours.

Are EMV payment tokens out of PCI DSS scope?

An EMVCo Payment Token defined and used under the EMV Payment Tokenisation Specification, and outside the token service provider's token data environment, is not account data. According to PCI SSC FAQ 1326, it is out of PCI DSS scope for merchants and acquirers. This does not cover the whole payment flow. Any system that also handles PAN, or connects to systems that do, stays in scope. Confirm with your acquirer and assessor which token type your provider issues before relying on this position.

What work must my own team do to reduce scope through tokenization?

Your team owns the mapping and the proof. Start with a current inventory of every system that touches PAN before tokenization, then document the data flows, including any places where clear PAN still appears such as logs, backups or support tools. Your team must verify that token-only systems cannot reach PAN, maintain segmentation controls, review the scope each year and keep the evidence assessors will request. A provider or consultant can help prepare this material, but the organization owns its scope decisions.

How does tokenization affect my SAQ eligibility?

Tokenization can change which Self-Assessment Questionnaire fits your environment, but only when the systems that store, process or transmit PAN are clearly separated from the rest of your network and your payment channel is covered by the SAQ's eligibility criteria. Choosing an SAQ depends on how you accept cards and what you store, so review the SAQ eligibility conditions against your final architecture. Do not select the SAQ until the scope verification is complete and documented.

What drives the cost of a tokenization scope reduction project?

Cost depends on the drivers of the work, not on a standard figure. The main drivers are the number of systems that currently touch PAN, how many data flows must be redesigned or segmented, whether the tokenization is outsourced or on-premises, the number of integrations and third parties involved, and how much existing documentation is usable. On-premises tokenization shifts more responsibility to your organization, which adds internal effort. Ask any provider for a written scope listing deliverables, responsibilities and assumptions, and confirm with your QSA whether the proposed reduction will be accepted before work begins.

How DeployOpen prepares tokenization scope evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the tokenization boundary is designed and evidenced before an assessor arrives. We prepare systems and evidence for your assessment, while your organization owns its scope decisions and the independent QSA issues the report.

How we scope

Written scope agreed before work starts, stating which systems are proposed as out of scope and why
Network and data-flow mapping that shows whether any out-of-scope system can reach the token vault or retrieve PAN
Confirmation steps for each system claimed out of scope, documented so your QSA can test them

How we build

Segmentation of the tokenization system as part of the cardholder data environment, separated from out-of-scope networks
Controls for capture points and de-tokenization points, where PCI DSS requirements still apply to PAN
Configuration and hardening of the token service, with access restricted to the roles that need it

How we hand over

Scope documentation, architecture diagrams and the inventory of in-scope components for your records
Test results and configuration evidence mapped to the requirements your assessor will sample
Runbooks for re-confirming scope after significant changes, with your team trained to operate them

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Scope re-verification when systems, providers or payment flows change, agreed in the written scope
Clear ownership: your organization keeps the scope decision and the assessor issues the validation