ISO 27001 A.8.21 - Security of Network Services

Requirement

Requirement lens

This control asks whether the security mechanisms, service levels, and service requirements for network services are known, implemented, and monitored.

“Security mechanisms, service levels and service requirements of network services shall be identified, implemented and monitored.”

Plain-language meaning

When the organization uses network services, especially third-party network services, it should know exactly what security features and service levels are required, what the provider actually supplies, and how those commitments are monitored.

This includes confidentiality, integrity, and availability. A carrier, managed network provider, cloud connectivity provider, VPN provider, DNS provider, DDoS protection service, internet service, or managed firewall service can become a direct security dependency.

Why this matters

Network service providers can create exposure through weak access controls, poor resilience, unclear service levels, weak failover, inadequate monitoring, or standard service packages that do not match the organization’s risk needs.

If the provider cannot offer a needed security feature, the organization may need compensating controls, an accepted risk, or a different service model.

Implementation guidance

Implementer focus

Do not treat network service contracts as procurement-only records. Translate network risk into required service features, service levels, and monitoring evidence.

1. Identify network services in scope

Create a register of internal and external network services such as WAN, ISP, VPN, DNS, DDoS protection, managed firewall, SD-WAN, private cloud connectivity, wireless managed services, and network monitoring services.

2. Define required security mechanisms

For each service, identify security requirements such as encryption, authentication, segregation, logging, monitoring, DDoS protection, change notification, incident notification, access control, resilience, and failover.

3. Define service levels

Availability and resilience need explicit attention. Define uptime, failover, support response, incident notification, maintenance windows, recovery expectations, and escalation paths.

4. Put requirements into agreements

Provider agreements, service descriptions, SLAs, or security schedules should clearly state the required security mechanisms, service levels, responsibilities, and monitoring/reporting obligations.

5. Monitor the service

Review provider reports, service performance, outages, security notifications, failover tests, incidents, and unresolved issues. Where the provider cannot meet a requirement, document compensating controls or risk acceptance.

Audit guidance

Auditor focus

Trace a network service from risk assessment to required security features, provider agreement, operational procedure, monitoring evidence, and review.

Auditors should verify:

network services are identified and owned;
risks and security needs are assessed;
provider security features are understood and documented;
confidentiality, integrity, and availability are considered;
service levels and failover/resilience requirements are defined;
requirements are included in agreements or operational procedures;
provider security features are verified in practice;
ongoing monitoring and review are performed;
compensating controls exist where provider features are weak or fixed.

Auditors should not accept “the provider handles it” as evidence. The organization remains responsible for knowing whether the service is suitable for its risk.

Evidence examples

Evidence quality

Strong evidence proves the organization knows what security it needs from network services, has agreed it, and monitors delivery.

Evidence	What it proves
Network service register	Services and owners are known
Risk assessment	Required security features are justified
Provider service description or SLA	Service levels and features are defined
Security requirement checklist	Confidentiality, integrity, and availability needs are mapped
Provider reports and review records	Service delivery is monitored
Failover/resilience evidence	Availability features are tested or evidenced
Exception/risk acceptance records	Provider gaps are managed

Strong evidence

Each network service has an owner and risk assessment.
Security mechanisms are mapped to business and risk requirements.
Provider agreements include service levels and security responsibilities.
Resilience and failover provisions are understood and reviewed.
Provider performance and security reports are reviewed.
Weak provider features have compensating controls or risk acceptance.

Weak evidence

Network services are known only by procurement or invoices.
SLA focuses on uptime but ignores security mechanisms.
Provider security features are assumed, not verified.
Failover capability is claimed but not evidenced.
Standard provider limitations are not risk-assessed.
No one reviews provider reports or service changes.

Common failures

Implementation watchouts

A.8.21 fails when third-party network services are consumed as black boxes.

Failure	Why it matters
No service inventory	Dependencies are invisible
Security requirements not defined	Provider features may not fit risk
SLA ignores security	Availability alone is not enough
No review of provider reports	Weak service delivery is missed
No compensating control	Provider limitation becomes unmanaged risk
Failover not understood	Outage recovery may bypass security needs

Exam traps

Exam focus

A.8.21 is about network service security features, service levels, requirements, and monitoring. It is not the same as A.8.20 network device security.

Trap	Correct interpretation
Provider network service means the provider owns the risk	The organization must identify, agree, and monitor required security
SLA uptime is enough	Confidentiality and integrity requirements also matter
Standard provider terms always satisfy the control	Standard services may need compensating controls or risk acceptance
Failover is only continuity	Failover must preserve required security levels
Agreement signing is enough	Service features and performance must be monitored

KB-ready summary

Mentor takeaway

A.8.21 makes network services auditable. Strong implementation proves the organization identified required security mechanisms, service levels, provider responsibilities, monitoring evidence, and compensating controls for gaps.

Identify network services and owners.
Define security mechanisms and service levels.
Put requirements into agreements or operational procedures.
Monitor provider delivery and service changes.
Manage provider limitations with compensating controls or risk acceptance.

Templates and checklists

Iso27001
Iso27002
Annex a
Technological controls
Network security
Supplier security
Audit

Note Metadata

Aliases: A.8.21, Security of Network Services

Source: 05 Annex A Technological Controls/A.8.21 Security of Network Services.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

links

Control

ISO 27001 A.8.21 - Security of Network Services

Requirement context

Primary control text, framework notes, or adjacent controls this note points to.

Implementation artifacts

Templates and working records that help operate the control.

Evidence required

Evidence packs and proof records that support auditability.

A.8.21 Audit Evidence Pack

Audit checks

Audit questions, checklists, or review material connected to the control.

A.8.21 Audit Checklist

Risk treatment

Risk records and ISO 27005 material this control mitigates or supports.

Risk Assessment

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.

Risk treatment artifacts

Risk records, mappings, and treatment-supporting references.

Risk Assessment