Skip to main content
Commerce Security Authority
Category: Vulnerability and Software Security

Segmentation Penetration Testing

Also known as: Segmentation Check, Segmentation Testing, Network Segmentation Penetration Testing, Internal Network Segmentation Penetration Test
Simply put

Segmentation penetration testing is a set of controlled tests used to confirm that networks kept separate from systems handling payment card data cannot actually reach or communicate with those sensitive systems. In simple terms, it checks that a less-secure network is truly isolated from a more-secure one, rather than just being labeled as separated. If the testing finds unexpected connectivity, it means the separation is not working as intended.

Formal definition

Segmentation penetration testing is a series of penetration tests intended to validate that networks and systems treated as out of scope for PCI DSS do not have connectivity into the cardholder data environment (CDE), and that less-secure networks cannot communicate with higher-security networks. Its scope should consider systems considered out of scope in order to verify the effectiveness of segmentation controls used to isolate the CDE from other networks; where such isolation is relied upon to reduce PCI DSS scope, this testing is a means of confirming that the isolation actually holds. Note that the specific PCI DSS requirement numbering, wording, and testing frequency differ between versions of the standard, and readers should confirm the applicable requirements against the current published PCI DSS and its associated Penetration Testing Guidance. This term addresses only the validation of segmentation controls and does not, by itself, assess the security posture of in-scope systems, which is covered by broader application- and network-layer penetration testing.

Why it matters

Segmentation is one of the most common ways organizations reduce PCI DSS scope. By isolating the cardholder data environment (CDE) from the rest of the network, systems that never touch payment card data can be treated as out of scope, which lowers the cost and complexity of compliance. But that scope reduction is only valid if the isolation actually holds. A firewall rule, VLAN, or access control list that is misconfigured, overly permissive, or drifted over time can leave a supposedly out-of-scope network with a path into the CDE. Segmentation penetration testing exists to confirm that the separation relied upon is real rather than assumed.

Without this validation, an organization may believe its scope is smaller than it truly is. If a less-secure network can reach the CDE, then that network is effectively in scope, and controls that should apply to it may be missing. This is where the risk concentrates: an attacker who compromises a low-security segment could pivot into systems handling payment card data if the segmentation gap goes undetected. Segmentation testing is intended to surface these unexpected paths before they can be exploited.

It is important to understand what this testing does and does not cover. Segmentation penetration testing validates the effectiveness of isolation controls; it does not, on its own, assess the security posture of in-scope systems, which is the job of broader application- and network-layer penetration testing. Note also that the specific PCI DSS requirement numbering, wording, and testing frequency differ between versions of the standard, so readers should confirm the applicable requirements against the current published PCI DSS and its associated Penetration Testing Guidance rather than assuming a fixed requirement.

Who it's relevant to

Security Engineers and Penetration Testers
Engineers and testers design and execute the controlled tests that attempt to reach the CDE from out-of-scope segments. They need to define testing scope to include the networks and systems treated as out of scope, document any unexpected connectivity discovered, and distinguish segmentation validation from the broader application- and network-layer testing that assesses the posture of in-scope systems.
Compliance Officers and QSAs
Those responsible for demonstrating PCI DSS compliance rely on segmentation testing to substantiate claims that certain networks are out of scope. Because the scope reduction depends on isolation actually holding, they use this testing as evidence that segmentation controls are effective, and they should confirm the applicable requirement wording and testing frequency against the current published standard rather than assuming a fixed requirement number.
Network and Infrastructure Teams
Teams that configure firewalls, VLANs, and access control lists are responsible for the segmentation controls being validated. Findings from segmentation penetration testing help them identify misconfigured or overly permissive rules, and configuration drift that may have opened a path between a less-secure network and the CDE over time.
Merchant and Service Provider Risk Teams
Risk teams overseeing payment environments use segmentation testing results to understand whether their true PCI DSS scope matches what they assume. Confirmation that isolation holds supports scope decisions, while discovered gaps may indicate that additional networks must be brought into scope or remediated before they can be relied upon for isolation.

Inside Segmentation Penetration Testing

Scope Isolation Validation
Testing that verifies the controls intended to isolate the cardholder data environment (CDE) from out-of-scope networks actually prevent connectivity, so that systems claimed to be out of scope cannot reach in-scope systems. This confirms whether segmentation reduces PCI DSS scope as asserted.
Attack Path Testing
Attempts from out-of-scope network segments to reach the CDE across the segmentation boundary, exercising firewall rules, ACLs, routing, and other isolation mechanisms to determine whether any path exists that would expand scope.
Segmentation Controls Under Test
The specific mechanisms relied upon for isolation, such as network firewalls, router ACLs, VLAN configurations, and other access controls. The test evaluates these controls as implemented rather than as documented.
Coverage of All Boundaries
Exercising each defined boundary between in-scope and out-of-scope networks, including connections to third parties or other internal zones, so that no segmentation interface is left unverified.
Reporting and Evidence
Documentation of the methods used, segments tested, results, and any findings where isolation failed, providing evidence to support scope reduction claims. Requirement numbering and wording for penetration testing differ between PCI DSS versions, so confirm the applicable requirement against the current published standard.
Remediation and Retest
Correction of any identified gaps where out-of-scope systems could reach the CDE, followed by retesting to confirm the segmentation control now enforces the intended isolation.

Common questions

Answers to the questions practitioners most commonly ask about Segmentation Penetration Testing.

Does passing a segmentation penetration test mean the segmented systems are permanently out of PCI DSS scope?
No. A segmentation penetration test provides point-in-time assurance that the controls isolating the cardholder data environment (CDE) from out-of-scope networks were effective at the time of testing. Scope is not a permanent attribute conferred by a passing result. Network changes, new firewall rules, added connectivity, or configuration drift can reintroduce paths into the CDE and bring previously out-of-scope systems back into scope. This is why testing must be repeated periodically and after significant changes, and why segmentation must be validated on an ongoing basis rather than treated as a one-time determination. Confirm the specific testing frequency and change-driven requirements against the current published PCI DSS.
Isn't a segmentation penetration test just the same thing as a general penetration test of the CDE?
They are related but distinct. A general penetration test seeks to identify and exploit vulnerabilities in systems and applications. A segmentation penetration test has a narrower, specific objective: to verify that segmentation controls actually prevent access from out-of-scope networks into the CDE, so that in-scope and out-of-scope environments are genuinely isolated. The segmentation test focuses on confirming that no unintended connectivity or exposed paths exist across the segmentation boundary. An assessment program typically includes both the broader penetration testing of the CDE and the specific segmentation testing; one does not substitute for the other. Confirm how each is required and scoped against the current published PCI DSS.
From which network position should segmentation penetration testing be performed?
Testing is generally performed from the out-of-scope networks toward the CDE to confirm that the segmentation controls block access into the cardholder data environment. The objective is to demonstrate that systems the organization believes are isolated cannot reach in-scope systems through unintended paths. Depending on the environment, testing may need to be conducted from multiple out-of-scope segments to cover all relevant boundaries, and the tester should verify the accuracy of the documented scope and data-flow diagrams rather than relying on them alone. Confirm the applicable expectations against the current published PCI DSS.
How often should segmentation penetration testing be performed?
PCI DSS specifies a periodic testing cadence for segmentation controls, and additionally requires testing after significant changes to segmentation methods or controls. Requirement numbering, wording, and stated frequencies differ between PCI DSS versions, and service providers may be subject to different expectations than merchants. Rather than relying on a fixed interval or requirement number, confirm the current cadence, the definition of significant change, and any entity-type-specific expectations against the current published standard applicable to your assessment.
Who is qualified to perform segmentation penetration testing, and can it be done internally?
Segmentation penetration testing should be performed by a qualified individual or team with appropriate skills and experience in penetration testing, and with organizational independence from the management of the systems being tested. The tester may be internal or external, provided the independence and qualification expectations are met. Documenting the tester's qualifications and the basis for their independence supports the assessment. Confirm the specific qualification and independence expectations against the current published PCI DSS.
What should the scope of a segmentation penetration test cover?
The test should cover the boundaries between all out-of-scope networks and the CDE, so that every segmentation control relied upon to reduce scope is exercised. This includes validating that the organization's documented scope and network segmentation are accurate, since an incorrect scope determination can leave untested paths. The tester should confirm that controls block connectivity from each relevant out-of-scope segment into in-scope systems. Broader vulnerability exploitation within the CDE falls under general penetration testing rather than the segmentation-specific test. Confirm scope expectations and documentation requirements against the current published PCI DSS.

Common misconceptions

Segmentation penetration testing is the same as a general network penetration test of the CDE.
A general penetration test seeks to exploit vulnerabilities within in-scope systems, while segmentation penetration testing is specifically intended to verify that isolation controls prevent out-of-scope networks from reaching in-scope systems. They address different objectives and both may be required; one does not substitute for the other.
If firewall rules and network diagrams show segments are separated, testing is unnecessary.
Documentation describes intended configuration, but segmentation penetration testing validates the controls as actually implemented. Misconfigurations, undocumented paths, or drift can allow connectivity that documentation does not reflect, which is why the boundary is exercised in practice.
Passing segmentation testing guarantees the CDE is secure from compromise.
Segmentation testing is intended to confirm scope isolation, not to eliminate risk within the CDE. It helps reduce scope and limit attack paths, but it does not by itself demonstrate that in-scope systems are free of vulnerabilities or that fraud and compromise are prevented.

Best practices

Define and document every boundary between in-scope and out-of-scope networks before testing, so each segmentation interface is explicitly identified and exercised.
Test isolation from the out-of-scope side toward the CDE, attempting to reach in-scope systems across each boundary rather than relying solely on configuration review.
Validate segmentation controls as implemented against the current published PCI DSS version, confirming the applicable requirement wording and cadence rather than assuming a fixed requirement number.
Record the methods, segments covered, and results in enough detail to serve as evidence supporting any scope reduction claim.
Remediate any path where out-of-scope systems can reach the CDE and retest to confirm the isolation now holds.
Repeat segmentation penetration testing after significant changes to network architecture or segmentation controls, since configuration drift can reintroduce connectivity.