ISO 27001 Control 8.22: Segregation of Networks

A single compromised endpoint on a flat network can reach every database, file server, and production system within minutes. Attackers who gain a foothold through a phishing email or unpatched workstation don’t need sophisticated tools to escalate their impact when nothing stops lateral movement. Ransomware spreads from user workstations to domain controllers to backup servers because the network treats all traffic as equally trusted. ISO 27001 Control 8.22 exists to prevent exactly this failure by mandating deliberate segregation of networks into distinct security zones.

What 8.22 requires

ISO 27001 Control 8.22 requires organizations to divide their networks into logical domains or security zones based on trust levels and business needs, directly limiting how far any breach, error, or malware can travel before hitting a boundary. The control’s official objective frames this as containment architecture, requiring organizations to segregate networks to prevent unauthorized lateral movement between zones and ensure that a compromise in one domain cannot freely propagate to others.

In practice, this means organizations must identify distinct groups of users, services, and information systems and assign each to a defined network domain. A finance team’s workstations occupy a different zone than production database servers, which occupy a different zone than guest Wi-Fi endpoints. Traffic between these zones doesn’t flow freely. Instead, it passes through explicitly configured gateways such as firewalls, application-layer filters, or routing controls that enforce which communication is permitted and which is denied by default.

The separation applies across all network types, including wired, wireless, cloud-hosted, and hybrid environments. Virtual Local Area Networks (VLANs), Virtual Private Clouds (VPCs), and physical air gaps are all valid implementation mechanisms, but the mechanism matters less than the principle. Every zone boundary must enforce deliberate access decisions. This is architectural intent, not network convenience. Organizations that treat their networks as a single flat domain are effectively choosing to let any compromise propagate to every connected system without resistance.

Control 8.22 also requires that these segregation decisions are documented and reviewed periodically. The network architecture must reflect current business needs and threat models, not the organic growth patterns from years of ad hoc deployments. When new systems are added, when business units merge, or when cloud migrations shift workloads between environments, the segregation architecture must be reassessed.

Why 8.22 matters

An attacker compromises a Tier 2 support analyst’s workstation through a credential-stuffing attack against a reused password. From that endpoint, they scan the local subnet and discover database servers hosting customer records on the same network segment with no firewall rules restricting access between user workstations and server tiers. Within hours, they’ve exfiltrated sensitive data and deployed ransomware across production systems. The entire incident chain, from initial access to full-environment compromise, succeeds because the network architecture offered zero internal resistance.

This scenario plays out repeatedly across industries. The 2025 Illumio report reveals that nearly 90% of organizations experienced some form of lateral movement in the past year, underscoring how pervasive the problem remains despite years of industry guidance on network segregation. The pattern is consistent. Attackers gain initial access through a relatively low-value endpoint, then move unrestricted to high-value targets because the network offers no internal resistance.

When ransomware lands on a workstation connected to a flat network, every reachable system becomes a target. The risk class spans confidentiality (data exfiltration), integrity (system tampering), and availability (ransomware-driven outages). The resulting attack surface extends to every system on the flat network. This combination makes flat network architectures one of the highest-impact gaps an organization can carry. A breach that could have been contained to a single user segment instead becomes an enterprise-wide incident requiring full-environment recovery.

What attackers exploit

• Flat networks with no segregation between user endpoints and server tiers, allowing unrestricted scanning and lateral movement from any compromised host
• Guest Wi-Fi bridged to corporate networks, giving unauthenticated devices a direct path to internal resources
• Unrestricted third-party and vendor network access, where VPN connections terminate inside production segments without dedicated isolation
• Missing or overly permissive firewall rules between zones, including legacy “any-to-any” rules that negate the purpose of VLAN assignments
• Dual-homed systems that bridge otherwise segregated network segments, bypassing perimeter controls entirely
• Lack of monitoring at network boundaries, meaning cross-zone traffic violations go undetected for days or weeks

How to implement 8.22

For your organization

Most organizations that fail to implement effective segregation don’t lack the technical capability. They lack a systematic approach. Network architectures accumulate organically over years, with new subnets, cloud workloads, and vendor connections added without revisiting the overall zone model. Effective segregation follows a structured sequence that starts with visibility into what you’re protecting and builds outward to enforcement and monitoring.

1. Map and classify network assets by sensitivity, criticality, and function. Before defining zones, you need a complete inventory of what sits on the network. Classify assets using a tiering model: Tier 1 (critical infrastructure and sensitive data stores), Tier 2 (business applications and internal services), Tier 3 (general user endpoints), and Tier 4 (guest and untrusted devices). Tools like network discovery scanners and Configuration Management Databases (CMDBs) provide the foundation for this mapping.

2. Define network domains. Based on your asset classification, establish distinct domains: user endpoints, application servers, database servers, management and administration networks, Demilitarized Zones (DMZs) for public-facing services, guest networks, and third-party/vendor segments. Each domain should reflect a consistent trust level and functional purpose.

3. Implement logical segregation using VLANs, VPCs, or physical separation. VLANs remain the most common mechanism in on-premises environments, configured on managed switches with IEEE 802.1Q trunking between network devices. In cloud infrastructure, VPCs, security groups, and network ACLs provide equivalent segregation capabilities with the added benefit of software-defined policy management. For environments handling classified or highly regulated data, physical separation (air-gapped networks) may be required by frameworks such as IEC 62443 for industrial control systems. Choose the mechanism based on your risk profile, compliance requirements, and operational constraints.

4. Deploy firewalls and Access Control Lists (ACLs) at every zone boundary with a default-deny posture. Every inter-zone boundary needs an enforcement point. Start with a deny-all baseline and explicitly permit only the traffic flows required for business operations. Document each permitted flow with a business justification. Next-generation firewalls that perform application-layer inspection provide stronger enforcement than port-based ACLs alone.

5. Segregate wireless networks explicitly. Treat all wireless networks as untrusted by default. Corporate wireless should authenticate users via 802.1X with certificate-based or RADIUS authentication and place them into the appropriate VLAN based on their role. Guest wireless must terminate in a completely isolated segment with internet-only access.

6. Isolate third-party connections to dedicated segments. Vendor VPN connections, managed service provider access, and partner integrations should terminate in purpose-built network zones with their own firewall policies. These segments should permit only the minimum connectivity required for the vendor’s function, monitored and logged independently. Apply the principle of least privilege at the network layer by restricting vendor access to specific destination hosts and ports rather than granting broad subnet access.

7. Prevent unauthorized bridging. Dual-homed systems (hosts with network interfaces in multiple zones) create bypass paths that undermine segregation. Establish policies prohibiting unauthorized multi-homed configurations, and use endpoint detection tools to identify systems with multiple active network interfaces.

8. Document network architecture comprehensively. Maintain current network diagrams showing all segments, trust boundaries, gateway devices, and inter-zone traffic flows. Include domain definitions, boundary control specifications, and the business rationale for each permitted flow. Use a standardized diagramming approach (such as NIST’s network architecture documentation guidelines or the Zachman Framework for infrastructure views) to ensure consistency. This documentation serves both operational and audit purposes, and it becomes the primary artifact auditors request during ISO 27001 certification assessments.

9. Implement centralized logging at boundaries. Forward all firewall logs, ACL denies, and inter-zone traffic records to a Security Information and Event Management (SIEM) platform. Build detection rules for anomalous cross-zone traffic patterns, unauthorized scanning activity, and policy violations. Effective detection signatures include alerts for any traffic from user segments to database ports that bypasses the application tier, connections from guest networks to internal resources, and unexpected protocol usage at zone boundaries. NetFlow or sFlow data provides additional visibility into traffic volumes and patterns between zones.

10. Review segregation after changes, incidents, or system additions. Network architecture isn’t static. Every infrastructure change, security incident, or new system deployment should trigger a review of whether existing segregation boundaries remain appropriate and effective. Schedule periodic reviews (at minimum quarterly) even without triggering events, and incorporate segregation validation into your vulnerability management and penetration testing programs. Many organizations adopt the Purdue Model or similar reference architectures to maintain a consistent framework for evaluating whether their zone definitions remain aligned with operational requirements.

Common mistakes to avoid:

• Allowing “any-to-any” rules between VLANs, which makes segregation cosmetic rather than functional
• Treating wireless networks as internal by default without separate authentication and VLAN assignment
• Not isolating guest Wi-Fi from corporate network segments
• Failing to document or periodically review network architecture diagrams and firewall rules
• Leaving legacy flat-network segments in place after a partial migration to segregated architecture
• Granting third-party VPN connections unrestricted access to internal network segments

For your vendors

When assessing whether a vendor has implemented adequate network segregation, questionnaire-based evaluation needs to go beyond surface-level yes/no responses. The goal is to understand the vendor’s actual network architecture and whether they’ve made deliberate segregation decisions or inherited a flat topology from their early infrastructure.

Questionnaire questions to include:

• “Describe how your production network is segmented into distinct security zones.”
• “Are guest and corporate networks isolated? What controls enforce this separation?”
• “How do you restrict lateral movement between network segments?”
• “What controls govern third-party network access to your environment?”

Evidence to request:

• Network architecture diagrams showing all segments, trust boundaries, and inter-zone gateways
• Firewall rule summaries demonstrating default-deny posture and documented exceptions
• Penetration test results with scope explicitly covering segmentation verification between zones

Red flags during assessment:

• No network diagram available or willingness to share one
• “Flat network” described as the current architecture
• Guest Wi-Fi on the same VLAN as production workloads
• No firewall or access controls between development, staging, and production environments
• Inability to describe or name trust zones within their infrastructure

Verification beyond self-attestation:

Request penetration test reports with scope that specifically validates segmentation controls. Ask for firewall rule exports covering inter-zone boundaries. Cross-reference vendor claims against their SOC 2 Type II report, specifically the network security controls section, to verify that an independent auditor has validated their segregation architecture. If the vendor operates in a cloud environment, request evidence of VPC configuration, security group rules, and network access control lists that demonstrate isolation between environments. Vendors that can’t produce any of this evidence warrant elevated risk ratings in your Third-Party Risk Management (TPRM) program.

Audit evidence for 8.22

Preparing for an ISO 27001 audit against Control 8.22 requires demonstrating that network segregation exists as a deliberate, documented, and maintained security architecture. Auditors will look for evidence that zones are defined, boundaries are enforced, and the architecture is reviewed in response to changes. The following table summarizes the key evidence types and what each should contain.

Cross-framework mapping

ISO 27001 8.22 aligns with network segregation and boundary protection requirements across major compliance frameworks. The following mapping helps organizations that maintain multiple certifications identify where 8.22 evidence satisfies parallel obligations.

Related ISO 27001 controls

Control 8.22 operates within a broader set of ISO 27001 Annex A controls that collectively address network security, access management, and monitoring. Understanding these relationships helps organizations build cohesive control implementations rather than treating each requirement in isolation.

Frequently asked questions

What is ISO 27001 8.22?

ISO 27001 Control 8.22 requires organizations to segregate their networks into distinct security zones based on trust levels and business needs. The control’s purpose is to contain security breaches by limiting lateral movement between network segments, ensuring that a compromise in one zone cannot freely propagate to others.

What happens if 8.22 is not implemented?

Without network segregation, a single compromised endpoint can reach every system on the network. Attackers exploit flat networks for lateral movement, enabling ransomware to spread from user workstations to production databases and backup systems. During an ISO 27001 audit, the absence of segregation controls would result in a nonconformity finding against Annex A 8.22.

How do you audit 8.22?

Auditors verify 8.22 by reviewing network architecture diagrams, firewall rule sets, and VLAN/VPC configurations to confirm that distinct security zones exist with enforced boundaries. Penetration test reports that specifically test segmentation controls provide validation beyond documentation. Change management records demonstrate that segregation is maintained as the environment evolves.

How UpGuard helps

• Breach Risk: Continuously monitors your external attack surface to detect exposed network services, open ports, and misconfigurations that indicate segregation failures visible from the internet. When internal network zones leak services externally, Breach Risk identifies and prioritizes these exposures before attackers do.

The UpGuard platform gives security teams external attack surface visibility into the network boundary gaps that segregation controls are designed to prevent, connecting your 8.22 implementation to continuous, real-world validation. Learn more about Breach Risk.