PCI DSS scope reduction is the work of shrinking the set of people, processes and technology an assessment has to cover. You do it by removing account data from systems that do not need it, isolating the systems that do, and proving the isolation holds. Every system you take out of scope no longer needs the full weight of Requirements 1 through 12 applied to it, or evidence produced for it every year.
This is the highest-leverage engineering decision in a card programme. Two companies with identical payment volumes can face assessments that differ by an order of magnitude in effort, because one designed for a small cardholder data environment and the other let card data spread. The catch is that scope is wider than most teams assume, and the parts people forget are rarely the parts that touch a card number.
How PCI DSS Scope Is Actually Determined
Scope is the cardholder data environment — the CDE — which means the people, processes and technology that store, process or transmit account data. That much is intuitive. The part that catches teams out is the second half: systems that are connected to the CDE, and systems that could impact the security of the CDE, are also in scope.
Connected-to and security-impacting systems are in scope even when they never see a primary account number. Your identity provider, configuration management server, monitoring control plane, the laptop your engineer administers the CDE from, the DNS resolver the CDE trusts — none hold a PAN, and all can be used to compromise the systems that do. An assessor treats them as in scope because the standard does.
Confirming scope is the entity's job, not the assessor's. You validate it at least annually and after any significant change; the assessor validates your result rather than producing it. That means someone on your side maintains the data flow diagrams, the inventory and the reasoning behind every exclusion. Walk in without that and the assessor starts from a broader assumption about what must be covered.
Significant change is the clause that catches growing companies. A new payment flow, a new region, a cloud migration, a new SaaS tool that touches checkout — each is a trigger to re-confirm scope, not something to reconcile at next year's assessment. The obligations that land on in-scope systems are covered in our walkthrough of the twelve PCI DSS requirements.
What a Network Segmentation Claim Must Prove
Network segmentation is not required by PCI DSS. It is the only practical way to avoid the alternative: without segmentation, the entire network is in scope. That is the real choice — segment deliberately, or assess everything.
Where segmentation is used to reduce scope, its effectiveness has to be tested rather than asserted. Penetration testing of the segmentation controls is expected at least annually, and more frequently for service providers. A diagram is not evidence. The evidence is a tester who sat in the out-of-scope network and could not reach the CDE.
A segmentation claim holds up under testing when four things are true:
- The controls enforce rather than advise. Deny by default, with an explicit allow-list of flows that each trace back to a business need. A rule set permitting any-to-any inside a VPC is not segmentation because the VPC has "prod" in its name.
- The allowed flows are few and documented. Every permitted path into the CDE is a path an assessor follows to decide whether the system on the other end is connected-to. Fewer paths means fewer in-scope systems.
- Shared infrastructure is accounted for. A hypervisor, Kubernetes control plane, shared load balancer or shared storage array serving both CDE and out-of-scope workloads puts that layer in scope. Network segmentation does not undo adjacency at the infrastructure layer.
- The testing is adversarial and current. Run from inside the untrusted segments, against the current rule set, after the last significant change — not a scan from a jump host already inside the boundary. See our guide to PCI DSS penetration testing.
The most common failure is not a weak firewall. It is a boundary that was accurate when drawn and has since been punctured by a dozen operational conveniences nobody documented.
Want a second read on where your CDE boundary actually sits?
Share your work email and we'll walk your payment flows, mark every connected-to and security-impacting system, and flag the ones most likely to pull your network back into scope.
Tokenization and What Stays in Scope
Tokenization replaces the PAN with a surrogate value — a token — that has no usable relationship to the original number. Systems that only ever hold tokens can be out of scope, and this is where the largest reductions in cardholder data environment scope usually come from. Your order service, analytics warehouse, support tooling and reconciliation jobs can all run on tokens.
What stays in scope is worth naming, because teams routinely tokenize well and then leave three things in the assessment:
- The tokenization vault itself. The system holding the mapping between token and PAN is squarely in scope, with the full weight of the standard on it.
- The key management supporting it. Whatever protects the stored account data and the mapping is in scope, including the processes and people administering those keys.
- Anything able to request de-tokenization or retrieve the PAN. This is the one that spreads. A service with credentials to call the de-tokenization API is in scope even if it only calls it for one edge case — as is the admin console that can reveal a full card number, and the batch job that re-expands tokens before sending a file to a processor.
Treat de-tokenization as a privilege held by as few systems as possible, and check who actually holds it rather than who was supposed to. An entitlement granted for a migration two years ago keeps a service in scope indefinitely.
Using a third-party tokenization provider is usually right for a midmarket company, but outsourcing does not outsource accountability. You remain responsible for your own compliance, third-party responsibilities have to be documented so every requirement has an owner, and each provider's compliance status has to be tracked rather than assumed.
Redirect and Iframe Patterns for E-Commerce
For e-commerce, two questions determine scope: where the payment form is actually served from, and whether your page can influence the payment transaction. The redirect-versus-iframe-versus-direct-post decision reduces to those two.
A fully hosted redirect, where the customer leaves your site for the provider's page and returns after payment, keeps the most out of scope. A properly isolated iframe served directly from the provider — your page supplying the container and nothing else — is close behind. A form rendered by your own code, posting card data through your servers, puts your web tier and everything behind it in scope. That choice, made once at implementation time, sets the size of every assessment you will ever do, and determines which self-assessment questionnaire you qualify for — see our breakdown of the PCI DSS SAQ types.
The subtlety PCI DSS v4 made explicit is script integrity on the payment page. Scripts that can affect the integrity of checkout bring the page hosting them into scope — which puts your tag manager, analytics snippet, session-replay tool, chat widget and A/B testing library in the conversation. An attacker who can modify a script served into your checkout page can overlay a replacement form or read the fields around an iframe, without ever touching your payment provider.
So a redirect or iframe pattern reduces scope only when the hosting page is controlled: an inventory of every script on it, a justification for each, assurance that each is the script you intended, and an alert when the set changes. Most teams discover at this point that nobody knows who added the fourth analytics tag.
P2PE for Card-Present Merchants
For a card-present merchant, point-to-point encryption using a validated solution with hardware terminals substantially reduces what is in scope. The card data is encrypted inside the terminal, before it reaches anything you operate, and your store network and point-of-sale systems never handle usable account data.
The word carrying the weight is "validated". A validated P2PE solution has had its encryption, key management and device handling assessed as a package. An encryption arrangement your integrator calls end-to-end, assembled from components, does not carry the same scope reduction even if the cryptography is sound — what was validated was never the whole chain.
What remains yours is physical and procedural: terminal inventory, tamper inspection, device deployment and decommissioning, and following the solution provider's instruction manual. Small obligations next to assessing a store network, which is why the pattern justifies the hardware refresh.
The Traps That Quietly Expand Scope
These are the traps that expand scope after the architecture work is done — found during assessments rather than during design. Each is a path by which a system you consider out of scope becomes connected-to or security-impacting.
Flat Networks and Shared Services
A flat network means everything is in scope, and plenty of cloud environments are flatter than their diagrams suggest. The usual culprits: a single VPC with permissive internal security groups, a shared Kubernetes cluster running CDE and non-CDE workloads as namespaces, a shared database instance with CDE and non-CDE schemas.
Shared services are the subtler version. Active Directory, your identity provider, secrets manager, CI/CD runners, patch management server and endpoint management console all reach into the CDE by design. They are security-impacting and in scope — and because they reach everything else too, they are the ones most likely to be administered casually.
Jump Hosts and Support Tooling
A jump host is in scope, which surprises nobody, but so is the laptop connecting to it, the identity system authenticating that laptop, and the MFA provider behind it. Administrative access is a chain, in scope up to the point where a control you can evidence breaks it.
Support tooling is where account data leaks back into systems you thought were clean. An agent asking a customer to read a card number over a recorded call puts the recording platform in scope. A screen-sharing session displaying a full PAN puts the sharing tool and the agent's endpoint in scope. A customer pasting a card number into a chat widget or a ticket puts the ticketing system in scope — and that happens whether you designed for it or not, which is why detection matters as much as policy.
Logging Pipelines and Backups
A logging pipeline that carries PAN is a CDE, wherever it ends up. Verbose request logging, an unredacted error payload, a debug dump of a webhook body — any of these ships account data into a log aggregator never designed to be in scope, along with every system that queries it and every analyst with access.
Backups follow the same rule. A snapshot of a CDE database is cardholder data at rest in whatever account, region or archive tier holds it, for as long as retention keeps it. Teams that reduced their live scope correctly often find the backup estate still holds years of account data under a policy nobody revisited. Scope reduction is not finished until those copies are purged or brought inside the boundary.
Running a PCI DSS Scope Reduction Project
To reduce PCI scope deliberately rather than discover it at assessment time, work in this order.
- Map the real flows. Follow account data from every entry point — checkout, terminals, phone orders, batch files, refunds, chargebacks, support channels — to every place it rests. Interview the teams rather than reading the architecture document.
- Find the data you did not expect. Scan file shares, databases, logs, ticket systems and backups for PAN patterns. This step changes the plan more often than any other.
- Eliminate storage you do not need. Most stored card data supports a feature that could work on tokens, or survives because nobody turned off a legacy flow. Deleting it is the cheapest scope reduction available.
- Choose the architecture pattern per channel. Hosted redirect or isolated iframe for e-commerce, validated P2PE for card-present, a tokenization provider for anything requiring stored credentials.
- Draw the boundary, then enforce it. Deny by default, allow-list the flows, and separate shared infrastructure rather than only shared networks.
- Test the boundary and keep the inventory alive. Annual segmentation testing, scope confirmation after significant change, and a documented list of third-party responsibilities with their compliance status tracked.
Steps three and four carry the savings; steps one and two decide whether they are aimed at the right targets. The cost of getting this wrong compounds every year, as our analysis of what PCI DSS compliance costs lays out.
PCI DSS Scoping Questions Teams Ask
These are the PCI DSS scoping questions teams ask most often once they start taking scope reduction seriously.
No. Systems that only ever hold tokens can be out of scope, which is a large reduction for most architectures. But the tokenization vault, the key management supporting it, and any system able to request de-tokenization or retrieve the PAN all stay in scope. Check which service accounts actually hold de-tokenization entitlements rather than which ones were meant to.
Segmentation is not required by the standard; the consequence of not using it is that the whole network falls within scope. Where it is used to reduce scope, its effectiveness has to be tested — penetration testing of segmentation controls is expected at least annually, and more frequently for service providers.
Yes, and this is the point most teams miss. Scope covers systems connected to the CDE and systems that could impact its security, regardless of whether account data passes through them. Identity providers, configuration management, monitoring control planes, administrative endpoints and shared infrastructure are routinely in scope on that basis.
You do. Confirming scope is the entity's responsibility, at least annually and after significant change; an assessor validates your scope rather than defining it. Arriving without current data flow diagrams, an inventory and documented reasoning for exclusions means the assessor starts from a broader assumption.
No. Outsourcing does not outsource accountability. You remain responsible for your own compliance, third-party responsibilities have to be documented so every requirement has a clear owner, and each provider's compliance status has to be monitored. An attestation is evidence to collect and refresh, not a reason to stop looking.
Keep your CDE boundary defensible between assessments
Book a demo and we'll show how Konfirmity tracks your in-scope inventory, segmentation test evidence and third-party compliance status so scope confirmation is a review rather than a rebuild.
Book a demo
Make the Next Assessment Smaller
The most valuable artefact in a card programme is an accurate, current picture of what is in scope and why. Everything else — the control work, the evidence, the questionnaire, the assessor's time — is sized by it. Produce that picture first, with the connected-to and security-impacting systems named explicitly, and the rest becomes a known quantity.
Start with the two steps that cost nothing but attention: follow account data through every channel including the ones nobody designed, and search your logs, tickets and backups for PAN you did not know you held. Those findings tell you whether your next move is tokenization, an architecture change at checkout, or deleting data that should have been purged years ago. The current standard is v4.0.1, published with its supporting guidance by the PCI Security Standards Council.
Then keep scope from creeping back: confirm it annually and after every significant change, test the boundary rather than asserting it, and keep a live register of which third party owns which requirement. If you are still placing the card programme alongside your other obligations, our comparison of PCI DSS and SOC 2 covers where the two overlap, and the PCI DSS glossary entry is the shorter starting point.
