Annex A 8.21: Security Of Network Services

Annex a 8.21: security of network services requirement means you must define and enforce security requirements for any network service you use or provide (internet links, WAN, cloud networking, SD-WAN, VPN, DNS, DDoS protection), then keep evidence that those requirements are met in day-to-day operations. Treat network services as third-party-dependent controls with clear ownership, SLAs, monitoring, and change management.

Key takeaways:

• Build a written “network services security requirements” standard and map it to each network service in scope (provider, purpose, data sensitivity, security features, monitoring).
• Put security terms into contracts and technical configurations (segmentation, encryption, logging, resilience, access control), then verify via recurring operational evidence.
• Audits fail most often on missing scope clarity and missing proof that monitoring, incident handling, and provider management actually run.

Security teams often secure endpoints and applications while assuming the “network” is someone else’s job: the ISP, the cloud provider, the SD-WAN vendor, or the MSP. Annex A 8.21 closes that gap. It pushes you to treat network services as part of your control environment, even when delivered by a third party, and to document what “secure” means for each service.

For a Compliance Officer, CCO, or GRC lead, the operational goal is simple: you need a repeatable way to (1) identify every network service your organization depends on, (2) set minimum security requirements for each, (3) ensure the requirements are implemented through contracts and configurations, and (4) retain evidence that the control operates.

This page is written for fast execution. You’ll get a scope definition you can use immediately, a step-by-step implementation checklist, a set of artifacts to retain for ISO 27001 assessments, and the audit questions that commonly cause delays. The focus is requirement-level implementation guidance tied to ISO/IEC 27001 and Annex A control expectations. ¹

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A control 8.21 implementation expectation (Security Of Network Services). ¹

Operator interpretation (what you must do):
You must define security requirements for network services, ensure those requirements are agreed with any internal or third-party network service provider, and verify the services continue to meet requirements through operational controls and evidence. “Network services” includes connectivity and network functions that enable systems to communicate (for example, internet circuits, private links, cloud VPC/VNet networking, DNS, VPN, DDoS protection, managed firewalls, and SD-WAN). ²

Plain-English interpretation of the requirement

Annex A 8.21 expects you to stop treating network services as “plumbing” and start treating them as controlled services with explicit security expectations. Practically, that means:

• You know which network services exist and which systems/data depend on them.
• You have written minimum requirements (security features, logging, access control, availability/resilience, incident handling, and change rules).
• You enforce requirements through contracts (for third parties) and through technical configurations (for internal services).
• You can prove the control operates: monitoring exists, alerts are reviewed, changes are approved, and provider performance/security is governed. ²

Who it applies to

Entity scope

This applies to service organizations implementing or maintaining an ISO/IEC 27001 ISMS, especially where customer data, regulated data, or business-critical services depend on network connectivity or managed network functions. ³

Operational scope (what counts as “network services”)

Include any service that provides connectivity or network security functionality, whether delivered internally or by a third party:

• Internet service (ISP), MPLS, private circuits, colo cross-connects
• Cloud networking (VPC/VNet routing, peering, transit gateways, load balancers where treated as network infrastructure)
• DNS, CDN, DDoS protection
• VPN / ZTNA / remote access gateways
• Managed firewalls, secure web gateways, SASE/SD-WAN
• Network monitoring platforms operated by a managed service provider (MSP)

Exclude purely application-layer SaaS that does not provide network service functionality unless your architecture treats it as a security boundary (document your rationale either way). Your auditor will care less about your choice and more about whether the scope is coherent and consistently applied.

What you actually need to do (step-by-step)

Step 1: Build your “Network Services Register”

Create a single inventory of network services with enough detail to manage risk and prove control operation. Minimum fields:

• Service name and type (ISP, DNS, SD-WAN, DDoS, managed firewall)
• Provider (internal team or third party)
• Business owner and technical owner
• Systems supported / dependency mapping
• Data classification and criticality supported
• Security features in use (encryption, segmentation, filtering, authentication)
• Logging/monitoring sources and retention location
• Change process (who can approve, how emergency changes work)

Practical tip: if you already have a third-party inventory, add a “Network service?” flag and a “Security boundary?” flag to drive scoping and testing.

Step 2: Define minimum security requirements (a standard you can test)

Write a short standard called “Security Requirements for Network Services.” Keep it requirement-shaped and testable. Cover:

• Access control: admin access method, MFA, least privilege, separation of duties
• Segmentation and traffic control: approved network zones, firewall policy governance, default-deny where feasible
• Encryption: requirements for management plane, remote access, and data-in-transit where applicable
• Logging and monitoring: what must be logged (admin actions, config changes, security events), where logs go, who reviews
• Availability/resilience: redundancy expectations, DDoS considerations, provider outage communications
• Vulnerability and configuration management: patching responsibility, secure baselines, configuration drift controls
• Incident management: escalation path between you and provider, evidence you can obtain, timeline expectations you set internally
• Change management: notification requirements, approval steps, backout plans for high-risk changes

Make each statement auditable (for example, “All administrative access uses MFA” is testable; “strong security is used” is not).

Step 3: Map requirements to each service (control mapping)

For each entry in the register, document:

• Which requirements apply (some won’t, based on service type)
• How they are met (contract clause, configuration, runbook)
• What evidence proves it (log source, screenshots, tickets, provider attestations)

This is where teams commonly fail: they write a standard but do not show how each network service conforms.

Step 4: Put requirements into third-party agreements and operating procedures

For third-party network services, align procurement, legal, and IT:

• Contract/SOW includes security responsibilities, change notifications, incident cooperation, and logging/access expectations.
• SLAs and support escalation are defined and owned.
• Your third-party due diligence process captures provider security documentation relevant to the service. ³

For internally delivered network services, put the same expectations into:

• Network engineering runbooks
• Change templates (firewall rules, routing changes, VPN changes)
• Access provisioning workflows (including joiner/mover/leaver triggers)

Step 5: Implement ongoing verification (recurring evidence capture)

Define what “proof of operation” looks like and schedule it:

• Monitoring checks: alerts exist for availability and security events; evidence is alert rules + sample alerts + review tickets.
• Change control sampling: pull a set of recent network changes and confirm approvals, testing, and backout plans.
• Access review: verify current admin list for network management planes and confirm least privilege.
• Provider governance: retain incident/outage communications and service review notes where relevant.

If you need an operational shortcut, configure Daydream to tie the register to a recurring evidence checklist so owners submit the same artifacts on a predictable cadence, and you can show assessors consistent operation without a scramble.

Required evidence and artifacts to retain

Use this table as your audit-ready checklist.

Artifact	What it proves	Owner
Network Services Register	Scope completeness and ownership	GRC + Network/IT
“Security Requirements for Network Services” standard	You defined testable requirements	Security/GRC
Per-service requirement mapping	Requirements implemented per service	Service owners
Contracts/SOWs or provider terms	Third-party obligations and SLAs	Procurement/Legal
Network diagrams / segmentation diagrams (as appropriate)	Architecture supports requirements	Network team
Monitoring configuration evidence (alerts, dashboards)	Operational detection and response capability	SecOps/NetOps
Change tickets for network changes	Controlled change management	NetOps/ITSM
Admin access lists and access review record	Least privilege and governance	IT/Security
Incident/outage records and communications	Provider coordination and response	IT/SecOps

Common exam/audit questions and hangups

Expect assessors to ask:

• “What network services are in scope, and how do you know you found them all?”
• “Show me the security requirements for your ISP / SD-WAN / DNS provider.”
• “How do you validate the provider meets requirements after onboarding?”
• “Show evidence of logging/monitoring and that someone reviews it.”
• “How are firewall/routing/VPN changes approved and tracked?”
• “Who owns the relationship with the network service provider during an incident?”

Hangups that slow audits:

• No single register; services are scattered across procurement, IT, and cloud teams.
• Requirements exist but are not mapped to each service.
• Evidence is anecdotal (“we monitor”) rather than demonstrable (alert rules + review tickets).

Frequent implementation mistakes and how to avoid them

1. Mistake: treating cloud networking as “handled by the cloud provider.”
   Avoidance: document the shared responsibility boundary in your mapping. You still control routing, security groups, NACLs, peering, and logging configuration in most architectures.

2. Mistake: focusing only on availability SLAs.
   Avoidance: include security-specific obligations (access control, incident cooperation, change notification, logging support).

3. Mistake: no operational evidence trail.
   Avoidance: define an evidence calendar and attach artifacts to each service entry. Daydream can centralize submissions so you do not rebuild the story at audit time.

4. Mistake: unclear ownership between SecOps and NetOps.
   Avoidance: name a business owner and technical owner for every service. If the service is third-party, also name a vendor manager.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control, so this page does not cite enforcement actions.

Operational risk still matters: weak control over network services increases the chance that outages, misconfigurations, or provider-side incidents become business-impacting events, and it creates audit risk because assessors expect evidence of managed dependencies within the ISMS. ³

Practical execution plan (30/60/90-day)

First 30 days (Immediate stabilization)

• Build the first version of the Network Services Register from procurement records, cloud accounts, and network team inputs.
• Identify the “top critical” services (those supporting core production and sensitive data flows) and assign owners.
• Draft the “Security Requirements for Network Services” standard with testable statements.

By 60 days (Implement and map)

• Complete per-service mapping for critical services: requirement applicability, implementation method, and evidence sources.
• Update contract templates or renewal checklists to include your network service security terms for third parties.
• Stand up the evidence workflow: where artifacts live, who submits, and who reviews exceptions.

By 90 days (Operate and prove)

• Run the first full operating cycle: sample network changes, perform an admin access review, and export monitoring evidence.
• Document exceptions with risk acceptance, compensating controls, and target remediation actions.
• Prep an assessor-ready “8.21 evidence pack” (register + standard + mappings + sample tickets/logs/contracts).

Frequently Asked Questions

Does Annex A 8.21 apply if all our networking is “in the cloud”?

Yes, because you still depend on network services and configurations to deliver connectivity and enforce boundaries. Document which parts are provider-managed versus customer-configured, then retain evidence for the parts you control. ²

What’s the difference between Annex A 8.20 and 8.21?

In practice, 8.21 is about security of the network services themselves, especially where third parties provide them, and proving requirements are defined and met. Keep 8.21 artifacts service-centered: register, requirements, contracts, and operational monitoring evidence. ²

Do we need provider audits or SOC reports for every network service?

ISO 27001 does not mandate a specific report type in the provided excerpt, but assessors expect reasonable assurance proportional to risk. For lower-risk services, a contractual requirement plus operational monitoring may be sufficient; for higher-risk services, request stronger assurance during due diligence. ³

What evidence is most persuasive to an auditor?

A current register, a short security requirements standard, and a mapped trail from requirement to implementation to proof (tickets, alert configurations, access review record). Assessors respond well to consistency across services more than one-off screenshots.

How do we handle legacy circuits or providers with weak contract terms?

Document the gap as an exception, add compensating controls you can enforce (monitoring, segmentation, stronger internal access controls), and tie remediation to renewal or a provider transition plan. Keep the exception approval and rationale with your 8.21 evidence pack.

Can Daydream help without changing our network tooling?

Yes. Treat Daydream as the control system of record: track the network services register, map requirements to each service, assign owners, and collect recurring evidence submissions so audit prep becomes a retrieval task instead of a reassembly project.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISMS.online Annex A control index

3. ISO/IEC 27001 overview