Most organisations that have “done” network segmentation completed a project. They didn’t build a capability. The architecture deck shows clean zones, defined trust boundaries, clearly labelled traffic flows between them. The environment on the ground stopped resembling that diagram roughly around the time the project closed out.

This isn’t usually a criticism of the original design. Most segmentation projects are technically sound at the point of delivery. Firewalls are placed where the design called for them. VLANs are configured to spec. Where micro-segmentation policies exist, they usually reflect an accurate read on east-west traffic risk at the moment they were written. The failure happens afterwards, in the months and years the environment keeps changing while the segmentation boundary does not.

Where the drift comes from

New workloads get provisioned into whichever segment is fastest to approve. That’s rarely the one that matches their actual risk profile. A firewall rule opened as a temporary exception for a migration outlives the migration by years, because closing it requires someone to remember it exists and justify the disruption of removing it. A third-party integration gets bridged across a boundary the original design explicitly meant to keep separate, because the alternative held up a delivery deadline.

None of these decisions look reckless in isolation. Each one is a reasonable trade-off made by someone solving an immediate operational problem. The segmentation boundary erodes through the accumulation of many defensible decisions, and nobody is responsible for evaluating any of them against the original design intent.

Cloud environments accelerate this further. A segmentation model built for a relatively static on-premises estate assumes boundaries change infrequently enough that manual review can keep pace. Cloud infrastructure does not behave that way. Workloads spin up and down within minutes. Security groups get cloned from a template that was itself a compromise. Infrastructure-as-code pipelines can quietly reproduce a permissive rule across every new environment the pipeline touches. The velocity that makes cloud infrastructure useful also makes segmentation drift invisible until something forces a closer look.

Why nobody re-certifies it

Segmentation is typically treated as a one-time architecture decision rather than an ongoing control with a named owner. Access is treated differently. Access certification has an owner, a defined cadence, and an audit trail that demonstrates the review actually happened. Segmentation boundaries govern blast radius in almost exactly the same way access governs exposure, but they rarely have an equivalent governance layer sitting over them.

The tooling required to detect segmentation drift is mature and widely available. Network traffic analysis can show what is actually crossing a boundary versus what the design intended to permit. CMDB reconciliation can surface workloads sitting in the wrong zone. Firewall rule audits can flag exceptions that have outlived their justification. None of this is a technical gap. What’s missing in most organisations is a function whose job is to own the outcome: to look at what the tooling surfaces and decide what happens next.

In practice, this function doesn’t need to be large. It needs to exist, be named, and report on a cadence that someone above it actually reads.

What examiners and incident responders both find

Regulatory expectations have started to catch up with this gap. NIS2 and DORA both push toward evidence of network segmentation as a live control, not a design artefact, with testing scoped specifically to lateral movement rather than perimeter penetration alone.

An examiner asking for evidence that segmentation works is asking a different question than an examiner asking whether it was designed correctly. Most organisations can answer the second question. Fewer can answer the first.

Incident responders see the consequence of this gap more directly than examiners do. A recurring pattern in post-incident reviews: segmentation existed on paper and failed in practice. An attacker moved laterally through a boundary that the design documentation still shows as closed. The containment plan assumed a network topology that had not existed for some time. The gap between documented and actual segmentation is rarely discovered proactively. It is discovered during the incident, at the worst possible moment to learn it.

What governance actually requires here

Closing this gap doesn’t require a bigger segmentation project. It requires treating segmentation as a control with the same governance discipline already applied to access: a named owner, a recertification cadence, and evidence that the boundary was checked against reality rather than assumed to still hold. That evidence needs to exist before an examiner or an incident responder asks for it, not stitched together under pressure once one of them does.

Organisations that get this right tend to have quietly moved segmentation out of the architecture function and into the same governance rhythm as identity and access. It’s reviewed on a schedule, owned by a named accountable person, and treated as something that degrades by default unless actively maintained. Architecture teams are generally staffed and incentivised to design and deliver. Sitting above a control indefinitely and answering for its ongoing state isn’t part of that mandate. Placing recertification with the team that built the segmentation is often how it quietly stops happening: the project ends, the team moves to the next design problem, and the boundary is left to look after itself.

A workable model puts the recertification cycle with whichever function already owns periodic control review, often the same team running access certification, with architecture retained as the technical authority consulted when a proposed exception needs a design judgement rather than a governance one. The distinction matters: whether a rule should exist is a risk decision, not an engineering one, and it should be owned accordingly.

None of this requires new tooling in most environments. It requires a decision that segmentation drift is somebody’s job to find, on a schedule, whether or not an auditor or an attacker has asked yet. That reframing costs little relative to the original project. What it buys is a boundary that still matches the diagram the year after the diagram was drawn.