PCI Segmentation Testing

If you use network segmentation to keep systems out of your cardholder data environment, PCI DSS expects you to prove the isolation actually works. Segmentation testing is that proof. We attempt to reach your CDE from every network you have declared out of scope, and document exactly what we could and could not reach.

Why it matters

Segmentation is what keeps your PCI scope small. A smaller CDE means fewer systems to assess, fewer controls to evidence, and a lower compliance cost. But a firewall rule that looks right on paper is not evidence. If an out-of-scope network can reach the CDE, your scope is larger than you think, and your assessor will treat it that way.

What we test

• Every out-of-scope segment against the CDE, in both directions
• Firewall and ACL rules, VLAN boundaries, and cloud security groups
• Paths that are easy to miss: management networks, jump hosts, shared services, VPNs
• All protocols and ports, not a sample

What PCI DSS 4.0 requires

• Requirement 11.4.5: segmentation controls tested at least once every 12 months and after any change to segmentation controls
• Requirement 11.4.6: service providers test at least once every six months

What you get

A report your QSA can use directly: the segments tested, the method, the results for each path, and evidence. Any path we find into the CDE is written up with reproduction steps and a fix. Retesting of remediated issues is free.

Segmentation testing is usually run alongside your annual PCI penetration test. See pricing for how it is added to an engagement, or get in touch to talk through your scope.