Using Network Segmentation to Reduce PCI DSS Scope

Segmentation decides how much of a network PCI DSS applies to. The standard does not require it, and it does not take effect just because a firewall exists. This article sets out what PCI DSS v4.0.1 says segmentation is, what it takes for a system to fall outside scope, and the two recurring checks that keep a segmented network segmented.

What PCI DSS applies to

Section 4 of the standard defines scope in two parts. The first is the cardholder data environment (CDE): the system components, people and processes that store, process or transmit cardholder data or sensitive authentication data, plus any system component with unrestricted connectivity to them. The second is everything that could affect the security of that data even though it never touches it: the standard's examples include authentication servers, remote access servers, logging servers, name resolution and e-commerce redirection servers. The glossary covers these as connected-to and security-impacting systems.

So scope is not "the systems that see card numbers". A directory server that authenticates administrators to the payment switch is in scope. So is the log collector that receives its logs.

Segmentation is optional, and without it everything is in scope

The standard is explicit: segmentation, or isolation, of the CDE from the rest of the network is not a PCI DSS requirement. It is strongly recommended, because it can reduce the scope and cost of the assessment, the cost of running the controls, and the risk of holding account data in many places. Without it, in what the standard calls a flat network, the entire network is in scope.

The test for being out of scope is strict. A system component is out of scope only if it is isolated from the CDE so well that, even if it were compromised, it could not affect the security of cardholder data or sensitive authentication data. Being on a different subnet does not meet that test by itself.

How segmentation is built

The standard leaves the method open. Its examples are properly configured internal network security controls (NSCs), routers with strong access control lists, and other technologies that restrict access to a part of the network. What matters is that traffic into and out of the CDE is limited to what is necessary and everything else is denied, which is what 1.3.1 and 1.3.2 require.

• A VLAN groups traffic; it does not isolate it. VLANs isolate only when an NSC between them actually denies the traffic, and the segmentation test below is where that gets proved.
• Wireless networks get an NSC at the boundary regardless. 1.3.3 requires one between every wireless network and the CDE, whether or not the wireless network is itself part of the CDE.
• The diagrams are part of the design. 1.2.3 requires an accurate network diagram showing every connection between the CDE and other networks, and 1.2.4 an accurate data-flow diagram of all account data flows. The standard notes that data-flow diagrams are also what supports confirming that segmentation isolates the CDE.

Segmentation has to be tested

Where segmentation is used to reduce scope, the assessor must verify that it is adequate, and the entity must test it. 11.4.5 requires penetration tests on the segmentation controls at least once every 12 months and after any change to them, covering every segmentation control or method in use, following the entity's penetration testing methodology, and confirming that the controls work and isolate the CDE from all out-of-scope systems. Service providers test every six months under 11.4.6.

A segmentation design that has never been tested is a claim, not a control. The test report is what an assessor relies on when deciding which systems they can leave out.

Scope is confirmed every year

12.5.2 requires the entity itself to document and confirm its scope at least once every 12 months and after any significant change. Among the elements it lists: every data flow for each payment stage and channel, every place account data is stored, processed or transmitted, every system component in, connected to or able to affect the CDE, and every segmentation control in use together with the environments the CDE is segmented from and the justification for treating each as out of scope. Service providers do this every six months under 12.5.2.1.

The standard is clear that this confirmation is the entity's work. The assessor checks scope during the assessment as well, but that check does not replace the entity's own.

Reducing scope starts with the data

Segmentation shrinks scope around wherever account data already is. The standard points to an earlier step: understand the business processes that need account data, then keep it in as few places as possible by removing what is not needed and consolidating what is. That can mean changing long-standing practices, such as card numbers kept in order notes or spreadsheets. Moving card entry to a hosted payment page takes a whole system out of the flow rather than fencing it off.

For the controls themselves, see the Requirement 1 overview and the testing controls in Requirement 11.