Scoping and Segmenting the CDE
PCI DSS does not tell you to segment your network. It tells you what falls in scope, and leaves the size of that scope to you. Here is what the cardholder data environment is, how systems get sorted, and why a boundary is only as real as the test behind it.
Every PCI DSS program begins with a boundary. Before an organization configures a single control, it has to decide which systems store, process, or transmit cardholder data, which systems can reach those, and which sit outside entirely. That set of decisions is the scope of the assessment, and its size determines how much of the environment a Qualified Security Assessor has to examine. Most guidance on the subject treats the exercise as an accounting problem: draw the line tightly, and the audit gets smaller, cheaper, and faster. That description is accurate. It is also where a specific and recurring class of breach begins. AKATI runs these assessments and the penetration tests that follow them, and the pattern we see is rarely a merchant who scoped too much. It is a merchant who declared a system out of scope, never proved the claim, and then watched an intruder use exactly that system as the road into the cardholder data environment.
This piece explains what the cardholder data environment is, how PCI DSS sorts every system into three categories, what network segmentation does to scope and what it does not, and the two things that separate a boundary an organization can defend from one it has merely drawn.
What the cardholder data environment contains
The cardholder data environment, or CDE, is the set of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. That definition is the starting point for scope, not the whole of it. PCI DSS scope reaches past the systems that touch card data to include every system that can connect to them or affect their security. A jump server used to administer the CDE, a directory service that authenticates users into it, a DNS server it depends on: none of these hold a single card number, and all of them are in scope. The CDE is where the data lives. The scope is everything that can influence whether that data stays protected.
The three categories PCI DSS actually uses
PCI DSS sorts every system into one of three categories: in-scope, connected-to or security-impacting, and out-of-scope. In-scope systems store, process, or transmit account data, or share a network segment with systems that do. Connected-to and security-impacting systems have a communication path into the CDE or can affect its security, and the PCI SSC guidance is clear that PCI DSS requirements apply to them in full. Out-of-scope systems have no access to the CDE and cannot influence its security even if they are compromised. The distinction a buyer most often gets wrong is treating "connected-to" as a lighter class of obligation. A system with a live path into the CDE carries the requirements as though it were the CDE, because from an attacker’s position it is the route in. In cloud and hybrid environments this line is easy to lose, since a serverless function or a management plane can hold a path into the CDE without ever appearing on a traditional network map.
What segmentation does to scope, and what it does not
Network segmentation is not a PCI DSS requirement. The standard does not order any organization to segment its network. It defines what falls in scope, and it permits segmentation as the recognized method for moving systems out of scope. When segmentation isolates the CDE, only the segmented environment and its connected-to systems fall to the assessor, and everything the segmentation successfully separates drops away. This is the mechanism underneath every scope-reduction claim in the market. Fewer systems in scope means fewer controls to operate, less evidence to gather, and a shorter assessment, which is why segmentation is usually sold as a cost lever. The reduction is genuine. The error is treating it as automatic. Segmentation lowers scope only to the extent that it can be shown to work, and PCI DSS writes that proof requirement directly into the standard.
Segmentation lowers scope only to the extent that it can be shown to work.
Why out-of-scope is a claim, not a status
Declaring a system out of scope removes it from the assessment. It does not remove it from the attacker’s map. The PCI SSC guidance is explicit that a system is treated as in scope until segmentation is demonstrated to isolate it, and it sets the bar for that isolation concretely: a properly segmented out-of-scope system could not affect the security of the CDE even if an attacker gained administrative control of it. Read that condition in reverse, because it describes where most environments actually sit. If an out-of-scope system has not been shown to meet that bar, an attacker who lands on it may still have a path into the CDE, and the label recorded nothing about whether the system was secure. Palo Alto Networks Unit 42 reported that 87 percent of the intrusions it investigated in 2026 moved across multiple attack surfaces rather than staying on one system, and that in most breaches, preventable gaps such as inconsistently applied controls opened the path for lateral movement. The machine a merchant quietly files as out of scope is frequently one of those surfaces, administered casually, patched late, and monitored by no one, which is precisely what makes it a useful place to begin.
Why a diagram is not a tested boundary
A network diagram asserts isolation. A penetration test demonstrates it. Where segmentation is used to reduce scope, PCI DSS requires the segmentation controls to be penetration tested to confirm they are operational and effective. Under PCI DSS v4.0.1, that test is performed at least once every twelve months and after any change to segmentation controls under Requirement 11.4.5, and for service providers at least once every six months and after such changes under Requirement 11.4.6. The reason for the cadence is drift. Between two tests, a firewall rule relaxed for a project, a new VLAN, or a widened cloud security group can quietly reconnect what the diagram still shows as separated. Until the segmentation is tested, the assessor cannot credit it and the attacker is not bound by it, and both are entitled to treat the network as flat. This is also where the current piece departs from an earlier article in this series that examined scans and penetration tests as evidence with defined limits. There, the tests were the subject. Here, the segmentation boundary is the subject, and the penetration test is the single thing that converts it from an assertion into a control.
Until the segmentation is tested, the assessor cannot credit it and the attacker is not bound by it.
The question worth asking before scope reduction
The useful question is not how small the scope can be drawn, but what can be proven isolated. Scope reduction and security are related measurements, and they are not the same one. A tightly drawn scope resting on unvalidated segmentation is smaller on paper and no safer in practice. PCI DSS also requires an organization to confirm the accuracy of its scope on a set cadence, at least once every twelve months for all entities and more often for service providers, and to document and justify the segmentation it relies on. That documentation is where a claim becomes reviewable, because it forces the organization to write down why a given system is out of scope, which is the same question the assessor will ask and the same one an attacker will answer for themselves. An organization that can state the reason, and demonstrate it under testing, has a boundary. One that cannot has a drawing.
Scope is the most consequential architectural decision in a PCI DSS program, since it defines everything the assessment will and will not examine. Treated purely as a lever for a smaller number, it optimizes for the paperwork and leaves the harder question open. The boundary that holds is the one an organization can document, defend, and prove on the schedule the standard sets, so that "out of scope" names a tested condition rather than a hopeful label.
SOURCES
1. PCI Security Standards Council. Payment Card Industry Data Security Standard (PCI DSS): Requirements and Testing Procedures, Version 4.0.1. https://www.pcisecuritystandards.org/document_library/
2. PCI Security Standards Council. Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation. https://listings.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf
3. PCI Security Standards Council. Information Supplement: PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures. https://blog.pcisecuritystandards.org/new-information-supplement-pci-dss-scoping-and-segmentation-guidance-for-modern-network-architectures
4. Palo Alto Networks, Unit 42. 2026 Unit 42 Global Incident Response Report. https://www.paloaltonetworks.com/resources/research/unit-42-incident-response-report
DISCLAIMER
This article is provided for general educational purposes. It is not legal, compliance, or professional security advice, and it does not create an advisory relationship. PCI DSS applicability, including which validation path, self-assessment questionnaire, and testing requirements apply to a given organization, depends on that organization’s specific environment and its acquirer or payment brand obligations. Requirement references are drawn from PCI DSS v4.0.1; confirm the version in force at the time of your assessment. Organizations should consult a Qualified Security Assessor and their acquiring bank before relying on any interpretation set out here.
PCI DSS · Scoping
