PCI DSS 11.4.5: If segmentation is used to isolate the CDE from other networks
PCI DSS v4.0.1 control 11.4.5: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 11.4.
Requirement 11: Test Security of Systems and Networks Regularly › Section 11.4
If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows:
- At least once every 12 months and after any changes to segmentation controls/methods
- Covering all segmentation controls/methods in use.
- According to the entity’s defined penetration testing methodology.
- Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems.
- Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3).
- Performed by a qualified internal resource or qualified external third party.
- Organizational independence of the tester exists (not required to be a QSA or ASV).
Summary
If you rely on segmentation to keep systems out of scope, prove yearly that the segmentation actually holds.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 11.4.5.a | Examine segmentation controls and review penetration-testing methodology to verify that penetration-testing procedures are defined to test all segmentation methods in accordance with all elements specified in this requirement. |
| 11.4.5.b | Examine the results from the most recent penetration test to verify the penetration test covers and addresses all elements specified in this requirement. |
| 11.4.5.c | Interview personnel to verify that the test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV). |
This is the control with the largest consequence in Requirement 11. Segmentation is how most entities reduce assessment scope, and this is the test that decides whether that reduction was real. A failure does not produce a finding against 11.4.5 alone: it means the systems you excluded were never isolated, so they were in scope all along, and the assessment that assumed otherwise no longer holds. Note the elements. The test must cover all segmentation controls and methods in use, confirm isolation from all out-of-scope systems, and separately confirm the effectiveness of any isolation used to separate systems of differing security levels under 2.2.3. The trigger is twofold: at least every 12 months and after any changes to segmentation controls or methods, which is the part that gets missed because a firewall rule change rarely feels like a segmentation change.
What to prepare
- The inventory of segmentation controls and methods, which is what "all" is measured against.
- The penetration testing methodology from 11.4.1, including how segmentation is tested.
- Results from the most recent test, mapped to each segmentation method.
- Change records for segmentation controls, showing a test followed each.
How to implement it
1. Enumerate the segmentation methods first. VLANs, firewall rules, cloud security groups, separate accounts or tenancies, and physical separation are all methods in use, and "all" cannot be evidenced against a list nobody wrote.
2. Test from every out-of-scope network, not from one. The requirement says isolation from all out-of-scope systems, so testing from the office network and not from the warehouse leaves the claim partly untested.
3. Treat segmentation changes as a test trigger in change control. This is the element most often missed, and the fix is a field on the change record rather than vigilance.
4. Do not let a failure sit. A failed segmentation test means the scope reduction is not valid now, which is a much larger problem than the finding itself and is worth escalating as such.
Where this commonly fails
- Tested annually with nothing after segmentation changes, failing half the trigger.
- Tested from one out-of-scope network, leaving the rest of the claim unproven.
- The 2.2.3 element skipped, since separating differing security levels is a distinct confirmation the requirement asks for.
- A failure treated as a remediation item rather than as evidence the assessment scope was wrong.
Related controls
This control refers to 2.2.3.
Others in section 11.4:
| Control | What it requires |
|---|---|
| 11.4.1 | A penetration testing methodology is defined, documented, and implemented by the entity… |
| 11.4.2 | Internal penetration testing is performed… |
| 11.4.3 | External penetration testing is performed… |
| 11.4.4 | Exploitable vulnerabilities and security weaknesses found during penetration testing… |
| 11.4.6 | Service providers: If segmentation is used to isolate the CDE from other networks… |
| 11.4.7 | Multi-tenant service providers support their customers for external penetration testing per… |
← 11.4.4 · All controls · 11.4.6 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.