ISO 27001:2022 Annex A 8.22 segregation of networks: zones and goals

The security questionnaire asks you to describe your network segmentation, and the honest answer is "everything can see everything". The deal slows while your team scrambles for a diagram. This guide covers ISO 27001:2022 Annex A 8.22 segregation of networks for IT leaders and network engineers at 25–250-person firms: how to draw three to five zones, enforce them with default-deny gateways and automate the proof.

It also answers the question most guides skip: what goals to set for your network team, so the control becomes sprint-sized work and the evidence builds itself.

What does ISO 27001 Annex A 8.22 require?

ISO 27001 Annex A 8.22 requires you to divide the network into zones by trust level and sensitivity, then enforce what crosses each boundary through a gateway such as a firewall. The control sits beside A.8.20, which secures the network fabric; A.8.22 governs how that fabric is partitioned and policed.

The guidance behind the Annex A control sits in ISO 27002:2022 control 8.22 segregation of networks. In plain English, ISO 27002:2022 8.22 segregation of networks asks for three things:

• Zones by trust level and sensitivity. Internet-facing services, staff devices, servers and anything high-risk each get their own segment.
• A gateway at every boundary. A firewall, filtering router or cloud security-group rule decides what crosses.
• Rules that follow a business need. Traffic crosses only where someone can justify it.

Zoning follows the same logic as your access control policy, applied to network paths instead of people. Which zones you draw, and what each gateway admits, should follow from what the zone actually holds, not from how the network happened to grow. A zone holding customer databases admits far fewer paths than one holding staff laptops.

The control is preventive, and it protects confidentiality, integrity and availability together. Zoning keeps sensitive data out of reach of untrusted segments, stops unauthorised hosts altering critical systems and caps the blast radius when ransomware lands. Boundaries drawn and enforced before an incident are what stop it spreading.

Why does network segregation matter beyond passing the audit?

Segregation limits blast radius. On a flat network, one phishing click gives an attacker reach to every server and database, and recovery is measured in weeks. NCSC guidance says to identify, group and isolate critical business systems, and enterprise questionnaires and cyber insurers ask how you do exactly that.

The NCSC Guidance on Preventing Lateral Movement describes the principle: segregate networks as sets, then apply appropriate network security controls to the critical business systems you have isolated. A compromised laptop is only the starting point. What the attacker can reach from it decides the damage, and zones give the incident edges: a compromised endpoint reaches its own segment and the few paths a gateway admits.

Cyber insurers ask the same question as enterprise buyers, and the answer moves premiums.

With zones, the incident report names one segment, and the questionnaire answer is a diagram, a ruleset and a probe history. Without them, the outage announcement names the company.

Is network segmentation the same as segregation?

No. Segmentation draws the zones; segregation enforces rules on what crosses between them. A VLAN with no inter-VLAN restrictions is segmented but not segregated, and it fails Annex A 8.22. Auditors grade enforcement, not structure, so the control is only met when traffic between zones is actually restricted.

Use the terms precisely and the rest of this guide gets easier. ISO 27001 network segmentation is the drawing: subnets, VLANs, VPCs and the boxes on the diagram. Segregation is the policing, meaning the rules at each boundary that decide which traffic may pass.

The NCSC Network Security Fundamentals page makes the same point: breaking a network into smaller networks is what lets you control how traffic flows and what access is allowed between them. The breaking-up is segmentation. The controlling is what A.8.22 grades.

The common trap is the VLAN estate that looks finished. The switch carries VLANs for staff, servers and guests, but inter-VLAN routing permits everything, so any host still reaches any other. Structure without enforcement scores no points.

Run a quick self-test: pick any two VLANs or subnets and find the rule that restricts traffic between them. If you cannot point to one, the network is drawn but not defended.

How do you implement ISO 27001 segregation of networks with 3–5 zones?

Sort what you run into three to five zones by sensitivity and function: public-facing services, staff endpoints, servers and data stores, and anything high-risk or regulated. A zone per team is over-engineering. Do it after asset and data classification, because you cannot zone by sensitivity you have not assigned.

A workable starting set for a 50-person regulated firm places each asset by its recorded sensitivity and function:

• Public-facing: services reachable from the internet, held in a buffer zone.
• Staff endpoints: laptops, desktops and the corporate wireless.
• Servers and data stores: production systems and the databases behind them.
• High-risk or regulated: systems whose compromise would hurt most, plus administrative access paths.

Decide what each boundary admits by what the zone holds, weighing security gain against cost and performance like any other risk decision. Then write the zoning criteria into a short network security procedure. It should list the zones, what belongs in each, the default rule and who approves an exception, so the design outlives the engineer who built it.

The common failure at this scale is still the flat network: one broadcast domain where any compromised host can reach every server.

Over-zoning is the opposite failure. A dozen micro-domains at 40 people create rule-management overhead that outweighs the risk they treat, and a zone per team multiplies the rule set with every reorganisation. Without a network operations centre, the design has to be small enough for one team to hold in its head and review.

More zones is not more security: rules nobody reviews protect nothing.

Are VLANs and security groups enough, or do you need physical separation?

Logical separation is enough. Cloud VPC or VNet boundaries, subnets and security groups, or on-premise VLANs with firewall rules between them, satisfy the control without separate cabling. What matters is enforcement: a control point at every zone edge, default-deny, a DMZ for internet-facing hosts, and isolated wireless.

Auditors care whether the boundary is enforced, not what it is made of. Four mechanics make it real:

• A control point at every zone edge. A firewall, filtering router or cloud security-group rule defaults to deny, so traffic crosses only where a business need justifies it.
• A DMZ for anything internet-reachable. It is a segment that internet traffic can reach but that cannot talk directly to internal systems. Connections to internal data stores go through a proxy or inspection point.
• Wireless treated as hostile until proven otherwise. Guest Wi-Fi is fully cut off from corporate resources and no more permissive than the staff network, or your own people drift onto it. In sensitive setups, treat all Wi-Fi as external and make it earn its way in through a gateway.
• Extra friction for admin access. Multi-factor authentication and tightly scoped identity roles guard restricted zones, with zero trust (verifying every request on identity and context, not network location) as the direction of travel rather than a day-one purchase.

Two pitfalls recur. DMZ hosts with direct paths into internal systems turn the buffer zone into a stepping stone instead of a barrier. Guest Wi-Fi reaching printers or file shares is the other, usually because isolation was assumed rather than tested. Test it the way an auditor would: from a guest device, try to reach an internal server.

Guest Wi-Fi isolation that has never been probed is an assumption, not a control.

The table below maps each boundary to its construct, enforcement point and exhibit.

How do you automate segregation with Terraform, drift detection and reachability tests?

Define security groups, subnets and firewall rules in Terraform so every boundary change has an author, a review and a rollback. Cloud-posture rules then flag drift from the declared design within minutes, and scheduled reachability probes prove untrusted zones still cannot reach critical hosts. Evidence accumulates as a by-product.

Because the zone design lives in version control, the pull request becomes the change record. The reviewer's approval answers the auditor's question, "why is this port open, and who decided?", before anyone asks it.

The loop runs in five steps:

1. Declare. Zones, security groups and firewall rules reach the main branch only after review.
2. Compare. Cloud-posture rules continuously check deployed rules against the declared design.
3. Probe. Scheduled checks, using cloud-native network analysers or simple probe jobs, try to reach critical hosts from untrusted zones such as guest or staff segments. They should fail.
4. Log. Firewall denies and cross-zone alerts go to central logging so violations surface.
5. Keep. Change tickets, drift alerts and probe results are retained as the evidence pack.

Drift is where good designs quietly die. An engineer opens a rule to debug an incident, means to close it on Friday, and the diagram stops matching reality. With a posture rule watching, that rule becomes a finding that points at the change that introduced it.

Each probe run adds a dated result, so segregation is proven rather than asserted. If the zone design itself is the gap, our cloud security architecture work covers landing-zone segmentation, VPC and subnet design and DMZ patterns on AWS, Azure and GCP, and our GRC engineering service builds the drift-and-probe loop.

What are good ideas for goals for a network team?

Good network team goals are measurable outcomes of the segregation design, not activity counts: every zone edge has a default-deny rule, drift findings are closed within an agreed time, reachability probes pass on schedule, boundary logs reach central logging, and the diagram matches the live rulesets at every review.

Frame each goal as a sprint-sized outcome with an owner, so the team can close it, show it and repeat it. Activity counts such as rules reviewed or tickets closed tell an auditor nothing about whether traffic is actually restricted.

Six goals cover the design:

• Default-deny at every zone edge. Measure the zone edges that carry a default-deny rule against the total. The target is all of them.
• Drift findings closed in an agreed time. The team and the security lead agree the window and record it in the zoning procedure.
• Reachability probes passing on schedule. A failed probe is a finding with an owner, not a note.
• Boundary logs reaching central logging. Firewall denies and cross-zone alerts appear in the logging platform. A silent feed is itself a gap.
• Diagram matching live rulesets. At each review, sample a boundary on the diagram and compare it with the deployed rules.
• Zoning procedure current. The document changes when a zone changes, and training records show that whoever manages the network understands the design.

Pick two or three for a quarter rather than all six. A goal the team cannot move in a sprint belongs in a project plan, not in the quarter's goals.

What evidence pack does Annex A 8.22 need?

Prepare five exhibits: a network diagram showing zones and internet-facing services, the firewall, security-group, VLAN and routing configuration behind it, wireless configuration separating guest from corporate, boundary logs showing denies and cross-zone alerts, and the written zoning procedure with training records for whoever manages the network.

The diagram is the first exhibit an auditor opens and the one that must match reality. Review it against the live rulesets whenever a boundary changes, not in the week before the audit.

Where each exhibit comes from:

• Diagram and configuration. The Terraform history shows who changed each boundary and who approved it.
• Wireless. The guest-to-internal test result sits next to the configuration it proves.
• Boundary logs. Central logging output shows filtered traffic and the alerts raised on cross-zone violations.
• Procedure and training. These are the human exhibits, reviewed on a schedule by a named person.

Drift alerts, change tickets and probe results accumulate on their own, so the pack needs no audit-season assembly. Only the diagram review and the written procedure need a person to keep them current.

What will an auditor test under ISO 27001:2022 Annex A 8.22 segregation of networks?

Auditors take your diagram and test it: they pick a boundary, ask for the live ruleset, or have an engineer show that an untrusted segment cannot reach a critical host. A flat network or guest Wi-Fi routed to internal resources grades major; stale diagrams or undocumented rules grade minor, aggregating to major.

Expect these questions in the room:

• "Where does the guest network end and the corporate network begin?"
• "What sits between your internet-facing services and your production database?"
• "Show me the rules on this boundary: why is this port open, and who decided?"
• "If this laptop is compromised, what can the attacker reach?"
• "Can a device on guest Wi-Fi ping an internal server?"

Diagram-versus-reality drift is the classic catch: a live rule the diagram never mentioned becomes the finding, however sound the rest of the design is.

Certification bodies grade by pattern. An undocumented firewall rule, a stale diagram or a missing alerting feed is a minor on its own, but several together can aggregate to a major. Close each minor before the next surveillance audit, so a pattern never forms.

A reachability history of green ticks turns the auditor's favourite test into routine evidence. The engineer runs a command and shows the result instead of defending an assumption.

Frequently asked questions