If you use network segmentation to keep systems out of PCI DSS scope, Requirement 11.4.5 says you have to prove it works. That means penetration testing your segmentation controls at least once every 12 months and after any change to those controls or methods. The test must cover every segmentation method you use and confirm the cardholder data environment (CDE) is isolated from all out-of-scope systems. It must be carried out by a qualified tester, internal or external, who is organizationally independent. Service providers must test every six months under Requirement 11.4.6.

PCI DSS v4.0.1 is now the only active version of the standard, and the requirements that were future-dated in v4.0 have applied since March 31, 2025. The segmentation testing requirements themselves aren't new, but they're easy to get subtly wrong. Here's what they require in practice.

What does Requirement 11.4.5 say?

Requirement 11.4.5 applies if segmentation is used to isolate the CDE from other networks. When it is, penetration tests on segmentation controls must:

  • Happen at least once every 12 months and after any changes to segmentation controls or methods.
  • Cover all segmentation controls and methods in use.
  • Follow the entity's defined penetration testing methodology.
  • Confirm that the segmentation controls are operational and effective, and isolate the CDE from all out-of-scope systems.
  • Confirm the effectiveness of any isolation used to separate systems with differing security levels (see Requirement 2.2.3).
  • Be performed by a qualified internal resource or qualified external third party.
  • Be performed by a tester with organizational independence, who doesn't need to be a QSA or ASV.

That opening condition matters. If you don't rely on segmentation, there's nothing for 11.4.5 to test, but your whole network is then in scope for PCI DSS.

How does 11.4.6 differ for service providers?

Requirement 11.4.6 is an additional requirement for service providers only. It has the same elements as 11.4.5, with one difference: the test frequency.

Requirement 11.4.5 Requirement 11.4.6
Applies to All entities that use segmentation Service providers that use segmentation
Minimum frequency At least once every 12 months At least once every six months
After changes to segmentation controls or methods Yes Yes
Coverage, methodology, tester requirements Same Same

Multi-tenant service providers have a separate obligation in Appendix A1. Requirement A1.1.4 calls for penetration testing of the logical separation between customer environments at least once every six months. It was future-dated in v4.0 and has been mandatory since March 31, 2025.

What counts as a change that triggers a retest?

The requirement says "after any changes to segmentation controls/methods." It doesn't list what qualifies, so build the triggers into your change management process and agree them with your assessor. Changes that should normally trigger a retest include:

  • Replacing or adding a firewall or other network security control on the CDE boundary.
  • Rule changes that alter what can reach the CDE.
  • Adding a network segment, site or cloud account that connects to the boundary.
  • Moving CDE workloads to a new platform, such as a different cloud environment or a container cluster.
  • Introducing a new segmentation method, such as host-based or software-defined micro-segmentation.

Agree with your assessor, in advance, how much of the test has to be repeated after a change, and document the reasoning each time.

Who can perform segmentation testing?

Either a qualified internal resource or a qualified external third party. The standard doesn't require a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV).

Two conditions apply. The first is qualification. Your assessor will expect evidence that the tester has relevant penetration testing experience, and certifications or a documented track record help. The second is organizational independence. The person testing shouldn't be the person who designs, configures or manages the segmentation controls or the systems being tested. An in-house network engineer who maintains the firewall rules can't independently test them. Someone from a separate security testing function in the same company usually can.

The PCI SSC's Penetration Testing Guidance information supplement (September 2017) discusses tester qualifications and independence in more depth and is still worth reading.

What should a segmentation test cover?

The goal is to show that no out-of-scope system can reach the CDE. That shapes how the test is built.

Test from every out-of-scope network

List every network that's meant to be out of scope. That includes user networks, guest wireless, development and test environments, general server networks, partner connections and cloud accounts outside the CDE. Test from each one toward every CDE address range.

Testing from a single out-of-scope segment doesn't show that the others are isolated. A thorough test also covers the full TCP port range and relevant UDP services, not just a handful of common ports.

Cover every segmentation method in use

"All segmentation controls/methods" means exactly that. If the CDE boundary uses a perimeter firewall, VLAN access control lists, cloud security groups and host-based firewalls on some servers, each method needs testing. The same goes for any isolation used under Requirement 2.2.3 to separate functions with different security levels on the same system.

Look for indirect paths

An out-of-scope system may legitimately reach a connected-to system, such as a shared directory server or a jump host. The test should confirm that it can't use that system as a route into the CDE. Many testers also check traffic leaving the CDE toward out-of-scope networks, which helps confirm the boundary is enforced in both directions.

Know what a finding looks like

Allowed, documented flows from connected-to systems aren't failures. A failure is any path from an out-of-scope system into the CDE that isn't approved and justified. Each one means either the control needs fixing or your scope is larger than you thought.

What evidence will your assessor expect?

Plan the evidence before the test so the report answers the assessor's questions. We'd expect to see:

  • A documented methodology that meets Requirement 11.4.1, which includes testing to validate any segmentation and scope-reduction controls.
  • A test report that names the tester, describes their qualifications and independence, and lists the source networks, target ranges, segmentation methods covered, dates and results.
  • Alignment with your scope documentation. The networks tested should match your current network diagram (Requirement 1.2.3) and the scope confirmation under Requirement 12.5.2.
  • Remediation and retesting. Requirement 11.4.4 expects exploitable vulnerabilities and security weaknesses found during penetration testing to be corrected and the testing repeated to verify the corrections.
  • Retention. Requirement 11.4.1 calls for penetration testing and remediation results to be kept for at least 12 months.

Scope confirmation and segmentation testing reinforce each other. Requirement 12.5.2 has you document segmentation controls and justify each out-of-scope environment at least once every 12 months, and service providers must do it every six months under 12.5.2.1. The segmentation test is the technical evidence behind that justification.

For newer architectures such as zero trust, micro-segmentation and multi-cloud, the PCI SSC's information supplement PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures, published in September 2024, adds useful detail. It supplements the Council's 2016 scoping and segmentation guidance rather than replacing it.

Frequently asked questions

Is a vulnerability scan enough for segmentation testing?

No. Port and service discovery is usually part of a segmentation test, but 11.4.5 calls for a penetration test performed under your methodology. External ASV scans under Requirement 11.3.2 serve a different purpose and don't validate internal segmentation.

Can our own IT team do the test?

Yes, if the testers are qualified and organizationally independent of the systems and controls being tested. Your firewall administrators can't test their own rules.

Do we have to test if we don't use segmentation?

11.4.5 only applies if you use segmentation to isolate the CDE. Without segmentation, though, every system on the network is in scope for PCI DSS, which is almost always more work.

Does a cloud environment need segmentation testing too?

Yes, if cloud controls such as security groups or account boundaries separate the CDE from out-of-scope systems. They're segmentation methods, so they're covered by the requirement. Check your provider's penetration testing policy before you start.

Key takeaways

  • If segmentation reduces your scope, test it at least every 12 months (every six months for service providers) and after any change to segmentation controls or methods.
  • Test from every out-of-scope network toward the CDE, and cover every segmentation method in use.
  • Use a qualified, organizationally independent tester. They don't need to be a QSA or ASV.
  • Tie the test to your methodology, network diagrams and scope confirmation, and keep results and remediation evidence for at least 12 months.
  • Define in change management which changes trigger a retest, and agree those triggers with your assessor.