A.8.20 through A.8.22 — Network Security and Web Filtering
Executive Summary: The Network Security Foundation
• Controls A.8.20-A.8.22 form the technical security backbone that determines whether your ISMS actually protects information or merely documents good intentions
• Network segregation (A.8.22) is the single most effective control for preventing lateral movement during security incidents
• Web filtering has evolved from URL blocking to comprehensive threat intelligence integration, requiring alignment across multiple frameworks
• Cross-framework mappings reveal these controls as foundational requirements across NIST CSF, CMMC, TISAX, and SOC 2 — get them wrong and everything else fails
Network security controls in ISO 27001:2022 have evolved significantly from their 2013 predecessors, and controls A.8.20 through A.8.22 represent the foundation of what most organizations actually need to get right before anything else matters. I've watched companies invest hundreds of thousands in sophisticated endpoint detection and response platforms while their network segmentation resembles a college dorm room setup—flat networks where a compromised workstation in accounting becomes direct access to production databases.
These three controls—Network security, Security of network services, and Segregation of networks—along with the increasingly critical topic of web filtering, form the backbone of technical security that auditors scrutinize carefully. Failures here cascade into everything else. When TS 27008 guidance emphasizes "effective implementation," it's specifically referencing whether these foundational network controls actually function as intended, not just whether they're documented.
A.8.20 — Network Security: Beyond Firewall Rule Archaeology
Control A.8.20 requires that networks and network devices be managed and controlled to protect information in systems and applications. This sounds straightforward until you start pulling threads during an audit and discover that "managed and controlled" means wildly different things across industries and organization types.
The control demands establishment and implementation of controls for the security of information in networks. What I see most often resembles network archaeology—firewalls configured years ago by departed personnel, with rules referencing decommissioned servers and protocols nobody remembers authorizing. One manufacturing client I audited had 847 firewall rules, of which 312 referenced IP addresses no longer in their network. Their "annual review" consisted of verifying the firewall was still running.
Multi-Standard Integration for A.8.20
ISO 27033-1 provides the architectural foundation that A.8.20 references, but implementation requires understanding how this control maps across frameworks:
- NIST CSF 2.0: PR.AC-5 (Network integrity protection) and DE.AE-2 (Potentially harmful events analyzed)
- CMMC 2.0: AC.L2-3.1.20 (Control information system access) and SC.L2-3.13.1 (Monitor network communications)
- TISAX: Corresponds to VDA ISA 5.1 (Network and system security) with automotive-specific hardening requirements
- SOC 2: CC6.1 (Logical access controls) and CC7.1 (System monitoring)
Effective implementation of A.8.20 demands several concrete elements that satisfy requirements across these frameworks:
Network Architecture Documentation
Document current network architecture that reflects reality, not the sanitized version from three years ago. This includes all the accumulated technical debt—shadow IT connections, temporary VPN links that became permanent, and IoT devices nobody documented. ISO 27033-1 emphasizes that network architecture documentation must support risk assessment activities, meaning it needs sufficient detail to identify trust boundaries and data flows.
Configuration Management Standards
Establish configuration standards for all network devices—routers, switches, firewalls, wireless access points—that specify hardening requirements, authentication mechanisms, and change control procedures. The standards must address both legacy equipment and emerging technologies like SD-WAN controllers and cloud network services.
Monitoring and Detection Capabilities
Implement monitoring that detects anomalous traffic patterns, unauthorized connection attempts, and policy violations. This isn't just SIEM log aggregation—it requires understanding normal network behavior patterns and establishing meaningful thresholds for alerting.
Regular Review Processes
Conduct periodic reviews of firewall rules, access control lists, and routing tables. If your last comprehensive firewall rule review predates the current presidential administration, you have a gap that auditors will identify immediately.
Industry-Specific Implementation Examples
A financial services firm I worked with discovered during implementation that their network monitoring was generating 40,000 security alerts daily, of which fewer than 50 represented actual security events. The noise-to-signal ratio made their SIEM essentially useless. We implemented traffic flow analysis to establish baseline patterns before tuning detection rules—a process that reduced false positives by 94% while improving detection of actual threats.
In contrast, a healthcare organization had the opposite problem—minimal monitoring that missed lateral movement during a ransomware incident because they treated their internal network as trusted. Post-incident analysis revealed the attacker had maintained persistence for 76 days before triggering encryption, moving laterally through unmonitored internal segments.
A.8.21 — Security of Network Services: Your Vendors Are Your Problem
A.8.21 extends network security to include services obtained from network service providers, whether in-house or outsourced. This control recognizes that your network security perimeter extends through every ISP, managed service provider, and cloud connection your organization relies upon.
The control requires identification, implementation, and monitoring of security mechanisms, service levels, and service requirements of network services. Here's where most organizations fail: they treat their ISP connection as a utility like electricity or water. You don't audit your power company's security practices, so why bother with network providers?
Because your power company can't exfiltrate your customer database.
Cross-Framework Requirements for Network Services
Network service security requirements appear across multiple compliance frameworks with varying levels of prescription:
- NIST CSF 2.0: ID.SC-4 (Suppliers characterized and understood) and PR.IP-9 (Response plans tested)
- CMMC 2.0: SR.L2-3.14.1 (Service provider risk management) and SI.L2-3.14.2 (External service monitoring)
- SOC 2: CC9.1 (Vendor risk management) requires documented vendor security assessment processes
- TISAX: Extends requirements to automotive supply chain network connections with specific assessment criteria
Service Agreement Security Requirements
Develop service agreements that specify security requirements beyond availability SLAs. Document encryption standards, access controls, logging capabilities, and incident response coordination. The agreements should address what happens to your traffic during normal operations and how security is maintained during service provider incidents or maintenance windows.
Third-Party Risk Assessment
Implement right-to-audit clauses or accept third-party attestations (SOC 2, ISO 27001 certification) that demonstrate adequate security practices. For critical network services, this might include on-site assessments or penetration testing coordination.
Incident Coordination Procedures
Establish incident notification requirements specifying how quickly providers must notify you of security events affecting your services, and coordinate response activities when incidents span multiple service providers.
Real-World Service Provider Risks
A financial services firm I audited had meticulously secured their primary data center but used a small regional ISP for their disaster recovery site connection. During the audit, we discovered the ISP had no formal security program, no SOC report, and couldn't describe their own incident response capabilities. The backup connection was essentially an unmonitored attack vector—one that would become active precisely when the organization was most vulnerable during a disaster recovery scenario.
Another organization learned this lesson the hard way when their managed firewall provider experienced a security incident that resulted in configuration changes being pushed to customer firewalls without notification. The changes opened unexpected ports and created new attack vectors. The organization only discovered this during their own vulnerability assessment two months later.
The connection to ISO 27001 Clause 8.1 (operational planning and control) is critical here—managing outsourced processes includes network services, even if you've never thought of your ISP connection as an outsourced process requiring security oversight.
A.8.22 — Segregation of Networks: The Control That Prevents Lateral Movement
If I had to select one technical control that separates organizations serious about security from those performing compliance theater, it's A.8.22. Network segregation—properly implemented—prevents compromised workstations from becoming direct access to production systems, intellectual property repositories, and customer data.
The control requires groups of information services, users, and information systems to be segregated in networks. The standard doesn't prescribe implementation methods—VLANs, physical separation, software-defined networking, or hybrid approaches all satisfy the requirement if properly configured and maintained.
Multi-Framework Network Segregation Requirements
Network segregation appears as a fundamental requirement across frameworks, each with specific implementation guidance:
- NIST CSF 2.0: PR.AC-4 (Access permissions managed) and PR.DS-5 (Protections against data leaks implemented)
- CMMC 2.0: AC.L2-3.1.3 (Information flow enforcement) with specific requirements for CUI protection
- TISAX: Requires segregation of automotive supplier networks from other business networks
- SOC 2: CC6.6 (Logical access controls restrict access) includes network-level access controls
- ISO 27033-1: Provides detailed guidance on network domain segregation strategies
Trust-Based Segmentation Architecture
Design network segments based on trust levels, data classification, and business function rather than traditional departmental boundaries. This might include public-facing services, user workstation networks, administrative networks, production systems, and development environments as separate trust zones.
Inter-Segment Access Controls
Implement controlled access between network segments using firewalls, application-layer gateways, or zero-trust network access solutions. The access controls should enforce least-privilege principles and log all inter-segment communications for monitoring and auditing.
Wireless Network Isolation
Treat wireless networks as separate security domains, particularly guest networks and IoT device connections. Wireless access points should connect to isolated network segments until devices authenticate and pass security policy compliance checks.
Industry-Specific Segregation Examples
A manufacturing organization implemented network segregation to separate operational technology (OT) networks from information technology (IT) networks. The segregation included industrial control systems, SCADA networks, and IoT sensors on isolated network segments with controlled bridges to business systems. During a security incident affecting the corporate network, production systems continued operating normally because the attack couldn't traverse segment boundaries.
A healthcare organization used network segregation to separate patient care networks from administrative systems and research networks. Medical devices, electronic health record systems, and clinical workstations operated in isolated segments with application-layer gateways providing controlled access to shared resources like directory services and network time protocol servers.
Web Filtering: The Evolved Network Security Control
While not explicitly called out in ISO 27001:2022, web filtering has become fundamental to network security implementation and appears in audit findings related to A.8.20, A.8.24 (cryptography use), and A.5.10 (acceptable use of information and other associated assets).
Modern web filtering extends far beyond URL category blocking to include threat intelligence integration, SSL/TLS inspection, and real-time risk assessment of web content. The technology has evolved from simple blacklist/whitelist approaches to sophisticated analysis of web traffic patterns, DNS requests, and content delivery mechanisms.
Web Filtering Cross-Framework Integration
Web filtering capabilities support requirements across multiple frameworks:
- NIST CSF 2.0: DE.AE-3 (Event data aggregated and correlated) and PR.IP-1 (Baseline network configuration)
- CMMC 2.0: SI.L1-3.14.1 (Flaw remediation) and SI.L2-3.14.4 (Malicious code protection)
- SOC 2: CC7.2 (System monitoring includes network traffic analysis)
Threat Intelligence Integration
Configure web filtering to integrate with threat intelligence feeds that provide real-time information about malicious domains, IP addresses, and URL patterns. This should include both commercial threat intelligence services and information sharing platforms relevant to your industry.
SSL/TLS Inspection Capabilities
Implement SSL/TLS inspection for encrypted web traffic where legally and technically feasible. This requires careful consideration of privacy requirements, certificate management, and potential impact on application performance.
Policy Enforcement and Monitoring
Establish web filtering policies that align with acceptable use requirements and monitor policy violations as potential security indicators. The monitoring should distinguish between policy violations that represent productivity concerns versus those indicating potential security compromises.
Implementation Challenges and Solutions
A government agency discovered that their web filtering solution was blocking legitimate software updates and security patches, creating vulnerabilities while attempting to enhance security. We implemented application-aware filtering rules that permitted necessary software update traffic while maintaining protection against malicious downloads.
A professional services firm found that aggressive SSL inspection was breaking client VPN connections and cloud application functionality. The solution involved implementing selective SSL inspection based on destination categories and risk assessment rather than universal inspection that impacted business operations.
Common Audit Findings for Network Security Controls
Based on hundreds of ISO 27001 audits, these network security findings appear repeatedly across industries and organization sizes:
Documentation and Configuration Issues
- Outdated network diagrams: Documentation that doesn't reflect current network architecture, missing recent infrastructure changes or cloud service integrations
- Firewall rule creep: Accumulated firewall rules that haven't been reviewed or validated, often including temporary rules that became permanent
- Inconsistent hardening: Network devices configured with different security standards or default configurations still in place
Monitoring and Detection Gaps
- Log aggregation without analysis: Collecting network device logs without implementing meaningful analysis or alerting capabilities
- Missing baseline establishment: Network monitoring without established baselines for normal traffic patterns or behavior
- Alert fatigue: Monitoring systems generating too many false positive alerts, resulting in ignored legitimate security events
Segregation Implementation Problems
- VLAN leakage: Network segregation that doesn't properly isolate traffic due to misconfigured trunk ports or routing protocols
- Administrative access paths: Segregated networks with shared administrative access that bypasses segmentation controls
- Exception proliferation: Network segregation policies with so many exceptions that the segregation becomes ineffective
Integration with Broader ISO 27xxx Standards
Network security controls integrate with multiple ISO 27xxx standards to provide comprehensive security management:
ISO 27002:2022 Implementation Guidance
ISO 27002:2022 provides detailed implementation guidance for network security controls, including specific techniques for network monitoring, traffic filtering, and segregation implementation. The guidance emphasizes risk-based approaches to network security that align with organizational threat models.
ISO 27033 Network Security Series
The ISO 27033 series provides comprehensive guidance on network security architecture, design, and implementation. ISO 27033-1 establishes the conceptual framework that supports A.8.20-A.8.22 implementation, while subsequent parts address specific network technologies and scenarios.
ISO 27035 Incident Management Integration
Network security controls provide detection and containment capabilities that support incident management processes defined in ISO 27035. Network monitoring generates security event data that feeds incident detection and analysis processes.
Emerging Technologies and Future Considerations
Network security control implementation must address emerging technologies and evolving threat landscapes:
Software-Defined Networking (SDN)
SDN technologies enable more dynamic and granular network security controls but require new approaches to configuration management and change control. Traditional firewall rule review processes must evolve to address programmatically managed network policies.
Zero Trust Network Architecture
Zero trust principles extend network segregation concepts to assume no implicit trust based on network location. This requires enhanced authentication, encryption, and monitoring capabilities that go beyond traditional perimeter-based security models.
Cloud and Hybrid Network Security
Organizations using cloud services must extend network security controls to include cloud provider networks, hybrid connectivity, and shared responsibility models. This includes understanding how network security controls apply to infrastructure as a service, platform as a service, and software as a service environments.
Building a Risk-Based Implementation Strategy
Successful implementation of network security controls requires a risk-based approach that considers organizational context, threat landscape, and resource constraints:
Risk Assessment Integration
Network security control selection and implementation should be based on risk assessment findings that identify critical information assets, potential threat scenarios, and vulnerability exposure. This ensures that security investments address the most significant risks to the organization.
Phased Implementation Approach
Implement network security controls in phases that prioritize critical systems and high-risk scenarios. This allows organizations to achieve immediate security improvements while building capabilities for more comprehensive security architecture.
Continuous Improvement Process
Establish processes for continuously improving network security controls based on threat intelligence, incident lessons learned, and technology evolution. This includes regular review and updating of network security architecture, policies, and procedures.
Network security controls A.8.20 through A.8.22 represent the foundation that determines whether your ISO 27001 implementation actually protects information or merely documents good intentions. Organizations that invest the time and resources to properly implement these controls—with comprehensive monitoring, effective segregation, and risk-based architecture—create a security foundation that supports all other ISMS components.
Those that treat these controls as checkbox exercises typically discover their shortcomings during security incidents, when compromised systems provide attackers with broad network access and minimal detection capabilities. The difference between effective implementation and compliance theater becomes clear when these controls face real-world threats.
Need help designing a network security architecture that satisfies ISO 27001 requirements while supporting your business objectives? Book a consultation to discuss your specific situation and develop a risk-based implementation strategy.
For deeper dives into related topics, explore our comprehensive guides on ISO 27001 risk assessment methodology, incident management integration, and cloud security implementation within ISO 27001 frameworks.
Related Articles
- A.8.1 through A.8.5 — Endpoint Devices Access Rights and Authentication
- A.8.6 through A.8.8 — Capacity Malware and Vulnerability Management
- A.8.9 and A.8.10 — Configuration Management and Data Deletion
- Annex A.5.1 through A.5.4 — Information Security Policies and Roles
- A.7.1 through A.7.4 — Physical Perimeters Entry and Securing Facilities
💬 Got ISO 27001 Questions?
Our AI-powered ISO 27001 expert is available 24/7 in 12 languages. Get instant, accurate answers about implementation, controls, audits, and certification.