PCI scope is the #1 cost driver for enterprise retail compliance. Learn how tokenization removes cardholder data from downstream systems without rewriting apps.
PCI DSS scope reduction reduces the number of systems, people, and processes subject to the Payment Card Industry Data Security Standard (PCI DSS) by removing cardholder data from your environment.
For enterprise retailers operating across in-store point-of-sale (POS), e-commerce, mobile, and call center channels, scope is the single largest driver of compliance cost and complexity.
Level 1 merchants – i.e., those processing more than 6 million card transactions annually – spend between $150,000 and over $1 million per year on PCI compliance.
The primary cost multiplier is not the audit itself; rather, it is the size of the Cardholder Data Environment (CDE): how many systems store, process, or transmit cardholder data (CHD), and how many more are connected to those systems.
Tokenization is the most effective scope reduction strategy available, replacing Primary Account Numbers (PANs) with mathematically unrelated tokens that carry no exploitable value. Systems that handle only tokens fall entirely outside the PCI scope, reducing the CDE by up to 90%.
This guide explains why enterprise retail scope expands so rapidly, what PCI DSS 4.0.1 changed, and how to shrink your CDE across hybrid and legacy environments – including mainframe backends – without rewriting applications.
PCI DSS scope defines every system, person, and process that falls under PCI DSS requirements.
This includes any component that stores, processes, or transmits CHD or Sensitive Authentication Data (SAD).
It also includes "connected-to" systems – i.e., anything on the same network segment as the CDE – and "security-impacting" systems such as authentication servers, logging infrastructure, and vulnerability scanners.
The PCI Security Standards Council (PCI SSC) is explicit on this point: organizations should assume that everything is in scope until verified otherwise.
That guidance matters less for a small merchant running a single hosted checkout.
Instead, it matters enormously for a Level 1 retailer whose payment data touches POS terminals across thousands of stores, e-commerce platforms, mobile apps, call center Interactive Voice Response (IVR) systems, loyalty databases, Enterprise Resource Planning (ERP) backends, and analytics pipelines.
Scope is not the same thing as compliance.
Scope defines the number of systems you must secure. Compliance means meeting all applicable PCI DSS requirements within that scope.
Reduce the scope, and you reduce the number of controls to implement, the volume of evidence to collect, and the cost of the Qualified Security Assessor (QSA) engagement. For a deeper breakdown of what compliance validation actually requires, see our guide to PCI Attestation of Compliance.
The numbers confirm this. PCI DSS 4.0.1 now contains more than 500 requirements, up from 370 in version 3.2.1. A Level 1 merchant's first-year compliance program typically runs between $245,000 and $600,000, with ongoing annual costs of $160,000 to $350,000.
Internal teams spend 200 to 400 hours per year on evidence preparation alone. Every system you remove from scope reduces that cost.
The scope problem at enterprise scale is structural. It stems from the number of channels, systems, and technology paradigms that simultaneously handle cardholder data.
Five specific patterns drive scope expansion for large retailers.
A single customer might tap a card in-store, use Apple Pay on a mobile app, enter card details on the website, and call the contact center to dispute a charge – all within one week.
Each channel runs different technology stacks, different vendors, different encryption methods, and different compliance postures. Mapping where PAN data actually lives and moves across these channels is the first challenge. Until you map it, you cannot scope it.
This is where data discovery and classification becomes a prerequisite — you cannot reduce what you have not inventoried.
Any system sharing a network segment with CDE components gets pulled into scope. So does any system that manages CDE security: authentication servers, log aggregators, vulnerability scanners, admin workstations, even remote access tools used by third-party vendors.
Without rigorous segmentation, an enterprise's entire corporate network can become in-scope.
This is how the 2013 Target breach happened, i.e., an HVAC vendor's stolen credentials provided a pathway into the CDE that should never have existed.
Many of the world's largest retailers still process transactions on IBM Z or IBM i (AS/400) platforms. Mainframes process 87% of global credit card transactions.
Walmart runs IBM CICS on z Systems. Costco runs on IBM i for inventory, payroll, and transaction processing. These platforms are reliable and actively maintained, but PCI DSS controls and modern security tooling were not designed for them.
Vulnerability management is particularly difficult: no public database tracks mainframe-specific vulnerabilities or patches.
Log formats like System Management Facilities (SMF) records and Resource Access Control Facility (RACF) outputs are cryptic and low-level, requiring specialized parsing to feed into modern Security Information and Event Management (SIEM) platforms.
The skills gap compounds everything; the people who understand both mainframe security and PCI DSS requirements are retiring, and replacements are scarce.
PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 now require enterprises to inventory every script executing on payment pages, document business justification for each one, verify script integrity, and detect unauthorized changes in real time.
Enterprise e-commerce sites routinely run 30 to 100 or more third-party scripts on checkout pages, be it analytics, marketing tags, A/B testing tools, chat widgets, or fraud detection.
Each script is a potential Magecart or eSkimming attack vector, and each one expands your compliance obligations.
Large retailers maintain development, testing, and staging environments that often use copies of production data, including real PANs, for quality assurance and analytics.
These shadow CDEs expand PCI scope and represent breach vectors that QSAs increasingly scrutinize under the 4.0.1 standard.
Three strategies work together to shrink your CDE. Tokenization removes cardholder data from downstream systems. Network segmentation isolates what remains.
Data masking eliminates non-production exposure. Used in combination, they represent the most aggressive scope reduction available to a Level 1 merchant.
Tokenization replaces sensitive PANs with randomly generated tokens that have no mathematical relationship to the original data.
A token cannot be reversed to reveal the PAN without access to a secure token vault. Because tokens are not cardholder data, systems that store, process, or transmit only tokens fall outside the CDE entirely.
This is where tokenization differs fundamentally from encryption – and the distinction has direct scope implications.
Encryption transforms data using a cryptographic key, making it unreadable without the corresponding decryption key.
The PCI SSC, however, treats an encrypted PAN as equivalent to a cleartext PAN for scope purposes. The logic is straightforward: because decryption is possible, the encrypted data retains its sensitivity, and the systems handling it remain in scope.
This also means that encryption keys themselves become in-scope assets requiring their own controls, be it key management, rotation, storage, and access restrictions.
Tokenization sidesteps this entirely. However, the token is not a transformation of the PAN. It is a replacement. No key can reverse it.
Only the vault can map a token back to its original value, and the vault is the only component that remains in scope.
At enterprise retail scale, the strategy is to tokenize as early as possible in the payment flow. Capture the PAN at the checkout page, at the POS terminal, or at the IVR, then immediately replace it with a token.
From that point forward, every downstream system – e.g., analytics, loyalty, CRM, fraud detection, ERP, batch settlement – handles only tokens.
All of those systems drop out of PCI scope, and the practical impact is measurable.
A merchant that fully outsources payment capture and tokenization to a PCI-validated third-party service provider can shift from a Self-Assessment Questionnaire (SAQ) D with more than 300 applicable controls to SAQ A with only 22 controls. That is the maximum scope reduction available under the PCI DSS framework.
One clarification is important here: tokenization does not eliminate PCI scope entirely.
The tokenization vault, the token generation mechanism, and the initial capture point remain in scope. So do organizational controls related to policies, personnel, and physical security.
What tokenization eliminates is the long tail of downstream systems that previously touched cardholder data and required full PCI compliance. For a detailed walkthrough of how PCI tokenization works in practice, see our PCI tokenization guide.
Network segmentation physically or logically separates CDE systems from non-CDE systems using firewalls, access controls, and routing policies. Where tokenization removes data from scope, segmentation removes connectivity from scope.
For enterprise retailers, effective segmentation means isolating in-store POS networks from corporate networks, separating e-commerce payment processing infrastructure from marketing and analytics systems, and ensuring that third-party vendor access – e.g., HVAC contractors, maintenance providers, cleaning companies with physical server room access – cannot traverse into the CDE.
Segmentation does not reduce the amount of cardholder data in your environment. It reduces the number of systems classified as "connected to" the CDE.
Combined with tokenization, the effect compounds: tokenization shrinks the CDE itself, and segmentation shrinks the ring of connected systems around it.
PCI DSS 4.0.1 strengthened segmentation testing requirements. Annual penetration tests must now specifically validate that segmentation controls prevent cross-boundary access.
Any failure in segmentation validation can pull out-of-scope systems back into the CDE, thereby undoing months of scope-reduction work.
This is the pain point that enterprises underestimate most often.
Development, testing, and staging environments that use copies of production data, including real PANs, are in PCI scope. They are shadow CDEs. QSAs can and will assess them.
If your dev team copies the production database into staging for regression testing and that database contains unmasked card numbers, your staging environment requires the same controls as production.
The solution is static data masking, synthetic data generation, and/or test data management.
These techniques replace real PANs with realistic but non-sensitive substitutes that maintain referential integrity, so your test scripts still work, your joins still resolve, and your application logic still validates, without exposing actual cardholder data.
For practical guidance on implementing this, see our test data management best practices.
Masking eliminates non-production environments from PCI scope entirely. For a large retailer running dozens of dev and QA environments, this alone can remove significant systems from the CDE.
Most PCI scope reduction guidance focuses on cloud-native or e-commerce-only architectures. It ignores a fundamental reality: the largest retailers in the world still run mainframes as their system of record for transaction processing.
You cannot rip and replace a mainframe that processes millions of transactions daily with 99.999% uptime requirements.
The compliance challenge is not the mainframe itself. For example, modern IBM Z hardware supports pervasive encryption and even post-quantum cryptography.
The challenge is at the seams.
Cardholder data flows between a mainframe backend running COBOL and CICS applications and a cloud-native checkout or mobile app. These are two fundamentally different technology paradigms, each requiring different security tooling and different expertise.
For a deeper look at the security controls native to z/OS – including RACF, ACF2, and Top Secret – and where they fall short for PCI scope reduction, see our mainframe controls guide.
Mainframe log formats do not natively feed into cloud-based SIEMs.
Vulnerability management lacks a public CVE database for mainframe-specific issues. PCI DSS 4.0.1's continuous monitoring requirements are harder to meet with legacy tooling designed for batch-oriented operations.
The solution pattern is to tokenize cardholder data in transit between the mainframe and downstream cloud systems.
The mainframe backend handles the token vault and the initial capture – e.g., benefiting from the platform's inherent security strengths, including hardware-level encryption and fine-grained access controls.
Everything on the cloud side – e.g., analytics, CRM, loyalty programs, reporting dashboards – handles only tokens and falls out of PCI scope.
For enterprises building these pipelines, our guide to securing mainframe-to-cloud data flows covers the architecture in detail.
When this tokenization layer operates at the network level, it requires no code changes to COBOL applications, no modifications to z/OS configurations, and no disruption to existing mainframe workflows.
The data is tokenized transparently as it crosses the boundary between environments.
This is the scope-reduction approach that enterprise retailers with hybrid environments actually need – and it is the one most compliance content overlooks entirely.
PCI DSS 4.0.1 became mandatory on March 31, 2025.
Forty-seven previously future-dated requirements are now enforced, expanding the standard from 370 to more than 500 total requirements. Three changes have direct implications for enterprise scope management.
PCI DSS 4.0.1 moved the standard away from annual audit snapshots toward continuous monitoring and validation. This means scope discipline is no longer something you address once a year before the QSA arrives. It is an operational requirement.
Systems that drift into contact with cardholder data between audits can retroactively expand your CDE – and your next Report on Compliance (ROC) will reflect that expansion.
Requirements 6.4.3 and 11.6.1 introduced mandatory controls for payment page scripts that were not present in previous versions.
You must maintain a complete inventory of all scripts executing on payment pages, document business justification for each, verify integrity using mechanisms like Subresource Integrity (SRI) or Content Security Policy (CSP), and detect unauthorized changes in real time — not daily, not weekly, but continuously.
For an enterprise e-commerce site running 50 or more third-party scripts on checkout pages, this represents a substantial new compliance surface.
For merchants who have already been flagged on these requirements, our guide on how to fix Requirements 6.4.3 and 11.6.1 audit failures walks through remediation options.
Disk-level and volume-level encryption no longer qualify as encryption at rest under Requirement 3.5.1.2.
This affects enterprises that relied on storage-layer encryption for mainframe DASD or SAN volumes. Targeted Risk Analyses (TRAs) are now mandatory for multiple controls, requiring granular risk assessments on a per-system basis – i.e., more work at scale.
For a broader view of how encryption, masking, and tokenization each contribute to a PCI-ready data protection strategy, see our comparison guide.
Non-compliance carries material consequences.
Fines can reach $100,000 per month. Card brands may increase transaction fees or terminate merchant processing agreements. In the event of a breach, costs escalate to include forensic investigation, legal fees, regulatory penalties, and customer notification.
DataStealth is a data security platform that discovers, classifies, and protects sensitive data using tokenization, encryption, and masking – i.e., deployed at the network layer with no code changes, no agents, and no API integrations.
For enterprise retailers managing PCI compliance across hybrid environments, DataStealth addresses each of the scope expansion patterns described in this guide:
See how DataStealth can reduce your PCI audit scope — schedule a demo.
Lindsay Kleuskens is a data security specialist helping enterprises reduce risk and simplify compliance. At DataStealth, she supports large organizations in protecting sensitive data by default, without interrupting user workflows. Her work focuses on PCI DSS scope reduction, preventing client-side attacks, and enabling secure third-party integrations without the security risk. Lindsay regularly shares practical insights on modern data protection challenges and helps organizations navigate evolving compliance standards with confidence.
