Skip to main content
Category: Network Security

Network Segmentation

Also known as: network isolation, network zoning, segmentation
Simply put

Network segmentation is the practice of dividing a larger computer network into smaller, separated sections or zones so that systems in one section cannot freely communicate with systems in another. Organizations use devices such as firewalls, switches, and routers to create and enforce these boundaries. In payment security, segmentation is commonly used to help limit which systems can reach the environment that handles cardholder data.

Formal definition

Network segmentation is an architectural approach that divides a network into multiple isolated segments or subnets, each functioning as its own smaller network, with traffic between segments controlled and restricted by enforcement points such as firewalls, switches, and routers. In a PCI DSS context, segmentation is not itself a mandatory requirement but is a technique frequently used to isolate the cardholder data environment (CDE) from out-of-scope systems, potentially reducing the systems, people, and processes that fall within assessment scope. Effective segmentation depends on the strength and validation of the isolating controls rather than on network design intent alone; connectivity that allows a system to affect the security of the CDE keeps that system in scope. Readers should confirm segmentation guidance and any scope-reduction expectations against the current published PCI DSS standard, as wording and expectations differ between versions.

Why it matters

Network segmentation matters in payment security primarily because it can influence the scope of a PCI DSS assessment. When the cardholder data environment (CDE) is isolated from the rest of an organization's network, the systems, people, and processes that fall within assessment scope may be reduced. A flat, unsegmented network, by contrast, can pull large portions of an organization's infrastructure into scope, because any system able to reach or affect the security of the CDE is generally considered in scope.

Beyond scope considerations, segmentation supports a broader defense-in-depth posture. By restricting which systems can communicate with the CDE, segmentation is intended to make lateral movement across a network more difficult, so that a compromise of one zone does not automatically grant access to systems handling cardholder data. It is important to note that segmentation reduces risk rather than eliminates it: its effectiveness depends on the strength and correct configuration of the isolating controls, not on network diagrams or design intent alone.

Under PCI DSS, network segmentation is a technique organizations may choose to use rather than a mandatory requirement. Because connectivity that allows a system to affect the security of the CDE keeps that system in scope, poorly validated or misconfigured segmentation can create a false sense of scope reduction. Readers should confirm segmentation guidance and any scope-reduction expectations against the current published PCI DSS standard, as wording and expectations differ between versions.

Who it's relevant to

Security engineers and network architects
These teams design and implement the segments, subnets, and enforcement points such as firewalls, switches, and routers that create isolation. They are responsible for ensuring the isolating controls actually enforce the intended boundaries, since segmentation effectiveness depends on configuration and validation rather than design intent alone.
Compliance officers and PCI DSS assessors
For those managing PCI DSS assessments, segmentation is relevant because it can affect which systems, people, and processes fall within assessment scope. They should confirm that any claimed scope reduction is supported by validated isolation and check expectations against the current published PCI DSS standard, since segmentation is a technique rather than a mandatory requirement and wording differs between versions.
Merchant risk and infrastructure teams
Organizations handling cardholder data use segmentation to isolate the cardholder data environment from other systems, which can help contain the impact of a compromise by making lateral movement more difficult. These teams should treat segmentation as one part of a defense-in-depth approach that reduces rather than eliminates risk.

Inside Network Segmentation

Cardholder Data Environment (CDE) isolation
The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, which segmentation seeks to separate from the rest of the network. Isolating the CDE is intended to reduce the number of systems that fall within PCI DSS scope.
Connected-to and security-impacting systems
Systems that are not part of the CDE but can connect to it or affect its security (for example, authentication servers, patch or monitoring servers). These remain in scope even after segmentation because they can influence the security of the CDE, and segmentation must account for them rather than assume isolation alone removes them.
Segmentation controls
The technical and procedural mechanisms that enforce separation, such as firewalls, access control lists, VLANs, and network access controls. Their effectiveness depends on correct configuration and validation, not on the presence of the control alone.
Segmentation as an optional practice
Under PCI DSS, network segmentation is not a requirement but a practice an entity may use to reduce scope. Where segmentation is relied upon to limit scope, it must be verified; readers should confirm the exact expectations against the current published version of PCI DSS rather than assuming fixed requirement numbering.
Scope reduction outcome
The intended result of segmentation: fewer systems subject to the full set of PCI DSS controls, which can reduce assessment effort and attack surface. Scope reduction is only achieved when segmentation is effective and demonstrable.
Segmentation validation
Testing intended to confirm that segmentation controls are operating as designed and that out-of-scope networks cannot reach the CDE. This is typically demonstrated through methods such as penetration testing at a frequency defined by the current standard and the entity's risk profile.

Common questions

Answers to the questions practitioners most commonly ask about Network Segmentation.

Does network segmentation reduce PCI DSS scope automatically just because it is in place?
No. Segmentation is not scope-reducing simply because it exists or is labeled as such. To reduce scope, the segmentation must actually isolate the cardholder data environment (CDE) from out-of-scope systems so that a compromise of an out-of-scope system cannot affect the security of the CDE. This isolation must be validated, typically through penetration testing that confirms the controls work as intended. Segmentation that is misconfigured, overly permissive, or unverified does not reliably reduce scope, and any system that can affect the security of the CDE remains in scope regardless of network diagrams.
Is network segmentation a mandatory PCI DSS requirement?
Segmentation is not itself a mandatory requirement; it is described in the standard as an optional method to reduce the size and scope of the CDE, the cost of assessment, and the difficulty of maintaining controls. An entity can choose to treat its entire network as in scope and forgo segmentation. However, if segmentation is used to reduce scope, the standard expects it to be validated and maintained. Confirm the current published standard for exact wording and expectations, as requirement numbering and phrasing differ between versions.
How do we verify that our segmentation is actually effective?
Effectiveness is typically confirmed through segmentation testing, generally as part of penetration testing, to verify that out-of-scope networks cannot reach the CDE and that the isolating controls operate as configured. The intent is to demonstrate that the controls separating in-scope and out-of-scope systems are working. Testing frequency and rigor may differ depending on the entity type and the current standard's requirements, so confirm the applicable expectations against the published version rather than assuming a fixed interval or number.
What kinds of controls can be used to implement segmentation?
Segmentation is commonly achieved through a combination of network and other controls, such as firewalls or equivalent access-control mechanisms, router or switch configurations, VLAN separation combined with enforced access rules, and physical separation. The relevant point is that the controls must enforce isolation, not merely categorize traffic. VLANs alone, for example, do not provide segmentation unless access controls actually restrict traffic between segments. The effectiveness depends on configuration and validation, not on the technology label.
Which systems remain in scope even after segmentation?
Systems remain in scope if they store, process, or transmit cardholder data or sensitive authentication data, if they are on the same network segment as the CDE, or if they can affect the security of the CDE. This last category commonly includes connected systems such as security services, management or monitoring tools, authentication servers, and administrative access paths. Segmentation narrows scope only by removing a system's ability to reach or affect the CDE; a system that retains such connectivity stays in scope regardless of segmentation intent.
How should segmentation be maintained after initial deployment?
Segmentation is not a one-time activity. Network changes, new connections, firewall rule modifications, and added systems can erode isolation over time, so controls should be reviewed through change management and re-verified periodically. Documentation such as current network and data-flow diagrams should reflect the actual environment so that scope can be reassessed when the network changes. Ongoing monitoring of the controls that enforce isolation helps confirm that segmentation continues to operate as intended between validation cycles.

Common misconceptions

Network segmentation is mandatory under PCI DSS.
Segmentation is not a PCI DSS requirement. It is an optional practice used to reduce the scope of the assessment. An entity may choose to treat its entire network as in scope instead, though this is generally more costly and complex.
If a system is on a separate VLAN or segment, it is automatically out of scope.
Placing a system on a separate segment does not by itself remove it from scope. Systems that connect to or can impact the security of the CDE remain in scope, and segmentation must be correctly configured and validated to be relied upon for scope reduction.
Once segmentation is in place, it does not need to be re-checked.
Segmentation can degrade over time due to configuration changes, new connections, or errors. It should be periodically validated to confirm it still isolates the CDE effectively; the specific frequency and method should be confirmed against the current published PCI DSS.

Best practices

Define and document the CDE and all connected-to and security-impacting systems before designing segmentation, so isolation boundaries reflect actual data flows.
Enforce separation with layered controls such as firewalls, access control lists, and VLANs, and verify each is configured to deny traffic between out-of-scope networks and the CDE by default.
Validate segmentation through testing, such as penetration testing, to confirm that out-of-scope segments cannot reach the CDE, rather than assuming isolation from network diagrams alone.
Re-validate segmentation after significant network or environment changes and on a periodic basis, confirming the required frequency against the current published version of PCI DSS.
Maintain current, accurate documentation of segmentation boundaries and data flows so that scope and any reliance on segmentation for scope reduction can be demonstrated during assessment.
Treat scope reduction as a demonstrable outcome, not a label; only claim systems as out of scope where effective, validated segmentation supports that conclusion.