ISO 27001 A.8.20: Secure the networks carrying business information

What A.8.20 requires in practice

Annex A control A.8.20 asks the organisation to secure, manage and control its networks and the devices that make them work, so that information held in systems and applications stays protected. In plain terms, it is about three verbs: secure, manage and control. Securing means putting protective measures around connections and equipment. Managing means someone is responsible for how the network is run and changed. Controlling means the organisation decides what may connect, and can show that those decisions are enforced.

The control does not describe a product or a topology. Whether it applies, and how far, follows from the organisation's risk treatment and is recorded in the Statement of Applicability, as clause 6.1.3 expects.

In practice the outputs are an understanding of what the network connects, defined responsibility for administering it, rules about which devices and services may attach, protected management access, and a way to keep those arrangements current as the environment changes. Networks that include wireless, virtual or provider-run elements fall inside the same expectation when they carry in-scope information.

Know what the network connects

Maintain an appropriate understanding of important devices, services, boundaries and external connections. A diagram can help, but it must reflect the relevant operating environment. Include virtual networks and provider-managed elements where they affect information in scope; the absence of a physical cable does not remove the security decision.

Identify who owns network administration and who approves business connectivity needs. The network team should know which information and services its design supports, while business owners should understand consequential restrictions or dependencies. Unclear ownership often leaves old connections in place after their original purpose ends.

Control connection and administration paths

Decide which devices and services may connect, and how those decisions are enforced. Suitable measures can include authentication, restricted connection rules and appropriate filtering. Keep management access protected so ordinary traffic does not automatically provide a route to administer important network equipment.

Review device configurations and unnecessary functions through configuration management. Apply appropriate protection to information crossing public, third-party or wireless networks, considering confidentiality, integrity and availability. The measure should follow the information and exposure rather than depend solely on whether a connection is called internal.

Why network security matters to the business

Almost every service a customer relies on travels over a network at some point. When that network is poorly understood, a single forgotten connection or an exposed management interface can turn a minor error into a loss of customer information, an outage or a contractual breach. Prospects who send security questionnaires usually ask how connections are restricted and who administers them, and vague answers slow deals. Clear network control also reduces the cost of investigating incidents, because the organisation knows what should be talking to what. For auditors, a well-run network is one of the quickest places to see whether the ISMS describes reality or only intentions.

How to implement A.8.20

Start from what exists, then decide what should exist. The steps below suit most organisations, whatever the size of the network team; one way Sterling's teams approach it is to keep the work proportionate to the information at stake.

1. Establish an accurate picture of networks, devices, provider-run services and external connections that touch in-scope information, including virtual and wireless elements.
2. Name an owner for network administration and a separate approver for business connectivity requests.
3. Decide which devices, users and services may connect, and choose how that rule is enforced, such as authentication or restricted connection rules.
4. Protect administrative access to network equipment so that ordinary traffic cannot reach it.
5. Review device settings for unnecessary functions as part of configuration management, and correct what is found.
6. Apply suitable protection to information that crosses public, third-party or wireless links, based on its sensitivity.
7. Route network changes through change management and update the picture when they close, including the removal of temporary connections.
8. Review the arrangements periodically and after significant change, keeping the results with the ISMS records.

Evidence an auditor expects for A.8.20

An auditor looks for proof that the organisation knows its network and acts on that knowledge. Typical evidence includes:

• a current view of networks and connections, checked against what is actually present
• records showing who approved recent connectivity and who administers equipment
• configuration or rule reviews with follow-up actions
• an interview with the network owner explaining how a temporary connection is closed
• observation of how administrative access is restricted

The diagram format and tooling are the organisation's choice; the point is that the evidence matches the live environment.

Common nonconformities with A.8.20

Findings under this control tend to come from gaps between the stated and actual environment. Each one below is something an auditor can see simply by comparing a diagram with the live environment.

• Network diagrams that omit virtual, wireless or provider-managed segments carrying in-scope information.
• Temporary supplier or project connections left in place with no recorded owner or purpose.
• Management interfaces reachable from ordinary user networks.
• Device configuration reviews that were planned but never evidenced.
• No clear owner for approving new connectivity, so rules accumulate without review.

Illustrative manufacturing example: an undocumented maintenance connection

Illustrative IT example: virtual network rules after a migration

A hypothetical IT provider moves an internal application into a virtual environment. The migration team reproduces connectivity broadly to avoid interrupting users, but the resulting rules allow more paths than the application's approved use requires. The physical network diagram does not show these new virtual relationships.

The provider maps the application's necessary communications, restricts inappropriate paths and verifies representative permitted and denied connections using authorised tests. It records the virtual configuration and its owner alongside the wider network. This demonstrates that network security applies to the actual service arrangement, including controls configured through a provider console.

Observe changes and maintain usable records

Relevant logging and monitoring should help identify changes or activity that affect security. Decide which events matter and who responds. A well-designed rule can still fail operationally if an unauthorised change is not noticed or a device stops enforcing the intended configuration.

Coordinate network changes with application owners and service providers. Restricting a route without understanding its legitimate purpose can interrupt work and encourage bypasses. Equally, a request to allow broad access for troubleshooting should have an accountable scope and review point rather than remain indefinitely.

Test behaviour rather than relying on the diagram

Useful evidence includes appropriate network records, ownership, authorised configurations, change decisions and safe test results. These are practical ways to demonstrate operation, not a mandatory requirement for one document format. Protect diagrams and configuration details according to their sensitivity.

An authorised review can select a business connection, trace its approval and test whether the intended path works while an inappropriate path is restricted. Define test boundaries, timing and operational safeguards in advance. Do not conduct uncontrolled scanning or disruption to prove a control; the test itself must respect the service's needs.

Common weaknesses include stale diagrams, unreviewed permissive rules and confusion between a provider's network and customer-managed configuration. Read security of network services for the service-requirement relationship and network segregation for separation decisions. Use operational control to keep these connected activities coordinated.