Control Definition
The organization must secure, manage, and control its networks and network devices to protect the information flowing through connected systems and applications — establishing clear responsibility for network management, hardening and authenticating devices, restricting and filtering connections, protecting management channels, and logging and monitoring network activity.
Control Objective
To protect information traveling across networks — and the systems connected to them — from interception, intrusion, and disruption arriving over the network itself.
What This Really Means
The network is the part of your estate every other technological control quietly assumes is trustworthy. Authentication, encryption, monitoring, malware defense — all of them ride on cables, Wi-Fi, and virtual networks, and all of them degrade if an attacker owns the layer underneath. Think of the network as the corridors and doors of a building: A.8.20 is the control that says the corridors are mapped, the doors lock, the master keys are accounted for, and someone is watching the CCTV.
In practice the control decomposes into a handful of disciplines. Know your network: maintain current architecture documentation showing zones, trust boundaries, and how traffic enters and leaves — you cannot secure what you cannot draw. Harden the devices: change default credentials, disable unused services and legacy protocols, keep firmware current, and apply a hardening baseline (CIS benchmarks are the usual reference) just as you would to a server. Protect the management plane: the interfaces used to administer routers, switches, firewalls, and access points should live on a separate management network, unreachable from user segments or the internet, behind MFA and a jump host. Filter the traffic: default-deny rules between zones, each rule with an owner and a business justification (the segmentation architecture itself is A.8.22's territory). Secure the wireless edge, authenticate what connects — NAC where your maturity supports it — and log and monitor network events so anomalies surface (feeding A.8.16).
If you are cloud-native, do not skip this control because you own no switches. Your VPC and VNet design, security groups, network ACLs, routing tables, load balancer exposure, and flow logs ARE your network controls. "Hardening a device" becomes reviewing the Terraform that defines a security group; "the management plane" becomes the cloud console and API, protected by IAM and MFA. The control translates cleanly — auditors increasingly expect you to make exactly that translation rather than declare the control out of scope.
What auditors treat as the heart of A.8.20: a network diagram that matches observable reality, devices that are demonstrably hardened rather than default-configured, management access that an ordinary user segment cannot reach, and evidence that someone actually looks at network logs. Pretty topology slides with default credentials behind them fail; a modest network that is mapped, filtered, and watched passes.
Why It Matters
Most serious intrusions are not won at the perimeter — they are won in the minutes and weeks after, when a flat, unwatched network lets one compromised laptop reach everything else. Network security is the control that decides whether an incident stays a contained event on one machine or becomes a company-wide ransomware deployment. It is also foundational evidence: weakness here undermines your story for monitoring, access control, and segregation simultaneously.
When networks are unmanaged, organizations face:
- •Lateral movement at attacker speed – On a flat network with no internal filtering, one phished endpoint reaches servers, backups, and domain controllers in a single hop
- •Default-configured entry points – Routers, switches, and access points still running factory credentials and legacy protocols are among the oldest and most reliable footholds attackers look for
- •Exposed management planes – Admin interfaces reachable from user networks or the internet turn one stolen password into control of the network itself
- •Blindness during incidents – Without flow logs, firewall logs, and DNS records, you can neither detect an intrusion in progress nor reconstruct it afterwards for reporting
- •Cascading compliance failure – PCI DSS, SOC 2, and sector regulators all lean on network controls; weak A.8.20 evidence rarely fails only the ISO audit
Regional Compliance Context
For India-connected systems, CERT-In's 180-day log retention requirement squarely covers network telemetry: firewall logs, VPN and remote-access logs, DNS logs, and NetFlow or cloud flow logs should all be in your retained set, because they are precisely what incident reconstruction — and the 6-hour reporting obligation — depends on. Check retention settings on cloud flow logs in particular; several platforms default to far shorter windows.
Indian BFSI organizations face parallel expectations from RBI master directions and SEBI's CSCRF, which treat network security and segmentation of critical systems as baseline obligations — an ISO 27001-aligned A.8.20 implementation, evidenced by architecture documents, hardening baselines, and monitored logs, does double duty in those examinations.
Implementation Guidance
Document the Network Architecture
Produce current diagrams covering on-premises segments, cloud VPCs and VNets, site-to-site and remote-access links, and wireless — showing zones, trust boundaries, and ingress and egress points. Assign a named owner for network architecture, and make updating the diagram a closure step of network changes rather than an annual scramble. Where possible, generate views from the source of truth (IaC or discovery tooling) so documentation cannot silently drift.
Harden Every Network Device
Apply a hardening baseline to routers, switches, firewalls, and access points: change all default credentials, disable unused services, ports, and management protocols (telnet and HTTP administration first), enable only supported firmware with a patching cadence, and back up configurations. Treat the baseline as configuration management for network gear (A.8.9) — CIS benchmarks give you a defensible starting point.
Separate and Protect the Management Plane
Put device administration interfaces on a dedicated management VLAN or out-of-band network that user segments and the internet cannot reach. Require MFA and a bastion or jump host for administrative sessions, restrict administration to named individuals (A.8.2), and log every session. In cloud, the management plane is the console and API — protect it with IAM least privilege, MFA enforcement, and control-plane audit logging.
Filter Traffic Between Zones
Enforce default-deny between network segments, with each permitted flow documented — rule, owner, business justification, and review date. Recertify firewall rules at least annually and remove or justify rules with no observed traffic. In cloud, manage security groups and network ACLs as code with pull-request review, so every rule change carries an approval trail (the zoning model itself belongs to A.8.22).
Secure the Wireless Edge
Run corporate Wi-Fi on WPA2/WPA3-Enterprise with 802.1X or certificate-based authentication tied to your directory, so departing staff lose access automatically. Keep guest and IoT networks on isolated segments with no route to corporate systems, and monitor for rogue access points. A single pre-shared key whispered around the office is the pattern to eliminate.
Control What Connects to the Network
Decide, risk-based, how unknown devices are kept off your network: 802.1X NAC on wired and wireless where maturity allows, or pragmatic interim measures — switch port controls, MDM-based posture checks before granting access, and alerting on new MAC addresses in sensitive segments. In cloud, the equivalent is restricting who and what can modify network configuration and attach resources, enforced through IAM.
Log and Monitor Network Events
Ship firewall logs, VPN and remote-access logs, DNS queries, and flow logs (NetFlow, VPC Flow Logs) to your SIEM, and alert on meaningful anomalies: traffic to new external destinations, internal port scanning, denied-traffic spikes, and management-plane access outside change windows. Set retention to satisfy investigation needs and regulation — 180 days minimum for India-connected systems under CERT-In directions. This feed is also half of your A.8.16 monitoring story.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.20:
Documentation
- Current network architecture diagrams (on-premises and cloud) showing zones, trust boundaries, and ingress/egress points
- Network device hardening standard plus sampled device configurations or IaC templates demonstrating it is applied
- Firewall and security-group rule sets with documented owners, business justifications, and recertification records
- Network security procedures covering management-plane access, wireless, remote access, and connection of new devices
- Network device inventory with firmware status, configuration backup records, and named administrators
Interviews
- Network or cloud platform engineers on how firewall rule and security-group changes are requested, reviewed, and applied
- IT or security manager on who can administer network devices and how that access is segregated and protected
- SOC analyst or designated log reviewer on which network events are monitored, alerted on, and escalated
Observations
- Live comparison of the network diagram against observable topology or the cloud console VPC layout for sampled segments
- Inspection of a sampled device or security-group configuration: default credentials changed, unused services disabled, default-deny in place
- Demonstration that a device management interface is unreachable from the user network, and that administrative access requires MFA via a bastion
Practitioner Insights
The fastest credibility test on this control is the diagram. A pattern I see across audits: the organization presents a polished network diagram, we trace three segments against the live environment, and none of them match — at which point every other network claim needs independent verification. The second chronic finding is firewall rule bloat: hundreds of rules, no owners, nobody willing to delete anything. Tie diagram updates to change closure and run an annual rule recertification with hit-count data; those two habits carry most of the audit on A.8.20.
Cloud-first startups tell me "we don't really have a network" — and then we open the console and find security groups allowing 0.0.0.0/0 on SSH and database ports, because someone was debugging in 2024 and never cleaned up. Treat your security groups as the firewall ruleset they are: define them in Terraform, review changes by pull request, turn on flow logs, and run one of the free misconfiguration scanners regularly. That gives a five-person team better network evidence than many enterprises, at close to zero cost.
Common Challenges & Solutions
Challenge
Network diagrams are outdated within weeks of being drawn, and nobody trusts them.
Solution
Stop treating the diagram as a deliverable and start treating it as an output: generate it from sources of truth (IaC, network discovery, the cloud console) where tooling allows, and make a documentation update a mandatory closure step for any network change. Keep one logical-zone diagram for auditors and architecture reviews, and let detailed views be generated on demand.
Challenge
The firewall ruleset has grown for years and nobody dares remove a rule in case something breaks.
Solution
Run a recertification: export the ruleset, attach hit-count or log data, and have rule owners justify what remains in use. Disable rather than delete suspect rules for a defined observation window (30 days is common) before removal, and add owner and justification metadata to every new rule going forward so the cleanup never has to be repeated at this scale.
Challenge
Administrators need remote access to network devices, so management interfaces have ended up exposed.
Solution
Exposure is never the answer to remote administration. Route admin sessions through VPN plus MFA onto a management VLAN or out-of-band network, with a bastion or PAM gateway recording sessions. In cloud, drop open SSH and RDP security-group rules in favor of session-manager or identity-aware proxy services, which remove the listening port entirely while improving the audit trail.
Challenge
Office Wi-Fi runs on one shared password that ex-employees, visitors, and half the neighborhood still know.
Solution
Move corporate Wi-Fi to 802.1X or certificate-based authentication tied to your directory, so access dies with the account on the day someone leaves. Stand up a separate isolated SSID for guests and another for IoT devices. If enterprise authentication must wait, rotate the PSK immediately, on every exit, and on a fixed schedule — but treat that strictly as a stopgap.
Challenge
In a hybrid estate, developers own the cloud network and IT owns the office network, and nobody owns the whole.
Solution
Publish one network security standard that covers both worlds — hardening, exposure rules, logging, and change control expressed in each platform's terms — and name a single accountable owner for network security end to end. Bring cloud network changes into the same change-management visibility as on-premises ones, and run periodic joint architecture reviews so the seam between the two estates, where attackers like to live, gets explicit attention.
