11.4.5 Annual segmentation penetration testing
Where segmentation is used to separate the CDE from other networks, the segmentation controls must be penetration tested: at least every 12 months, plus whenever segmentation controls or methods change; covering every segmentation control or method in use; in line with the penetration testing methodology the entity has defined; confirming the segmentation controls or methods are operational and effective and keep every out-of-scope system separated from the CDE; confirming the effectiveness of any isolation used to separate systems of different security levels (Requirement 2.2.3 refers); carried out by a tester who is qualified, whether an internal resource or an external third party; and with organizational independence of the tester (a QSA or ASV is not required). Guidance (good practice): host discovery and port scanning can help show out-of-scope segments cannot reach the CDE. Objective under the customized approach: where segmentation is used, periodic technical testing, including after any changes, confirms it keeps working to wall off all out-of-scope systems from the CDE.
Source: PCI DSS v4.0.1, 11.4.5. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open PCI DSS v4.0.1 in the compliance library.
Version 4.0.1 is the active version; 4.0 has been retired. Appendix A1 applies only to multi-tenant service providers, A2 only to card-present POS POI terminals that still use SSL or early TLS, and A3 only when a payment brand or acquirer requires it. Which requirements apply to you follows your validation type.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Evidence of retesting after firewall, VLAN or cloud security group changes affecting segmentation · Vulnerability scanner / patch tooling
periodic reviewEvidence produced at each review
- Segmentation test report covering each out-of-scope segment and every segmentation method · Vulnerability scanner / patch tooling
- Test results for isolation between systems of differing security levels (2.2.3) · Vulnerability scanner / patch tooling
- Tester qualification and independence records · Vulnerability scanner / patch tooling
governing documentDocuments that govern the control
- Network diagrams identifying segmentation controls and out-of-scope zones · Policy repository / GRC workspace
First move
Common gaps auditors find
- Segmentation test covers only one of several out-of-scope networks
- Segmentation changes made without a follow-up test
- Cloud or container segmentation methods not included
- Test shows open paths to the CDE that were never remediated
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet11.4.4 Correct exploitable findings from penetration tests · 11.4.6 Service provider segmentation testing every six months