ISO 27001 Network Security: Complete A.8.20–8.22 Guide 2026

ISO 27001 network security is not one control. It is three — A.8.20 Networks security, A.8.21 Security of network services and A.8.22 Segregation of networks — and they sit beside each other in Annex A because they answer three different questions. Most Statements of Applicability collapse them into one line, point at a single document called “Network Security Policy,” and leave two of the three controls with nothing an auditor can sample.

This guide walks ISO 27001 network security the way a stage 2 auditor walks it: what each control actually asks for, the requirements ISO/IEC 27002:2022 states plainly that almost every template skips, which parts carry no documentation obligation at all, and the specific records that close all three controls out.

What ISO 27001 network security requires under Annex A

Annex A of ISO/IEC 27001:2022 (Edition 3, published October 2022, 19 pages, with the free Amendment 1:2024 climate-action change) lists 93 controls across four themes — 37 organizational, 8 people, 14 physical and 34 technological. Three of the 34 technological controls govern the network, and each is stated in a single sentence:

• A.8.20 Networks security — networks and network devices are to be secured, managed and controlled to protect the information in systems and applications.
• A.8.21 Security of network services — the security mechanisms, service levels and service requirements of network services are to be identified, implemented and monitored.
• A.8.22 Segregation of networks — groups of information services, users and information systems are to be segregated in the organization’s networks.

None of the three is new in the 2022 edition. They were renumbered, not rewritten: A.13.1.1 became A.8.20, A.13.1.2 became A.8.21 and A.13.1.3 became A.8.22, and the network trio is absent from the eleven genuinely new controls (A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23, A.8.28). If your 2013 evidence was sound it still is; what changed is the reference number on the Statement of Applicability, which clause 6.1.3 makes mandatory.

The three ISO 27001 network security controls answer three different questions

The fastest way to find the gap in your own ISMS is to read the three controls as three questions with three different owners and three different evidence sets.

Control	The question it answers	Usually owned by	Primary evidence	The common SoA trap
A.8.20 Networks security	Are the network and its devices themselves secured, managed and controlled?	Network or infrastructure operations	Current diagrams, device configuration baselines, hardening records, network event logs	Describing the firewall and calling the control closed
A.8.21 Security of network services	Is what the network service is required to deliver written down, agreed and monitored?	Vendor management, with the network owner	Service agreements naming security mechanisms and service levels, plus monitoring reports against them	Marking it not applicable because the network is run in-house
A.8.22 Segregation of networks	Are groups of services, users and systems actually kept apart from each other?	Network architecture	Domain definitions, gateway rule sets, cross-zone denial logs	Treating the existence of VLANs as proof of segregation

Three questions, three answers. An auditor who asks the A.8.21 question and receives the A.8.20 answer has found a finding, and it is the single most common way ISO 27001 network security comes apart in a stage 2 audit.

Segmentation is not segregation, and an auditor tests the difference

Segmentation is structural: you divide the network into VLANs, subnets, VRFs or virtual networks. Segregation is behavioural: traffic between those divisions is controlled, and the control is enforced. A.8.22 asks for the second. Building the first and stopping is the defect that an hour with a rule export will always expose.

The test is mechanical. Take the diagram, pick two zones it says are separate, and read the rule governing traffic between them. If the rule is an any-to-any permit carrying a comment from a migration four years ago, the network is segmented and not segregated, and the honest SoA position is partial implementation with a remediation date. Auditors are reasonable about a documented gap with an owner and a date; they are not reasonable about an assertion the configuration contradicts.

The guidance’s own vocabulary makes the point: ISO/IEC 27002:2022 frames A.8.22 around dividing the network into domains and then controlling the connections between them at a gateway — a firewall or a filtering router. For ISO 27001 network security purposes, the gateway rule is the control; the VLAN tag is only the arrangement.

The guidance limbs behind ISO 27001 network security under A.8.20

A.8.20 is one sentence in Annex A and roughly fourteen separate considerations in ISO/IEC 27002:2022. Reading them as a checklist is the fastest route to an honest self-assessment, because each limb implies its own record.

A.8.20 guidance limb	Evidence that closes it
Information types and classification levels the network is able to carry	A statement in the network standard tying each zone to a classification level
Responsibilities and procedures for managing network equipment	Named role in the ISMS, change procedure for network devices
Current documentation, including diagrams and configuration files	A dated diagram and a configuration backup store with a retention period
Operational responsibility for networks separated from ICT system operations	An org chart or RACI showing the split, or the documented rationale where headcount makes it impossible
Controls safeguarding confidentiality and integrity over public, third-party and wireless networks	Encryption-in-transit standard and the enforcement record
Logging and monitoring of security-relevant network actions	Log sources list, retention, and evidence someone reviews them
Coordination of network management activities	Change records covering both network and system changes
Authentication of systems on the network	802.1X or equivalent configuration, certificate inventory
Restricting and filtering connections through firewalls	Rule base with business justification per rule
Detecting, restricting and authenticating equipment connections	NAC policy, port-security configuration, rogue device alerts
Hardening of network devices	A baseline per device class and a compliance report against it
Separation of network administration channels from other traffic	Management VLAN or out-of-band network, jump host access records
Temporary isolation of critical subnetworks if the organization is under attack	A pre-authorized isolation procedure naming who may invoke it
Disabling vulnerable network protocols	A disabled-protocol list and a scan confirming they are absent

Read against that list, the usual SoA justification for ISO 27001 network security — “perimeter firewalls are in place and managed” — answers one limb out of fourteen. The point of the exercise is not to produce fourteen documents. It is to know which limbs you have decided not to implement, so that your Annex A control decisions are deliberate rather than accidental.

The management plane is a stated requirement, not an advanced option

One A.8.20 limb deserves singling out because benchmarks treat it as advanced practice while ISO/IEC 27002:2022 states it flatly: network administration channels should be separated from other network traffic. In plain terms, you should not be able to reach the switch management interface from the same VLAN that carries a laptop browsing the web.

Compare that with CIS Controls v8.1, where the equivalent safeguard — 12.8, dedicated administrative computing resources, physically or logically separated, segmented from the primary network and denied internet access — sits in Implementation Group 3, the most mature tier. The standard asks for the separation at every maturity level; the benchmark treats the fully built version as a late-stage project. The middle ground that satisfies A.8.20 for most organizations is a dedicated management VLAN reachable only through a jump host with its own authentication, plus access records showing who connected and when.

NIST SP 800-53 Rev. 5 carries the same idea at SC-7(15) Networked Privileged Accesses, which routes privileged network access through a dedicated managed interface. If your SoA justification for ISO 27001 network security says nothing about the management plane, that is the gap worth closing first, because it is the one with the largest blast radius when it fails.

A.8.21 applies to your own network team, not just your ISP

A.8.21 is the control most often marked not applicable, and the reasoning is almost always the same: we do not outsource our network, so there is no network service provider. That reading does not survive contact with the guidance. ISO/IEC 27002:2022 applies A.8.21 to network services provided internally as well as to outsourced ones. An internal network team is a service provider to the rest of the business, and the control asks the same three things of it.

Those three things are worth separating, because they fail independently:

• Rules on who may use which service. Which networks and services may be accessed, authentication requirements, authorization procedures, the means of access (VPN, wireless), user attributes such as time or location, and monitoring of use. This overlaps heavily with your access control policy and should cross-reference it rather than repeat it.
• Security features of the service itself. The authentication, encryption and connection-control technology in use, the technical parameters that make a connection secure, and caching behaviour where confidentiality requirements apply.
• Agreed service levels and service requirements. The security mechanisms, service levels and service requirements the service is expected to deliver, recorded in an agreement — a contract and SLA for an external carrier, or an internal service definition for your own team.

The agreement limb is where the audit trail usually stops. NIST SP 800-53 Rev. 5 states the equivalent requirement precisely: CA-3 Information Exchange — renamed from “System Interconnections” in Rev. 5 — requires that each exchange agreement document the interface characteristics, the security and privacy requirements, the controls, the responsibilities of each party and the impact level of the information communicated, and that the agreements be reviewed and updated at a defined frequency. That is a usable template for an A.8.21 record whether the counterparty is a carrier or your own infrastructure group.

If you truly take no network service from anyone — no internet transit, no SD-WAN, no cloud interconnect, no managed Wi-Fi, no internal network function anyone depends on — A.8.21 can be excluded. That organization does not exist, and an exclusion here invites the auditor to go looking.

How to choose domains for ISO 27001 network security under A.8.22

A.8.22 does not prescribe your zones; it gives you the basis for choosing them. The guidance offers two approaches that can be combined: group by sensitivity and criticality — public-facing, end-user, server, high-risk systems — or group by business function, such as finance, HR and engineering. Both are defensible. A zone list nobody can explain the logic of is not.

Once the domains exist, the control moves to the boundary between them. The guidance asks you to evaluate the security requirements of each domain when you set up the separation and when you grant access through a gateway, consistent with your access control policy, your classification scheme and the cost of the technology involved.

The limb most pages omit is the wireless carve-out. Because the perimeter of a wireless network is imprecise by nature, the guidance tells you that for sensitive environments you should treat all wireless access as an external connection and keep it away from internal networks until the access has passed gateway controls. That single sentence turns the common corporate pattern — a single SSID bridged straight onto the user LAN — into a non-conformity in any estate with sensitive internal domains. The conforming pattern is a wireless network that terminates outside the trusted zone and is admitted inward only through the same gateway an external connection would use.

NIST SP 800-53 Rev. 5 offers three enhancements that map almost one-to-one onto A.8.22, and naming them in your documentation makes the architecture easier to defend: SC-7(21) Isolation of System Components, which isolates components supporting different missions or business functions; SC-7(22) Separate Subnets for Connecting to Different Security Domains; and SC-7(29) Separate Subnets to Isolate Functions. SC-7 itself requires, at item (b), that subnetworks for publicly accessible components be physically or logically separated from internal networks — which is the DMZ requirement stated as a control rather than as a design convention.

The isolation capability ISO 27001 network security asks you to pre-authorize

Buried in the A.8.20 guidance is a requirement that reads like an incident response task: the ability to temporarily isolate critical subnetworks if the organization comes under attack. It is a capability requirement, and capability means three things — a technical route to the isolation, a named authority who may order it, and a record of the decision.

Most organizations have the first and none of the rest. The question that exposes it is simple: at 02:00 on a Sunday, who is allowed to disconnect the manufacturing segment, and what is the evidence that the decision was made by someone entitled to make it? If the honest answer is that the on-call engineer would decide and tell someone on Monday, the limb is unmet regardless of how capable the firewall is.

NIST SP 800-53 Rev. 5 names the capability at SC-7(20) Dynamic Isolation and Segregation. Pair it with your incident response procedure and your malware protection response path, where the containment decision is the same decision under a different trigger. One page naming the thresholds, the authority and the notification list is enough, and it closes two controls at once.

What CIS Controls v8.1 says ISO 27001 network security needs at each tier

ISO 27001 is deliberately silent on how much network security is enough; it points you back at your own risk assessment. When you need an external yardstick to justify a proportionate implementation, CIS Controls v8.1 Control 12, Network Infrastructure Management, is the most useful one because it tiers its eight safeguards by organization size and maturity.

Safeguard	What it asks for	Asset type	Implementation Group
12.1	Ensure network infrastructure is up to date	Network	IG1
12.2	Establish and maintain a secure network architecture addressing segmentation, least privilege and availability	Network	IG2
12.3	Securely manage network infrastructure, for example version-controlled infrastructure-as-code and secure protocols	Network	IG2
12.4	Establish and maintain architecture diagrams	Documentation	IG2
12.5	Centralize network authentication, authorization and auditing	Network	IG2
12.6	Use secure network management and communication protocols	Network	IG2
12.7	Ensure remote devices use a VPN and connect to enterprise AAA infrastructure	Devices	IG2
12.8	Maintain dedicated, separated computing resources for all administrative work	Devices	IG3

That distribution answers the proportionality question better than any consultant will. Exactly one of the eight safeguards — keeping network infrastructure current — sits in IG1, the tier CIS defines as essential cyber hygiene for every organization. Segmentation appears at IG2, the fully separated administrative estate at IG3. A 20-person company running a flat network on patched, supported devices is not failing a recognized hygiene floor — but it is obliged to say so in its SoA justification and to show the risk assessment behind the decision. That is ISO 27001 network security working as intended: risk-based, not prescriptive.

The review frequencies ISO 27001 network security never sets

Nowhere in A.8.20, A.8.21 or A.8.22 does the standard state a frequency. There is no annual firewall rule review requirement in ISO 27001 network security, no quarterly diagram refresh and no mandated re-validation of segmentation. The guidance says only that documentation should be current and services should be monitored.

That silence is an opportunity, not a loophole. You set the interval, justify it from risk and rate of change, and the auditor tests you against your own figure. Annual rule-base review with change-triggered diagram updates is defensible. What fails is a policy claiming quarterly reviews with two years of no evidence.

ISO 27001 network security evidence an auditor will ask for

Request	What passes	What fails
Show me your network	A dated diagram showing zones, gateways and external connections, matching reality	A diagram with a date before the last office move or cloud migration
Show me the rule between these two zones	A rule set with a business justification and an owner per rule	An any-to-any permit with a migration comment
Show me the agreement for this network service	A contract or internal service definition naming security mechanisms and service levels	An invoice, or “it is our own team”
Show me how you monitor the service against it	Availability and security reports reviewed by a named role	A dashboard nobody has opened
Show me how network devices are hardened	A baseline per device class plus a compliance report	“They came configured by the vendor”
Show me who may isolate a segment under attack	A procedure naming the authority, thresholds and notification list	An assurance that the on-call engineer would handle it
Show me how administrators reach network devices	Management VLAN or out-of-band path with jump host access records	Admin access from the general user network

Nothing on that list is exotic, and most of it already exists somewhere in an infrastructure team’s tooling. The work of ISO 27001 network security is rarely building new controls; it is getting existing configuration into a form a third party can read and a named person has signed.

Is a network security policy a mandatory document?

No. A.8.20, A.8.21 and A.8.22 name no documented information and set no retention requirement, so a standalone network security policy is not one of ISO 27001’s required documents. Our breakdown of the mandatory documents lists seven documents and six categories of records, and a network policy is in neither list.

There is one near-exception. The A.8.20 guidance explicitly asks for current documentation including network diagrams and device configuration files — as close as Annex A comes to naming an artifact, and CIS reinforces it at safeguard 12.4. Whatever else you skip, keep the diagram current: it is the first thing every auditor asks for and the document that makes every other answer credible. Many organizations carry their ISO 27001 network security rules as a section inside an existing configuration standard rather than as a document nobody owns.

Mapping ISO 27001 network security to NIST SP 800-53 Rev. 5

If you report to a customer or regulator in NIST terms, this crosswalk saves rewriting the same control twice.

Annex A control	NIST SP 800-53 Rev. 5	What the NIST control adds
A.8.20 Networks security	SC-7 Boundary Protection; CM-7 Least Functionality; AU-6 Audit Record Review	SC-7 requires monitoring and control at external and key internal managed interfaces, not only at the perimeter
A.8.20 (management plane)	SC-7(15) Networked Privileged Accesses	Routes privileged network access through a dedicated managed interface
A.8.20 (isolation under attack)	SC-7(20) Dynamic Isolation and Segregation	Names the on-demand isolation capability as a control in its own right
A.8.21 Security of network services	CA-3 Information Exchange; SA-9 External System Services	Specifies exactly what an exchange agreement must document and that it must be reviewed
A.8.22 Segregation of networks	SC-7(21), SC-7(22), SC-7(29); AC-4 Information Flow Enforcement	Separates isolation by mission, by security domain and by function into distinct requirements
All three, deny-by-default posture	SC-7(5) Deny by Default — Allow by Exception	Makes the default-deny stance explicit rather than implied

For architecture rather than control language, NIST’s SP 800-215, Guide to a Secure Enterprise Network Landscape (November 2022) is the better free reference. It examines the limits of perimeter-based network access and works through zero trust network access, software-defined perimeter and SASE as responses — useful when your ISO 27001 network security plan has to survive a workforce that is mostly off-network. It pairs with SP 800-207 on zero trust architecture, published in August 2020.

A 30-day plan for ISO 27001 network security

Days	Action	What you end up with
1–5	Redraw the diagram from the live configuration, not from the last version	A dated diagram that matches reality, and a list of surprises
6–10	Export the rule base and test two zone pairs the diagram claims are separate	An honest segregation position for the SoA
11–15	Write the A.8.21 service definition for each network service, internal ones included	Agreements naming security mechanisms and service levels
16–20	Document the management path and close any admin access from the user network	The highest blast-radius gap shut
21–25	Write the isolation procedure: thresholds, authority, notification	The A.8.20 capability limb evidenced, and incident response improved
26–30	Split the SoA justification into three, one per control, with dates for anything partial	Three defensible positions instead of one assertion

ISO 27001 network security FAQ

Do we need a separate policy for each of A.8.20, A.8.21 and A.8.22?

No. One network security standard can cover all three as long as the three requirements are visibly answered inside it and the SoA points at the right sections. What you should not do is write one paragraph and claim it satisfies all three, because the evidence sets differ.

Is cloud networking in scope for ISO 27001 network security?

Yes, and cloud is usually where the segregation story is strongest and the documentation weakest. Virtual networks, security groups, subnets and peering are network controls, and a provider console export is perfectly good A.8.22 evidence. The shared responsibility boundary belongs in your A.8.21 service definition.

Does ISO 27001 network security require zero trust?

No. Zero trust is an architecture, not a requirement, and the standard names neither it nor any other design. A zero trust programme can be an excellent way to satisfy A.8.22, and so can a well-governed set of VLANs and firewalls. Choose on risk and record the reasoning.

Can we exclude A.8.22 if we have a flat network?

You can exclude any Annex A control provided the SoA justification holds up, but for A.8.22 the honest version is rare: if you hold data of differing sensitivity, or run guest or OT devices, the risk assessment usually drives you to some separation. Partial implementation with a dated plan is a stronger position than exclusion.

How often must firewall rules be reviewed under ISO 27001?

The standard sets no frequency. You define it, justify it from risk and change rate, and then meet the figure you set. Annual review with change-triggered updates is a common pattern that auditors accept.

Does the auditor test our network during the audit?

No. Auditors do not scan or attack your network. They sample records and configuration exports, and they compare your documents to what the configuration says. A current diagram, a justified rule base and a signed service definition answer more of ISO 27001 network security than any penetration test report.

Where to start

Split the one line in your SoA into three. Redraw the diagram from live configuration this week, test two zone pairs against the rule base next, write a service definition for your own network team even though they are internal, and close the path that lets administrators reach network devices from the user LAN. Those four actions evidence more of ISO 27001 network security than any new appliance, and they are the four things an auditor will ask about first.

If you want the documentation layer already built, our ISO 27001 Toolkit ships 165 editable templates covering the full ISMS — Statement of Applicability, risk register, Annex A control procedures and the audit records that go with them — for $149, so the writing is done and the work left is the implementing.