How to Reduce PCI DSS Scope: What Actually Takes a System Out of the CDE
To reduce PCI DSS scope, identify every system that stores, processes, or transmits cardholder data, then remove or isolate the ones that do not, and document the decision. Out of scope means proven. You need a data flow map, a written determination, segmentation test results, and an updated scan scope. Scope reduction is an evidence task, not a diagram edit.
A merchant walks into a scope review with a payment flow diagram that looks clean: checkout runs on a PCI DSS compliant third party, cards never land on their own servers, and the CDE box is small. The assessor asks where the reconciliation reports go, who can reach the point of sale servers, and when the last segmentation test was run. Within twenty minutes the "small" CDE has grown to include a database nobody remembers, a staging environment that mirrors production, and a support jump host that can reach the payment VLAN. The diagram said out of scope. The environment said otherwise.
This problem is nothing new, but the clock around it got shorter this week. CISA's Known Exploited Vulnerabilities catalog now lists 1,723 vulnerabilities confirmed exploited in the wild, and the entries added between September 21 and September 24, 2026 hit exactly the products that sit on the edge of a cardholder data environment: an unauthenticated remote code execution flaw in F5 BIG-IP APM (CVE-2026-94127), an improper certificate validation flaw in Check Point Security Gateway (CVE-2026-85102), and an authorization flaw in Adobe Commerce and Magento (CVE-2026-71362) with a BOD 26-04 remediation due date of September 27 [3]. Every one of those products is the kind of system a business argues is out of scope, and every one of them weakens that argument if the boundary is not proven. IBM's 2026 Cost of a Data Breach data adds the financial weight: organizations that use AI and automation in security operations cut average breach costs by almost $2 million [2].
Clone Systems' position, from the assessment side of this: reducing PCI DSS scope is not a drawing exercise. A system is out of scope only when you can prove it does not store, process, or transmit cardholder data and cannot affect the security of systems that do, and that proof has to survive a QSA's questions and the quarterly ASV scan list. In our scoping reviews, the systems that stay in scope the longest are rarely the ones on the payment flow diagram. They are the storage copies, the staging environments, and the old integrations that can still reach the cardholder data environment [5].
How Do You Reduce PCI DSS Scope in the First Place?
You reduce PCI DSS scope by shrinking the set of systems that meet the CDE definition, which covers systems that store, process, or transmit cardholder data, systems connected to the CDE, and systems that could affect its security. Everything else is a decision you make and then evidence.
PCI DSS v4.0.1 puts the scoping obligation on paper. Requirement 12.5.1 requires an inventory of all system components, including those that could affect the security of the CDE, and Requirement 12.5.2 requires the scope to be reviewed and updated as the environment changes [6]. The PCI SSC's Information Supplement on scoping and segmentation for modern network architectures makes the same point in architectural terms: hybrid multi-cloud CDEs and zero trust designs are now common, and effective scoping expects documented policies, strong identity and access management, and a working understanding of where data is stored and how it flows [4].
There are three levers, and they do different jobs:
- Eliminate. Stop storing cardholder data. Move it to a PCI DSS compliant third party so the data no longer touches systems you own. This is the only lever that removes data, not just access.
- Isolate. Segment the CDE from everything else and prove the segmentation works under Requirement 11.4.5, so the everything else drops out of scope.
- Document. Write a determination for each system, keep the data flow map current, and feed the same decision into the asset inventory and the ASV scan scope.
Most clients reach for lever two first, because it looks like an engineering project. Lever one is usually the bigger win, because storage is what keeps a system in scope the longest. A server that wrote card numbers to disk once, for a "just in case" report, has been processing cardholder data ever since, and no firewall rule will ever take it out.
Test your own environment in three questions
Run this against your current data flow map. It takes about ten minutes and it tells you whether your scope is a decision or an assumption:
- Which of my systems store cardholder data right now, and why? If the answer is "nobody remembers," that system is in scope until proven otherwise.
- Which out-of-scope systems can reach the CDE on any path, network or otherwise? A support tool, a backup job, or an integration that can write into the CDE keeps itself in scope [11].
- When did I last prove the segmentation holds? If the last test predates the last significant network change, the proof is stale.
Tokenization vs Segmentation for PCI DSS Scope: Which One Actually Shrinks the List?
Tokenization attacks scope from the data side; segmentation attacks it from the access side. Both are legitimate, and neither works if the boundary is only asserted.
| Tokenization (move the data) | Segmentation (wall the data) | |
|---|---|---|
| What it removes | Storage and processing of cardholder data in your environment | Reachability of the CDE from out-of-scope systems |
| What it requires | A PCI DSS compliant third party for the data that moves, plus a current scoping decision [1] | Requirement 11.4.5 segmentation testing, kept current as the network changes [4] |
| What breaks it | The gateway still receives the full primary account number "for reconciliation," so the system still processes cardholder data | The boundary moves after a migration and the test result goes stale |
| Effect on ASV scope | Can take systems off the in-scope list entirely [8] | Keeps the CDE, but proves the rest stays out [8] |
The tokenization caveat is the one that surprises people most. When a client tokenizes and the scope does not shrink, it is almost always because the payment gateway still receives the full primary account number for reconciliation. The card never left the building. It just stopped being stored. PCI SSC's resource guide on ASV scanning frames the same logic for SAQ A merchants: the scanning obligation attaches to the merchant system that redirects payment to, or embeds a payment page from, a compliant third party, because the external link between the store and the provider is the part an attacker can reach [1]. If your system still sits on that link, or still sees the raw number, it is in scope and it stays on the scan list.
If you are deciding between a tokenization project and a segmentation test, the two are not substitutes. In our work the best scope reductions come from both: tokenization removes the data, segmentation proves the boundary, and the scan scope gets updated to match the new reality. Our PCI ASV external vulnerability scanning runs against the revised scope [13], and our team can review your data flow map before you commit to either project.
How Do You Prove a System Is Really Out of PCI Scope?
An out-of-scope claim is only as good as its evidence, because the assessor is not going to take the word of the person who drew the diagram. This is the Clone Systems 5-Part Out-of-Scope Evidence Pack, and it is the same checklist we run with clients before a scoping decision goes in front of a QSA:
- A current data flow map. Shows where cardholder data enters, moves, and ends, with the out-of-scope system on the map and the path into the CDE demonstrably cut [4].
- A written scoping determination. Names the system, states that it does not store, process, or transmit cardholder data, says why, and is signed by someone who owns the decision [6].
- Segmentation test results. Requirement 11.4.5 testing that proves the out-of-scope system cannot reach the CDE, run after the last network change, not before [11].
- An updated asset inventory and scan scope. Requirement 12.5.1 keeps the component inventory current, and the ASV scan list matches the documented scope. A system that is out of scope but still on the scan list is a cost you pay for nothing [9].
- A re-verification schedule. Scope gets re-confirmed when the environment changes, because 12.5.2 expects the review as systems change. A determination from three years ago is not a determination, it is a rumor [6].
Clients are often surprised to learn that a system holding zero card data can still be in scope, because the definition reaches systems that could affect the security of the CDE, and that category catches monitoring tools, backup systems, and integrations that never see a card number [12]. The evidence pack exists to make that question answerable instead of arguable.
Why Do Out-of-Scope Claims Fall Apart in Review?
Four failure modes cover most of the scope arguments we have seen collapse, and none of them are about the claim being false. They are about the proof being absent.
Failure mode 1: The stale diagram. The scope was right in 2024. A migration moved the payment database, a support vendor added a jump host, and the diagram was never redrawn. The assessor works from what the environment does, not from what the diagram remembers [6].
Failure mode 2: The storage copy. The card numbers were "removed," but a reporting database, a log export, or a test fixture still carries them. PCI DSS scope follows data, and a copy counts as storage [6].
Failure mode 3: The untested wall. Segmentation exists in the firewall rules but has never been tested, or was tested before the change that matters. A boundary that has not been proven under 11.4.5 is an opinion, and opinions do not survive QSA review [11].
Failure mode 4: The ghost integration. An old API, a service account, or a vendor tool that can still reach the CDE after the official integration was decommissioned. Reachability, not address range, is what testing finds. We wrote about it in why PCI DSS internal penetration testing finds the systems your scope diagram missed [11].
The September 2026 KEV additions make the cost concrete, because they named products that are routinely argued out of scope: an F5 access policy manager that takes unauthenticated remote code execution, a Check Point security gateway, and an Adobe Commerce and Magento authorization flaw [3]. If one of those sits on the out-of-scope side of a boundary that was never tested, the argument does not save you. It just decides who finds out first. IBM's 2026 data is the backstop: the global average breach cost is $4.99 million, and financial services breaches average $6.3 million [2].
How Clone Systems Can Help
We work the scoping decision end to end. We review your data flow map against the live environment, run the three-question test with you, and build the 5-Part Out-of-Scope Evidence Pack for every system you claim out of scope. Where segmentation is the lever, the test is the point: our penetration testing services verify that the boundary actually holds, the way 11.4.5 intends [14]. Where scanning is the obligation, our PCI ASV external vulnerability scanning runs against the documented scope, with remediation and rescans handled until the result passes, so the attestation file matches the diagram you finally trust [13]. We covered what happens to that file when a quarter goes dark in what happens when you miss a quarterly PCI ASV scan [7].
If you have a scope decision you are nervous about, the ten-minute test above takes less time than explaining the gap after the assessor finds it. Talk to our team about your current scope. If you are sizing the scan list, the cost side is covered in PCI scan cost 2026 [9] and buy a PCI scan online [10].
Frequently Asked Questions
How do I reduce PCI DSS scope? Map where cardholder data enters, moves, and ends, then stop storing it, segment the rest, and document the decision. The claim only counts when an assessor can check the evidence [6].
Does tokenization reduce PCI DSS scope? It can, but only if the raw card number genuinely stops reaching your systems. A gateway that still receives the full primary account number for reconciliation is still processing cardholder data [1].
Does network segmentation reduce PCI DSS scope? Yes, when it is tested. Requirement 11.4.5 segmentation testing proves that out-of-scope systems cannot reach the CDE, and that proof is what allows them to stay out [4].
What evidence does an assessor expect for an out-of-scope system? A current data flow map, a written determination, segmentation test results, an updated inventory, and a re-verification schedule. That is the 5-Part Out-of-Scope Evidence Pack we run on every claim [6].
Does reducing PCI DSS scope lower my ASV scan cost? Usually, because external scan cost is driven by the number of in-scope IPs and domains. If a system is genuinely out of scope and off the scan list, it is not on the invoice [9].
Do out-of-scope systems still need to be secure? Yes, because they sit behind a boundary you are claiming holds. An untested boundary is the most common way a scope argument fails [11].
Conclusion
Reducing PCI DSS scope is not about drawing a smaller box. It is about making the box true: the data flow, the written determination, the tested segmentation, the updated inventory, and the scan list all telling the same story. The September 2026 KEV additions are a reminder of what sits on the edge of that box, and of what happens when the edge was never tested [3]. Run the three-question test, build the evidence pack for every claim, and keep the diagram honest. Start that work at www.clone-systems.com.
References
[1] PCI Security Standards Council: Resource Guide: Vulnerability Scans and Approved Scanning Vendors, July 10, 2024 (Requirement 11.3.2 requires passing external ASV scans at least once every three months; the SAQ A scanning obligation attaches to the merchant system that redirects to, or embeds a payment page from, a PCI DSS compliant third party). https://blog.pcisecuritystandards.org/resource-guide-vulnerability-scans-and-approved-scanning-vendors
[2] IBM (Ponemon Institute): IBM Study: One in Four Malicious Breaches are AI-Enabled, Costing Companies $6 Million on Average, July 29, 2026 (global average breach cost $4.99 million; financial services breaches average $6.3 million; organizations using AI and automation in security operations cut breach costs by an average of almost $2 million; 602 organizations, March 2025 to February 2026). https://newsroom.ibm.com/2026-07-29-ibm-study-one-in-four-malicious-breaches-are-ai-enabled,-costing-companies-6-million-on-average
[3] CISA: Known Exploited Vulnerabilities Catalog, accessed September 25, 2026 (catalog lists 1,723 vulnerabilities; additions of September 21-24, 2026 include CVE-2026-94127 F5 BIG-IP APM heap-based buffer overflow, CVE-2026-85102 Check Point Security Gateway improper certificate validation, and CVE-2026-71362 Adobe Commerce and Magento incorrect authorization with BOD 26-04 due date September 27, 2026). https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[4] PCI Security Standards Council: New Information Supplement: PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures, September 9, 2024 (hybrid multi-cloud CDEs and zero trust architectures are now common; effective scoping and segmentation expect documented policies, identity and access management, and an understanding of where data is stored and how it flows). https://blog.pcisecuritystandards.org/new-information-supplement-pci-dss-scoping-and-segmentation-guidance-for-modern-network-architectures
[5] Clone Systems: In our scoping reviews, the systems that stay in scope the longest are rarely the ones on the payment flow diagram. They are the storage copies, the staging environments, and the old integrations that can still reach the cardholder data environment. When a client tokenizes and the scope does not shrink, it is almost always because the payment gateway still receives the full primary account number for reconciliation.
[6] Clone Systems: Why Your PCI DSS Scope Is Bigger Than Your Diagram Says. www.clone-systems.com/blog/why-your-pci-dss-scope-is-bigger-than-your-diagram-says
[7] Clone Systems: What Happens When You Miss a Quarterly PCI ASV Scan. www.clone-systems.com/blog/what-happens-when-you-miss-a-quarterly-pci-asv-scan
[8] Clone Systems: Internal vs External Vulnerability Scanning: Why PCI DSS Requires Both. www.clone-systems.com/blog/internal-vs-external-vulnerability-scanning-why-pci-dss-requires-both
[9] Clone Systems: PCI Scan Cost 2026. www.clone-systems.com/blog/pci-scan-cost-2026
[10] Clone Systems: Buy a PCI Scan Online: 7 Things to Check Before You Pay. www.clone-systems.com/blog/buy-pci-scan-online
[11] Clone Systems: Why PCI DSS Internal Penetration Testing Finds the Systems Your Scope Diagram Missed. www.clone-systems.com/blog/pci-dss-internal-penetration-testing-scope-gap
[12] Clone Systems: Are AI Agents in PCI DSS Scope? The Test Isn't Whether They See Card Numbers. www.clone-systems.com/blog/ai-agents-pci-dss-scope
[13] Clone Systems: PCI ASV External Vulnerability Scanning service page. www.clone-systems.com/pci-asv-scan-external-vulnerability-scanning/
[14] Clone Systems: Managed penetration testing services. www.clone-systems.com/managed-penetration-testing-services/
[15] Clone Systems: Contact and consultation. www.clone-systems.com/contact