Control Definition
For every network service the organization relies on — whether delivered in-house or by an external provider — the security mechanisms, the service levels, and the service requirements must be identified, put into effect, and monitored on an ongoing basis.
Control Objective
To make sure the network services an organization consumes are used securely — with the protection features, capacity, and quality each service needs defined up front, delivered in practice, and verifiably maintained over time.
What This Really Means
If A.8.20 is about securing the networks you operate, A.8.21 is about governing the network capability you consume. Almost no organization runs its own network end to end anymore: internet circuits come from ISPs, the WAN is an SD-WAN service from a carrier, DNS sits with a registrar and a resolver provider, a CDN fronts the website, remote access is VPN-as-a-service or a ZTNA platform, and the firewall may be managed by an MSSP. Each of these is a dependency whose internals you cannot configure directly — you can only specify what you need, contract for it, and verify you are getting it.
The control asks for three verbs. Identify — build an inventory of every network service in scope and, for each one, document the security mechanisms it must provide (encryption in transit, authentication, DDoS protection, filtering), the service levels it must hit (availability, latency, time to restore), and the management requirements around it (logging and your access to those logs, incident notification timelines, data residency, subcontractor disclosure). Implement — get those requirements into agreements and configurations; this is where A.8.21 hands off to A.5.20, which governs supplier contracts. For commodity services where nobody will negotiate with you, implementation means choosing the service tier and options that meet your documented requirements and configuring your tenant well. Monitor — track actual delivery against what was agreed: SLA reports, status pages, your own uptime and latency checks, periodic service reviews, and assurance evidence such as SOC 2 reports or a contractual right to audit.
There is a quieter clause inside this control that often gets missed: authentication for the use of network services. Decide who in your organization may connect to or administer each service and how that access is authenticated. The admin portals for your DNS registrar, CDN, and SD-WAN controller can redirect every byte of your traffic — they deserve MFA, least-privilege roles, and inclusion in your access reviews just as much as a domain controller does.
What auditors treat as the heart of A.8.21 is the register and the monitoring trail. They want to see a list of network services with an owner and documented requirements per service, agreements (or documented acceptance of standard terms) that reflect those requirements, and evidence that someone actually checks delivery — SLA reviews, provider assurance reports with recorded conclusions, incidents raised and chased. The classic failure is "it is in the MSA somewhere"; the clean pass is a living register backed by a review rhythm.
Why It Matters
A meaningful share of your security posture is rented. A hijacked registrar account, a BGP problem at your ISP, a lapsed DDoS protection tier, or a breach at your managed-firewall provider all land on you with full force — your customers experience your outage and your regulators ask you the questions. Accountability does not transfer with the purchase order, and "our provider failed" has never satisfied an auditor, a regulator, or an enterprise customer.
Without governed network services, organizations face:
- •Inherited incidents – A compromise or outage at a DNS, CDN, or connectivity provider becomes your incident; without agreed notification duties you may learn about it from your own customers first
- •No leverage when it counts – An agreement that never defined security mechanisms, service levels, or breach-notification timelines leaves you with no recourse mid-incident and no remedy afterwards
- •Silent degradation – Provider-side changes quietly drop security features (a DDoS tier expires, a legacy TLS option is re-enabled); without monitoring against documented requirements, nobody notices until it is exploited
- •Unguarded service portals – Registrar, CDN, and SD-WAN admin consoles control where your traffic goes; a single phished credential on an un-MFA'd portal can redirect or intercept it
- •An easy audit finding – No network-services inventory and no per-service requirements is one of the simplest nonconformities for an auditor to raise, because the absence is visible in minutes
Done properly, this control gives you something operationally valuable beyond the certificate: a single view of every external dependency your connectivity stands on, with a named owner and a known weak point for each — exactly the map you need on the day one of them fails.
Regional Compliance Context
For India-connected operations, two CERT-In angles matter. First, your 6-hour incident-reporting clock does not pause while a provider investigates — so agreements with ISPs, MSSPs, and managed-network providers should require prompt incident notification, or you will be reporting late on incidents you did not even cause. Second, the 180-day log retention expectation extends to logs that live with the service provider: if your firewall is managed or your remote access is a service, confirm in writing what is retained, for how long, and how you can retrieve it during an investigation.
For regulated entities, RBI's master directions on IT outsourcing expect banks and NBFCs to retain oversight, audit rights, and exit options over IT service providers — network services included — and SEBI's CSCRF points market intermediaries the same way. If you operate in these sectors, your A.8.21 register and supplier reviews can serve double duty as outsourcing-oversight evidence.
Implementation Guidance
Build a Network-Services Register
Inventory every network service in scope: internet circuits, MPLS and SD-WAN, DNS (registrar and resolver separately), CDN and DDoS protection, VPN/ZTNA/SASE platforms, managed firewalls or IDS, cloud interconnects (Direct Connect, ExpressRoute), and SIP trunks. Record provider, internal owner, criticality, contract reference, and renewal date for each. Review the register quarterly and whenever a service is added or changed.
Define Security Requirements per Service
For each entry, document three things: security mechanisms (encryption in transit, authentication methods, DDoS protection, traffic filtering), service levels (availability percentage, latency, time to restore), and management requirements (logging and your access to it, incident notification timelines, data residency, subcontractor disclosure). Use one standard requirements template so services are comparable and gaps are obvious.
Embed Requirements in Agreements
Working with procurement under A.5.20, get the documented requirements into MSAs, SLAs, and service orders: security characteristics, service levels, breach-notification duties, audit rights or acceptance of independent assurance, and termination assistance. Where a commodity provider will not negotiate, record a documented acceptance of their standard terms together with any compensating controls you apply on your side.
Control Authentication and Access to Each Service
Treat provider admin portals as privileged access. Enforce MFA and SSO where supported on registrar, CDN, SD-WAN, and MSSP consoles; use named accounts with least-privilege roles; enable registrar and transfer locks on domains; scope API keys narrowly and restrict them by source IP. Include these portal accounts in quarterly access reviews and in the joiner-mover-leaver process.
Monitor Delivery Against Agreed Levels
Run your own uptime and latency monitoring rather than relying solely on provider dashboards. Subscribe to status pages and security advisories, collect and file SLA reports, track incidents and service credits, and hold service reviews — quarterly for critical services. Route security events from managed services (MSSP alerts, SD-WAN anomalies) into your SIEM so they join your own telemetry.
Obtain Assurance — Audit or Equivalent
Exercise the right to audit where the contract grants it. Where it does not — the normal case with large providers — collect SOC 2 Type II reports or ISO 27001 certificates annually, check the scope actually covers the service you consume, and record a review conclusion in the supplier file. An unread assurance report on a shared drive is not monitoring; a dated review note is.
Review on Change and at Planned Intervals
Re-validate requirements whenever the provider changes ownership, architecture, or subcontractors, whenever your own usage changes materially, and at least annually for critical services. For single-provider dependencies (one ISP, one DNS provider), document the concentration risk and maintain a tested exit or failover option — secondary DNS, a second circuit, or a documented CDN switch procedure.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.21:
Documentation
- Network-services register listing every service with provider, owner, criticality, and contract reference
- Documented security requirements and service levels per service, on a consistent template
- Agreements or service orders showing security clauses — notification duties, service levels, audit or assurance rights
- SLA performance reports, service review minutes, and records of provider incidents chased to closure
- Provider assurance evidence on file (SOC 2 Type II, ISO 27001 certificates) with dated review conclusions
Interviews
- Network or IT manager on how services are inventoried, how requirements are set, and how providers are monitored
- Procurement or vendor manager on how security requirements reach contracts and what happens at renewal
- Security analyst on how managed-service alerts and provider incidents enter the internal incident process
Observations
- A walkthrough of the register with one service traced from documented requirement to contract clause to monitoring record
- Provider admin portals (DNS registrar, CDN, SD-WAN controller) showing MFA enforced and least-privilege roles assigned
- Monitoring dashboards or SLA reports demonstrating live tracking of delivery against agreed service levels
Practitioner Insights
A pattern I see across audits: the organization can produce the contract with its ISP or managed-firewall provider, but not the security requirements behind it. When I ask "what did you require of this service, and how do you know you are getting it," the room goes quiet. A.8.21 is less a technology control than an ownership control — one register, one named owner per service, one monitoring trail. Build those three things and the audit conversation on this control becomes very short.
Smaller organizations often tell me this control cannot apply to them because no ISP or CDN will negotiate a custom contract with a forty-person company. That is not what the control asks. Choosing the service tier that meets your documented requirements, keeping the provider's published SLA and security documentation on file, and actually reviewing their SLA reports and status-page incidents is a perfectly defensible implementation. The evidence gap I find most often is the monitoring half — requirements written once during certification, then never checked against reality again.
Common Challenges & Solutions
Challenge
Large providers — ISPs, CDNs, hyperscaler interconnects — refuse custom security clauses or right-to-audit terms outright.
Solution
Accept independent assurance in place of audit rights: a SOC 2 Type II report or ISO 27001 certificate reviewed annually, with the review conclusion documented and any residual risk formally accepted. Select providers whose standard published terms already meet your requirements, and spend your negotiating effort on the few relationships where it works — the MSSP, the SD-WAN carrier, the regional ISP.
Challenge
Nobody can produce a complete list of network services — they were bought by different teams over many years.
Solution
Reconstruct from three sources: the accounts-payable recurring-spend list (every service invoices someone), external reality (domain registrations, public DNS records, BGP and IP allocations), and firewall egress rules showing where traffic actually goes. Assign every discovered service an owner on the spot, then gate new network services through procurement so the register stays complete going forward.
Challenge
The managed security service underperforms — slow rule changes, missed alerts — but the contract contains no metrics to hold it to.
Solution
Retrofit service levels at the next renewal: detection and notification timelines, change-implementation SLAs, report cadence, and named escalation contacts. Until then, measure unilaterally — your ticket timestamps and change lead times are data the provider cannot dispute — and table that data in a monthly service review. Providers respond to measured evidence far faster than to general complaints.
Challenge
Provider portal accounts (registrar, CDN, SD-WAN controller) are shared logins without MFA, and a single phished credential could redirect company traffic.
Solution
Treat these portals as tier-zero privileged access. Replace shared logins with named accounts behind MFA or SSO, apply least-privilege roles, enable registrar and transfer locks on all domains, scope API tokens narrowly and restrict by source IP, and pull every portal account into the quarterly access review and the leaver checklist. This is a one-sprint fix that removes a disproportionate amount of risk.
Challenge
Provider incidents surface on social media or status pages hours before any contractual notification arrives.
Solution
Stop depending on contractual notification as your detection mechanism. Subscribe to every critical provider's status feed and security advisories, run independent monitoring of the services you consume, and write a short playbook for provider-side incidents: who declares it internally, who can execute the DNS or CDN switch, who communicates to customers. Then add notification timelines to the contract at renewal anyway — for the post-incident accountability, not the detection.
