--- title: "ISO 27001 Annex A 8.20: secure and segregate networks for audit" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-20-network-security published: 2023-07-19 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.8.20 Networks security" journeyStage: implementation --- # ISO 27001 Annex A 8.20: secure and segregate networks for audit ## Key takeaways ISO 27001 Annex A 8.20 asks you to run networks as a managed asset across office kit, cloud VPCs and MSP arrangements. At 25–250 staff, VLANs, security groups and a ticketed rulebase meet it without enterprise tooling. Auditors compare your diagram with a scan, trace firewall changes to tickets and test whether you can isolate a segment. - **Control scope** — Annex A 8.20 requires networks to run as a managed asset: named owner, current diagrams, hardened devices, filtered connections, separate admin traffic and the ability to isolate a segment. - **Cloud estates** — Cloud VPCs, subnets and security groups are the network for cloud-first firms. Auditors test them directly, so a diagram that stops at the office door is a finding. - **Segmentation test** — Three or four zones cover most firms: guest, corporate users, servers and management. The test is blast radius, meaning what one compromised laptop can reach. - **MSP accountability** — Delegating operations to an MSP never delegates accountability. Keep the contract, a written responsibility split and evidence that someone internal reviews the MSP's changes and access. The customer's security questionnaire asks for your network diagram and how you segment. The diagram dates from your Stage 1 audit, and the firewall holds rules nobody can explain. This guide covers ISO 27001 Annex A 8.20 for 25–250-person firms: what the control requires, how to secure and segregate networks across office, cloud and MSP, and what auditors sample. It is written for IT leads, security managers and compliance owners who need VLANs, security groups and discipline, not enterprise micro-segmentation suites. You will leave with a build order, an evidence list and the questions the auditor will ask. ## What does ISO 27001:2022 Annex A 8.20 network security require? ISO 27001:2022 Annex A 8.20 network security requires networks to be run as a managed asset: a named owner, current diagrams and device configurations, hardened and authenticated devices, filtered connections, disabled weak protocols, separate admin traffic, and the ability to isolate a compromised segment. Cloud VPCs and software-defined networks are in scope, not exempt. The control's 2022 title is "Networks security". It reads less like a demand for new kit than a list of habits a good IT lead already wants: someone responsible, records that are current, and the ability to act when a segment is under attack. Read as a working list, the control asks for six things: - **An owner.** One named person, or an MSP under contract, accountable for the network. - **Current records.** Diagrams and device configurations that match what is deployed. - **Hardened, authenticated devices.** No default credentials, and devices prove themselves before joining. - **Filtered connections.** Firewalls permit only needed flows, with weak protocols switched off. - **Separate admin traffic.** Management kept apart from user traffic. - **Isolation.** The ability to cut a compromised segment loose. If you already run VLANs, a firewall with change tickets and an MFA-protected cloud console, you are most of the way there. The remaining work is writing it down and proving it holds. The 2022 revision replaced 13.1.1 in the 2013 standard and spelled out the practical parts: device visibility and authentication, firmware records, traffic filtering, cutting off vulnerable protocols and isolating segments under attack. Virtual networks get the same treatment, so auditors increasingly test the cloud side directly. 'We have no network' is not an answer in a cloud estate; it is a finding waiting for a sample. ## How does A.8.20 anchor A.8.21, A.8.22, A.8.24 and A.8.16? A.8.20 is the parent of a small control family. A.8.21 covers the security of network services, A.8.22 the segregation design itself, A.8.24 the use of cryptography, including encryption in transit, and A.8.16 the monitoring that makes network events visible. A.8.20 sets the managed baseline; the others each deepen one part of it. Segmentation is the thread that ties the family together. The [NCSC Network Security Fundamentals guidance](https://www.ncsc.gov.uk/guidance/network-security-fundamentals) describes it as breaking a network into smaller networks, so you control how traffic flows and what access is allowed between them. A.8.22 asks for that separation to be designed; A.8.20 asks that the network is managed well enough for the design to hold. Use the family as a build map: - **A.8.21, security of network services:** the ISO 27001 Annex A security of network services you consume from carriers, MSPs and cloud providers. - **A.8.22, segregation:** the zones and boundaries, covered in the segmentation section below. - **A.8.24, use of cryptography:** the rules behind TLS and IPsec on anything crossing untrusted space. - **A.8.16, monitoring:** syslog and flow data landing somewhere watched, so brute-force attempts and odd traffic surface. Asset management work feeds A.8.20, and the monitoring build consumes it. That is why the diagram and the inventory sit upstream of everything else in the family. ## Why does a flat network turn one compromised laptop into a breach? Without segmentation, a compromise in one area can quickly spread to others, as [NCSC guidance on limiting disruptive cyber attack impact](https://www.ncsc.gov.uk/collection/disruptive-cyber-attacks/reducing/3-limiting-compromise-impact) states. For 25–250-person firms the usual causes are unglamorous: unsegmented guest Wi-Fi, firewalls on factory credentials, and internet-exposed management ports. Each surfaces in hours during a penetration test or customer security review. The [NCSC Secure design principles](https://www.ncsc.gov.uk/collection/cyber-security-design-principles) frame the answer as design: assume an attacker gets a foothold, then make the next step as hard as possible. A flat network does the opposite. One machine falls, the topology is open, and the attacker walks sideways to everything else. Three exposures account for most of the damage at this size: - **Guest Wi-Fi bridged to production.** Visitors' phones and contractors' laptops share a broadcast domain with servers. - **Firewalls on factory credentials.** The published default login is the first thing anyone tries. - **Management ports open to the internet.** Remote-administration interfaces answer to anyone who finds them. The commercial stakes follow. Cyber Essentials checks the firewall and default-password basics, and segmentation is a standing question on insurer proposals and client due diligence. Containment is the second cost. An incident you cannot contain because you cannot isolate a segment can turn a bad day into a notifiable one. In a cloud-first firm the network has not disappeared; it has become configuration, and configuration is one careless change from public. The next sections remove the flat network, one zone and one control at a time. ## How do you implement ISO 27001 Annex A 8.20 step by step? Implement ISO 27001 Annex A 8.20 in this order: draw the real network and keep the diagram under change control, name an accountable owner, then harden devices against a recorded baseline. Hardening and MFA on management access are week-one moves; diagram and ownership come before everything else because every later step assumes them. This is the order we give a 50-person regulated firm: 1. **Draw the network you actually have.** Include the office, cloud VPCs, VPN paths and SaaS edges. An hour with a whiteboard beats a stale Visio nobody trusts. Store the result where change control can reach it. 2. **Name an owner.** In most firms this size that is the IT lead or an MSP under contract. Either works, provided the accountability and procedures are written down. The MSP section below covers supervision. 3. **Harden devices and their cloud equivalents.** Remove default credentials, take management interfaces off the internet, and disable Telnet, plain HTTP and FTP. Patch firmware on a cadence. 4. **Record a baseline per device.** The baseline is what makes drift detectable and a configuration export comparable. 5. **Put MFA on every management login.** That covers network devices, the VPN and the cloud console. Auditors ask for the diagram first because it predicts everything else. A dated diagram that includes the cloud side tells them the network is really managed. A missing one tells them the opposite before they open a single device. The pitfall is the diagram drawn for Stage 1 and never touched again. The first scan contradicts it, and every other artefact you present inherits the doubt. A network diagram nobody has compared with a scan is a drawing, not evidence. Invert the habit by treating the diagram as a controlled document. Every firewall or cloud change ticket asks whether the diagram changes, and a scheduled comparison against a scan is logged. The diagram then stops being an audit-week chore and becomes the first thing you can show. ## How much network segmentation is enough at 25–250 staff? Three or four zones cover most firms at this scale: guest, corporate users, servers or production, and management. The test is blast radius: if one compromised laptop can reach everything, you do not have enough. VLANs in the office and separate VPCs or subnets with security groups in the cloud deliver the control without enterprise micro-segmentation suites. The zones follow a simple logic. Guest and IoT traffic stays away from corporate, user devices stay away from servers and production, and your most sensitive systems sit behind a boundary of their own. Between zones, default to deny and open only the flows a named system needs. Around the zones, the rest of the build is six moves: - **Separate the admin path.** Use a management VLAN or bastion route over SSH or HTTPS, so admin traffic never shares the user network. - **Encrypt what crosses untrusted space.** TLS for application traffic, IPsec or equivalent for site links, and a deliberate look at wireless and third-party paths, where unencrypted traffic usually hides. - **Change-control the rulebase.** Every firewall and routing change has a requester, an approver and a record. - **Send telemetry to central monitoring.** Syslog and flow data go to the A.8.16 build. - **Control what joins.** Authenticate devices onto the network and scan periodically for hardware nobody recognises. - **Pre-plan containment.** Write down how you would isolate a segment or kill a protocol before you need the steps at 2am. Most failures here are habits rather than missing tools. Administration over the user network, unencrypted and without MFA, hands an attacker the path pre-built. Syslog from devices that nothing collects means detection exists only in theory. Give emergency changes the same record as planned ones. A rule added during an outage and never reviewed is how carefully designed boundaries rot. An emergency firewall rule with no expiry is a permanent rule nobody approved. The cloud needs the same discipline. Security groups left wide open "temporarily" and VPC peering nobody maps are the cloud's version of the stale rulebase, and a diagram that stops at the office door hides both. Resist enterprise-sized projects. Micro-segmentation platforms and NAC suites are products a 40-person firm will never run. VLANs, security groups and discipline deliver the control, and the evidence is the same either way: zones that hold under a scan. At this scale, four zones, one admin path and a ticketed rulebase satisfy both auditors and enterprise customers. ## Who is accountable for A.8.20 when an MSP runs your network? You are. An MSP can run day-to-day network operations, but ISO 27001 accountability stays with the certificate holder. Auditors expect the contract, a written split of responsibilities, and evidence that someone internal reviews the MSP's changes and access. A contract alone is not supervision. Auditors look hard at MSP access, because an MSP's admin accounts can reach every device and cloud console you own. Supervision evidence is what shows that reach is controlled. Build the supervision trail from four artefacts: - **The contract,** naming the network services the MSP runs. - **A written responsibility split** in the network security procedure: what the MSP owns and what stays in-house. - **Internal approval of changes.** A named person at your firm approves each firewall or routing change, and the ticket shows it. - **An access review.** The MSP's admin accounts, VPN access and cloud console roles are listed, MFA-protected and checked by someone internal. In most firms this size the IT lead is both owner and reviewer, which is fine provided the review leaves a record. Ask the MSP for configuration exports and scan results too. They are your evidence even when their staff produce them. ## How does network policy as code automate A.8.20 evidence? Network policy as code keeps security groups, firewall rules and segmentation in infrastructure-as-code, so each boundary change is a reviewed pull request and the approval trail writes itself. Scheduled drift checks, exposure scans and API-generated topology maps then turn the audit's favourite questions into standing, ticketed answers. Four mechanisms do the work: - **Boundary changes as pull requests.** The reviewer and the merge are the approval record. - **Drift detection.** Scheduled checks diff live rules and device configurations against the recorded baselines, and alert on the out-of-band change before an attacker or auditor finds it. - **Exposure scanning as a control loop.** Continuous checks for internet-exposed management ports, open storage and permissive rules turn "is anything gaping?" into a standing answer with a ticket attached. - **The living diagram.** Cloud APIs generate the topology map on demand, so the artefact auditors always find stale becomes a build output. Office switches and firewalls without good APIs still benefit. Export their configurations on a schedule into the same repository and diff them, so the office estate leaves the same trail as the cloud. The evidence becomes a by-product of how the network is changed, not a scramble before the audit. The human layer stays where judgement matters: deciding which exposure is acceptable and approving the change. | Audit question | Manual evidence | Policy-as-code evidence | | --- | --- | --- | | Does the diagram match reality? | Hand-drawn Visio, refreshed before the audit | Topology generated from cloud APIs and compared with a scan | | Who approved this firewall change? | Ticket found by searching email | Merged pull request with a named reviewer | | Did anything change outside change control? | Discovered by the auditor | Scheduled drift diff raises a ticket | | Is anything exposed to the internet? | Periodic manual review | Continuous exposure scan with a ticket attached | ## What audit evidence does A.8.20 need? Annex A 8.20 ISO 27001 audits turn on eight artefacts: version-controlled diagrams matching a scan, a network security procedure naming responsibilities, device configuration exports against baselines, ticketed firewall changes with approvers, admin and MFA configuration, live logging, vulnerability scan results with remediation, and documented containment steps. Each artefact answers one auditor question: - **Diagrams and a matching scan:** is the documented network the real one? - **Network security procedure:** who owns what, including the MSP split? - **Configuration exports and firmware inventory:** are devices hardened against the baseline? - **Firewall change tickets:** did each sampled change have a requester and an approver? - **Admin access lists and MFA configuration:** who can administer devices, VPNs and cloud consoles? - **Logging configuration and dashboard:** does network telemetry arrive somewhere watched? - **Vulnerability scan results:** was each finding remediated and traced? - **Containment steps:** could you isolate a segment during an incident? Each artefact is produced by a step earlier in this guide, so collect them as timestamped standing exports rather than audit-week screenshots. ## What will auditors ask about ISO 27001 A.8.20, and how is it graded? Auditors put your diagram next to reality, trace recent firewall changes to approved tickets, check live device configuration, and ask whether you could isolate a segment. Internet-exposed management interfaces, factory credentials or a wholly flat network grade major; a stale diagram or one undocumented change grades minor, aggregating to major as a pattern. Expect questions along these lines: - "Show me your network diagram. When was it last updated, and does it include the cloud side?" - "Who manages your network, and if that is an MSP, how do you supervise their changes?" - "If a laptop in the office is compromised, what can it reach?" - "Walk me through your last firewall change: who asked, who approved, where is the record?" - "Could you isolate a segment during an incident? Show me the procedure." The sampling follows the questions. The auditor compares the diagram with a scan output, the cloud console or an interview, then picks two or three recent firewall or routing changes and traces each to an approved ticket. A live look at one device configuration checks for default credentials, open management ports and legacy protocols. They may also ask to see network alerts landing in your monitoring platform. The grading comes from certification bodies, not from ISO 27001 itself. Smaller gaps, such as an unhardened legacy protocol on an internal segment, grade minor, but a run of them can add up to a major. A team with a living diagram and ticketed changes answers by demonstration, not by recollection. ## Frequently asked questions ### Is A.8.20 a preventive or a detective control? Both, with preventive first. Hardening, filtering, authentication and segmentation exist to stop network-borne compromise before it lands, while the logging and watching reveal hostile activity in transit. The control also touches confidentiality, integrity and availability, because interception, in-flight tampering and lost connectivity are all network failures. ### Does A.8.20 require an internal penetration test? Not for the control itself. Periodic technical testing is still how mature firms prove that segmentation holds, and it is the fastest way to find the bridge nobody knew about. Aim the test from the guest and user zones towards servers and management, since that path is what the zones exist to block. ### Does A.8.20 require 802.1X or network access control? No. The control wants devices authenticated onto the network and unknown hardware noticed. Use 802.1X where it is practical and an NAC-lite approach through your MDM otherwise, backed by a periodic scan for unrecognised devices. A full NAC suite is rarely proportionate for a 40-person firm. ### How long does a first A.8.20 segmentation pass take in a cloud-native firm? Plan on one to two weeks of engineering in a cloud-native estate, longer where office switches and firewalls are involved. Most of that time goes on mapping the flows each system really needs, because default-deny rules break whatever was quietly relying on the flat network. Roll the rules out one zone at a time, with a way back for each.