PCI segmentation testing, and your CDE scope

What Req 11.4.5 and 11.4.6 require

If your organization relies on network segmentation to keep systems out of the cardholder data environment (CDE), PCI DSS v4.0.1 does not let you assert that the segmentation works — it makes you test it. Requirements 11.4.5 and 11.4.6 exist specifically to confirm that the controls separating the CDE from the rest of your network actually hold under an attacker's scrutiny, not just on a network diagram.

• ✅ 11.4.5 — applies to every entity using segmentation to reduce PCI DSS scope. Segmentation controls must be tested at least once every 12 months, and again after any change to the segmentation controls or methods themselves.
• ✅ 11.4.6 — applies specifically to service providers. The same segmentation controls must be tested on a shorter, at-least-every-6-months cadence, plus after any change — reflecting the larger blast radius when a service provider's segmentation fails and multiple customer environments are exposed at once.

The purpose of both sub-requirements is identical: confirm that the segmentation controls in place — firewalls, ACLs, VLANs, routing restrictions, or a combination — actually isolate the CDE from out-of-scope networks, and that no path exists for an attacker on the out-of-scope side to reach cardholder data. "After any change to segmentation controls or methods" is deliberately broad: a firewall rule change, a new VLAN, a re-architected subnet, or a network merger following an acquisition can all trigger a retest obligation outside the annual or six-month clock. Treating 11.4.5/ 11.4.6 as a once-a-year (or twice-a-year) calendar entry rather than an event-driven obligation is one of the more common ways programmes drift out of continuous compliance between formal assessments.

Why segmentation shrinks your CDE scope

Segmentation is the single most effective lever most organizations have for controlling PCI DSS assessment cost and effort. Every system inside the CDE inherits the full weight of PCI DSS controls — access management, logging, vulnerability management, encryption, testing. Every system that is reliably isolated from the CDE by segmentation is out of scope for those same controls. A well-segmented environment can reduce a ROC from covering an entire flat network to covering a handful of payment systems.

That scope reduction is conditional, not permanent. It holds only as long as the segmentation controls are demonstrably effective — which is exactly what 11.4.5/11.4.6 exist to verify. If a segmentation test finds a path from an out-of-scope network into the CDE — a misconfigured firewall rule, a flat VLAN that was supposed to be isolated, a jump host with unintended connectivity — the systems on the wrong side of that failure are, from an assessment standpoint, back in scope. That is not a hypothetical: it is the single largest source of scope surprises in PCI assessments, and it is why QSAs treat segmentation test results as load-bearing evidence rather than a formality. A failed or stale segmentation test doesn't just cost you a finding — it can retroactively pull systems, and their associated controls, back into an assessment you thought was already scoped down.

Testing inside your environment (sovereign deployment)

Segmentation testing is inherently a two-sided exercise: you need to confirm that traffic cannot cross the boundary from an out-of-scope network into the CDE, and — for a complete picture — that testing from inside the CDE doesn't reveal an unexpected route out. breachr deploys inside your environment and runs both directions of that test from within your own infrastructure, rather than probing your perimeter from the outside and inferring what an internal attacker could reach.

Because the platform runs inside your environment, cardholder data never has to leave your control to be tested — no packet captures, credentials, or CDE data are transmitted to a third-party testing infrastructure. This sovereign deployment model is architected to satisfy the intent of 11.4.5/11.4.6 directly: the segmentation boundary is exercised from both sides, using real traffic patterns against the actual controls in production, not a simulated model of them.

Signed segmentation evidence for your QSA

A QSA reviewing your ROC needs to see segmentation test results mapped explicitly to 11.4.5 (or 11.4.6, if you are a service provider) — which controls were tested, what traffic was attempted across the boundary, what the result was, and when the test ran relative to your last change to the segmentation architecture. breachr produces that mapping as a structured part of the evidence pack rather than leaving you to reconstruct it from a generic test report after the fact.

Every segmentation test result is signed with a cryptographic chain of custody recording what was tested, when, and by what — a named human tester, an identified AI agent, or both working the same engagement — so the timeline your QSA needs (last test date, last change date, and whether the 11.4.5/11.4.6 clock was respected in between) is never in question. For the rest of the 11.4 family — the internal and external penetration tests that sit alongside your segmentation testing — see the Req 11.4 requirements guide.

Related guides