ISO 27001 A.8.21: Specify security for network services
A network service should deliver the protection and service behaviour the organisation needs, not merely a working connection. ISO 27001 Annex A.8.21 concerns identifying, implementing and monitoring security mechanisms, service levels and other requirements for network services. This applies whether the provider is an internal team or an external organisation.
What A.8.21 requires in practice
Annex A control A.8.21 concerns network services, meaning the connectivity and related functions the organisation uses, whether run by an internal team or an outside provider. It calls for three things to be identified, put into effect and watched over: the security mechanisms of the service, its service levels, and the requirements placed on it.
Read together, this means the organisation should know what protection it expects from each service, make sure that protection is actually delivered, and keep checking. Mechanisms might include how access is authenticated or how traffic is protected. Service levels cover availability and support. Requirements cover anything else the business needs, such as notice of material change.
The outputs are a description of each important network service, agreed expectations that can be verified, clarity on who does what between provider and customer, and monitoring information such as service reports. Applicability and extent follow the risk treatment decisions recorded in the Statement of Applicability.
Describe the service in business and security terms
Identify the service, its users, the information it carries and the effect of a failure or inappropriate connection. Network services can range from basic connectivity to managed security functions. Two offers with similar bandwidth may allocate authentication, configuration, monitoring and incident responsibilities very differently.
Specify relevant requirements before relying on the service. These may concern permitted access, protection of communications, availability, support and notification of material changes. Requirements should be clear enough to verify. A phrase such as secure managed connection provides little direction unless the parties understand what is included and who operates it.
Why network service security matters to the business
Organisations rarely run all their connectivity themselves. When a managed link, hosted connection or monitoring service fails to deliver what the business assumed, the gap is usually discovered during an incident, which is the worst moment. Specifying requirements in advance protects customer data, avoids disputes with providers about who was responsible, and gives the business a basis for comparing offers on more than price or bandwidth. It also supports answers to customer due diligence, where buyers ask how outsourced connectivity is controlled. At audit, clear service expectations demonstrate that outsourcing has not removed accountability for information security.
How to implement A.8.21
The aim is to turn a vague promise of secure connectivity into expectations both parties understand. Work through the following sequence, scaling it to the importance of each service.
- List the network services in use, including those supplied by internal teams, and note the information each one carries.
- Rank them by the effect of failure or misuse, so effort goes first to the services that matter most.
- For each priority service, write down the security mechanisms, service levels and other requirements expected, in terms that can be verified.
- Record which party operates each element, who approves access, who changes settings and who reviews alerts, including handoffs between providers.
- Reflect these expectations in the supplier agreement or internal service arrangement.
- Agree how assurance will arrive, such as periodic service reports or review meetings, and who reads them.
- Test the delivered configuration against the expectation before relying on it for sensitive work.
- Revisit the arrangement when the service, the provider or the business need changes.
Illustrative construction example: connectivity for a temporary office
A fictional construction company obtains a managed network service for a temporary project office. The supplier installs connectivity, while the project team assumes that visitor access and administration are also controlled as part of the package. The original order does not clearly allocate those responsibilities.
The company clarifies the required service boundaries, access arrangements and support responsibilities before relying on the connection for sensitive project work. A joint check verifies the intended configuration and escalation contacts. The resulting evidence describes what the service actually provides, instead of treating successful internet access as proof of an adequate security arrangement.
Illustrative BPO example: a managed monitoring handoff
A hypothetical BPO business buys a network service that includes alert monitoring. The provider will notify a nominated customer contact, but the customer's operating team assumes the provider will also decide whether to restrict an affected service. Neither party has a clear agreed handoff for that decision.
The business defines notification, assessment and authorisation responsibilities and checks them through an agreed exercise. It confirms how urgent information reaches the appropriate person across relevant working hours. The example shows that a monitored service still needs a customer-side response arrangement; outsourcing the signal does not automatically outsource every business decision.
Review performance and security together
Monitor whether the service continues to meet its agreed requirements. An availability report can establish part of the picture, but it may say little about access changes, security events or the provider's handling of an exception. Choose review information that relates to the actual commitments.
Reassess requirements when locations, users, information types or business criticality change. A service suitable for a small office may need different protection when it begins carrying sensitive customer traffic. Keep service changes coordinated with network security and network segregation.
Evidence that supports an informed service decision
Useful evidence includes defined requirements, allocation of responsibilities, relevant agreement terms, implementation checks and review outcomes. These are practical ways to demonstrate control, not a mandated contract format. Protect any sensitive provider material and use it only within authorised review arrangements.
A proportionate test can trace one requirement from the agreed wording to its implementation. For example, verify that an authorised user can obtain the intended service and that an inappropriate access request follows the agreed restriction or approval process. Test the contact route as well as the technical feature, especially after personnel or supplier changes.
Common weaknesses include accepting marketing language as a requirement, reviewing only uptime and retaining contact details that no longer reach the responsible team. Use operational control to connect service review with actions. If a requirement is not met, identify the consequence, owner and treatment rather than repeatedly recording the same unresolved concern.
Common nonconformities with A.8.21
Typical findings show reliance on assumptions rather than agreed and monitored requirements. Most are visible by reading the agreement alongside a recent service report.
- Services described only as secure or managed, with no verifiable expectations recorded.
- Responsibility for monitoring alerts or approving access unclear between customer and provider.
- Provider reports received but not reviewed by anyone accountable.
- A provider's general certificate treated as proof that the organisation's own configuration meets its requirements.
- Service expectations never revisited after the provider or the architecture changed.
Frequently asked questions
Does this control apply to an internal network team?
Yes. Internal services also need clear security requirements, responsibilities and monitoring. A formal external contract is not the only way to establish these arrangements.
Does a provider certificate prove our service is suitable?
It can contribute assurance within its scope, but it does not replace evaluation of the specific service, customer configuration and agreed responsibilities.
Should network-service reviews cover only availability?
No. Include relevant security mechanisms, access arrangements, changes and response responsibilities, using evidence that matches the service requirements.
Buy and manage network services with clearer expectations
Discuss network-service requirements with Sterling, including scoped supplier governance, documentation, learning and agreed Effivity ISO & GRC automation software. Authorised vulnerability scanning and findings review can support the wider ISO 27001 programme. Continuing support covers defined preparation while certification remains independent. Enrol in ISO/IEC 27002 Information Security Controls to connect service assurance with the technological controls.