PCI DSS segmentation testing explained

Segmentation testing is the part of PCI DSS most often mistaken for a smaller penetration test. It is not. It is the evidence underpinning your entire scope claim — and if it fails, everything you excluded from assessment comes back. This first part covers what the test proves, what PCI DSS v4.0.1 requires at 11.4.5 and 11.4.6, who may perform it and how often.

What segmentation testing actually is

Segmentation testing is a test of the controls that keep systems out of your cardholder data environment. It is not a penetration test of the CDE itself. The question it answers is narrow: do the mechanisms separating in-scope from out-of-scope systems actually work, in the configuration running today?

That distinction matters because of how PCI DSS scoping works. The standard applies to all system components included in, or connected to, the cardholder data environment, and to anything that could affect the security of account data. Left flat, a typical corporate network drags almost everything into assessment: staff wireless, build servers, the HR database, the printers. Segmentation is how you cut that down. You put controls in place that prevent out-of-scope networks reaching the CDE, and on that basis declare those networks out of scope.

The logic is sound but conditional: the exclusion only holds if the separation holds. A network declared out of scope that can in fact reach a cardholder data store is not out of scope — it was always in scope, and has gone unassessed for however long the error persisted. Segmentation is the one control whose failure retroactively invalidates your assessment boundary rather than merely producing a finding. Hence the requirement to test it.

OUT OF SCOPE                     IN SCOPE
+-------------------+            +---------------------+
| Corporate LAN     |            | CDE                 |
| Staff Wi-Fi       |  --X-->    | Card data stores    |
| Dev / test        |            | Payment apps        |
| Guest network     |            +---------------------+
+-------------------+                      ^
                                           |
         the X is the segmentation control  |
         (firewall ruleset, ACL, VRF,       |
          security group, VLAN boundary,    |
          microsegmentation policy)         |
                                           |
+-------------------+                       |
| CONNECTED-TO /    | ----------------------+
| SECURITY-IMPACTING|  permitted, assessed paths
| Jump hosts, AD,   |  (these are IN scope, even
| monitoring, admin |   though they are not the CDE)
+-------------------+

Segmentation testing targets the "X" and everything
left of it. It asks: can anything in the out-of-scope
column reach the in-scope column? If yes, the
out-of-scope column was never out of scope.

Framed internally: a CDE penetration test asks how badly could an attacker already inside the scope hurt us? A segmentation test asks is our scope diagram true? Requirement 11.4.1 expects your methodology to cover both, but they are not substitutes, and a report covering only the former will not satisfy an assessor looking for the latter. For how this sits in the wider programme, see our PCI DSS page.

What the standard requires

PCI DSS v4.0.1 remains the current version as of October 2026. It was published in June 2024 as a limited revision to v4.0, which was retired on 31 December 2024, and introduced no new or deleted requirements — only clarifications and corrections. A successor, widely expected to be v5.0, has been through request-for-comments cycles, but no release date has been announced. Requirement 11.4 was not altered between v4.0 and v4.0.1.

Two requirements deal specifically with segmentation. Requirement 11.4.5 applies to all entities: if segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls at least once every 12 months and after any changes to segmentation controls or methods; covering all segmentation controls and methods in use; according to the entity's defined penetration testing methodology; confirming that those controls and methods are operational and effective and isolate the CDE from all out-of-scope systems; and confirming the effectiveness of any use of isolation to separate systems with differing security levels, cross-referencing Requirement 2.2.3. The test must be performed by a qualified internal resource or qualified external third party, with organisational independence of the tester.

Requirement 11.4.6 is an additional requirement for service providers only. Its content is identical to 11.4.5 but for one change: the interval is at least once every six months rather than twelve, with the same obligation to test after any changes. A service provider does not satisfy 11.4.6 by doing 11.4.5 well; it satisfies it by doing the same thing twice as often.

Three details repay attention. It says penetration tests, not configuration review — the expectation is attempted traversal of the boundary, not a desk check of a ruleset. It says all segmentation controls and methods in use: every mechanism you depend on, not a sample. And it says all out-of-scope systems, which is the hard part, because the test must be driven from each distinct out-of-scope position rather than one convenient vantage point.

These do not stand alone. 11.4.1 requires a documented, implemented penetration testing methodology whose elements explicitly include testing from both inside and outside the network, and testing to validate any segmentation and scope-reduction controls — so segmentation testing must be described in your methodology before it is performed, not invented ad hoc. 11.4.2 and 11.4.3 cover internal and external penetration testing, each at least once every 12 months and after any significant infrastructure or application upgrade or change. 11.4.4 requires that exploitable vulnerabilities and security weaknesses found during testing are corrected in line with your risk assessment under Requirement 6.3.1, and that testing is repeated to verify the corrections — segmentation findings included. 11.4.7 obliges multi-tenant service providers to support their customers' external testing.

A single engagement often produces internal, external and segmentation results together, but they are three distinct sets of findings against three distinct requirements, and your Report on Compliance treats them as such.

Who can perform it

The requirement is explicit, and more permissive than many organisations assume. Segmentation testing under 11.4.5 and 11.4.6 must be performed by a qualified internal resource or a qualified external third party, and organisational independence of the tester must exist. The standard then states, in parentheses and in these terms, that the tester is not required to be a QSA or an ASV. The same wording appears at 11.4.2 and 11.4.3.

So there are two tests of the tester, and neither is a certification scheme. The first is qualification: can this person demonstrate the skills and experience to do the work? Your assessor looks for evidence — credentials, documented methodology, prior work of comparable scope. Qualification is a judgement about competence, not a licence you hold.

The second is organisational independence, where most arguments happen. The principle: the person testing a control must not be the person responsible for it. Independence is a property of reporting lines and accountability, not employment status. An internal team reporting to the CISO with no operational ownership of firewalls or network policy can be organisationally independent. An external consultancy that designed and maintains your segmentation architecture may not be — being a separate legal entity does not cure the conflict.

Which is why the network team testing its own firewall rules is usually the wrong choice, however capable the engineers. Three problems compound. They are assessing their own work, so a negative finding is a self-indictment and the incentive runs the wrong way. They know what the rules are meant to do, so they test intended paths — while the value of the exercise lies entirely in the paths nobody designed. And they test from where they sit, a privileged administrative position, not from the out-of-scope positions an attacker would occupy. The result is usually a document confirming the ruleset matches the design: a configuration review, not what 11.4.5 asks for.

To be plain about our own position: PXL Security is a penetration testing firm. We are not a QSA, an ASV or any kind of PCI assessor, we do not perform PCI DSS assessments, and we do not issue Attestations of Compliance. We perform segmentation testing as a qualified, organisationally independent third party and produce evidence your QSA can assess against 11.4.5 or 11.4.6. Your assessor decides whether that evidence satisfies the requirement; we cannot make that determination.

How often, and what counts as a change

The cadence is straightforward on paper. All entities using segmentation: at least once every 12 months. Service providers: at least once every six months. Both, additionally: after any changes to segmentation controls or methods.

That second trigger is where the difficulty lives, and a drafting detail is easy to miss. Requirements 11.4.2 and 11.4.3 are triggered by any significant infrastructure or application upgrade or change. Requirements 11.4.5 and 11.4.6 say any changes to segmentation controls or methods — without the qualifier. Read literally, the threshold for re-testing segmentation is lower than for re-testing anything else, which makes sense given what segmentation is holding up.

Read absolutely literally it is unworkable: nobody re-runs a penetration test for every object-group edit in a firewall policy. What organisations do instead — and what assessors generally expect — is define, in the methodology required by 11.4.1 and in the change process, which categories of change trigger fresh testing. Those that plainly qualify include:

• New or removed rules permitting traffic across a segmentation boundary.
• Introduction or decommissioning of a segmentation mechanism.
• Replacement or major upgrade of the enforcing device or platform.
• New segments, VLANs, VRFs, VPCs or cloud accounts on either side of the boundary.
• New connectivity to third parties or additional sites.
• Routing changes that could create a path around the control.
• Movement of systems between in-scope and out-of-scope segments.

Patching the enforcement platform with no configuration change, or edits wholly inside a segment that neither open nor alter a boundary path, usually do not qualify.

Be honest about the limits of that list. PCI DSS sets the principle — test after changes to the controls you rely on — and deliberately does not enumerate qualifying changes, because significance depends on the environment. The standard offers examples of change types warranting reassessment rather than an exhaustive definition, and the Council's guidance here has been clarified across versions rather than made more prescriptive. The detail is filled in by your assessor's judgement against your documented process. That is not a gap to exploit; it puts the burden on you to write a defensible rule and apply it consistently.

The sequencing point follows. A segmentation change made in March and tested at the annual test in November leaves eight months in which your scope documentation asserted something nobody had verified. Where a boundary change matters, treat the test as part of the change rather than a later compliance task.

Scoping the test properly

Segmentation testing fails at the scoping stage far more often than at the technical stage. The requirement text is explicit that the test covers all segmentation controls and methods in use, so the first deliverable is not a scan — it is a list. If a control is not on the list, it was not tested, and nothing in the report says otherwise.

The Council's scoping guidance sets the posture: assume everything is in scope until it has been verified that controls are in place and are actually providing effective segmentation. It also states that all controls which establish segmentation are included in each assessment to validate their effectiveness, including those that limit connections to specific ports or services on specific systems. The unit of coverage is therefore the control, not the device: a firewall is not one control, and each rule you rely on to keep an out-of-scope segment away from the cardholder data environment needs exercising.

Enumerate these classes before anyone touches a terminal:

• Firewalls and rule sets — physical, virtual and host-based. Record the named rule or policy that enforces the boundary, not just the appliance hostname.
• VLANs and ACLs — switch and router ACLs, private VLANs, and any routing design (including the absence of a route) you are treating as a control.
• Cloud security groups and network policies — security groups, NACLs, subnets, routing tables, peering and transit gateways, and Kubernetes network policies. The Council's 2024 supplement on modern network architectures makes the point that a single port scan from one host outside the segment is not sufficient testing here, that policies may reference named resources rather than addresses, and that results obtained inside a containerised workload differ from those obtained outside it.
• Virtualisation boundaries — virtual switches, virtual firewalls and the shared underlying host. Virtual devices typically share common resources, so the hypervisor and orchestration layers are part of the boundary, not scenery behind it.
• Jump hosts, brokers and proxies — anything that legitimately crosses the boundary: a jump box, a remote access gateway, a TLS proxy, a sidecar, a file broker, a deployment pipeline. In the Council's worked examples the jump box sits in shared services and is treated as connected-to or security-impacting, fully in scope. It is the component most likely to carry an attacker across, and the one most often omitted because it is "just" administration.

Turn that inventory into a source-to-destination matrix. Every row is one test: a vantage point, a target, the control that should stop or constrain the traffic, and the expected outcome. The plan is then auditable before it runs, and gaps appear on paper rather than mid-assessment.

SOURCE (vantage point)        -->  DESTINATION (in scope)     CONTROL RELIED ON            EXPECTED
corp-user-vlan-120            -->  cde-pos-10.20.0.0/24       fw-core policy "CDE-DENY"    deny all
corp-user-vlan-120            -->  shared-ad-10.30.0.5        fw-core + host firewall      389,636/tcp only
ot-print-vlan-140             -->  cde-app-10.20.1.0/24       vfw-dc01 rule 31             deny all
aws-dev-vpc / sg-dev-app      -->  aws-cde-vpc / sg-cde-web   sg-cde-web ingress           443/tcp from alb
k8s ns=build                  -->  k8s ns=cde-pay             netpol "cde-pay-deny"        deny all
vendor-vpn-pool-172.22.9.0/24 -->  cde-pos-10.20.0.0/24       vpn-gw policy "VND-3"        jump-01:3389 only
cde-pos-10.20.0.0/24          -->  corp-user-vlan-120         fw-core "CDE-EGRESS"         deny all

Testing both directions, and from the right places

The common technical error is a test that only ever points inbound: one scanning host on the corporate network, firing at the cardholder data environment. That proves one thing about one path. It says nothing about the other segments you have declared out of scope, nor about what a compromised in-scope host can reach on the way back out.

Test from each out-of-scope segment your scope reduction depends on. The Council's example report shows exactly this shape: a table of testing perspectives, each pairing a source network with the target environment. Where an environment genuinely has too many isolated segments to cover individually, the 2015 penetration testing guidance allows a representative subset, provided every unique segmentation methodology is examined and the depth of testing gives assurance it is effective in all instances of use. That permits sampling of vantage points with justification, not of control types. Record why those segments represent the rest.

Outbound rows earn their place because permissive egress and return paths are how a foothold becomes an exfiltration route. Then there are the paths that go around the obvious boundary rather than through it:

• Management networks. Out-of-band management, hypervisor interfaces, device management planes, and the cloud console or control plane. The modern-architectures supplement asks testers to consider scenarios that attack the console or control plane to change a configuration and defeat the segmentation control — the fastest route into a segment is often a change to the rule that defines it.
• Backup and monitoring. Backup agents, monitoring and scanning tools, patch and anti-virus deployment servers. The Council lists these among common shared services, in scope where they connect into the cardholder data environment. They also tend to hold broad credentials.
• Shared directory services. Active Directory, LDAP, AAA, DNS, NTP and mail. The Council notes that an administrator account compromised in an out-of-scope network must not be usable to reach the cardholder data environment, and that authentication connectivity should be limited to business need. A boundary an inherited credential walks straight through is not a boundary.
• Vendor remote access. Third-party VPN pools, support tooling and supplier jump paths. For hybrid environments the guidance asks how an attacker could circumvent a remote access gateway — attacking the gateway directly, attacking the provisioning system such as Active Directory or IAM, or impersonating a privileged user.

What the evidence has to show

Assessors differ, but the evidence that survives review tracks the reporting outline in the Council's penetration testing guidance: scope, methodology, limitations, a testing narrative, a dedicated summary of segmentation results, and findings. In practice:

• Dates — when testing was performed, not only when the document was issued, so cadence can be checked against the previous test and against changes to segmentation controls.
• Scope and the segment list — the in-scope environment and the segments claimed as out of scope. The guidance asks explicitly for clarification of CDE versus non-CDE systems and segments considered.
• Methodology — what was done and how, tied to your documented penetration testing methodology, plus any restriction imposed: windows, bandwidth limits, excluded legacy systems.
• Source and destination for every test — the matrix, reproduced with results. It is the most useful page in a segmentation report.
• A result per control — pass or fail against each named segmentation control, not a global verdict.
• Remediation and retest — exploitable vulnerabilities and security weaknesses found during penetration testing must be corrected and testing repeated to verify the corrections. The guidance sketches a retest report carrying the original test date, the retest date, the original findings and the retest results.

Supporting evidence means screenshots, raw tool output, captures and configuration extracts. Retention is not itself a PCI DSS requirement, but the Council recommends it and expects retention and destruction to be agreed beforehand — settle it in the rules of engagement.

Evidence is usually rejected for one reason: tool output with no mapping to named segmentation controls. A port scan from an unspecified host, showing filtered ports against an address range, does not establish which control filtered the traffic, whether every control of that type behaves the same way, or whether that vantage point represents the segments you exclude. If the reader cannot trace a line from "VLAN 140 cannot reach the cardholder data environment" to the rule enforcing it and the test that proved it, the document is a scan report, not a segmentation test.

Where segmentation testing goes wrong

The recurring patterns are few, and most are organisational rather than technical:

• Sampling where coverage is required. Reducing the number of vantage points is a documented, justified decision about segments. Quietly skipping a control type — cloud security groups, network policies, host firewalls — is not sampling, it is a gap.
• Testing a representative firewall. One appliance is tested, its siblings are assumed identical, and the assumption is never written down or verified. Configuration drift is routine.
• Missing the shorter cadence where it applies. Organisations that have changed status, or that provide services to others without thinking of themselves as a service provider, tend to discover the six-month cycle late.
• Ignoring changes mid-year. The requirement also bites after changes to segmentation controls or methods. The modern-architectures supplement warns that even simple modifications to an infrastructure-as-code definition can inadvertently remove a segmentation control, and that controls should be verified and documented as intact after any change affecting them.
• Finding a path, fixing it, and not retesting. A closed ticket is not evidence. The guidance also notes that where a supposedly isolated segment turns out to have access into the cardholder data environment, the options are to restrict that access or to run a full network-layer penetration test to characterise it — the segment may never have been out of scope.
• Treating a passing scan as the test. Scanning and segmentation penetration testing answer different questions. A clean scan says nothing about whether a boundary can be defeated.

Fitting it into the annual cycle

Three habits make this routine rather than eventful.

Keep the segment inventory as a living document. It is the same artefact your scope confirmation depends on, so maintain it alongside the network and data-flow diagrams rather than rebuilding it each year from memory. It should name each segmentation control, its owner, and the segments either side. For cloud estates, where workloads are ephemeral, the Council suggests automated inventory tooling and a configuration management database to keep pace.

Test segmentation before the main assessment, not alongside it. Leave room to fix what the test finds and to retest it. A segmentation failure found during an assessment is not merely a finding — it can pull a whole segment into scope and change the assessment itself. Found a quarter earlier, it is a change ticket. That is the practical argument for running this as a distinct piece of compliance-driven penetration testing, with its own dates and its own report, rather than folding it into a general internal test.

Tie it to change management. A new VLAN, security group, network policy, peering connection or vendor access path should trigger a documented check against the inventory and, where it alters a segmentation control, a test. The guidance recommends change management that automatically identifies alterations to segmentation controls such as IAM or networking configuration, backed by preventive and detective checks. A pipeline check that fails a build when a boundary-enforcing rule changes will find more than any once-a-year exercise.

Done this way, the test confirms what you already know. Done the other way, it is a discovery exercise with an audit date attached.