Segmentation is a claim until Requirement 11.4.5 tests it

Segmentation is not a control the standard requires you to have. It is a statement you make about your network — that these systems cannot reach the cardholder data environment, and are therefore out of scope. Every system left out of your assessment is out because of that statement, and Requirement 11.4.5 is where somebody has to demonstrate it is true. An external penetration test that finds nothing tells you your perimeter held. A segmentation test that finds something tells you your scope was wrong — for the period behind you, not from the day you found out.

Optional control, conditional test

PCI DSS v4.0.1 is plain about the asymmetry. Section 4, Scope of PCI DSS Requirements: segmentation “is not a PCI DSS requirement”, only “strongly recommended” — and without it, “the entire network is in scope for the PCI DSS assessment.” Requirement 11.4.5 then opens on the matching conditional: “If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls.” You are free not to segment. You are not free to segment, take the scope reduction, and skip the test.

What 11.4.5 actually asks for

Seven elements, not one. Most published summaries give the first bullet and stop.

• 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 — the requirement cross-references Requirement 2.2.3 here.
• 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).

The fifth is the one that goes missing. Requirement 2.2.3 governs primary functions with differing security levels sharing a system component, and one of its permitted answers is that those functions are “isolated from each other” — including, explicitly, where virtualisation technologies do the isolating. So if part of your scope reduction rests on a hypervisor or container boundary rather than on a VLAN and an access control list, that boundary sits inside 11.4.5's coverage. A test that walks the network edge and never touches the virtualisation layer has covered some of the segmentation methods in use, not all of them.

The test runs inwards, and coverage is counted by method

The fourth bullet fixes the direction of travel: the test confirms the controls “isolate the CDE from all out-of-scope systems”. The question is not whether the CDE is hardened, but whether a network you have declared irrelevant can reach it. PCI SSC's Penetration Testing Guidance supplement gives the technique plainly — host discovery and port scanning from the out-of-scope side, verifying “that all out-of-scope LANs truly have no access to the CDE”.

Coverage is where large environments get it wrong. The supplement allows “a representative subset” of segments to be tested, but insists “each unique segmentation methodology should be tested”. Ten branch VLANs behind one firewall ruleset are one method. A firewall, a VLAN ACL, a cloud security group and a hypervisor boundary are four, and a subset that exercises only the first has said nothing about the other three.

When a segment turns out not to be segmented

The supplement does not soften the consequence: if a segment thought to be out of scope has access into the CDE, the organisation “will either need to adjust the segmentation controls to block that access, or perform a full network-layer penetration test to characterize the access and the impact on PCI DSS scope”. Requirement 11.4.4 applies on top — exploitable findings corrected per the risk assessment defined at 6.3.1, and “penetration testing is repeated to verify the corrections”. Found early in the assessment window, that is a remediation with time to run. Found a fortnight before the assessor arrives, it is a scope change, a retest, and an uncomfortable conversation about which systems were in scope all along.

Service providers, and the clocks that are not 11.4.5

Requirement 11.4.6 is the same test on a six-month cycle: “at least once every six months and after any changes to segmentation controls/methods”. The standard's reasoning is that service providers have “larger and more complex networks that are subject to more frequent change”, so segmentation is likelier to fail — and its Good Practice note asks for the exercise “as frequently as possible”.

More than one requirement sets a cadence, and they are not interchangeable:

A1.1.4 is the row most often missed, because it is not in Requirement 11 at all. It asks a different question from 11.4.6: not whether an out-of-scope network can reach the CDE, but whether one customer's environment can reach another's — testing that “is in addition to the penetration tests specified in Requirement 11.4.6”, confirmed with temporary mock-up environments. A multi-tenant SaaS, hosting or platform business that segments its CDE carries both, on top of the customer-facing obligation at 11.4.7. A1.1.4 and 12.5.2.1 were best practice until 31 March 2025 and are required now; 11.4.5 and 11.4.6 carry no such note, were never future-dated, and offer no grace period to point at.

Three artefacts, and the reconciliation that decides it

The testing procedures under 11.4.5 are three examinations, which makes them a usable specification for the evidence: the methodology (11.4.5.a — that your procedures are “defined to test all segmentation methods”), the most recent test report (11.4.5.b — that it “covers and addresses all elements specified in this requirement”), and an interview on who performed it and whether organisational independence existed (11.4.5.c). Requirement 11.4.1 closes the loop, naming “testing to validate any segmentation and scope-reduction controls” as a mandatory element of the methodology itself.

The reconciliation between the first two is where segmentation evidence usually fails. Requirement 12.5.2 already obliges you to identify “all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope”. Requirement 11.4.5 obliges the test to cover all segmentation controls/methods in use. Those are the same list, written down twice by two different teams. If your scoping document names five segmentation methods and your test report enumerates three, you have handed your assessor two contradictory statements about one network — and the document that governs your scope is the longer one, while the document that proves it is the shorter one.

Scope the test from the current 12.5.2 output rather than from last year's target list and the gap closes before anyone has to explain it. It is the cheapest of the reasons a PCI penetration test report gets sent back to prevent, and it belongs in the evidence pack alongside the report rather than stapled to it afterwards.

Who performs it

The standard answers that in the requirement itself, using the same two lines at 11.4.5 and 11.4.6 that it uses at 11.4.2 and 11.4.3: “Performed by a qualified internal resource or qualified external third party”, and “Organizational independence of the tester exists (not required to be a QSA or ASV).”

One numbering note, because the sources disagree. PCI SSC's only penetration testing supplement is v1.1, September 2017, and still calls segmentation testing Requirement 11.3.4 — the v3.2 number. The technique in it is current; the citation is not. Under v4.0.1, the sole active version of the standard, it is 11.4.5, and 11.4.6 for service providers.

Security Brigade performs segmentation testing under Requirements 11.4.5 and 11.4.6 as the qualified external third party the requirement describes — scoped from your 12.5.2 documentation and reported element by element, so the two reconcile.