---
title: "ISO 27001:2022 Annex A 8.22 segregation of networks: zones and goals"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-22-segregation-of-networks
published: 2023-07-24
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.22 Segregation of networks"
journeyStage: implementation
---

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

## Key takeaways

ISO 27001:2022 Annex A 8.22 requires a network divided into zones by trust level and sensitivity, with gateways enforcing what crosses each boundary. Three to five zones, default-deny rules and Terraform-managed boundaries meet the control for 25–250-person firms. Measurable team goals and automated reachability probes turn audit evidence into a by-product.

- **Zone count** — Three to five zones suits most small and mid-sized firms: public-facing, staff endpoints, servers and data stores, and high-risk systems. A zone per team is over-engineering.
- **Segmentation versus segregation** — Segmentation draws the zones. Segregation enforces rules on what crosses between them. A VLAN without inter-VLAN restrictions is segmented but not segregated, and fails the control.
- **Default-deny gateways** — A control point sits at every zone edge, whether firewall, filtering router or cloud security-group rule. Traffic crosses only where a business need justifies it.
- **Evidence by-product** — Auditors open the network diagram first and test it against live rulesets. Terraform history, drift alerts, reachability probe results and boundary logs build the evidence pack as a by-product.

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](https://www.ncsc.gov.uk/guidance/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](https://www.ncsc.gov.uk/guidance/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.

| Boundary | Construct | Enforcement point | Exhibit |
| --- | --- | --- | --- |
| Cloud workloads | VPC or VNet, subnets | Security-group rules, default deny | Security-group definitions and Terraform history |
| On-premise networks | VLANs | Firewall rules between VLANs | VLAN assignments, rulesets and routing rules |
| Internet-facing hosts | DMZ | Proxy or inspection point before internal data stores | Diagram and rules showing no direct internal path |
| Wireless | Separate guest and corporate networks | Gateway; guest no more permissive than staff | Wireless configuration and guest-to-internal test result |
| Admin access | Restricted zones | MFA and scoped identity roles | Role definitions and MFA settings |

## 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

### Does A.8.22 still apply if we run fully in the cloud?

Yes, and the cloud makes it easier because the machinery already exists. The risk is default-open wiring between services that nobody designed. Expect the auditor to ask which workloads can reach the production database, and have the security-group definitions ready to answer.

### Is guest Wi-Fi really an A.8.22 audit issue?

Yes, and it is one of the cheapest checks an auditor can run. Guests should reach the internet and nothing of yours, including printers, file shares and the admin pages of your own network kit. Keep the dated result of your own test in the evidence pack and repeat it after any wireless change, such as a new access point or guest network.

### How long does A.8.22 take to implement in a cloud-native firm?

Typically one to two weeks of engineering, because the work is zone design and closing default-open rules rather than buying new kit. Do it early, before the network hardens into architecture debt. Retrofitting segmentation onto a network that has grown flat is a genuine project, with its own plan and budget.

### How does A.8.22 relate to the access control policy in A.5.15?

The access control policy decides who may reach what; A.8.22 applies that reasoning to network paths. Reference the policy from your zoning procedure so zone rules and access rules cannot contradict each other. When a new system arrives, its access rules and its zone are then decided together.

### Does zero trust replace network segregation under A.8.22?

No. [NIST SP 800-207 Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) assumes no implicit trust is granted to assets or user accounts based solely on physical or network location. That removes trust from the network; it does not remove the zones auditors test. Keep the default-deny gateways and add identity and context checks on admin paths first.