Card data is a known liability for businesses. The global average cost of a data breach was US$4.44 million in 2025. Every server, log file, and backup that stores a primary account number (PAN) becomes part of what the Payment Card Industry Data Security Standard (PCI DSS) calls the cardholder data environment (CDE), and every aspect of that environment is subject to compliance requirements.

Tokenisation changes what’s actually in that environment by replacing the PAN with a substitute value that carries no exploitable worth on its own. If you implement tokenisation properly, you can shrink your compliance obligations to a fraction of what they’d be otherwise. Below, we cover how PCI compliance tokenisation works, the limits of its protections, where other security controls need to be implemented, and what the PCI Security Standards Council requires from a compliant token system.

Key takeaways

• Tokenisation can remove entire systems from the compliance scope of the Payment Card Industry Data Security Standard (PCI DSS), but only when the token generation, vault security, and detokenisation controls meet specific technical standards.

• Encryption and tokenisation protect card data differently under the PCI DSS, and many compliant architectures rely on both rather than choosing one over the other.

• Qualifying for the simplest PCI compliance self-assessment questionnaire depends on how card data flows through an integration rather than simply whether tokenisation is present somewhere in the system.

What is PCI DSS compliance?

PCI DSS compliance means meeting the security requirements set by the PCI Security Standards Council for any business that stores, processes, or transmits cardholder data. The standard covers 12 core requirements spanning network security, access control, encryption, and monitoring. It applies whether you’re running a single payments terminal or processing millions of transactions a year.

What the PCI DSS says about tokenisation

PCI DSS guidance for tokenisation advises that, if a token carries no value outside the system that created it, and if that system is properly isolated and secured, then the environments where the token lives don’t need to be assessed as if they hold real card data. Each PAN still exists somewhere, usually inside an encrypted vault, but tokenisation means it only exists in that single location, not spread across systems.

How tokenisation reduces PCI compliance scope

Tokenisation reduces PCI compliance scope by limiting the number of places where readable card data is stored or transmitted. This is true as long as the tokens can’t be reversed back to the original PAN by anyone outside the tokenisation system. If someone can calculate the PAN from the token using known logic, the token doesn’t reduce scope.

PCI DSS tokenisation guidelines and requirements for scope reduction

The PCI Security Standards Council’s guidelines include specific technical expectations for any system claiming scope reduction. These fall into two main categories: token generation and token vaults.

Token generation

Token generation must resist reverse engineering. Format-preserving tokens that mimic the length and structure of a given card number are safe as long as the substitution itself is unpredictable rather than derived through a reversible formula.

Tokens created through a one-way process, so there’s no mathematical inverse function, qualify more reliably for scope reduction than tokens generated through encryption with a recoverable key. Encrypted values are still considered cardholder data under PCI DSS definitions, even when they’re formatted to look like tokens. How tokens are generated determines how an assessor classifies your system. PCI DSS guidelines also address brute-force resistance. If the tokenisation algorithm can be guessed or reversed through repeated attempts, the token doesn’t qualify for scope reduction, regardless of how it’s generated.

Token vaults

The system for storing tokens is called a vault. The token vault needs to sit in a segmented network zone, apply strict role-based access control to data that maps tokens back to the original PAN, and log every detokenisation event in enough detail to support a forensic review. PCI DSS assessors generally hold to the standard that detokenisation should be rare, deliberate, and auditable. The guidance also requires the tokenisation provider, whether that’s an internal team or a third party, to undergo its own PCI DSS assessment. A compromised vault defeats the purpose of tokenisation.

Documentation has to prove the scope reduction claim to assessors and should include a data flow diagram that shows exactly where PANs exist in plaintext (i.e., readable data that’s not encrypted), where tokenisation happens, and where tokens take over across your systems. The diagram needs to be updated whenever a new system enters the payment path; if not, the scope reduction claim stops matching reality even if nothing else has changed.

How tokenisation compares with encryption under the PCI DSS

Both tokenisation and encryption protect the same underlying data, but the PCI DSS treats them very differently when it comes to scope. An encrypted PAN generally stays in scope unless the storing system has no access to the decryption keys needed to read the ciphertext (the encrypted format). The system holding the ciphertext has to meet the same access control, activity logging, and vulnerability management requirements as a system storing the PAN in plaintext, even though the practical risk is lower.

With tokenisation, there’s no key to protect. When a token is generated through a properly implemented one-way process, it can’t be mathematically reversed, which means the systems holding it exist outside the CDE.

In practice, many PCI-compliant architectures use both encryption and tokenisation, because each adds different safeguards. Encryption protects the PAN inside the vault for authorisation and settlement, while tokenisation protects the PAN everywhere else, such as in the systems that need to reference a transaction, issue a refund, or show a customer the last four digits, without ever needing the actual number. Ultimately, encryption protects usable data, and tokenisation removes it from a system entirely.

Who’s responsible for maintaining tokenisation compliance after implementation?

PCI DSS compliance requires ongoing validation, and tokenisation adds its own maintenance on top of the standard’s usual patching (i.e., applying security updates) and monitoring cycle. If you’re using a third-party tokenisation provider, you’re still responsible for confirming that the provider maintains its own PCI DSS validation and for reviewing its Attestation of Compliance every year. A lapsed certification on the vendor side puts your own scope reduction claim at risk, even if nothing changed on your end.

Internally, someone needs to own the data flow diagram and update it whenever a new system enters the payment path. Scope reduction can silently erode when, for example, a new analytics tool gets connected, or a support team exports transaction data into a spreadsheet for troubleshooting and finds a plaintext PAN that no one accounted for at the last assessment. Vault access logs also need periodic review to catch detokenisation requests that don’t match expected business processes.

In many medium-sized businesses, this is the responsibility of whoever manages the payments infrastructure (often someone in finance or engineering), who works with a qualified security assessor (QSA) during the annual assessment cycle. Smaller businesses using a payments provider that handles tokenisation end-to-end have a lighter lift, but they still need to confirm they haven’t reintroduced PANs into their own systems through exports, screenshots, or customer service workflows that fell outside the original scope reduction.

Is tokenisation enough to guarantee PCI DSS compliance on its own?

Tokenisation reduces scope, but it doesn’t eliminate compliance obligations for the systems that remain in scope. The vault still needs full compliance: the generation logic, token-to-PAN mapping data, and detokenisation controls all have to meet complete PCI DSS standards.

Pretokenisation touchpoints must also stay in scope. Any system that handles a PAN before it gets tokenised, such as a checkout page or a point-of-sale (POS) terminal, needs encryption in transit, network segmentation, and vulnerability scanning.

The self-assessment questionnaire (SAQ) eligibility gap

Many businesses assume any tokenisation solution qualifies them to use Self-Assessment Questionnaire A (SAQ A), the simplest self-assessment questionnaire. But that’s true only if the tokenisation system keeps the business from ever handling, transmitting, or storing PANs, typically through a hosted payment page or an embedded component where card data goes directly from the customer’s browser to the payments provider. A tokenisation approach where raw card data still passes through the business’s own server, even briefly, before it gets tokenised keeps that server in a broader scope, regardless of how strong the tokenisation is from that point forward.

How Stripe Payments can help

Stripe Payments provides a unified, global payments solution that helps any business – from scaling startups to global enterprises – accept payments online, in person and around the world.

Stripe Payments can help you:

• Optimise your checkout experience: Create a frictionless customer experience and save engineering time with prebuilt payment UIs, access to 125+ payment methods, and Link, a wallet built by Stripe.

• Expand to new markets faster: Reach customers worldwide and reduce the complexity and cost of multicurrency management with cross-border payment options, available in 195 countries across 135+ currencies.

• Unify payments in person and online: Build a unified commerce experience across online and in-person channels to personalise interactions, reward loyalty and grow revenue.

• Improve payments performance: Increase revenue with a range of customisable, easy-to-configure payment tools, including no-code fraud protection and advanced capabilities to improve authorisation rates.

• Move faster with a flexible, reliable platform for growth: Build on a platform designed to scale with you, with 99.999% historical uptime and industry-leading reliability.

Learn more about how Stripe Payments can power your online and in-person payments or get started today.