Auditing ISO 27001 Annex A 8.22 Segregation of Networks is the technical verification of traffic isolation and boundary protection mechanisms within the organisational infrastructure. The Primary Implementation Requirement is the logical or physical separation of security zones, providing the Business Benefit of preventing lateral threat movement and protecting sensitive information assets from unauthorised access.
ISO 27001 Annex A 8.22 Segregation of Networks Audit Checklist
This technical verification tool is designed for lead auditors to establish the security integrity of network boundaries and traffic isolation. Use this checklist to validate compliance with ISO 27001 Annex A 8.22.
1. Network Segregation Policy Formalisation Verified
Verification Criteria: A documented policy or architectural standard exists defining the criteria for segregating networks into distinct security zones based on risk, business function, and data sensitivity.
Required Evidence: Approved Network Architecture Standard or Segregation Policy with defined trust boundaries.
Pass/Fail Test: If the organisation cannot produce a formal document defining the logical or physical boundaries of its network zones, mark as Non-Compliant.
2. Logical Zone Isolation via VLANs Confirmed
Verification Criteria: Logical segregation is implemented using Virtual Local Area Networks (VLANs) to separate functional departments and sensitive asset classes (e.g., HR, Finance, Production).
Required Evidence: Running configurations from core and distribution switches showing defined VLAN IDs and associated port assignments.
Pass/Fail Test: If critical servers and general staff workstations reside on a single, unsegmented “flat” network, mark as Non-Compliant.
3. Perimeter Segregation (DMZ) Integrity Validated
Verification Criteria: Public-facing services (Web, Mail gateways) are isolated within a Demilitarised Zone (DMZ), preventing direct external access to the internal trusted network.
Required Evidence: Firewall rule base and topology diagrams showing three-pronged or back-to-back firewall architecture isolating the DMZ.
Pass/Fail Test: If a public-facing web server has direct, unfiltered routing to the internal production database, mark as Non-Compliant.
4. Wireless Network Traffic Segregation Verified
Verification Criteria: Guest wireless networks are physically or logically isolated from the corporate network, with no internal routing permitted.
Required Evidence: Wireless Controller (WLC) configuration or Firewall ACLs showing the “Guest” SSID is mapped to a restricted VLAN with internet-only access.
Pass/Fail Test: If an unauthenticated guest user can ping or access internal corporate resources (e.g., printers or file shares), mark as Non-Compliant.
5. Micro-segmentation for Critical Assets Confirmed
Verification Criteria: Highly sensitive assets (e.g., PCI-DSS card data or PII) are protected by granular micro-segmentation or host-level firewalls to prevent lateral movement.
Required Evidence: Configuration logs from SDN (Software Defined Networking) tools or host-based firewall policy reports (e.g., iptables, Windows Firewall).
Pass/Fail Test: If an attacker who compromises one server in a zone can move laterally to any other server in that zone without technical restriction, mark as Non-Compliant.
6. Cross-Zone Traffic Filtering (ACLs) Validated
Verification Criteria: Traffic between defined network segments is restricted by Access Control Lists (ACLs) on routers or firewalls, following the principle of “Default Deny.”
Required Evidence: Firewall rule set showing specific “Permit” rules followed by a “Deny All” cleanup rule for inter-zone traffic.
Pass/Fail Test: If inter-VLAN routing is enabled on core switches without any associated ACLs or firewall filtering, mark as Non-Compliant.
7. Management Network Segregation Verified
Verification Criteria: Network management interfaces (SSH, GUI) and monitoring traffic are isolated on a dedicated Out-of-Band (OOB) management network.
Required Evidence: Physical or logical network map showing a dedicated management VLAN/Network with restricted access controls.
Pass/Fail Test: If administrative interfaces for firewalls or switches are accessible from the general staff network, mark as Non-Compliant.
8. Third-Party/Contractor Network Segregation Confirmed
Verification Criteria: Third-party partners or contractors accessing the network are restricted to a segregated “Partners” zone with limited visibility into the wider environment.
Required Evidence: VPN configuration profiles or dedicated VLAN settings specifically for external partner identities.
Pass/Fail Test: If a third-party VPN tunnel grants broad access to the internal network beyond the specific services required for their contract, mark as Non-Compliant.
9. Cloud VPC/VNet Isolation Validated
Verification Criteria: Cloud environments (AWS, Azure, GCP) use Virtual Private Clouds (VPCs) or VNets with segregated subnets and Security Groups to maintain workload isolation.
Required Evidence: Cloud Security Posture Management (CSPM) reports or console exports showing “Inbound/Outbound” rules for specific subnets.
Pass/Fail Test: If a cloud production environment shares the same VPC/Subnet as the development environment without a stateful firewall separating them, mark as Non-Compliant.
10. Periodic Segregation Efficacy Audits Recorded
Verification Criteria: The organisation performs regular technical verification (e.g., VLAN hopping tests or internal port scans) to ensure segregation remains effective.
Required Evidence: Internal vulnerability scan reports or penetration test results specifically testing inter-segment isolation.
Pass/Fail Test: If the organisation has not performed a technical review of its network boundaries and firewall rule-base in the last 12 months, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Zone Definition | Tool checks if an “Architecture PDF” is uploaded. | Verify Reality. A PDF is a plan. The auditor must check switch configs to see if VLAN 10 (Finance) is actually routed to VLAN 20 (Public). |
| Guest Isolation | Platform identifies that “Guest Wi-Fi” exists as a line item. | Test Routing. An auditor should join Guest Wi-Fi and attempt to scan the internal gateway; if successful, segregation is a failure. |
| Firewall Efficacy | Tool identifies “Firewall: Enabled” via a cloud API. | Inspect Rule Logic. “Enabled” doesn’t mean “Secure.” A GRC tool often misses “Allow Any-Any” rules within a VNet. |
| Micro-segmentation | SaaS tool records “Workload Security Active.” | Verify Lateral Prevention. Check if two servers in the same tier can talk to each other on non-essential ports (e.g., RPC/SMB). |
| OOB Management | Tool assumes management is secure because of MFA. | Check Pathing. If management traffic traverses the same physical/logical path as data traffic, a saturating attack will kill management. |
| Legacy Protocols | Platform ignores “VLAN 1” usage. | Verify Native VLAN. If the organisation uses default VLAN 1 for production, it is susceptible to VLAN hopping attacks. |
| Audit Frequency | Tool sets a task to “Review Network” once a year. | Check Drift. Network changes happen daily. Annual GRC tasks are useless for catching ad-hoc “temporary” firewall bypasses. |
Stop Guessing. Start Passing.
AI-generated policies are generic and fail audits. Our Lead-Auditor templates have a 100% success rate. Don’t risk your certification on a prompt