If you use segmentation to keep part of your estate out of scope, the standard asks you to prove, by testing, that the segmentation works. If the proof is weak, the scope is unproven, and so is everything assessed inside it. This is what the test has to do.
What the requirement asks
Requirement 11.4.5 asks for penetration testing of the segmentation controls at least once every twelve months, and after any change to them, confirming that the controls are operational and effective and that they isolate every out-of-scope network from the cardholder environment. Service providers do it at least every six months under 11.4.6. The test has to follow a defined methodology, cover all segmentation methods in use, and be done by a qualified tester with organisational independence from the people who manage the controls.
From where
From each out-of-scope network. Not from one jumpbox on a network the report does not name. If you have an office network, a developer network, a partner network, three peered cloud networks and a supplier’s management network, you have at least seven source networks, and the report should list them. The test from one point proves isolation from one point.
The test from one point proves isolation from one point.
To what
To every address in the cardholder environment, or to a sample the report justifies, on every port and protocol. A test that tries the web ports and stops has tested the web ports. And to the shared services: the directory, the monitoring platform, the backup server, the management tools. If a domain controller is reachable from the user network, the user network is not out of scope, whatever the firewall in front of the payment servers says.
The cloud details most tests miss
Peering plus a default rule. Cloud platforms ship a default rule that allows traffic between peered networks. A diagram shows isolation; the console shows every port open. Test what the console says.
Security groups that trust the whole network. A rule that accepts traffic from the entire production range makes that instance reachable from everything, whatever the subnet is called.
Policies dated after the test. A network policy that took effect the week after the test was not tested. The test proves the state on the day.
Private endpoints named as the control. A private endpoint is a path, not a filter. The security group or the firewall is the control, and that is what should be named and tested.
What the report has to say
The methodology. The source networks, by name. The targets and how the sample was chosen. The dates. The tools. The results, per source network, with the evidence that each one was isolated or was not. Who did it and why they are independent. A report missing any of these is read by an assessor as “a test may have happened”.
What people get wrong
They buy a reachability scan and call it a segmentation test. They test the perimeter and skip the shared services. They forget the cloud defaults. They run the test once, before the network was finished, and never again after the changes.