UnixTime

Research Note

ISO 27001 A.8.20 - Networks Security

Networks are not just cables and routers. They are trust paths between users, systems, applications, cloud services, suppliers, and management interfaces. If the network is poor...

On this page

Requirement

Requirement lens

This control asks whether networks and network devices are secured, managed, and controlled to protect information in systems and applications.

“Networks and network devices shall be secured, managed and controlled to protect information in systems and applications.”

Plain-language meaning

Networks are not just cables and routers. They are trust paths between users, systems, applications, cloud services, suppliers, and management interfaces. If the network is poorly designed or poorly controlled, attackers can move, intercept, disrupt, or modify information.

Network security should be considered during design, implementation, operation, monitoring, problem management, and change control.

Why this matters

Networks are complex and easy to misconfigure. A weak firewall rule, exposed management interface, badly protected administrative network, unmanaged virtual network, or forgotten disaster recovery link can bypass the intended architecture.

The control protects confidentiality, integrity, and availability by making network architecture, devices, traffic flows, zoning, remote administration, monitoring, encryption, routing, and access control deliberate and documented.

Implementation guidance

Implementer focus

Start with architecture and zoning. Tools matter, but uncontrolled routes and management paths defeat tools quickly.

1. Define network architecture and zones

Document network topology, zones, trust boundaries, sensitive traffic paths, internet exposure, supplier connections, administrative networks, backup networks, and disaster recovery links.

2. Secure network devices

Routers, switches, firewalls, wireless controllers, load balancers, VPN gateways, SD-WAN devices, and virtual network components should have secure configuration, restricted administration, logging, monitoring, patching, backup, and change control.

3. Control traffic and routing

Use routing restrictions, firewall rules, access control lists, segmentation, and network access controls to limit traffic to business need. Avoid flat networks unless risk assessment justifies them.

4. Protect traffic over public or untrusted networks

Where confidentiality or integrity matters, use appropriate encryption, VPN, secure protocols, certificate management, or equivalent controls.

5. Include virtual and cloud networks

Virtual networks, hypervisors, cloud networking, security groups, route tables, private links, and management planes should be treated as network security scope. Virtual architecture can bypass physical network assumptions.

6. Monitor and record network activity

Network monitoring should detect faults, suspicious traffic, policy violations, and security events. Faults, problems, corrective actions, and security alerts should be recorded and linked to A.8.16 Monitoring Activities and incident reporting.

Audit guidance

Auditor focus

Do not accept a network diagram as proof. Test whether architecture, zoning, device configuration, public exposure, virtual networks, and monitoring evidence match the documented design.

Auditors should verify:

  • network topology and operating environments are documented;
  • sensitive traffic and exposed network areas are identified;
  • network zones and trust boundaries are defined and enforced;
  • public network use is protected appropriately;
  • network devices are securely configured and access-controlled;
  • remote administration is controlled and logged;
  • network changes are authorized and documented;
  • virtual networks, hypervisors, cloud networking, backup networks, and administrative networks are included;
  • monitoring detects faults and potential breaches;
  • incidents and problems are reported and corrected;
  • internal or external network security expertise is adequate for complexity.

Auditors should look for bypass paths. Administrative networks, backup links, emergency routes, hypervisor layers, and disaster recovery connections often escape normal review.

Evidence examples

Evidence quality

Strong evidence proves that network design, device control, zoning, monitoring, and change management operate together.

Evidence What it proves
Network architecture and topology diagrams Network scope and zones are known
Network security standard Management and protection rules are defined
Firewall/router/switch configuration review Technical controls match design
Network device access records Administration is restricted
Network change records Changes are authorized and traceable
Monitoring and fault records Network events are detected and handled
Zoning/segmentation test evidence Boundaries are enforced
Virtual/cloud network review Non-physical network paths are controlled

Strong evidence

  • Diagrams match actual network configuration.
  • Sensitive traffic paths are identified and protected.
  • Administrative and management networks are tightly controlled.
  • Firewall and route rules are reviewed and justified.
  • Virtual/cloud network controls are included in scope.
  • Network device access is restricted, logged, and reviewed.
  • Monitoring records lead to incident or corrective action where needed.

Weak evidence

  • Network diagram exists but is stale.
  • Flat network with no risk justification.
  • Firewall rules are broad and not reviewed.
  • Network device admin access is shared or unmanaged.
  • Virtual/cloud networks are considered outside network scope.
  • Backup or disaster recovery links bypass zoning.
  • Monitoring detects faults but security events are not escalated.

Common failures

Implementation watchouts

A.8.20 fails when network security is treated as firewall ownership instead of architecture, device, route, zone, and monitoring control.

Failure Why it matters
Stale topology diagrams Review is based on fiction
Weak zoning Attackers can move laterally
Uncontrolled admin network Management access bypasses normal controls
Virtual network blind spots Cloud or hypervisor paths bypass physical assumptions
Poor device configuration control Misconfiguration creates exposure
Unrestricted remote management Increases compromise likelihood
No network monitoring follow-up Breaches and faults remain unresolved

Exam traps

Exam focus

A.8.20 is about securing and managing networks and network devices. It is not just installing firewalls.

Trap Correct interpretation
Network security equals firewall rules Architecture, zoning, device management, monitoring, routing, encryption, and change control also matter
Physical networks are the main concern Virtual and cloud networks are also in scope
Network diagrams prove compliance Diagrams must match actual configuration and operation
Admin networks are trusted by default Management paths can bypass controls and need stronger protection
Monitoring faults is enough Potential security breaches must be detected and escalated

KB-ready summary

Mentor takeaway

A.8.20 protects network trust paths. Strong implementation proves network architecture is documented, zones are enforced, devices are secured, public and virtual paths are controlled, and monitoring leads to corrective action.

  • Document topology, zones, trust boundaries, and sensitive routes.
  • Secure and restrict network device administration.
  • Control routing, segmentation, and public network exposure.
  • Include virtual, cloud, administrative, backup, and DR networks.
  • Monitor faults and suspicious activity.
  • Keep network changes documented and reviewed.

Templates and checklists

  • Iso27001
  • Iso27002
  • Annex a
  • Technological controls
  • Network security
  • Zoning
  • Audit

Note Metadata

Aliases: A.8.20, Networks Security, Network Security

Source: 05 Annex A Technological Controls/A.8.20 Networks Security.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

12

links

01
02
03

Evidence required

Evidence packs and proof records that support auditability.

04

Audit checks

Audit questions, checklists, or review material connected to the control.

05

Risk treatment

Risk records and ISO 27005 material this control mitigates or supports.

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.

Risk treatment artifacts

Risk records, mappings, and treatment-supporting references.