What is segmentation testing?
When an organization uses network segmentation to keep systems out of PCI DSS scope, the whole scope reduction rests on one assumption: those out-of-scope segments genuinely cannot reach the cardholder data environment (CDE). Segmentation testing is the penetration test that checks the assumption. A tester works from each network that is supposed to be isolated and tries to reach the CDE. If nothing gets through, the segmentation is doing its job and the scope reduction holds. If anything gets through, the "out-of-scope" network was in scope all along.
This is narrower than a full application or network penetration test. It is specifically about reachability across segmentation boundaries, not about finding vulnerabilities inside the CDE.
What PCI DSS requires
PCI DSS v4.0.1 covers segmentation testing in two requirements under 11.4.
Requirement 11.4.5 applies to all entities that use segmentation. It requires that penetration tests on segmentation controls are performed:
- At least once every 12 months and after any changes to segmentation controls or methods.
- Covering all segmentation controls and methods in use.
- According to the entity's defined penetration testing methodology.
- Confirming the segmentation controls are operational and effective, and isolate the CDE from all out-of-scope systems.
- Confirming the effectiveness of any isolation used to separate systems with differing security levels.
- Performed by a qualified internal resource or a qualified external third party, with organizational independence of the tester. The tester is not required to be a QSA or ASV.
Requirement 11.4.6 is an additional requirement for service providers only. It is identical to 11.4.5 except for the frequency: at least once every six months and after any changes to segmentation controls or methods. A service provider therefore tests segmentation twice a year, not once.
Both requirements ask for the same work; the only difference is cadence. The rule that the tester be qualified and organizationally independent is a rule of the standard about who performs the test, and it applies whether that person is internal or a third party.
What a tester actually does
The test proceeds from the outside in, one out-of-scope segment at a time.
- Confirm the scope with the entity. Get the network diagram and the data-flow diagram, the list of CDE ranges, and the list of segments treated as out of scope. The segmentation test must cover every out-of-scope segment and every control that enforces the boundary.
- Place a testing host on an out-of-scope segment. For example, the corporate user VLAN, a guest network, a development environment, or a partner-connected segment.
- Enumerate reachability toward the CDE. From that host, scan the CDE ranges for reachable hosts and open ports, at both network and transport layers, and test the paths the segmentation control is supposed to block. This covers routed access, firewall and ACL rules, and any shared services that straddle the boundary such as DNS, jump hosts, or management interfaces.
- Attempt to cross the boundary. Where a path responds, confirm whether it actually reaches a CDE system or is filtered. A port that answers from an out-of-scope segment is a segmentation failure even if the service behind it is patched.
- Repeat from every out-of-scope segment. Isolation that holds from one VLAN can fail from another. Each segment is its own test.
- Test both directions where relevant. Outbound paths from the CDE to out-of-scope networks can also break isolation and matter for exfiltration.
What counts as evidence
The report has to let a QSA see that the boundary was exercised, not asserted. Adequate evidence includes:
- The scope tested: every out-of-scope segment and every segmentation control, mapped to the network and data-flow diagrams, so a reviewer can see nothing was skipped.
- The methodology followed, matching the entity's documented penetration testing methodology.
- The raw results from each segment: scan output, the specific hosts, ports and paths tested toward the CDE, and the response for each.
- The conclusion for each boundary: isolated, or a specific reachable path that constitutes a finding.
- Any finding, with the remediation and a re-test confirming the path is now blocked.
- The date, and the tester's identity and qualification, since 11.4.5 and 11.4.6 require a qualified, independent tester.
A clean segmentation test is a report showing that from every out-of-scope segment, the CDE was unreachable, with the scan evidence to back it.
[ Sources ]
Written by Parameter · Last reviewed
