PCI DSS Segmentation Testing: What Assessors Expect

PCI DSS segmentation testing is a penetration test that tries to cross from your out-of-scope networks into the cardholder data environment (CDE) and proves that it cannot. Segmentation itself is optional. Once you rely on it to keep systems out of scope, though, you have to prove it works, with evidence an assessor can follow line by line. This guide covers what the requirement says, how to plan and run the test, what the report must contain, and where teams most often fail.

TL;DR

• Segmentation is not mandatory under PCI DSS, but it is the main way to shrink scope. The PCI Security Standards Council notes that effective segmentation limits compliance effort to the systems, people and processes that need it.
• If you use segmentation to isolate the CDE, you must test it with penetration testing methods. Under PCI DSS v4.x that is Requirement 11.4.5: at least every 12 months and after any change to segmentation controls. Service providers have a stricter cycle under 11.4.6, every six months.
• A pass/fail statement is not evidence. Assessors want the starting foothold, the attempted routes, ports and protocols, and the control that blocked each attempt.
• Every firewall rule, ACL or cloud peering change is a potential scope event. Test after changes, not only before the audit.

Table of Contents

• What segmentation testing actually proves
• Is segmentation required?
• PCI segmentation requirements: what 11.4.5 and 11.4.6 ask for
• How to run a segmentation test, step by step
• What assessors want in the report
• Where segmentation tests fail
• Segmentation testing, vulnerability scanning and penetration testing
• Planning the cycle so nothing is missed
• Our perspective
• Get segmentation evidence your assessor will accept
• FAQ
• Sources

What segmentation testing actually proves

Scoping and segmentation are two different jobs. Scoping identifies the people, processes and technologies that interact with or could affect the security of cardholder data. Segmentation adds controls that separate those systems from everything else.

Segmentation testing answers one narrow question: can a system outside the CDE reach a system inside it in a way the design does not allow? If the answer is no, across every segmentation method you use, the out-of-scope systems stay out of scope. If the answer is yes, those systems and everything that touches them may be pulled into the assessment.

That is why the stakes are higher than they look. A flat network puts the entire environment in scope for a full assessment. For a Houston law firm that takes card payments for retainers, or an energy retailer with a payment portal and a corporate network on the same switches, one failed test can turn a small assessment into an organization-wide one. We cover the energy side in more detail in PCI DSS compliance for energy retail operations.

Is segmentation required?

No. The Council's guidance describes network segmentation as something that is not a PCI DSS requirement, yet it is strongly recommended because it can reduce the scope, cost and difficulty of maintaining controls. The Council's own FAQ on reducing assessment scope says that isolating the CDE from the rest of the network is strongly recommended as a way to reduce scope.

The decision is a business one:

• Segment if you want fewer systems, fewer people and fewer policies under assessment.
• Do not segment if your environment is small enough that treating it all as in scope is cheaper than building and testing boundaries.

The obligation to test only appears once you choose segmentation. That is the point many smaller organizations miss: the network diagram says "segmented" and the assessor asks for the test report that backs it up.

If you are still deciding what belongs in scope, start there. Our PCI DSS readiness roadmap explains why confirming scope comes before any control work. A plain-language PCI compliance checklist for merchants also shows how an unsegmented network can bring the whole environment into an assessment.

PCI segmentation requirements: what 11.4.5 and 11.4.6 ask for

Under PCI DSS v4.x, segmentation testing sits in Requirement 11, inside the penetration testing requirements. In practice the requirements work like this:

Before you plan, check the current PCI DSS document for the exact wording and your assessor's interpretation. Also confirm whether you are a merchant or a service provider. A law firm taking its own clients' card payments is generally a merchant. A managed hosting or payment-adjacent provider handling cardholder data for others is likely a service provider, and the six-month cycle is the one most often missed by teams reading merchant-oriented guidance.

Two practical notes follow from the requirement text:

1. The test must follow your penetration testing methodology. Segmentation testing is not a port scan someone ran last quarter. It needs a defined approach, a qualified tester and documented results.
2. Change triggers matter as much as the calendar. A new VLAN, a rewritten firewall rule set or a new cloud connection resets the clock on the controls it touched.

For the wider penetration testing context, including internal and external tests, see our guide to PCI penetration test requirements.

How to run a segmentation test, step by step

The approach below follows the logic in the Council's Penetration Testing Guidance and standard assessment practice. Adapt it to your environment and your assessor's expectations.

1. Document the segmentation design

Start with a current network diagram and data flow diagram. List every control that enforces separation: firewalls, router ACLs, VLANs, software-defined network policies, cloud security groups, host-based firewalls. If a control is not on the list, it will not be tested, and an untested control cannot support a scope reduction.

2. Define in-scope and out-of-scope networks

Name the CDE segments, the connected-to systems and every out-of-scope segment that sits next to them. These adjacent segments are the places an attacker would start, so they become your test origins.

3. Choose the test origins

The test runs from the out-of-scope side toward the CDE. Typical starting points:

• A corporate user VLAN
• A guest or wireless network
• A server or management network that is out of scope
• A cloud VPC or subscription that is peered to the CDE
• Remote access or VPN pools

In large environments with many segments, testing from every single source point may be infeasible. The PCI Penetration Testing Guidance suggests planning the testing so that every type of segmentation methodology in use is examined, for example firewall rules, VLAN ACLs and SDN policy, so the effectiveness of each control type is validated consistently.

4. Test every host and port in the CDE segments

A commonly recommended technique is to scan each host in a PCI in-scope segment across all 65,535 TCP and UDP ports from an out-of-scope position. Running scans in batches keeps the traffic manageable and lets you spot dropped or rate-limited responses. Treat this as one practitioner's recommendation, not a PCI mandate, and agree the final depth with your assessor.

Beyond scanning, a penetration tester should try to bypass the control, not just observe it. That includes checking for permissive "any" rules, jump hosts that straddle both sides, shared credentials, misrouted management interfaces and tunneled protocols that a firewall allows by design.

5. Test both directions where the design requires it

Inbound traffic into the CDE is the headline concern. Outbound traffic from the CDE to out-of-scope networks also matters, because it can show that the CDE is not as isolated as the diagram claims.

6. Record everything

Capture the source, the destination, the port and protocol, the tool and the result for each attempt. A short screenshot of a refused connection is more persuasive than a paragraph saying nothing got through.

7. Remediate and retest

Any successful crossing is a finding. Fix the rule or the design, then rerun the affected tests and keep both the failed and passed results. The retest is what shows an assessor the control is now effective.

What assessors want in the report

The most common mistake is a black-box test that returns only a pass or fail. According to the PCI Council's penetration testing guidance, the testing should examine specific attempts against the segmentation controls, and in our experience an assessor wants to see the following:

• The starting foothold in the out-of-scope network, including its subnet and role
• The target systems and segments in the CDE
• The routes, ports and protocols attempted
• The enforcement point that blocked each path, or the misconfiguration that let one through
• The methodology and the qualifications and independence of the tester
• Dates, tool versions and the network diagram version tested
• Remediation and retest results for every finding

Clear documentation of attempted and blocked paths is the quickest route through the audit conversation, because it lets the assessor reproduce the logic rather than take your word for it. Our guides on what an audit-ready pentest report contains and pentest reporting that gets fixed go deeper on structure.

Where segmentation tests fail

The technical failures are rarely exotic. The same patterns show up again and again:

Segmentation testing is a lifecycle activity, not a one-time check. Most failures happen during ad hoc network changes: edited firewall rules, updated ACLs, new cloud peering links. IT teams often overlook them until the annual assessment. The teams that stay out of trouble treat every infrastructure change as a potential scope-impacting event and validate it right away.

For environments that also run industrial networks, such as pipelines, terminals or field operations, the same logic applies to zones and conduits. Our OT network segmentation blueprint shows how to design the boundaries before anyone tests them.

Segmentation testing, vulnerability scanning and penetration testing

These three activities are often confused, and an assessor will not accept one in place of another.

• Vulnerability scanning looks for known weaknesses on hosts. It does not test whether a network boundary holds. See our explainer on what vulnerability scanning is.
• Penetration testing (internal and external) attempts to exploit weaknesses in the CDE and connected systems.
• Segmentation testing is a penetration test focused on the boundary: can an attacker or a misconfigured system cross it?

NIST's Technical Guide to Information Security Testing and Assessment describes testing, examination and interviewing as three distinct assessment methods. That is a useful frame: segmentation testing is the testing method, while reviewing firewall configurations is examination. A strong package contains both, and the assessor will read them together.

Planning the cycle so nothing is missed

A simple operating rhythm keeps the test from becoming a scramble:

1. Maintain a change register for any network, firewall or cloud routing change touching the CDE or its neighbors.
2. Flag scope-impacting changes at the change approval stage, not after deployment.
3. Run a targeted retest for the affected controls after each flagged change.
4. Run the full segmentation test on the 12-month cycle (or six-month for service providers), timed so results are ready well before the assessor arrives.
5. Archive results with the diagram version, the scope statement and the remediation record.

If your team wants to reduce the manual load, continuous penetration testing with AI proofs can keep evidence fresh between annual tests, and AI-assisted penetration testing with vCISO guardrails explains where human review still has to stay in the loop. Teams with cloud-heavy CDEs should also read about cloud pentesting that produces audit-ready evidence.

Our perspective

We see segmentation treated as a diagram problem when it is an evidence problem. A well-drawn network picture does not reduce scope. A test report does, and only if it shows what was attempted, from where, and what stopped it.

Three habits separate the organizations that pass without drama from those that scramble:

• They decide scope first. Segmentation design follows a clear statement of which systems touch card data. Building boundaries before knowing what is inside them produces rules nobody can explain to an assessor.
• They tie testing to change control. The annual test is the floor. The real protection comes from validating segmentation whenever a firewall, ACL or cloud route changes.
• They ask for detail from testers. If a report cannot tell you the foothold, the attempted paths and the enforcement point, it will not satisfy your assessor either.

For regulated organizations such as law firms, energy operators and healthcare-adjacent businesses, a segmented design also limits the damage of a breach, not just the audit effort. Fewer systems with card data means fewer places for an attacker to go and fewer people who need training and access reviews. Whether you hire full-time security leadership or use a virtual CISO, someone senior should own the scope statement and sign off on the evidence before the assessor sees it.

— vCISO

Get segmentation evidence your assessor will accept

CISOSafe is a Houston-based virtual CISO firm with an AI-powered platform for penetration testing, compliance intake and reporting. We help regulated organizations confirm PCI DSS scope, test the controls they rely on and prepare audit-ready documentation, through services such as security risk assessments, compliance program management and audit and certification readiness. See the full list of our vCISO and compliance services, or talk to us about your PCI scope.

FAQ

Is segmentation testing required for PCI DSS?

Only if you use segmentation to reduce scope. Segmentation itself is not a PCI DSS requirement, but once you rely on it, the controls must be tested with penetration testing methods. If you skip segmentation, the whole network is treated as in scope instead.

How often do you need to test PCI segmentation?

Under PCI DSS v4.x, Requirement 11.4.5 calls for testing at least every 12 months and after changes to segmentation controls or methods. Service providers face a six-month cycle under Requirement 11.4.6. Confirm your category and timing with your assessor.

Can a vulnerability scan replace a segmentation test?

No. A vulnerability scan finds weaknesses on hosts, while a segmentation test tries to cross the boundary between out-of-scope networks and the CDE. Assessors expect penetration testing evidence for segmentation, including attempted routes, ports and the controls that blocked them.

Who should perform the test?

The tester should be qualified, follow a documented penetration testing methodology and be organizationally independent from the systems being tested. Internal staff can qualify if they meet those conditions. Many regulated organizations use an external specialist or a vCISO-led program to keep the evidence consistent.

What happens if segmentation testing fails?

A successful crossing is a finding. You fix the control, retest the affected paths and keep both results. Until the retest passes, the systems reachable through that gap may need to be treated as in scope for the assessment.

Sources

• Guidance for PCI DSS Scoping and Network Segmentation, PCI Security Standards Council
• Penetration Testing Guidance, PCI Security Standards Council
• FAQ 1178: How do I reduce the scope of a PCI DSS assessment?
• How to conduct network segmentation testing, Dr. Atalay Keleştemur
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment

Recommended

• PCI Penetration Test Requirements: A Compliance Officer's Guide
• Confirm Scope First for PCI DSS Readiness, 30–90 Day v4 Roadmap
• Audit Ready Pentest Reports for Security Teams with vCISO Templates