Network Segmentation Testing: What PCI DSS Actually Requires

Network segmentation testing checks whether a network boundary actually works. A tester sits on one side, often a low-trust network like guest Wi-Fi. They try every route to the other side, usually the systems that handle card payments. If they get through, the boundary has failed. Network segmentation testing exists to catch that before an attacker does.

Most UK businesses order network segmentation testing for one reason: PCI DSS. Here is what the standard actually asks for, what counts as proof, and where network segmentation testing stops and a full penetration test begins.

Why PCI DSS requires network segmentation testing

PCI DSS protects payment card data. The PCI Security Standards Council, the body behind the standard, says it applies to any organisation that stores, processes or transmits that data. If your card systems sat on the same flat network as everything else, your whole network would fall under full PCI DSS scope. That’s slow and expensive to assess.

Segmentation lets you shrink that scope. You carve out a smaller cardholder data environment and treat the rest of the network as out of scope. But that only works if the isolation is real. That’s the condition network segmentation testing exists to prove. The standard won’t just take your word for it.

What PCI DSS actually requires

Under PCI DSS version 4.0, segmentation used to reduce scope must be tested. The rule is simple: at least once every 12 months, and again after any change to the segmentation, such as a new firewall rule or an added VLAN. Service providers face a shorter cycle. They must test every six months. One failure on a shared platform can expose several clients at once, so the standard checks more often.

A general annual penetration test won’t cover this automatically. The scope has to name segmentation testing directly. Otherwise your tester may never have tried to cross the boundary between your card environment and everything else.

What network segmentation testing is not

It is not a firewall rule review. Reading a configuration file only tells you what a firewall is supposed to do. It doesn’t prove the rule works. It doesn’t rule out a second route, or a forgotten VPN tunnel that bypasses the rule entirely. Network segmentation testing is active. A tester actually tries to reach the protected zone. Then they report exactly what happened.

It’s also not the same as a full penetration test. A penetration test hunts broadly for vulnerabilities. It tries to escalate access wherever that’s possible. Network segmentation testing has one job: find out whether traffic can cross one specific boundary. That narrower scope makes it faster and usually cheaper to run alone. Many providers bundle it with an internal or external network penetration test instead, since the tester is mapping the network anyway.

What a QSA or auditor wants to see

Assessors want three things. First, a written scope naming every segment meant to isolate the cardholder data environment. Second, a report showing exactly which routes were tried and which held. Third, proof the test happened inside the required window. A network diagram showing intended segmentation isn’t evidence on its own. The test report is what an assessor actually checks. So keep dated copies of every report, not just the most recent one, because an assessor may ask to see the trend over several cycles.

Other frameworks ask similar questions. If your business also sits under ISO 27001 or NIS2, evidence from network segmentation testing tends to satisfy their network control questions too, even though neither sets PCI’s exact testing cadence.

What segments actually get tested

The most common boundary sits between the cardholder data environment and everything else: office workstations, guest Wi-Fi, and any third-party systems that touch the network. A thorough scope also covers quieter connections. Think of a backup server that sits on both networks, a monitoring agent installed on both sides, or a jump box used for remote admin.

Cloud environments need the same scrutiny. A subnet can look isolated on a console diagram and still be reachable. Perhaps a security group rule is broader than intended, or a shared service account crosses the boundary it shouldn’t. The principle stays the same in the cloud: try the route, don’t trust the diagram.

Why network segmentation testing matters beyond compliance

The National Cyber Security Centre makes the security case without mentioning payment cards at all. Its guidance on preventing lateral movement is blunt. Networks with strong boundary protection but no internal security, it warns, “give attackers free rein to traverse the network once they have gained access.” Ransomware relies on exactly that gap. One compromised laptop becomes a company-wide breach because nothing stops it moving sideways.

The NCSC’s advice is direct too. “Segregate networks as sets,” it says, and “isolate critical business systems.” Its separate ransomware guidance adds two more habits. Keep obsolete systems away from the main network. Review user permissions regularly. Both slow down how far malware can travel after that first foothold. Network segmentation testing is how you confirm those controls actually hold, rather than hoping they do.

Getting ready for a segmentation test

Start with a current network diagram, not last year’s. List every boundary meant to isolate a sensitive zone. Note any recent changes: new VLANs, a cloud migration, a merged office network. Any of those can quietly open a gap. Gather your existing firewall rule sets too. A tester who can compare intended rules against what actually happens on the wire finds gaps faster than one working blind.

Agree in advance who can approve emergency fixes during the test. If a tester finds a serious route into the cardholder data environment, a week-long wait for sign-off defeats the point of finding it early. Aardwolf Security scopes network segmentation testing alongside our wider penetration testing services. Talk to us through our contact page about what a proportionate test plan looks like for your PCI DSS environment.

Frequently asked questions

Does network segmentation testing replace a full penetration test?

No. PCI DSS requires both. A broader penetration test covers your in-scope environment. Network segmentation testing separately checks any controls used to reduce that scope. They answer different questions.

What happens if a segmentation test fails?

You get a specific route between two zones that should have been isolated. You also get enough detail to close it, usually a firewall rule or a forgotten connection. Fix it. Then retest that boundary before treating the segmentation as valid again, because an unfixed route stays a real risk until someone checks it a second time.

Who needs to test segmentation every six months instead of twelve?

Service providers whose segmentation controls protect multiple clients’ cardholder data. PCI DSS 4.0 sets a shorter six-month cycle for them, rather than the standard twelve-month requirement.

Can an internal team run network segmentation testing itself?

PCI DSS expects testing done by someone with the right skills and independence. Most organisations meet that bar by using an external tester rather than the team that built the segmentation.

Does network segmentation testing cover cloud environments?

It should, if segmentation is part of how you isolate cloud workloads. The principle stays the same as on a physical network. A tester attempts the route between segments rather than trusting a security group configuration that looks correct.