Network Segmentation in PCI DSS: The Requirement That Isn't One

Somewhere in Southeast Asia this month, a bank is telling its assessor that most of its estate is out of PCI DSS scope because the servers do not store, transmit or process (SToP) card numbers. Those servers sit on the same subnet as the payment switch. The argument feels intuitive to the infrastructure team, and it is wrong in a way that will define their entire assessment.

This misunderstanding is common enough, and expensive enough, that it deserves its own explanation. Network segmentation is, bizarrely, not a PCI DSS requirement. It is also one of the most consequential controls you can put in place before an assessment, because it is the mechanism that decides how far the standard reaches into your organisation.

How PCI DSS scope actually works #

Most people read PCI DSS as a standard about card data, and it is. But the definition of scope in the standard is wider than the systems that touch a card number. Scope includes two categories:

1. System components that store, process, or transmit cardholder data or sensitive authentication data.
2. System components, people, and processes that could impact the security of that data.

The second category is the one organisations forget. A logging server that never sees a card number is in scope if the payment systems depend on it. A DNS server is in scope if a compromised lookup could redirect a payment flow. And every desktop and server that shares a network segment with the cardholder data environment (CDE) is in scope, because a compromised host on that segment has a network path to the systems handling payments.

PCI DSS v4.0.1 states the exclusion test plainly: to be considered out of scope, a system component must be isolated from the CDE such that it could not impact the security of cardholder data even if that component was compromised. The question is never whether a system handles PAN. The question is what an attacker could reach from that system if it fell.

The requirement that isn’t a requirement #

Here is the strange part. The PCI DSS v4.0.1 scoping guidance says this in almost so many words: segmentation of the CDE from the rest of an entity’s network “is not a PCI DSS requirement”, but it is “strongly recommended” because it reduces the scope of the assessment, the cost of the assessment, the cost of maintaining compliance controls, and the risk to the organisation by consolidating card data into fewer, better controlled locations.

Read that trade again. The standard’s authors chose not to mandate segmentation, but they wrote an entire paragraph explaining why you should do it anyway. Requirements tell you what an assessor must verify. The scoping guidance tells you what will decide whether those requirements consume three systems or three hundred.

The same guidance contains the sentence every infrastructure lead should pin to their wall: without adequate segmentation, sometimes called a flat network, the entire network is in scope for the PCI DSS assessment.

What a flat network does to a PCI DSS assessment #

On a flat network, scope is not negotiated, it is inherited. Every server, every office computer, every printer and every backup host that shares the segment inherits the security expectations of the systems handling card data. That means the same hardening, the same vulnerability management cadence, the same logging, the same access control discipline you would apply to a payment application, applied to the finance team’s laptops.

Organisations generally understand what PCI DSS expects of their payment servers. What they cannot absorb is applying that regime to an entire office or data centre. Patch windows that were routine become negotiations with every business unit. Change control slows down work that has nothing to do with payments. The assessment itself grows to match: more systems to sample, more evidence to produce, more interviews, more cost, and a longer runway to compliance.

I have watched a technically strong environment fail an assessment on these grounds. The payment tier was well built, carefully hardened, and sitting on a network where it was indistinguishable from everything else. The security of the CDE was real, but the perimeter that was supposed to demonstrate it did not exist, so the assessment had to treat hundreds of unrelated systems as if they were payment systems. Strong engineering, wrong architecture, expensive outcome.

A case from the field #

A current engagement involves a bank with exactly this problem. Unrelated servers across the organisation share one network with payment infrastructure. Their position is the intuitive one: these servers do not handle PAN, so they should be excluded from scope.

The answer comes straight from the standard’s own exclusion test. A system leaves scope only when it cannot impact the security of the CDE even if it is compromised. A standard office server on the same subnet as payment systems fails that test twice: it has a routable path to the CDE, and an attacker who takes it over inherits that same path. Lateral movement from a compromised desktop to a payment switch is not an exotic scenario; it is the opening move of most real intrusions.

The productive conversation is not whether these systems store PAN. It is which of them an attacker could pivot through, and what network controls would break that pivot.

How segmentation gets verified #

Segmentation that reduces scope has to earn that reduction, and PCI DSS specifies how:

• Annual scope confirmation (Requirement 12.5.2). The entity itself must confirm scope every twelve months, identifying all data flows and every system connected to, or able to impact, the CDE. Your assessor then reviews that work, so an undocumented segment becomes a finding, not a loophole.
• Segmentation penetration testing (Requirement 11.4.5). Where segmentation is used, it must be penetration tested at least annually and after any change to the segmentation controls, confirming the controls are operational and actually isolate the CDE from out-of-scope systems.
• Every six months for service providers (Requirement 11.4.6). Service providers test segmentation controls twice a year, because their segmentation is the boundary protecting other people’s card data.

Note the symmetry: segmentation itself is optional, but the moment you rely on it to shrink scope, testing it is mandatory. An untested segmentation control is a scope assumption, and assessors do not accept assumptions.

Where to start #

You do not need a re-architecture programme. You need an honest data-flow diagram and one boundary that holds. Find where card data actually lives, consolidate it into as few locations as the business allows, draw a perimeter around those locations, and deny everything across that perimeter by default. Then prove the perimeter works the way an attacker would test it.

For the design side, the companion piece on network segmentation design covers zoning that limits lateral movement generally, and the PCI DSS compliance guide for Thailand walks through the wider assessment journey.

Our PCI DSS QSA audit includes scoping as the first deliverable, so the boundary is agreed before evidence collection begins. Our configuration and architecture assessment maps real traffic flows into a segmentation design your engineers can execute, and our penetration testing verifies the segments actually hold under the same attacks an assessor will bring.