Most damaging incidents are not one compromise - they are one compromise followed by unrestricted movement. An attacker lands on a laptop through a phishing email and reaches the database because nothing between the two said no. Segmentation is the control that changes the second half of that sentence.
Two benefits, one of which pays for it
The security benefit is containment: an intruder in one zone cannot reach another without crossing a control point that can block, log or alert. It converts a breach into an incident.
The benefit that usually funds the work is scope reduction. Compliance scope follows the systems that store, process or transmit the regulated data - and anything that can reach them. Segment properly and your PCI DSS cardholder data environment might be twenty systems rather than the whole network. That is a direct reduction in assessment cost, control burden and evidence volume, every year.
Segmentation is one of very few controls with a clear return that a finance function recognises: it makes the recurring audit smaller. The security value is real, but the scope argument is the one that gets it funded.
Where to draw the lines
Segment by trust level and function, not by office floor or historical accident:
- Regulated data environments - cardholder data, health records, personal data at scale. Tightest controls, smallest possible footprint.
- Production vs non-production. Development and test environments are less controlled and frequently contain copies of real data; they should not reach production.
- End-user devices vs servers. Users get phished; servers should not be one hop away.
- Management and administrative networks - hypervisors, network devices, backup infrastructure. Reachable only from dedicated administrative paths.
- Operational technology, kept firmly away from corporate IT.
- Guest, IoT and unmanaged devices - printers, cameras, building systems. Rarely patchable and frequently the initial foothold.
- Third-party access, confined to exactly what the supplier needs.
Know exactly what is in scope
GRC Copilot ties your asset inventory to the controls and frameworks each system falls under - so scope decisions are documented, defensible and easy to re-evidence.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Segmenting an existing network
Nobody gets to start clean. A workable sequence:
- Map actual traffic first. Not the documented architecture - the real flows. Assumptions about what talks to what are wrong more often than not, and this step alone usually surfaces surprises.
- Start with one high-value zone rather than redesigning everything. The regulated data environment is the natural first candidate because it carries the scope benefit.
- Deploy rules in monitoring mode before enforcing. Log what would have been blocked, review it, then enforce. This is what prevents the outage that gets the whole programme cancelled.
- Default deny between zones, with explicit allowances. Default allow with exceptions decays into no segmentation within a year.
- Control the crossing points - inspection, logging and alerting where zones meet. A boundary nobody watches is a boundary that fails silently.
- Extend to cloud. Security groups, network policies and private endpoints are the same discipline in different vocabulary.
Microsegmentation and its cost
Microsegmentation applies policy per workload rather than per network zone, so two servers on the same subnet can be prevented from talking. It is the strongest form available and pairs naturally with zero-trust architectures.
The honest caveat: it requires accurate knowledge of application dependencies, and it generates significant policy volume to maintain. Organisations that adopt it before they can map their own traffic tend to end up with permissive rules that provide the appearance of segmentation without the substance. Coarse segmentation done properly beats fine segmentation done aspirationally.
Proving it works
Segmentation is asserted far more often than it is verified. Auditors - and PCI DSS explicitly - expect testing:
- Segmentation testing from outside each zone, attempting to reach inside it. Annually at minimum, and after significant network changes.
- Firewall rule review at least twice yearly, removing rules that are expired, duplicated or overly broad.
- Current network diagrams showing zones and data flows - and these must match reality, which is where the finding usually lands.
- Change records for rule modifications, showing approval.
The most common failure is rule sprawl: a temporary any-any rule added during an incident three years ago, still present, quietly connecting two zones that the diagram shows as separate.
Frequently asked questions
Are VLANs sufficient?
VLANs separate broadcast domains; they do not enforce policy by themselves. Segmentation requires filtering between them - VLANs with unrestricted routing are not segmentation.
How much scope reduction is realistic?
For PCI DSS it is often dramatic - from an entire network to a few dozen systems. The saving recurs every assessment cycle, which is what makes the business case.
Does zero trust replace segmentation?
It extends it. Zero trust removes implicit trust inside a zone as well as between zones; network segmentation remains a layer within that model, not a competing one.
How often should segmentation be tested?
Annually as a baseline, more frequently for high-risk environments, and after any significant network or firewall change.
Key takeaways
- Segmentation contains breaches and shrinks compliance scope - the second funds the first.
- Map real traffic before drawing boundaries; documented architecture is usually wrong.
- Deploy in monitoring mode, then enforce default-deny between zones.
- Test segmentation and review rules - unverified segmentation is an assertion, not a control.