Category: Network Security

Segmentation Testing

Also known as: Network Segmentation Testing, Network Segmentation Test, Segmentation Penetration Testing

Simply put

Segmentation testing is a set of checks used to confirm that network controls meant to separate one part of a network from another are actually working as intended. In payment security, it helps verify that systems outside the sensitive cardholder data environment cannot reach systems inside it. This supports the practice of narrowing which systems fall under compliance requirements.

Formal definition

Segmentation testing is the validation activity that confirms the effectiveness of network segmentation controls used to isolate an in-scope environment (such as the cardholder data environment) from out-of-scope networks. The same technologies used to segment networks are often also used to manage access between in-scope systems or networks, so testing verifies that these controls actually prevent connectivity between segments as designed rather than merely being configured. In a PCI DSS context, segmentation testing is a component of validating scope reduction; practitioners should confirm the specific testing frequency, method, and requirement wording against the current published version of PCI DSS, as these differ between versions. Note that segmentation testing validates isolation controls and is distinct from broader penetration testing of in-scope systems, though the two are frequently performed together.

Why it matters

Network segmentation is one of the most common ways organizations reduce the number of systems that fall under PCI DSS requirements. By isolating the cardholder data environment (CDE) from the rest of the network, a business can narrow the scope of what must be assessed and secured. However, segmentation only provides that benefit if the controls actually work. A firewall rule, access control list, or VLAN configuration that looks correct on paper may still permit unintended connectivity in practice. Segmentation testing exists to close that gap between intended design and actual behavior.

This matters because the technologies used to separate networks are frequently the same ones used to manage access between in-scope systems. A misconfiguration can quietly place out-of-scope systems within reach of the CDE, expanding the true attack surface and potentially the compliance scope without anyone realizing it. If segmentation fails and cannot be demonstrated as effective, systems assumed to be out of scope may in fact need to be treated as in scope, which can undermine the scope reduction the organization relied upon.

For these reasons, segmentation testing supports both security and compliance objectives. It helps confirm that isolation controls prevent connectivity between segments as designed rather than merely being configured, and it provides evidence that scope reduction claims are defensible. Practitioners should confirm the required testing frequency, method, and specific requirement wording against the current published version of PCI DSS, as these details differ between versions.

Who it's relevant to

Compliance Officers and QSAs

Segmentation testing provides the evidence needed to support scope reduction claims. Those responsible for PCI DSS validation rely on it to confirm that out-of-scope systems genuinely cannot reach the cardholder data environment, and to verify that the testing method and frequency align with the current published version of the standard.

Security Engineers and Network Architects

Teams that design and maintain segmentation controls use these tests to confirm that firewalls, access control lists, and VLAN configurations enforce isolation as intended. Because the same technologies often manage access between in-scope systems, engineers benefit from verifying actual behavior rather than relying on configuration review alone.

Penetration Testers

Practitioners performing segmentation testing attempt to reach in-scope systems from out-of-scope networks to demonstrate whether isolation holds. This work is distinct from broader penetration testing of in-scope systems but is frequently conducted alongside it in the same engagement.

Merchants and Service Providers

Organizations that rely on segmentation to narrow their PCI DSS scope depend on this testing to keep that scope reduction defensible. Without demonstrated segmentation effectiveness, systems assumed to be out of scope may need to be treated as in scope.

Inside Segmentation Testing

Segmentation Definition

Network or system segmentation isolates the cardholder data environment (CDE) from out-of-scope networks and systems using controls such as firewalls, access control lists, VLANs with enforced separation, or other technologies. Segmentation is not required by PCI DSS but, when used, is intended to reduce the scope of assessment.

Purpose of Segmentation Testing

Testing seeks to verify that segmentation controls are operational and effective, confirming that out-of-scope systems cannot reach the CDE and that the isolation relied upon to reduce scope actually holds in practice.

In-Scope Determination

Where segmentation is inadequate or unverified, the entire network may be considered in scope. Effective, tested segmentation supports treating isolated systems as out of scope, but the label alone does not establish this; it must be validated.

Testing Methods

Typically involves technical testing such as port scanning, connectivity checks, and controlled attempts to reach the CDE from out-of-scope segments to confirm that controls block unauthorized paths. The specific procedures should be confirmed against the current published PCI DSS.

Frequency and Scope of Testing

PCI DSS specifies expectations for how often segmentation is tested and by whom, with different expectations that may apply to service providers versus merchants. Frequency, wording, and requirement numbering differ between versions; confirm against the current standard rather than assuming a fixed value.

Relationship to Penetration Testing

Segmentation testing is commonly performed as part of, or in conjunction with, penetration testing activities, but it is focused specifically on validating isolation boundaries rather than broadly assessing exploitable vulnerabilities.

Common questions

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

Does network segmentation automatically remove systems from PCI DSS scope?

No. Segmentation is a scope-reducing technique, not an automatic exemption. Segmentation is only effective if it is properly implemented and validated; controls that are assumed to isolate the cardholder data environment (CDE) but are not tested may still permit connectivity. Segmentation testing is intended to confirm that the isolation actually holds. If testing shows that out-of-scope systems can reach the CDE, those systems remain in scope regardless of the intended design.

Is segmentation testing the same thing as a penetration test?

They are related but distinct. Segmentation testing focuses specifically on validating that in-scope and out-of-scope networks are effectively isolated, confirming that controls intended to separate the CDE from other networks function as designed. A penetration test may include or accompany this work, but a broader penetration test also examines exploitable vulnerabilities and attack paths beyond segmentation boundaries. Confirm the exact expectations, frequency, and wording against the current published PCI DSS, as these differ between versions.

What is segmentation testing intended to demonstrate?

It is intended to demonstrate that the controls used to isolate the cardholder data environment from out-of-scope networks are operating effectively, so that only intended paths into the CDE exist. This typically involves attempting to reach in-scope systems from out-of-scope segments to verify that isolation controls block or restrict that access as expected. Confirm the specific objectives and documentation requirements against the current version of the standard.

How often should segmentation testing be performed?

PCI DSS specifies testing frequency and the circumstances that trigger testing, and these details differ between versions of the standard and can differ for service providers versus merchants. Testing is also generally expected after significant changes to segmentation controls or the environment. Because the exact intervals and triggers are version-specific, confirm the applicable frequency against the current published PCI DSS rather than assuming a fixed interval.

Who is qualified to perform segmentation testing?

The standard addresses tester qualifications and organizational independence for this type of testing, and the specific requirements vary by version and by entity type. In practice, segmentation testing should be performed by someone with appropriate skills and sufficient independence from the systems being tested. Confirm the current requirements for tester competency and independence against the applicable version of PCI DSS and, where relevant, your assessor's guidance.

What should the scope of segmentation testing cover?

Segmentation testing should cover the boundaries between out-of-scope networks and the in-scope cardholder data environment, verifying that intended isolation controls restrict access as designed across those boundaries. The precise scope depends on how the environment is segmented and which systems are relied upon to enforce isolation, so it should be defined based on the documented segmentation approach for the specific environment. Confirm scope expectations against the current published standard.

How does segmentation testing relate to the results feeding scope decisions?

The outcome of segmentation testing informs whether systems can legitimately be treated as out of scope. If testing confirms effective isolation, the segmented systems may remain outside the assessed scope; if testing reveals that isolation is incomplete, affected systems are drawn into scope and must be assessed accordingly. Because scope determination depends on validated results rather than intended design, testing outcomes should directly drive the documented scope for the assessment.

Common misconceptions

Implementing segmentation automatically removes systems from PCI DSS scope.

Scope reduction depends on segmentation being correctly implemented and verified through testing. Until isolation is validated, systems presumed out of scope may still be considered in scope, and inadequate segmentation can place the entire network in scope.

Segmentation testing and a full penetration test are the same thing.

Segmentation testing specifically validates that isolation controls prevent access from out-of-scope systems into the CDE. It is often conducted alongside penetration testing but has a narrower, boundary-focused objective and does not replace a broader vulnerability assessment.

Segmentation is a mandatory PCI DSS requirement.

Segmentation is not required by PCI DSS. It is an optional approach used to reduce assessment scope; when an organization chooses to rely on it, the standard sets expectations for verifying its effectiveness.

Best practices

Maintain current and accurate network diagrams and data-flow documentation that identify the CDE boundaries and every point where cardholder data enters, moves through, or leaves the environment, so testing can target the correct segmentation controls.

Test connectivity from out-of-scope segments toward the CDE to confirm that firewalls, access control lists, and other isolation controls actually block unauthorized paths, rather than assuming the configuration is effective.

Confirm testing frequency, scope, and any differing expectations for service providers against the current published version of PCI DSS instead of relying on a remembered requirement number or interval.

Coordinate segmentation testing with penetration testing activities while keeping the boundary-validation objective distinct, and ensure testers understand which segments are claimed to be out of scope.

Re-test segmentation after significant changes to the network, controls, or CDE, since prior validation may no longer reflect the current environment.

Retain documented evidence of testing methods and results to demonstrate that scope reduction is based on verified isolation, and address any discovered gaps before relying on the reduced scope.