ISO 27001 Network Security: Controls A.8.20 and A.8.21

ISO/IEC 27001 network security is a managed system of responsibilities, architecture, technical safeguards and operating decisions. A firewall at the internet boundary is only one component. Controls must cover internal and external networks, cloud connectivity, wireless access, remote administration and the services supplied by third parties.

Annex A controls 8.20 and 8.21 provide a useful division: secure the networks and network devices, and define and monitor the security of network services. Effective implementation joins both sides so that the design promised by a provider or network team is visible in configuration and operation.

Use the current control references

Older material groups network security under A.13.1 in ISO/IEC 27001:2013. The 2022 edition reorganised the control set. Network security is A.8.20, security of network services is A.8.21 and segregation of networks is A.8.22.

Do not simply replace control numbers in a policy. Reassess scope, risks, responsibilities and the Statement of Applicability against the current structure. Related controls may include access control, cryptography, logging, monitoring, configuration management, supplier relationships, cloud services and technical vulnerability management.

Use the Annex A control lookup to examine these relationships when designing or reviewing the control environment.

Define the network population and ownership

Begin with a current view of how information moves. Include corporate sites, data centres, remote users, cloud networks, internet-facing services, partner connections, management networks, wireless services, operational technology and outsourced network components.

A useful inventory links each material network or service to:

• business purpose and owner;
• technical operator;
• information and systems carried;
• trust boundaries and external connections;
• administration method;
• service provider and contract where applicable;
• logging and monitoring sources;
• recovery dependency; and
• approved architecture or data-flow record.

Ownership must separate accountability from operation. A managed service provider may operate devices, but the organisation still needs an accountable person who approves requirements, evaluates performance and accepts risk.

Translate risk into network requirements

Network requirements should follow the information and services being protected. Consider unauthorised access, interception, alteration, disruption, administrative compromise, insecure routing, supplier failure and unintended paths between systems.

Requirements can address:

• approved protocols and encrypted transport;
• authentication of users, devices and services;
• administrative access and privileged paths;
• permitted traffic between security zones;
• resilience, capacity and denial-of-service protection;
• secure configuration and change approval;
• monitoring, event retention and alerting;
• vulnerability and patch handling;
• availability and recovery expectations; and
• evidence the service provider must supply.

Requirements should be testable. “The network will be secure” is not testable. “Administrative interfaces are reachable only through the approved management path with named accounts and multi-factor authentication” gives designers, operators and auditors a concrete outcome.

The remote access policy evidence guide explores one important boundary in more detail.

Build defence in depth without relying on location alone

Use several layers so that one configuration error does not expose every asset. Depending on risk, these layers may include hardened devices, access control, traffic filtering, secure protocols, encryption, endpoint controls, detection, resilient design and restriction of administrative interfaces.

Network location can inform a decision, but it should not automatically establish trust. Users, devices and services may need authentication and authorisation even when traffic originates internally. Cloud and remote-working models make this especially important.

Network segregation is a distinct control with its own design and evidence needs. The A.8.22 network segregation guide explains how to establish zones and govern flows between them.

Govern configurations and changes

Define secure baselines for routers, switches, firewalls, gateways, wireless controllers, cloud networking and other relevant devices or services. Baselines can cover management protocols, accounts, encryption, unused services, logging, time synchronisation, backup and software support.

The baseline is design evidence. Operating evidence comes from current configurations, compliance results, reviewed deviations and changes. Protect configuration backups and make sure they can be restored to compatible equipment or services.

Changes should have a reason, risk assessment proportionate to impact, approval, implementation record, test and rollback approach. Emergency changes need retrospective review. Compare actual configuration with the approved change so that a successful ticket does not conceal an incomplete or broader modification.

The firewall governance guide gives detailed evidence patterns for ownership, rule change and recertification.

Specify security for network services

Control A.8.21 applies to services whether delivered internally or by an external provider. Examples include internet connectivity, private circuits, DNS, content delivery, secure access, filtering, anti-denial-of-service services and managed network operation.

Define the security features, service levels and management requirements that matter. A service description may address availability, capacity, encryption, incident notification, administrative control, logging, support, change notice, subcontracting, data location, recovery and termination.

Avoid relying on marketing labels. Confirm which features are included in the purchased tier, which settings the organisation must enable and which evidence is available. The contract, architecture and configured service should agree.

Control question	Design evidence	Operating evidence
What protection is required?	Risk decision, service specification	Current enabled features
Who operates and approves it?	Responsibility assignment	Access and change records
How is performance known?	Measures and reporting terms	Reports, alerts and review decisions
How are changes controlled?	Change and notification requirements	Sampled changes and tests
How does the service end?	Exit and transition requirements	Revocation, data return and closure records

Protect management paths

Network administration has broad impact and deserves separate attention. Use named privileged identities, strong authentication, restricted management sources and protected protocols. Limit direct internet exposure of administration interfaces. Record administrative actions where technically feasible and review access periodically.

Separate duties when the risk requires it. One person may prepare a high-impact change while another approves it. For smaller teams, detective review, alerts and independent periodic inspection may compensate for limited staffing.

Cryptographic protection of traffic should match risk and endpoints. The ISO 27001 cryptography guide explains how to connect cryptographic decisions with ownership, keys and evidence.

Monitor health, security and effectiveness

Monitor more than device availability. Relevant signals may include denied traffic, authentication failures, configuration drift, unexpected routes, exposed services, certificate status, capacity, provider degradation and loss of log sources.

Assign alert ownership, severity and escalation. Sample alerts through triage and closure. A dashboard with unresolved alerts is not evidence of an effective response process.

Measure whether controls achieve their intended outcome. Useful organisation-specific measures might include unauthorised exposure detected, overdue high-risk rule reviews, unsupported devices, failed configuration backups or provider incidents that breached agreed service levels. These are management choices, not prescribed ISO metrics.

Audit design and operation together

Select samples across network types, locations, providers and risk levels. Include recently changed infrastructure and a long-standing service. Trace each sample from requirement to configuration and operating evidence.

Useful audit questions include:

• Does the inventory cover cloud, wireless, partner and management networks?
• How were security requirements derived from information and service risks?
• Which configurations enforce them, and how is drift detected?
• Can the team show that an approved change matches the deployed result?
• Which service protections are the supplier’s responsibility and which are the customer’s?
• How are network events monitored and escalated?
• What happens when a provider, device or critical link fails?

A pass is supported when risk-based requirements, assigned ownership and current architecture lead to controlled configurations, monitored services and traceable changes.

A partial result may exist when safeguards are operating but inventories are incomplete, supplier requirements are vague, deviations are unmanaged or reviews are inconsistent.

A fail is likely when the organisation cannot explain its network boundaries, privileged interfaces are broadly exposed, material changes bypass control or provider claims substitute for verification.

Keep the network model current

Reassess the control when systems move to cloud services, new offices or suppliers connect, remote-access methods change, critical data flows appear or incidents expose assumptions. Reconcile architecture records with observed routes and assets rather than waiting for an annual review.

The official ISO/IEC 27002 overview describes guidance for information-security controls. The NIST Zero Trust Architecture publication provides complementary principles that remove implicit trust based only on network location. Neither source dictates one product or topology; the organisation must select and verify controls for its own context.

Strong network evidence forms a chain: understood data flows, approved requirements, configured protection, monitored operation and action when the result differs from the design.