Skip to content
Invadel

Network

Network
Segmentation Testing

Proving out-of-scope networks cannot reach the CDE

From $6,000 within an internal test; standalone quoted, fixed scope, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Full scoping questionnaire 
Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When you need segmentation testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • You use segmentation to keep systems out of PCI DSS scope and have to prove it works under Requirement 11.4.5, or 11.4.6 if you are a service provider.
  • You are a PCI service provider and owe a segmentation test every six months, not once a year.
  • You assumed segmentation from the network diagram and have never tested it from the wrong side.
  • You separate IT from OT, guests from staff, or one tenant from another, and need proof the boundary actually holds.
  • You want to reduce the cost and scope of your next audit by proving the cardholder data environment is truly isolated.

Definition

What is network segmentation testing?

Network segmentation testing proves that the controls separating one network zone from another actually work. Instead of reading firewall rules from a console, a tester starts in the out-of-scope or lower-trust networks and tries to reach the protected zone, usually the cardholder data environment, by every path: across the network, through shared services, over a jump host, through a management interface, or via cloud peering. Success is defined the way an auditor defines it: no path exists.

Segmentation is easy to assume from the network diagram and never test from the wrong side, which is exactly why PCI DSS makes you prove it. For most clients it is part of the internal network penetration test from $6,000, which covers segmentation alongside Active Directory and lateral movement. A standalone segmentation re-validation, the kind a PCI service provider needs every six months, is scoped and quoted on its own.

PCI DSS

PCI DSS 11.4.5 and 11.4.6, in plain terms

Segmentation is not itself a PCI DSS requirement. But if you use it to reduce scope, you have to prove it works, and the standard sets exactly how often.

Requirement 11.4.5

Who it applies to
All entities that use segmentation to reduce PCI scope
How often
At least once every 12 months and after changes to segmentation controls
What it must confirm
Segmentation controls are operational and effective and isolate the CDE from all out-of-scope systems
Who can run it
A qualified internal resource or qualified external third party with organizational independence, not required to be a QSA or ASV

Requirement 11.4.6

Who it applies to
Service providers that use segmentation
How often
At least once every 6 months and after changes to segmentation controls
What it must confirm
The same, twice as often, because service-provider networks tend to be larger, more complex, and change more often
Who can run it
The same

Both requirements also ask you to confirm the effectiveness of any isolation used to separate systems with differing security levels (Requirement 2.2.3). Our guide to PCI DSS penetration testing requirements walks through all of Requirement 11.4, and PCI compliance levels explains who counts as a service provider.

What we look for

What segmentation testing looks for

The existence of separate network segments does not create segmentation. We test the controls that are supposed to enforce it, from the side an attacker would start on, and prove whether any path into the protected zone exists.

Reaching the protected zone

The whole test in one line: starting in the out-of-scope networks and trying to reach the cardholder data environment or other protected zone by any route. Success means no path exists.

We test for

  • Host discovery and port scanning from out-of-scope segments toward the CDE
  • Every network path between the starting segment and the protected zone
  • Reachability confirmed or denied against the policy you say you have
  • Both directions where the threat model requires it
  • The paths named in the report so a QSA can verify them

Firewall and VLAN rules

The rules that are meant to enforce separation, tested from the wrong side rather than read from a console export. Our guide to firewall penetration testing covers the rule review that sits alongside it.

We test for

  • Firewall rules between user, server, management, and cardholder zones
  • VLAN and access-control-list gaps that let traffic cross
  • NAT rules that expose a host nobody expected
  • Routes and IPv6 paths that bypass the firewall entirely
  • Rules that look narrow but apply to an object group someone later expanded

Shared services and jump hosts

The connected-to and security-impacting systems that legitimately touch both sides, and become a bridge if they are not locked down.

We test for

  • Jump servers and bastion hosts that provide access into the CDE
  • Shared services such as name resolution, patching, and authentication reachable from both zones
  • Management interfaces exposed across the boundary
  • Administrator accounts usable from an out-of-scope segment
  • Whether a foothold on a shared service reaches the protected zone

Cloud and virtualized paths

Segmentation in a cloud or virtualized estate, where connectivity is not always a cable you can trace.

We test for

  • Cloud peering, transit, and VPC or VNet connections between zones
  • Security-group and network-rule gaps in the cloud
  • Virtual switches and firewalls sharing an underlying host
  • Identity paths that cross a boundary the network does not
  • Isolation of the protected zone from the wider cloud account

Isolation of differing security levels

For PCI, confirming any use of isolation to separate primary functions with different security levels (Requirement 2.2.3), and, more broadly, that guest, tenant, or OT zones stay apart.

We test for

  • Primary functions with differing security levels isolated on shared systems (2.2.3)
  • Guest and corporate network isolation
  • Tenant-to-tenant isolation in multi-tenant environments
  • IT-to-OT and IT-to-plant boundaries, tested with plant-safe methods
  • The boundaries that hold, and the ones that only exist on the diagram

Scoping

Why a failed segmentation test changes your whole scope

The PCI SSC guidance is blunt about it: without adequate segmentation, sometimes called a flat network, the entire network is in scope for the assessment. Segmentation is strongly recommended precisely because it can reduce the scope, the cost, and the difficulty of PCI DSS, by keeping cardholder data in fewer, more controlled places. But the guidance is equally clear that the existence of separate network segments does not automatically create segmentation: only purpose-built controls that enforce separation do.

That is why a failed segmentation test is not just a finding. If a path exists from an out-of-scope network into the cardholder data environment, the systems you thought were out of scope are in scope, with every PCI DSS requirement that comes with them. Testing from the wrong side, before your QSA does, is how you find that out on your terms. The same logic applies to a CMMC Level 2 enclave, where out-of-scope assets must be physically or logically separated from the systems that handle CUI.

Beyond PCI

Segmentation testing beyond the CDE

IT and OT

Manufacturers and operators prove the boundary between the corporate network and the plant floor. We test it with plant-safe methods: passive discovery first, active steps only in agreed windows. See OT and ICS penetration testing and our work for manufacturers.

Guest and corporate

The guest Wi-Fi and visitor networks that are supposed to stay away from internal systems, tested for the paths that quietly bridge them.

Tenant isolation

In multi-tenant and hosted environments, whether one tenant can reach another across the network, the classic isolation failure a buyer fears.

Ransomware blast radius

Segmentation is what stops one phished laptop reaching everything. We test it as part of a ransomware readiness assessment for exactly that reason.

Methodology

How segmentation testing runs

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your network segmentation testing runs through.

  1. 01

    Map the zones

    The in-scope and out-of-scope segments, the protected zone, and the controls that are supposed to separate them, agreed in writing.

  2. 02

    Start out of scope

    Testing begins in the lower-trust or out-of-scope networks, the position a real attacker or a compromised host would hold.

  3. 03

    Try every path

    Host discovery, port scanning, and manual attempts to reach the protected zone through the network, shared services, and management paths.

  4. 04

    Prove and document

    Each path is confirmed reachable or blocked against the stated policy, with the starting segments and paths named for the auditor.

  5. 05

    Report and retest

    A report a QSA can act on, a remediation list for any path that reached the zone, and a free retest of the fixes.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope & kickoff

    Targets, roles, and rules of engagement defined in writing, with a fixed scope and timeline.

  2. 02

    Testing goes live

    Findings post to your live platform dashboard the moment our testers confirm them.

  3. 03

    Track remediation

    Follow every finding from open to fixed, with severity, evidence, and status in one place.

  4. 04

    Report & retest

    Executive and technical reports land, then request a free retest in one click.

Compliance

Frameworks segmentation testing evidences

Segmentation testing proves a boundary holds, which several frameworks ask for in different words.

PCI DSSRequirement 11.4.5 segmentation testing every 12 months for all entities, and 11.4.6 every six months for service providers, confirming the CDE is isolated from all out-of-scope systems.CMMC Level 2Evidence that out-of-scope assets are physically or logically separated from the systems that process, store, or transmit CUI, and that the enclave boundary holds.NYDFS 23 NYCRR 500Part of the testing from inside the information systems boundaries that 500.5 requires, where segmentation protects nonpublic information.HIPAAInput to the periodic technical evaluation of 45 CFR 164.308(a)(8), where segmentation is one of the safeguards protecting systems that hold ePHI.SOC 2Evidence for CC6.1 logical access and the network separation an auditor expects between production and other environments.

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study
LatentPerygeeCity National BankAubaDesteiaDTCC
Request a reference 

Resources

Field notes from the offensive side

All articles →

Firewall Penetration Testing: What It Covers

Firewall penetration testing explained: external exposure, segmentation between zones, attacker-side rule review and PCI DSS segmentation tests, with costs.

PCI DSS Penetration Testing Requirements: Requirement 11.4 Explained Line by Line

PCI DSS v4.0.1 Requirement 11.4 explained: internal and external tests, segmentation testing, retesting, methodology, tester qualifications, QSA evidence.

Infrastructure Penetration Testing: What It Covers and How It Is Scoped

What infrastructure penetration testing covers, how external and internal scope is counted, how it maps to PCI, SOC 2 and NYDFS, and fixed prices from $4,200.

Want to see a report first?

Read a sample report for a fictional client, or request a redacted one from a real engagement. Our guide explains what a penetration testing report should contain.

See the sample report

FAQ

Frequently asked questions

What teams most often ask before scoping network segmentation testing.

Still have questions? 
01What is network segmentation testing?

It is a test that proves the controls separating one network zone from another actually work. A tester starts in the out-of-scope or lower-trust networks and tries to reach the protected zone, usually the cardholder data environment, through every path: the network, shared services, jump hosts, management interfaces, and cloud peering. If no path can reach the zone, the segmentation is effective; if one does, the report names it. A full internal test asks how far an attacker gets from a foothold; a segmentation test asks one narrower question, whether anything outside the protected zone can reach it.

02How often does PCI DSS require segmentation testing?

It depends on your role. Under Requirement 11.4.5, any entity that uses segmentation to reduce PCI scope must test it at least once every 12 months and after any change to segmentation controls or methods. Under Requirement 11.4.6, service providers must test at least once every six months and after changes. Both must confirm the segmentation is operational and effective and isolates the cardholder data environment from all out-of-scope systems, and both can be run by a qualified internal or external party with organizational independence, not necessarily a QSA.

03How much does segmentation testing cost?

For most clients it is part of the internal network penetration test, from $6,000, which covers segmentation alongside Active Directory and lateral movement. A standalone segmentation re-validation, the kind a PCI service provider needs every six months, is scoped and quoted on its own based on the number of zones, paths, and starting segments. Either way the price is fixed in writing before work begins, with a free retest. Starting prices for every service are on our pricing page.

04Is segmentation itself required by PCI DSS?

No. The PCI SSC is explicit that segmentation is not a PCI DSS requirement, but it is strongly recommended because it can reduce the scope, the cost, and the difficulty of the assessment. If you do not segment, the whole network is in scope. If you do segment to reduce scope, then you are required to prove the segmentation works through testing under 11.4.5 or 11.4.6.

05What happens if the segmentation test fails?

A failed test is more than a finding. If a path exists from an out-of-scope network into the cardholder data environment, then the systems you believed were out of scope are actually in scope, and every PCI DSS requirement applies to them. That can enlarge your assessment dramatically. Finding it in a test, before your QSA does, lets you fix the control and retest rather than discover it during the assessment. We include a free retest of the fixes.

06Do you test more than PCI segmentation?

Yes. The same technique proves any boundary: IT from OT and the plant floor, guest networks from corporate systems, one tenant from another in a hosted environment, and a sensitive enclave from the rest of the estate. For manufacturers we use plant-safe methods, passive discovery first and active steps only in agreed windows. We also test segmentation as part of a ransomware readiness assessment, because it is what decides how far one compromised host can spread.

07How do you test segmentation without disrupting production?

Segmentation testing is largely discovery and reachability work: host discovery and port scanning from the out-of-scope side to confirm what can and cannot reach the protected zone. It runs under written rules of engagement, with no destructive actions and agreed handling for fragile systems such as OT equipment, where we work in maintenance windows. Anything that does reach the zone is documented as evidence rather than exploited further than needed to prove the path.

Ready to test your defenses?

Talk to our team about scoping network segmentation testing.

Prefer the full scoping questionnaire? 
RelatedInternal Network External Network Network Pentest Ransomware Readiness

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.