Should compliance teams treat network segmentation as a security control or a scoping control?

Why PCI DSS Treats Segmentation as Both Control and Scope Boundary

Compliance teams should treat segmentation as a control that reduces exposure, but the compliance test is stricter: the boundary must be credible enough to justify smaller PCI DSS scope. That means the design, implementation, and evidence all matter. A weak or informal boundary may still lower risk, but it will not reliably remove systems from assessment scope.

Segmentation becomes a scoping control when it is used to separate the cardholder data environment from surrounding systems and show that traffic cannot flow except where explicitly allowed. In practice, the question is not only “does it help security?” but “does it genuinely constrain what the assessor must treat as in scope?”

The scoping lens is also operationally useful because it forces teams to define trust boundaries, document allowed paths, and keep the rule set aligned with architecture. That is why NIST SP 800-207 Zero Trust Architecture is a useful reference point, since it frames segmentation as part of explicit trust reduction rather than a cosmetic network design choice.

What Makes Segmentation Defensible in an Assessment?

For PCI DSS, the practical issue is whether the segmentation boundary is provable. If the design is only implied by VLANs, firewall intent, or undocumented routing assumptions, the boundary is fragile. Assessors generally expect evidence that the boundary is enforced, monitored, and not bypassed through alternate paths, management networks, remote access, or shared services.

Good segmentation therefore has three traits: the isolated zone is clearly defined, the technical controls enforce the boundary consistently, and the organisation can demonstrate that unauthorized reachability is blocked. Without that combination, segmentation may still be a security improvement, but it will not earn strong scoping confidence.

That is also why operational technology environments often rely on stricter boundary documentation. NIST SP 800-82 Rev. 3, Guide to Operational Technology Security is helpful because it treats segmentation as part of a broader containment strategy where trust boundaries and lateral movement paths must be understood, not assumed.

In payment environments, this same logic helps teams separate “security hardening” from “scope reduction.” Hardening reduces blast radius. Scope reduction requires proof that the blast radius is actually outside the regulated boundary.

How Compliance Teams Should Use Segmentation Evidence

Teams should think of segmentation evidence as an audit artifact set, not a single diagram. The most convincing package usually includes network diagrams, firewall or ACL rule reviews, routing and NAT evidence, test results showing blocked paths, and an explanation of shared services that remain in scope. If a segment relies on exceptions, those exceptions need to be explicit and controlled.

The strongest practice is to align architecture reviews with recurring validation. That means re-testing the boundary after major rule changes, new integrations, cloud connectivity changes, or remote administration changes. A boundary that was valid last quarter can become untrusted after a small routing or access change.

For payment programs, authoritative compliance guidance matters too. The PCI DSS v4.0 document library is the primary reference for scoping expectations, and it should be the basis for deciding whether a segmented environment can truly be treated as out of scope.

When teams use segmentation to reduce PCI footprint, they should also verify adjacent control dependencies. Shared admin networks, logging platforms, jump hosts, and identity services often become the hidden reason a supposedly isolated system remains in scope.

Practitioner Guidance

What to verify: Confirm that the segmentation boundary is tested from both expected and unexpected paths, including management access, third-party links, and cloud-to-on-prem connectivity. If any path can reach cardholder data or supporting systems, assume the boundary is not yet defensible.

Decision rule: If the control is being used to justify scope reduction, require stronger evidence than you would for ordinary hardening. If it only reduces exposure without proving isolation, treat it as a security control but not as a scoping decision.

What good looks like: The organisation can show a current diagram, a current rule set, a recent validation test, and a clear statement of which systems remain in scope because of shared services or reachable trust paths.

Practitioner takeaway: In PCI DSS work, segmentation is only “just a control” when the boundary is not yet proven; once the evidence is strong, its main compliance value is that it supports a narrower, defensible scope.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• What happens when host workloads and network teams treat segmentation as the same control?
• How should security teams prioritise NHI remediation in cloud environments?