.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
PCI DSS Segmentation Testing: Why Your CDE Boundary Fails Validation
What Requirement 11.4.5 asks a segmentation test to prove, the design and testing gaps that break a CDE boundary, and the evidence your QSA will check.
Accorp Compliance Team
Our team of compliance experts specializes in PCI DSS, SOC 2, and other security frameworks to help businesses achieve and maintain compliance.
Your network diagram shows a firewall between the cardholder data environment (CDE) and the corporate network. Your assessor still won't accept that the corporate network is out of scope. The usual reason is that the test report doesn't prove what Requirement 11.4.5 asks it to prove, or the test missed a path the assessor can see from the scoping documents.
A segmentation boundary passes validation when two things are true. Every system you call out of scope has no route to the CDE, direct or indirect. A qualified, independent tester has shown that with a test that covered every segmentation method you use. A rejected boundary traces back to a gap in one of them. This article covers both: what the requirement demands, where boundaries usually break, and what evidence to have ready.
What PCI DSS segmentation testing has to prove
Requirement 11.4.5 applies only if you use segmentation to isolate the CDE from other networks. If you do, penetration tests on the segmentation controls must meet every condition below (PCI DSS v4.0.1, Requirement 11.4.5):
Run at least once every 12 months, and again after any change to segmentation controls or methods.
Cover all segmentation controls and methods in use.
Follow the entity's own defined penetration testing methodology.
Confirm the controls are operational and effective, and that they isolate the CDE from all out-of-scope systems.
Confirm that any isolation used to separate systems with different security levels works. This ties back to Requirement 2.2.3.
Be performed by a qualified internal resource or a qualified external third party.
Be performed by a tester with organizational independence. The tester does not need to be a QSA or ASV.
Service providers have a stricter version in Requirement 11.4.6. The conditions are the same, but the test runs at least once every six months and after any change to segmentation controls or methods (Strike summary of 11.4).
Two words in that list carry more weight than they appear to. "All" means every firewall rule set, ACL, cloud security group, or host-based control that you rely on to keep systems out of scope. "Any change" means a rule update or a new VLAN can trigger a retest on its own, without waiting for the annual cycle. [VERIFY: confirm "any change" wording against the official PCI DSS v4.0.1 PDF from the PCI SSC document library]
Why segmentation only shrinks scope once it is tested
PCI DSS does not require segmentation. The PCI SSC treats it as a way to reduce scope, and the reduction only holds when the segmentation is proven to work (PCI SSC Guidance for PCI DSS Scoping and Network Segmentation, p. 6). On a flat network, every system is in scope if one of them stores, processes, or transmits account data.
The same guidance sorts systems into three groups:
Category | What puts a system here | Scope |
CDE systems | Stores, processes, or transmits cardholder or sensitive authentication data, or shares a network segment, subnet, or VLAN with systems that do | In scope |
Connected-to or security-impacting systems | Can connect to the CDE, can affect its configuration or security, provides security services to it, or supports a PCI DSS requirement | In scope |
Out-of-scope systems | Meets none of the above and cannot reach the CDE directly or through an in-scope system | Out of scope, but still treated as untrusted |
The third row is where network segmentation under PCI DSS earns its value, and where it has to be proven. A system qualifies as out of scope only when it meets every one of those negative conditions (p. 12 of the guidance). The segmentation test is the evidence that it does. The guidance also says separate network segments alone are not segmentation. Segmentation needs controls built to enforce the separation (p. 7).
Where CDE boundaries fail validation
A boundary fails for one of two reasons. Either the design leaves a path into the CDE, or the test can't show that no path exists.
Paths the design leaves open
VLANs or subnets with no filtering between them. A separate VLAN on its own doesn't enforce anything. If nothing filters traffic between the corporate VLAN and the CDE VLAN, the corporate VLAN is in scope. The PCI SSC guidance says an out-of-scope system can share a segment with a connected-to system only when it cannot reach the CDE by any path (p. 13).
Shared services that touch both sides. Active Directory, jump hosts, patch and antivirus servers, log servers, NTP, DNS, backup tools, and monitoring or scanning tools all appear in the guidance as connected-to or security-impacting systems (pp. 11 and 15). They belong in scope. The failure happens when they also accept connections from the corporate network. A user laptop that can reach the jump host, or a backup server that reaches both segments, gives out-of-scope systems an indirect route to the CDE. That route disqualifies them from being out of scope.
Third-party remote access. Vendor support connections that land inside or next to the CDE are another path the guidance names (p. 7). If a vendor's remote tool can reach the CDE from a network you treat as out of scope, the boundary is open.
Outbound rules from the CDE. Requirement 1.3.2 limits outbound CDE traffic to what is necessary. A permissive outbound rule toward a corporate subnet weakens the isolation the segmentation test is meant to confirm. [VERIFY: 1.3.2 wording in PCI DSS v4.0.1]
Gaps in the test itself
Only some segmentation methods were tested. The test checked the perimeter firewall, but isolation also depends on cloud security groups, host-based firewalls, or a second firewall pair at another site. Requirement 11.4.5 asks for coverage of all methods in use.
The test ran from one out-of-scope segment. The requirement asks the test to confirm isolation from all out-of-scope systems. A test from the guest Wi-Fi says nothing about the finance VLAN or the development network. Each out-of-scope segment needs its own test point.
The scan was too narrow. The requirement's good-practice note suggests host discovery and port scanning from out-of-scope segments. A scan of a handful of common ports can miss an open management interface. Scanning the full TCP range, plus the UDP services relevant to the environment, gives the result more weight.
Something changed after the last test. A new firewall rule, a re-addressed VLAN, or a migrated workload changes the segmentation method. Without a retest, last year's report describes a network that no longer exists.
The tester wasn't independent. If the engineer who wrote the firewall rules also ran the test, the independence condition fails, whatever the result says.
[MEDIA: show indirect paths into the CDE, simple network diagram with corporate, shared services, and CDE zones and arrows for the jump host and backup server routes, alt: "Diagram of a corporate network reaching the cardholder data environment through a shared jump host and backup server"]
How segmentation tests differ from the other PCI penetration testing requirements
Requirement 11.4 holds several tests, and it is tempting to fold the segmentation test into the annual internal pen test without checking that it meets its own conditions. The two can run in the same engagement. The report still has to show the segmentation work separately.
Internal and external pen tests (11.4.2, 11.4.3) | Segmentation tests (11.4.5, 11.4.6) | |
Question answered | Can an attacker exploit weaknesses in the CDE perimeter and critical systems? | Can any out-of-scope system reach the CDE? |
Frequency | Every 12 months | Every 12 months; every 6 months for service providers |
Retest trigger | Significant infrastructure or application change | Any change to segmentation controls or methods |
Starting point | Inside and outside the network | Each out-of-scope segment |
Pass condition | Exploitable findings fixed and retested (11.4.4) | No route from out-of-scope systems to the CDE |
Requirement 11.4.1 ties them together. The entity's methodology has to cover testing of segmentation and scope-reduction controls, so the segmentation test needs a written place in that document (Strike summary of 11.4).
What evidence your assessor will ask for
The testing procedures for Requirement 11.4.5 tell you what the assessor checks. Each one maps to a document or conversation you can prepare in advance.
Testing procedure | What the assessor does | What to have ready |
11.4.5.a | Examines segmentation controls and the pen test methodology | A methodology that defines segmentation testing against every element of the requirement, and a current list of segmentation controls |
11.4.5.b | Examines the most recent pen test results | A report showing each out-of-scope segment tested, each control covered, the scan scope, and the result |
11.4.5.c | Interviews personnel | A named tester, their qualifications, and how they are independent of the team that runs the controls |
Two supporting records make the review shorter. The first is your scope documentation. The PCI SSC guidance expects you to confirm scope at least once a year and before each assessment, and to keep a record of how you decided it (pp. 7-8). The second is a change log for segmentation controls, so the assessor can match each change to a retest.
A pre-test check for your segmentation boundary
Work through this list before you schedule PCI DSS segmentation testing. Each item closes one of the gaps above.
☐ List every segmentation control in use: firewalls, ACLs, cloud security groups, host-based firewalls, and any site-to-site links.
☐ List every out-of-scope segment and plan a test point inside each one.
☐ Map every shared service (AD, jump hosts, patching, logging, NTP, DNS, backup, monitoring) and confirm none of them accepts connections from out-of-scope systems.
☐ Review vendor remote-access paths into or near the CDE.
☐ Check outbound rules from the CDE toward internal networks.
☐ Pull the change log for segmentation controls since the last test and flag anything that needed a retest.
☐ Confirm the methodology document describes segmentation testing against each element of 11.4.5.
☐ Confirm the tester is qualified and independent of the team that manages the controls.
☐ Agree the scan scope with the tester: host discovery, full TCP range, and the UDP services that matter in your environment.
If any box stays unticked, fix it before the test rather than explaining it in the assessment. Accorp's penetration testing team runs segmentation tests as part of PCI DSS assessments, and can review your segmentation methodology before the test date. [VERIFY: confirm with Accorp that both services are offered as described]
If tokenization or Click to Pay has changed your card data flows, read how network tokenization changes PCI scope first, since scope has to be settled before segmentation can be tested.
Frequently asked questions
1. Do we need a segmentation test if we don't segment the CDE?
No. Requirement 11.4.5 applies only when segmentation is used to isolate the CDE. Without it, the whole network is in scope for the assessment, so there is nothing to test the boundary against.
2. Does the person running the test have to be a QSA?
No. The requirement asks for a qualified internal resource or a qualified external third party with organizational independence. It states outright that the tester doesn't need to be a QSA or ASV.
3. Can our own security team run the segmentation test?
Yes, if the tester is qualified and independent of the people who build and manage the segmentation controls. An engineer testing firewall rules they wrote fails the independence condition.
4. How often does segmentation have to be tested?
At least once every 12 months for merchants, and at least once every six months for service providers under Requirement 11.4.6. Both also need a retest after any change to segmentation controls or methods.
5. Does a firewall rule change really trigger a retest?
If the rule is part of how the CDE is kept separate, yes. The requirement says any change to segmentation controls or methods, so the trigger is lower than the "significant change" that drives the main internal and external pen tests.
6. Is an ASV scan enough to prove segmentation?
No. An ASV scan checks internet-facing systems for vulnerabilities under Requirement 11.3.2. A segmentation test runs from inside each out-of-scope segment and checks whether anything there can reach the CDE. [VERIFY: 11.3.2 reference in PCI DSS v4.0.1]
7. Do cloud security groups count as segmentation controls?
If you rely on them to keep systems out of scope, they are a segmentation method in use, and the test has to cover them. The same applies to host-based firewalls and network ACLs in a hybrid cloud setup.
