Auditing ISO 27001 Annex A 8.21 Security of Network Services is the systematic evaluation of security controls applied to both internal and third-party networking. The Primary Implementation Requirement is robust service level agreements and encrypted transmission, providing the Business Benefit of ensuring continuous network reliability and integrity.
ISO 27001 Annex A 8.21 Security of Network Services Audit Checklist
This technical verification tool is designed for auditors to establish the security integrity of internal and external network service agreements. Use this checklist to validate compliance with ISO 27001 Annex A 8.21.
1. Network Service Level Agreement (SLA) Security Clause Verified
Verification Criteria: All third-party network service agreements (ISPs, Cloud Providers, Managed Security Services) contain explicit information security requirements and service levels.
Required Evidence: Signed contracts or SLAs with highlighted security schedules and right-to-audit clauses.
Pass/Fail Test: If a network service is provided without a formal agreement specifying security obligations, mark as Non-Compliant.
2. Network Service Security Feature Identification Confirmed
Verification Criteria: The security features of all utilised network services (e.g. managed firewalls, VPNs, DDoS mitigation) are documented and aligned with the organisation’s risk appetite.
Required Evidence: Service catalogue or technical design document detailing the security controls provided by each network service.
Pass/Fail Test: If the organisation cannot define the specific security capabilities of a core network service (e.g. an unmanaged SD-WAN), mark as Non-Compliant.
3. Secure Transmission Mechanism Enforcement Validated
Verification Criteria: Technical controls ensure that all network services use secure, encrypted transmission protocols for data exchange (e.g. TLS 1.3, IPsec).
Required Evidence: Packet capture analysis, configuration logs, or cipher suite reports showing the rejection of insecure protocols (e.g. Telnet, HTTP, FTP).
Pass/Fail Test: If any network service allows the transmission of sensitive data over unencrypted channels, mark as Non-Compliant.
4. Network Service Access Restriction Verified
Verification Criteria: Access to network service management interfaces is restricted to authorised IP ranges and protected by strong authentication.
Required Evidence: Firewall Access Control Lists (ACLs) and Multi-Factor Authentication (MFA) logs for service provider portals.
Pass/Fail Test: If a network service management console is accessible from the public internet using only single-factor authentication, mark as Non-Compliant.
5. Service Provider Security Monitoring Alignment Confirmed
Verification Criteria: The organisation receives or has access to security event logs from the network service provider for integration into internal monitoring systems.
Required Evidence: SIEM ingestion logs showing data feeds from the ISP, Managed Firewall, or Cloud Gateway.
Pass/Fail Test: If a critical network service operates as a “black box” with no visibility into security events or threats, mark as Non-Compliant.
6. DDoS Mitigation and Traffic Filtering Validated
Verification Criteria: Network services include active protection against Distributed Denial of Service (DDoS) and unauthorised traffic ingress.
Required Evidence: Technical configuration showing active DDoS scrubbing services or Next-Gen Firewall (NGFW) traffic filtering rules.
Pass/Fail Test: If the external network service lacks any form of automated threat filtering or volumetric attack protection, mark as Non-Compliant.
7. Network Path Redundancy and Availability Confirmed
Verification Criteria: Critical network services are supported by redundant paths or providers to ensure continuous service availability.
Required Evidence: Network topology diagrams showing diverse routing and automatic failover test results.
Pass/Fail Test: If a single provider or physical cable failure results in total loss of critical network services, mark as Non-Compliant.
8. Service Provider Compliance Attestation Verified
Verification Criteria: The security posture of the network service provider is verified periodically through independent audits or certifications.
Required Evidence: Valid ISO 27001 certificates, SOC 2 Type II reports, or annual security self-assessment questionnaires from the provider.
Pass/Fail Test: If the organisation has not reviewed the provider’s security credentials within the last 12 months, mark as Non-Compliant.
9. Network Service Configuration Change Authorisation Validated
Verification Criteria: Any changes to network service configurations (e.g. firewall rule changes, VPN tunnels) follow a formalised change management process.
Required Evidence: Approved Change Request (CR) tickets cross-referenced against provider activity logs.
Pass/Fail Test: If a provider implements a significant configuration change without the organisation’s documented approval, mark as Non-Compliant.
10. Secure Management of Virtual Network Services Confirmed
Verification Criteria: Virtualised network services (e.g. VPCs, Cloud Firewalls, Load Balancers) are configured following the principle of least privilege.
Required Evidence: Security group rules or Cloud Security Posture Management (CSPM) reports showing no “Any-Any” permit rules.
Pass/Fail Test: If virtual network services allow unrestricted lateral movement or have default “Allow All” ingress rules, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Service Security Clauses | Uploading a standard T&C document to the GRC portal. | Examine the Liability and Audit clauses. Standard T&Cs often waive the provider’s responsibility for data breaches. |
| Traffic Encryption | Relying on a provider’s claim of “Secure Connectivity.” | Verify Cipher Strength. Many providers use legacy TLS 1.1 or weak hashes that GRC tools cannot detect via API. |
| Access Control | Platform identifies that “MFA is enabled” for the root user. | Verify All Access Points. Check for legacy API keys or “backdoor” SSH access that GRC tools frequently ignore. |
| Availability | Recording an SLA of “99.9%” as proof of redundancy. | Inspect the Physical Path. An SLA doesn’t stop two “redundant” lines from sharing a single, vulnerable conduit. |
| Security Monitoring | Tool checks if “Logging” is checked in a dashboard. | Verify Ingestion. If the logs exist in the provider’s portal but aren’t in your SIEM, you have zero real-time detection. |
| Change Management | SaaS tool creates a task to “Review Changes” once a month. | Check Emergency Fixes. GRC tools miss ad-hoc firewall changes made by provider support during “troubleshooting” events. |
| DDoS Mitigation | Checking a box that says “DDoS Protection included.” | Test the Threshold. Is it volumetric protection only, or does it cover Layer 7? GRC tools don’t distinguish the level of cover. |
About the author
