ISO 27001 Annex A 8.21: security of network services and SLAs

The enterprise due-diligence questionnaire asks how you assure the providers underneath your network. Your honest answer is a broadband contract nobody has reread and a cloud console. ISO 27001 Annex A 8.21 is the control that closes that gap.

This guide is for heads of security, IT directors and compliance leads at 25–250-person firms. It shows what the control requires and how it differs from Annex A 8.20. It then sets out the lean register, contract and review routine that satisfies Stage 2 auditors. Cloud providers, FCA SYSC 8 and automation are covered along the way.

What does ISO 27001:2022 Annex A 8.21 security of network services require?

ISO 27001:2022 Annex A 8.21 security of network services requires you to decide which security mechanisms, service levels and service requirements each network service must provide. You then agree them with the provider and keep checking delivery. It covers every network service you consume, from ISP lines to cloud virtual networks, VPN and managed firewalls.

Almost every network a 25–250-person firm runs on is bought, not built. Internet connectivity, cloud virtual networks, VPN and wireless access, managed firewalls and CDNs all belong to someone else. So the control is mostly about choosing, contracting and watching providers. There is little network engineering in it.

We read the control's three terms in plain English like this:

• Security mechanisms: the protections the service offers, such as encryption, authentication and access control.
• Service levels: the availability target, fix times and remedies if the provider misses them.
• Service requirements: what you need from the service, including data-protection constraints and who may use it.

Delivery is checked through monitoring, reporting and either a right to audit or an attestation you accept, such as a provider's ISO 27001 certificate.

ISO 27001:2022 A.8.21 security of network services is a preventive control. Agreed requirements and controlled access stop a compromise or an outage before it happens. It protects confidentiality, integrity and availability at once. An unencrypted link leaks data, a tampered service corrupts it, and a provider outage takes the business offline. The guidance in ISO 27002:2022 8.21 security of network services covers the same ground in more detail.

The stakes are practical. A connectivity outage with no SLA behind it leaves you without remedy or leverage mid-incident. Enterprise buyers increasingly probe how you assure the providers beneath your service, and a shrug reads as a lost-deal signal.

How does Annex A 8.21 differ from Annex A 8.20?

ISO 27001 security of network services under A.8.21 governs the services you consume: what you require, what the provider promised, and how you check delivery. A.8.20 secures the network fabric you operate, covering segmentation, firewalls and hardening. One is engineering; the other is supplier assurance applied to connectivity.

A cloud VPC is the useful test case. Segmentation rules inside it are Annex A 8.20 work. The provider's own platform security, and your review of its attestation, belong to Annex A 8.21.

A managed firewall splits the same way. The rule base you approve is Annex A 8.20 work, while the provider's patching, monitoring and support commitments fall under Annex A 8.21.

The provider-oversight half of 8.21 runs on the same discipline as supplier service monitoring under Annex A 5.22. One supplier review cadence can therefore serve both controls, so connectivity does not need a process of its own.

How do you manage security of network services at 25–250 people?

Managing security of network services at 25–250 people takes three artefacts. The first is a register with one page per service, listing security features, availability target and data-protection constraints. The second is contracts with uptime, remedies and an audit or attestation route. The third is usage rules, set once in your access control policy.

Build them in this order:

1. List the network services. Cover ISP lines, cloud VPCs and interconnects, VPN, wireless, and managed firewall, DDoS and CDN services. Per service, record the security features, availability target and data-protection constraints you need. One register page each is plenty.
2. Put commitments in contracts. Ask for uptime targets with remedies, security obligations, and either a right to audit or an agreed attestation route. At this scale, an annual review of a provider's ISO 27001 certificate or SOC 2 report does the job. For managed firewalls and SD-WAN, also name who patches the devices and how fast critical fixes land.
3. Set usage rules once. Your access control or network policy states which services staff may use and how each is reached, such as VPN or corporate wireless. It also names who authorises access and where MFA applies to admin.
4. Schedule the review. Review each service against its requirements annually, and out of cycle after a major outage or security incident on either side.

Depth follows risk. Primary connectivity and the cloud network that carries production deserve full contract terms and the closest monitoring. Guest wireless needs a line in the register and little more.

Build the register on top of your asset inventory and your supplier controls (Annex A 5.9, 5.20 and 5.22), not as a new silo. Standing it up takes one to two weeks of effort at this scale. After that, the cost is a light annual review plus whatever your monitoring already does.

The pattern this inverts is the consumer-grade contract under a business-critical service. An office that hosts production kit on standard broadband, with no uptime commitment, no fix time and no review since signature, hands the assessor an easy finding.

A network contract with no remedy isn't a control. It's a hope.

Does ISO 27001 Annex A 8.21 cover AWS, Azure and Google Cloud?

Yes. ISO 27001 Annex A 8.21 covers VPCs, private interconnects and cloud VPN under the shared-responsibility model: the provider secures the platform, you configure isolation, encryption and access. You cannot audit AWS, Azure or Google Cloud, so you review their SOC 2 Type II report or ISO 27001 certificate annually instead.

Shared responsibility sets the boundary. A permissive security group, an unencrypted tunnel or an over-broad IAM role in your VPC is your configuration and your finding, whatever the provider's certificate says.

When you review an attestation, check four things:

• Type and period. A SOC 2 Type II report covers a period of operation, so confirm it is current. If the period ended months ago, ask for a bridge letter covering the gap.
• Scope. The report or certificate must name the services you actually consume, not just the provider's corporate estate.
• Exceptions. Note any exceptions the auditor recorded and whether they touch your use.
• Your side. Map the controls the provider expects you to run, such as isolation, encryption and access, to your own configuration.

File the report, its date and a short review note. An auditor asking when you last reviewed your cloud provider's attestation then gets a dated record instead of a recollection.

The trap sits outside the hyperscalers. A regional ISP or managed SD-WAN provider may have no report to hand over. If the contract has no audit or attestation route, you find the gap when a client's questionnaire asks. Settle the route at signature.

How do you lock down the network management plane and data in transit?

Lock down the management plane with named accounts instead of shared logins, MFA on every admin path, least-privilege roles in the provider's IAM and encrypted admin protocols only. Pair that with authenticated, encrypted channels such as TLS or IPsec for data in transit. NCSC Cloud Security Principles 1 and 12 set the same bar for cloud providers.

The NCSC applies both halves to cloud providers' own services. NCSC Cloud Security Principle 12: Secure service administration warns that the systems a vendor uses to run its service hold highly privileged access, so their compromise would have significant impact. NCSC Cloud Security Principle 1: Data in transit protection expects user data crossing networks to be protected against tampering and eavesdropping, through encryption, network protection and authentication.

Apply these management-plane rules to every network service you administer:

• Named accounts only. No shared logins, so every admin action traces to a person.
• MFA on every admin path. Console, API, and VPN or firewall management interfaces alike.
• Least-privilege roles. Define roles in the provider's IAM so network changes need network rights and nothing broader.
• Encrypted protocols only. Use SSH and HTTPS for administration, and switch off Telnet and plain HTTP interfaces.
• Central logging. Admin activity lands in your logging platform, where unusual behaviour shows up.

For data in transit, require authenticated, encrypted channels end to end. TLS covers application and API traffic, and IPsec covers site-to-site VPN tunnels. Authentication matters as much as encryption, since an encrypted channel to the wrong endpoint protects nothing.

Shared admin credentials and legacy unencrypted protocols are among the cheapest fixes in this control. They also do outsized damage in an audit sample, because an auditor tracing admin access for one service sees them at once.

What does FCA SYSC 8 add to network service oversight?

FCA SYSC 8.1 applies when a common platform firm outsources operational functions critical to its regulated activities. The provider must supervise the outsourced work and manage its risks, and the firm and provider must keep a disaster-recovery contingency plan. For network services, the review loop Annex A 8.21 already asks for supplies most of the evidence.

FCA Handbook SYSC 8.1 General outsourcing requirements also requires backup facilities to be tested periodically. It gives the firm, its auditors and the FCA effective access to the provider's data and premises. Wherever a network service supports a regulated function, flag it in your register.

For each flagged service, keep three records:

• Operational oversight: a named internal owner who reviews SLA reports and incidents.
• Continuity: the disaster-recovery plan and its last test, or an attestation that covers both.
• Regulatory access: contract wording that permits it.

One set of records then serves both the ISO assessor and the FCA supervisor.

What will an auditor ask about A.8.21, and how is it graded?

Expect five questions: which network services you depend on, the SLA and latest uptime report for primary connectivity, when you last reviewed your cloud provider's attestation, who administers VPN and firewall services, and what you did after the last outage. Auditors sample one or two register entries and trace admin access end to end.

Evidence that answers each question:

• Services and requirements: the network services register, or a section in your IT security procedures.
• SLA and uptime: the contract clause and the provider's report, with proof someone reviewed it.
• Cloud assurance: the SOC 2 report or ISO certificate and a dated review note.
• Administration: IAM role definitions, MFA enforcement and ACLs for the service, with access logs in the SIEM.
• Outage response: the post-incident review and any SLA claim or reassessment of the service.

Grading follows certification-body practice:

• Major: no identification of security requirements for network services at all, meaning no register, no contracts reviewed and no monitoring.
• Minor: a stale attestation review, one service missing from the register, or uptime reports collected but never reviewed.
• Pattern: repeated minors add up to a major.

An uptime report nobody reviewed is a log, not monitoring.

With the register and records in place, the sample becomes a walkthrough. You open the entry, show the contract or attestation, then the last review and the admin access trace.

How can you automate A.8.21 evidence and monitoring?

Automate A.8.21 by treating each network service as a data record with owner, requirements, SLA and attestation expiry. Provider status APIs feed an availability dashboard that raises tickets on breach, attestation refresh becomes a scheduled task, and service access logs stream to the SIEM, so evidence builds up as a by-product.

Each automated signal replaces a diary entry. Provider status pages and uptime feeds are machine-readable. A breach of the availability target opens a ticket, instead of waiting for the annual review to notice. That ends the habit of signing well and never looking again, because the system looks for you.

Reviews stay human but become triggered. Run the annual review from the register, and treat the ticket from any major outage as the cue for an out-of-cycle review. A post-incident reassessment that never happens tells an auditor the monitoring loop is not real. A ticket that closes with a recorded decision on the service and its SLA proves it is.

The commercial upside lands in sales cycles. When a DDQ asks how you assure your network providers, you export the register entry, the latest attestation and the review note. The answer takes minutes, and the buyer reads a firm that runs its supply chain deliberately.

Frequently asked questions