Security of network services — ISO 27001 control 8.21

Organizations routinely hand control of critical network infrastructure to third parties and rarely verify what happens next. Unmonitored ISP connections, cloud providers operating without formal security agreements, and managed firewalls running on expired certificates create attack surface that security teams can’t see, measure, or defend. The problem compounds as organizations add more outsourced services without proportionally expanding oversight. When network service security is an afterthought, the gaps between trust and verification become the paths attackers use.

What 8.21 requires

ISO 27001 control 8.21 requires organizations to identify, document, and enforce the security features, service levels, and management requirements for every network service they use, whether operated internally or delivered by a third party. The goal is to ensure that each service meets the organization’s security needs through formal agreements, defined expectations, and ongoing verification.

In practice, this means building a structured approach to network service governance that covers four areas:

• Identification and documentation: Catalog all network services, including Internet Service Provider (ISP) connections, Virtual Private Network (VPN) tunnels, cloud connectivity services, managed firewalls, Software-Defined Wide Area Networks (SD-WAN), and internal services like Domain Name System (DNS) and Dynamic Host Configuration Protocol (DHCP). Each entry should record the provider, security features, and the business function it supports.
• Pre-procurement security requirements: Define encryption standards, availability targets, monitoring capabilities, and incident response obligations before selecting or renewing a network service provider. Security requirements shouldn’t be retrofitted after contracts are signed.
• Formal agreements: Embed security clauses into Service Level Agreements (SLAs) and contracts. These should specify encryption protocols, incident notification timelines, audit rights, access controls, and data handling obligations.
• Ongoing monitoring and review: Establish continuous or periodic review processes to verify that service delivery matches agreed requirements. This includes tracking uptime, reviewing security event logs, and reassessing provider posture over time.

Most organizations treat network services as a procurement and IT operations concern. Control 8.21 reframes them as a security governance responsibility, requiring the same rigor applied to internal controls to extend across every outsourced network dependency.

Why 8.21 matters

A mid-sized financial services firm outsources its perimeter firewall management to a Managed Security Service Provider (MSSP). The provider’s TLS certificate expires on a Friday evening. Without automated certificate monitoring or contractual notification obligations, the lapse goes undetected for 11 days. During that window, traffic between the firm’s branch offices traverses an unencrypted link. An attacker conducting passive interception on a shared network segment captures authentication tokens, gaining access to an internal application containing customer financial records. The firm only discovers the exposure during a quarterly compliance review, weeks after the data has been exfiltrated.

This type of failure is neither exotic nor unlikely. It stems from a predictable gap: organizations delegate network services to providers, define availability requirements, and then stop paying attention to security posture.

The risk extends well beyond individual incidents. SecurityScorecard found that 35.5% of all data breaches in 2024 originated from third-party compromises, up 6.5% from 2023 (source). Network service providers sit at the center of that exposure. They handle traffic routing, encryption termination, DNS resolution, and access control for the organizations they serve. A security failure at any point in that chain cascades directly into the customer’s environment.

Without 8.21’s requirements, organizations lack the mechanisms to verify that network services meet security expectations. The consequences span three categories. First, operational disruption. A network service failure without documented recovery requirements leaves the organization without contractual leverage to demand rapid restoration. Second, compliance exposure. Auditors will flag the absence of documented security requirements, SLAs without security clauses, and missing monitoring evidence as nonconformities. Third, regulatory risk. Regulators increasingly expect organizations to demonstrate oversight of outsourced infrastructure, not just internal systems. Frameworks like DORA in the EU and CPS 234 in Australia explicitly require documented oversight of third-party ICT services, including network infrastructure.

What attackers exploit

• Unmonitored third-party network connections that provide persistent access without detection
• Missing or inadequate SLAs with no security clauses, leaving no contractual basis for incident response
• Unencrypted traffic on shared network services, enabling passive interception
• No segmentation between tenants on shared infrastructure, allowing lateral movement
• Expired SSL certificates or deprecated protocols (e.g., TLS 1.0) that downgrade connection security
• Lack of logging and monitoring on managed network services, hiding malicious activity
• Shadow network services procured without security review, creating undocumented entry points

How to implement 8.21

For your organization (first-party)

Implementing 8.21 starts with knowing what network services exist and building governance around each one. The following steps move from discovery through ongoing assurance.

1. Inventory all network services. Build a comprehensive register of every network service the organization relies on. This includes ISP connections, VPN concentrators, cloud connectivity services (AWS Direct Connect, Azure ExpressRoute), managed firewall services, SD-WAN deployments, content delivery networks, internal DNS and DHCP services, load balancers, web application firewalls, and any network monitoring or management platforms. For each service, record the provider, contract owner, criticality classification, data sensitivity level, and the business processes it supports. Organizations frequently undercount their network services because shadow IT procurement bypasses centralized tracking. A discovery exercise that cross-references procurement records, cloud account inventories, and firewall rule sets often reveals services that never made it into the official register. The Configuration Management Database (CMDB) methodology from ITIL provides a structured framework for maintaining this inventory alongside broader IT asset management.

2. Define security requirements per service. For each network service, specify the security controls it must satisfy. This includes encryption standards (minimum TLS 1.2 for data in transit, with a migration path to TLS 1.3), availability targets (expressed as uptime percentages with defined Recovery Time Objectives), monitoring requirements (log collection, alerting thresholds), and access control expectations (role-based access, Multi-Factor Authentication (MFA) for administrative interfaces). Requirements should also cover patch management timelines, vulnerability disclosure processes, and geographic restrictions on data routing where regulatory obligations apply. Map these requirements to the organization’s risk appetite and the sensitivity of the data traversing each service. A managed firewall handling payment card data needs stricter controls than an internal DNS resolver serving a development lab.

3. Formalize in SLAs and contracts. Translate security requirements into binding contractual language. SLAs should include encryption obligations, incident notification timelines (e.g., notification within 24 hours of a confirmed security event), audit rights allowing the organization to review provider security controls, data handling and retention obligations, and subcontractor oversight requirements. The Cloud Security Alliance (CSA) STAR program and ISO 27001 Annex A provide reference frameworks for structuring these clauses.

4. Implement technical controls. Enforce encryption in transit for all network services, segment networks to isolate critical traffic from general-purpose services, apply access controls based on the principle of least privilege, and require MFA for all administrative access to network management interfaces. Network segmentation should follow a zero-trust architecture model, where traffic between segments is inspected and authorized regardless of source.

5. Establish monitoring. Deploy centralized log collection from all network services into a Security Information and Event Management (SIEM) platform. Track uptime against SLA commitments, configure alerts for security-relevant events (certificate expiration, configuration changes, unauthorized access attempts), and retain logs for the period required by your compliance obligations. Network Detection and Response (NDR) tools add behavioral analysis for identifying anomalous traffic patterns that signature-based detection misses.

6. Schedule periodic reviews. Conduct formal reviews of each network service provider at least annually, comparing actual service delivery against agreed requirements. For higher-risk services, increase review frequency to semi-annual or quarterly. Review security incident history, assess any changes to the provider’s security posture, validate certificate and protocol configurations, and update the service inventory to reflect any changes. Trigger ad hoc reviews after significant events such as provider acquisitions, major outages, or publicized security incidents affecting the provider’s infrastructure. Document review outcomes, remediation actions, and target dates for resolving identified gaps.

Evidence to produce: Network service inventory with owners and classification, SLA register with security clauses, monitoring dashboards and alert configurations, periodic review records with findings and actions.

Common mistakes:

• Treating network services as a pure IT concern with no documented security requirements
• Signing contracts without security SLAs or audit rights
• Monitoring availability only (uptime) without monitoring security posture
• Failing to review network service providers after initial onboarding
• No segmentation between production and development environments on shared services

For your vendors (third-party assessment)

When assessing whether vendors and suppliers meet the intent of 8.21, structure the evaluation around four categories.

Security questionnaire questions: Ask vendors to describe their encryption standards for data in transit and at rest, incident response SLAs (detection-to-notification timelines), administrative access controls and authentication mechanisms, subcontractor oversight processes (how they govern their own suppliers), change management procedures for network configuration modifications, and current certification status (ISO 27001, SOC 2 Type II, or equivalent). Questions should be specific and measurable. “Describe your encryption standards” yields more useful responses than “Do you use encryption?”

Evidence to request: Current ISO 27001 certificate with scope statement confirming network services are included, SOC 2 Type II report covering the relevant trust services criteria, penetration test summaries from the past 12 months, uptime and availability reports for the contracted period, network architecture diagrams showing segmentation and encryption points, and business continuity or disaster recovery plans covering the specific services provided. Pay attention to the scope of certifications. An ISO 27001 certificate that covers a vendor’s corporate IT but excludes the managed network services they deliver to customers provides limited assurance.

Red flags during assessment:

• No third-party certifications or independent attestation reports
• Vague security commitments without measurable targets (e.g., “we take security seriously” without defined SLAs)
• Refusal to share incident history or penetration test results
• No encryption in transit between provider infrastructure and customer environments
• Inability to describe subcontractor oversight processes

Verification methods: Request independent attestation reports (SOC 2, ISO 27001 surveillance audit reports) rather than relying solely on self-assessments. Check certificate validity and expiration dates directly. Test connectivity encryption using tools like SSL Labs or testssl.sh to verify protocol versions and cipher suites. Review network architecture documentation for segmentation controls between tenants. Where possible, validate claims through technical testing rather than documentation alone. A provider’s assertion that all traffic is encrypted can be verified in minutes by inspecting the connection parameters from the customer side.

Audit evidence for 8.21

Auditors evaluating 8.21 compliance look for documented evidence across policy, operational, contractual, technical, review, and incident response categories. The key test is whether the organization can demonstrate a systematic approach to managing network service security rather than ad hoc or reactive measures.

Cross-framework mapping

Control 8.21 aligns with requirements across several major compliance and security frameworks. Organizations subject to multiple frameworks can use these mappings to demonstrate overlapping coverage and reduce duplicated assessment effort. Partial coverage indicates the framework addresses some but not all aspects of 8.21’s requirements, typically covering the technical controls without the full governance and monitoring expectations.

Related ISO 27001 controls

Control 8.21 operates within a network of related controls that collectively govern network security, supplier oversight, and technical safeguards. Implementing 8.21 in isolation weakens its effectiveness because network service security depends on supporting controls for encryption, segmentation, monitoring, and supplier governance.

Frequently asked questions

What is ISO 27001 8.21?

ISO 27001 control 8.21 requires organizations to identify, document, and manage the security requirements of all network services, both in-house and outsourced. This includes formalizing expectations in SLAs, defining encryption and access control standards, and continuously monitoring whether providers deliver against those requirements. The control applies to every network service the organization uses, from ISP connections to managed cloud services.

What happens if 8.21 is not implemented?

Organizations lose visibility into the security posture of the network services they depend on. Unencrypted traffic, unmonitored third-party access, and missing contractual protections create exploitable gaps. Auditors will raise nonconformities for undocumented network service requirements and absent monitoring evidence, which can delay certification or trigger corrective action requirements during surveillance audits.

How do you audit 8.21?

Start with the network service inventory to confirm all services are cataloged with owners and classification. Review SLAs and contracts for security clauses, incident notification requirements, and audit rights. Examine monitoring evidence including uptime reports, SIEM outputs, and certificate validation records. Check periodic review documentation and incident response procedures.

How UpGuard helps

• Vendor Risk: Continuously monitors the security posture of network service providers, automates vendor assessments with AI-powered security questionnaires, and tracks compliance against your defined requirements through centralized dashboards and reporting.
• Breach Risk: Scans your external attack surface to detect exposed network services, expired certificates, and deprecated protocols before attackers exploit them.

Start a free trial to experience the UpGuard cybersecurity platform.