Control Definition
The organization must divide its networks into separate domains — grouping information services, users, and information systems by trust level, criticality, and sensitivity — and control what traffic is allowed to cross between those domains.
Control Objective
To break the network into defined security perimeters so that a compromise in one domain cannot spread freely into others, and traffic moves between domains only where the business genuinely needs it to.
What This Really Means
Think of network segregation as the watertight compartments in a ship's hull. A flat network is a ship without bulkheads: one breach below the waterline and everything floods. Segregation builds the bulkheads — separate network domains — and fits each door between them with a lock that opens only for traffic with a documented reason to pass.
In practice the control asks you to do three things. First, define your domains: group systems, services, and users by trust level and criticality. A typical model separates production, corporate user space, development and test, guest access, building systems and IoT (and OT in industrial settings), the network management plane, and an internet-facing DMZ. Second, build the boundaries: VLANs or subnets create the separation, and stateful firewalls or layer-3 controls at every crossing enforce it. Third — and this is where implementations live or die — default-deny the traffic between domains, with every permitted flow documented, justified, and owned. Two zones with an any-any rule between them are one zone with extra paperwork. Wireless deserves explicit treatment: guest Wi-Fi should reach the internet and nothing else, corporate wireless should be treated as semi-trusted and pass through a gateway before touching sensitive segments, and remote access (VPN or ZTNA) should terminate in a controlled landing zone where policy is applied — never flat into the corporate LAN.
If you are cloud-native, do not write this control off as datacenter-era. Your separation of accounts and subscriptions per environment, VPC and subnet design, security groups, network ACLs, and private endpoints ARE your segregation — they just need to be documented as a designed zone model rather than accidental architecture. Micro-segmentation and zero-trust networking are the modern expression of the same idea: shrinking domains from subnets down to individual workloads and identities. The standard does not mandate that maturity, but it is the direction of travel, and high-value segments like payment systems and backup infrastructure are where it pays first.
What auditors treat as the heart of A.8.22 is not the diagram — it is the rules and the proof they hold. A topology slide showing seven zones means nothing if the inter-zone policy is wide open. Expect an auditor (or your penetration tester) to ask the defining question: what can a compromised laptop in the user zone actually reach? Your answer should come from a segmentation test, not from hope.
Why It Matters
Segregation is the control that decides the scale of your worst day. Nearly every major ransomware post-mortem features the same scene: initial access on one unremarkable endpoint, then unobstructed lateral movement across a network with no internal boundaries. Whether that first foothold becomes a contained incident or a company-wide rebuild is determined years earlier, by the network architecture decisions this control governs.
On a flat or weakly segregated network, organizations face:
- •Unlimited blast radius – One phished endpoint can reach servers, databases, backups, and domain controllers in a single hop, and containment options collapse to "unplug everything"
- •Ransomware at machine speed – Encryption and worm-style propagation spread over open SMB, RDP, and admin protocols between segments that had no business talking to each other
- •Untrusted devices beside crown jewels – Guest laptops, personal phones, printers, cameras, and unpatched IoT share a broadcast domain with production systems and inherit a path to them
- •Compliance scope sprawl – Without segmentation every assessment expands to the whole estate; PCI DSS is the textbook case, where segmentation is the primary scope-reduction tool
- •A predictable audit finding – Flat networks and any-any inter-zone firewall rules are among the most common technical nonconformities raised against the network controls
The same boundaries that contain attacks also enable business: a properly fenced OT zone lets the plant connect to analytics without exposing controllers, a guest zone lets visitors work without touching your LAN, and a segregated landing zone lets you integrate an acquisition before you fully trust its network.
Regional Compliance Context
Indian BFSI carries explicit expectations here: RBI's cyber security frameworks and master directions for banks and NBFCs treat segregation of critical systems — payment infrastructure above all — from the general corporate network as a baseline control, and SEBI's CSCRF sets the equivalent expectation for market intermediaries. If you are a regulated entity, mark the regulator-relevant zones explicitly in your ISO zone model so one architecture serves both audits. In the Gulf, entities under Saudi SAMA's cyber security framework face comparable segmentation expectations for critical and payment systems.
For manufacturers and critical-infrastructure operators in both regions, the IT/OT boundary is the segregation decision that matters most: plant networks full of unpatchable controllers should sit behind an industrial DMZ with narrow, one-way flows — a flat IT/OT network turns a commodity phishing incident into a production-line outage.
Implementation Guidance
Map What You Actually Have
Run current-state discovery before designing anything: systems and their criticality, existing VLANs and subnets, firewall rules, wireless SSIDs, remote-access paths, and real traffic flows from NetFlow or cloud flow logs. Reconcile against the CMDB or asset register. The output is a current-state diagram that matches observable reality — you cannot zone what you cannot see.
Design a Target Zone Model
Define domains by trust level and criticality: production, corporate users, development and test, guest, IoT/OT, the management plane, and a DMZ for internet-facing services. Keep the count governable — most mid-size organizations land on five to eight zones. Document the model and the criteria for placing new systems in a network security standard so the architecture survives staff turnover.
Write the Inter-Zone Traffic Matrix — Default Deny
For every zone pair, record the permitted flows: source, destination, ports and protocols, direction, business justification, and owner. Everything not listed is denied. This matrix becomes both the build sheet for your firewall rules and the audit artifact that proves segregation is designed rather than accidental. Review it whenever the zone model changes.
Implement the Boundaries
Create separation with VLANs and subnets, then enforce it with stateful firewalls or layer-3 ACLs at every inter-zone crossing — separation without filtering is cosmetic. In cloud estates, use separate accounts or subscriptions per environment, VPC/VNet and subnet design, and default-deny security groups. Put the network management plane in its own zone, reachable only from admin jump hosts (per A.8.20).
Contain Wireless, Guest, and Remote Access
Map each SSID to its own VLAN. Guest wireless gets internet-only access with client isolation and no route to internal segments. Corporate wireless is treated as semi-trusted, passing a gateway before reaching sensitive zones. Remote access — VPN or ZTNA — terminates in a landing zone where authentication, posture checks, and policy are applied, never directly into the flat corporate LAN.
Micro-Segment Where Risk Justifies It
For crown-jewel workloads — payment systems, PII stores, backup infrastructure — go finer than subnet-level zoning: host-based firewalls, per-service cloud security groups, and identity-based east-west policies in the zero-trust direction. Start with the highest-value segments rather than attempting estate-wide micro-segmentation in one program; partial depth on the assets that matter beats shallow coverage everywhere.
Test, Review, and Control Change
Verify boundaries hold with technical segmentation tests — can a user-zone device reach the database VLAN or the management plane? — at least annually and after major changes, and fold the question into penetration test scopes. Review firewall rules against the traffic matrix quarterly, purging unjustified and expired entries. Route every rule change through change management (A.8.32), with expiry dates on temporary rules.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.22:
Documentation
- Network architecture diagram showing zones, trust boundaries, and inter-zone control points — dated and version-controlled
- Network security policy or standard defining the zone model and the criteria for placing systems in domains
- Inter-zone traffic matrix or firewall rulebase extract demonstrating default-deny with justified, owned exceptions
- Firewall and security-group rule review records with remediation of unjustified rules
- Segmentation test or penetration test reports verifying that zone boundaries hold in practice
Interviews
- Network architect on the zone model, its design criteria, and how new systems are placed into domains
- Firewall or cloud platform administrators on how inter-zone rule changes are requested, approved, and reviewed
- IT support staff on how guest, BYOD, and IoT devices are kept off corporate and production segments
Observations
- Live firewall or cloud security-group configuration compared line-by-line against the documented traffic matrix
- A demonstration that a guest or user-zone device cannot reach production or management segments
- Wireless controller configuration showing separate SSIDs mapped to separate VLANs with guest isolation enabled
Practitioner Insights
The diagram is where segmentation goes to die. A pattern I see constantly: a beautiful seven-zone model on slide four of the security deck, and an any-any rule between corp and production that was added "temporarily" during a migration two years ago and never removed. When I audit this control I do not start with the architecture document — I ask for the rulebase, and I ask what a compromised laptop in the user VLAN could reach right now. Make sure your answer comes from a segmentation test, not from the diagram.
Cloud-first startups regularly tell me segregation is a datacenter control that does not apply to them — while running separate VPCs per environment with default-deny security groups. They already have the control; they never wrote down the intent, so the auditor sees accidental architecture instead of designed segregation. A two-page zone description plus a record of security-group reviews converts what you already built into conformity. The reverse mistake exists too: everything in one default VPC with wide-open internal security groups is a flat network, whatever the cloud branding suggests.
Common Challenges & Solutions
Challenge
The network has grown flat over a decade, and re-segmenting feels like open-heart surgery on a live business.
Solution
Phase it. Carve out the highest-risk zones first — the management plane, backup infrastructure, and guest/IoT — using VLANs and a firewall you almost certainly already own. Run new boundary rules in log-only mode to discover real traffic before enforcing deny. A three-zone network shipped this quarter protects more than a twelve-zone design that never leaves the whiteboard.
Challenge
Nobody knows which inter-system flows are legitimate, so rules cannot be tightened without fear of breaking production.
Solution
Instrument before you enforce. Turn on flow logging — NetFlow, firewall logs in permit-and-log mode, or cloud flow logs — for four to six weeks and derive the actual traffic matrix from observed flows. Confirm the surprises with application owners, then flip to default-deny with documented exceptions, putting expiry dates on anything nobody could explain.
Challenge
Developers and administrators demand broad cross-zone access "to do their jobs", and exceptions steadily erode the boundaries.
Solution
Replace standing broad rules with brokered access: jump hosts or a PAM solution into production and management zones with time-bound, recorded sessions, and per-application ZTNA policies for remote work. Give every remaining exception a named owner and a review date, and let the quarterly rule review purge orphans. The goal is that no human path into a sensitive zone is both permanent and unmonitored.
Challenge
Printers, cameras, access controllers, and plant equipment cannot run agents or take patches, yet they sit on the corporate LAN.
Solution
Treat anything unpatchable as hostile and fence it accordingly. Give IoT and building systems dedicated VLANs with narrow, mostly one-way flows: cameras reach their NVR only, printers are reachable on print ports only, and OT sits behind an industrial DMZ with no direct internet path. Where switches support it, use private VLANs or port isolation so these devices cannot even reach each other.
Challenge
In the cloud, any team can create networks and peerings in minutes, so segmentation drifts as fast as it is built.
Solution
Codify the zone model: landing-zone patterns with separate accounts per environment, IaC modules that ship default-deny security groups, policy-as-code guardrails that block 0.0.0.0/0 ingress and unapproved peering at deploy time, and drift detection that alerts when reality diverges from code. Review cloud network policy on the same cadence as firewall rules — it is the same control in a different syntax.
