ISO 27001 A.8.22: Segregation of Networks

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 8.22 requires that groups of information services, users and information systems be segregated on the organization's networks, splitting the network into security domains and controlling traffic between them based on business need.

The Bottom Line: Segregation is what limits an attacker's lateral movement. On a flat network, one compromised laptop can reach everything; with segmentation, the same compromise is contained to one zone. It is among the most effective controls against ransomware spread and data-centre compromise.

What the Control Asks For

The ISO 27001:2022 Text

In short:

ISO 27001:2022 Annex A 8.22 asks organizations to split networks into segments that isolate different services, user groups, and systems.

Do you need this control?

A.8.22 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if your network has groups of services, users or systems that should be separated, which is most networks of any size. Small flat networks may need only a few segments, for example guest Wi-Fi and production.

What ISO 27002:2022 Adds

ISO/IEC 27002:2022 (8.22) gives this guidance, paraphrased:

• Divide large networks into separate domains and separate them from the public internet.
• Choose domains by level of trust, criticality and sensitivity (for example public access, desktop, server, low- and high-risk systems), by organisational unit (HR, finance, marketing), or a mix of the two.
• Segregation can use physically separate networks or separate logical networks (VLANs, virtual networks, cloud VPCs).
• Define each domain's perimeter clearly. Where traffic between domains is allowed, control it at the perimeter with a gateway such as a firewall or filtering router.
• Base the criteria on an assessment of each domain's security requirements. Take into account the access control policy (5.15), access requirements, the value and classification of the information, and the relative cost and performance impact of the gateway technology.
• Wireless needs special treatment because its perimeter is poorly defined:
  • consider adjusting radio coverage to help segregate wireless networks;
  • in sensitive environments, treat all wireless access as an external connection that must pass a gateway (8.20) before it reaches internal systems;
  • keep guest wireless separate from staff wireless where staff use only managed, compliant devices;
  • give guest Wi-Fi at least the same restrictions as staff Wi-Fi, so that staff are not tempted to use guest Wi-Fi to get around controls.
• Networks extend to business partners. Interconnections with partners raise the risk of unauthorised access, so partner links need their own controlled segment.

The "shall vs should" Analysis

What Auditors Actually Check

1. A documented segmentation design (zones/domains, not a flat network).
2. Server/database and sensitive systems separated from user and public networks.
3. Gateways (firewalls) with default-deny controlling inter-zone traffic, reviewed periodically.
4. Wireless/guest separated from internal networks, with guest Wi-Fi no less restricted than staff Wi-Fi.
5. Partner and vendor connections terminated in a controlled segment, not on the internal LAN.
6. For PCI/regulated scope: the in-scope environment (e.g. CDE) is segmented, and segmentation is tested.

Why Network Segregation Matters

The Business Risk Narrative

Most serious intrusions involve lateral movement (MITRE ATT&CK lists it as its own tactic, TA0008): the attacker lands on one device and then moves across the network to the crown jewels. A flat network is an open plain: one foothold reaches everything. Segregation builds internal walls so that a compromise of a marketing laptop cannot reach the core banking system or the customer database. It is one of the most effective architectural controls against ransomware, which spreads fastest on flat networks.

How It Goes Wrong (hypothetical patterns)

• Flat office network. A phished laptop in marketing can reach the database servers and domain controllers directly, so one click becomes an estate-wide incident.
• Guest Wi-Fi looser than staff Wi-Fi. Staff move to the guest network to reach blocked sites, and their laptops leave the protection of the corporate controls.
• Vendor VPN lands on the internal LAN. A support supplier's account is compromised and the attacker arrives inside, with no filtering between the vendor link and production.
• "Temporary" any-any rule. A rule added during an outage is never removed; segmentation exists on the diagram but not on the firewall.
• OT on the IT network. Ransomware on an office PC reaches the plant historians and stops production.

Indian Regulatory Context

• RBI: the Cyber Security Framework in Banks (2016) baseline expects network management and security, including segmentation and protection of critical systems such as core banking. The Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023) applies to banks, NBFCs and other regulated entities.
• SEBI: the Cybersecurity and Cyber Resilience Framework (CSCRF, 2024) covers network security and segmentation for regulated entities in the securities market.
• IRDAI: the Information and Cyber Security Guidelines (2023) apply to insurers and intermediaries.
• NCIIPC: systems notified as protected systems (critical information infrastructure) are expected to be isolated from general and internet-facing networks.
• DPDP Act 2023: segregating systems that hold personal data supports the reasonable security safeguards required by section 8(5).
• PCI DSS v4.0.1 (card data): segmenting the cardholder data environment (CDE) reduces scope. Where segmentation is used, it must be tested by penetration testing at least every 12 months (11.4.5), and every six months for service providers (11.4.6).

Industry-Specific Consequences

Impact of Non-Compliance

A flat network turns a containable incident into a company-wide one. The 2017 wave of self-propagating ransomware demonstrated that segmentation is the difference between "we lost a department" and "we lost everything." Segmentation is an architecture investment that pays for itself the first time it stops a breach at a zone boundary.

Scope and Applicability

What the Control Covers

• The organisation's networks, on-premises (LAN/WLAN/data centre), cloud (VPC/VNet), and OT, and the domains/zones into which they are divided and the gateways controlling traffic between them.

Who It Applies To

Every organisation with a network beyond a trivial size. SMEs segment at least servers/databases, users, and guest/wireless; enterprises run multi-tier segmentation and increasingly micro-segmentation.

Size-Based Applicability

Key Definitions and Terminology

Relationship to Other Controls

Where Segregation Fits

Network controls layer: 8.20 manages and protects the network overall; 8.21 secures network services and their agreements; 8.22 divides the network into trust domains and controls traffic between them; 8.23 filters outbound web access. A.8.22 is the structural control, it shapes the battlefield so that the other controls (and incident response) operate on a contained, defensible architecture rather than an open plain.

Segmentation Models and Network Domains

Choose a model (or combination) per ISO 27002:

A common baseline: DMZ (internet-facing), user/desktop domain, server domain (further split into app/database tiers), management network (for admin/out-of-band), guest/wireless, and, where relevant, a strictly separated OT zone. Each boundary is controlled by a gateway with default-deny.

Physical vs Logical Segregation and Micro-Segmentation

• Physical segregation: separate physical networks/hardware, strongest isolation, used for the most critical/OT systems; higher cost.
• Logical segregation: VLANs, virtual networks, cloud VPC/subnets, flexible and efficient; relies on correct configuration of switches/firewalls.
• Micro-segmentation: fine-grained, often identity/workload-aware policies controlling east-west traffic down to the host. Reduces lateral movement dramatically and underpins Zero Trust networking, every flow is explicitly allowed, nothing is trusted by location alone.

Most organisations use logical segregation for the bulk of the network and physical for the highest-criticality/OT systems, evolving toward micro-segmentation at higher maturity.

Detailed Implementation Guidance

Map Flows, Then Define Domains

Inventory systems and map current traffic flows (who talks to what). Define domains by trust/sensitivity/org unit, and place sensitive systems (databases, CBS, CDE, domain controllers) in protected domains.

Separate from the Internet (DMZ)

Internet-facing services go in a DMZ, never directly on the internal network. Internal systems reach the internet through controlled egress (with web filtering, A.8.23).

Control Inter-Domain Traffic at Gateways (Default-Deny)

Place firewalls/filtering routers at domain perimeters; configure default-deny and allow only explicitly justified flows. Document the criteria and the rule justifications.

Protect the Crown Jewels

Put databases, core systems and management interfaces in tightly-controlled segments reachable only from where business requires, never directly from the user VLAN or the internet. This single step stops most lateral-movement-to-data paths.

Segregate Wireless, Guest and Untrusted Devices

Isolate guest Wi-Fi and untrusted/BYOD devices from internal networks; treat wireless as untrusted unless strongly authenticated; segment IoT. Give guest Wi-Fi at least the same restrictions (web filtering, blocked categories, rate limits) as staff Wi-Fi, so staff gain nothing by using it. Adjust access-point power and placement so radio coverage does not spill far beyond the premises.

Put Partner and Vendor Connections in Their Own Segment

Terminate business-partner links, vendor VPNs and support access in a dedicated extranet or partner segment. Allow only the specific systems and ports each partner needs, log the sessions, and review the access when the contract changes (A.5.19, A.8.21).

Review Rules and Test Segmentation

Periodically review inter-zone firewall rules (remove stale/over-broad rules) and test segmentation to confirm zones are actually isolated; configuration drift silently erodes segmentation. A simple test: from a host in each zone, scan the other zones for open ports and compare the results with the approved flow list. Record the source zone, target zone, ports found open, whether each was expected, and the fix.

Monitor East-West Traffic

Monitor inter-zone and east-west traffic (link A.8.16) to detect lateral movement and policy violations; segmentation plus monitoring is far stronger than either alone.

Cloud and OT Segregation

Cloud. Segregation in cloud uses VPCs/VNets, subnets, security groups/NSGs, and network policies. Apply the same principles: separate tiers (web/app/db), restrict east-west with security groups, isolate management, and default-deny. Cloud-native micro-segmentation (security groups per workload, service mesh policies) is often easier than on-prem.

OT (Operational Technology). IT/OT convergence without segregation is a top critical-infrastructure risk. Apply a zoned model (e.g. the Purdue model): strictly separate plant/control networks from corporate IT via a controlled DMZ/conduit, allow only essential, inspected flows, and never let OT sit on the office LAN. Ransomware crossing from IT to OT can halt production and create safety hazards.

Network Segregation Policy (Template)

Illustrative extract (the Control Pack has the full policy):

Network Segregation Policy — [Organisation Name] (A.8.22)

1. The network shall be divided into security domains based on trust, criticality and
   sensitivity, and shall be separated from the public internet.

2. Internet-facing services shall reside in a DMZ, never on internal networks.

3. Sensitive systems (databases, core/financial systems, domain controllers, management
   interfaces) shall reside in protected domains not directly reachable from user or public
   networks.

4. Traffic between domains shall be controlled at gateways (firewalls) on a default-deny
   basis; flows shall be allowed only on documented business justification.

5. Guest and wireless networks shall be isolated from internal networks. Guest Wi-Fi shall
   have at least the same restrictions as staff Wi-Fi. OT networks shall be segregated from
   corporate IT via a controlled conduit/DMZ.

6. Partner, vendor and support connections shall terminate in a dedicated partner segment
   and reach only the systems they need.

7. Inter-domain rules shall be reviewed at least [quarterly]; segmentation shall be tested at
   least [annually] (segmentation penetration testing).

8. Inter-zone and east-west traffic shall be monitored (A.8.16).

Risk Assessment and Treatment

Audit and Compliance Checklist

(The Control Pack's audit evidence checklist (04) lists where to find the evidence for each question.)

Metrics and KPIs

Common Pitfalls and Audit Failures

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1, Indian Private-Sector Bank: Isolating Core Banking

Challenge. An RBI examination and an ISO 27001 audit found that the bank's core banking system (CBS) and customer database were reachable, via a largely flat internal network, from general office VLANs, meaning a single phished employee laptop could reach the crown jewels. Firewall rules between segments were riddled with any-any entries accreted over years.

Solution (12 weeks).

1. Mapped flows and re-architected into trust domains: DMZ, user, server (app/db tiers), management, and a strictly-isolated CBS zone.
2. Implemented default-deny at all zone gateways; allowed only documented, justified flows to the CBS and database tiers.
3. Moved internet-facing services into the DMZ; isolated guest Wi-Fi.
4. Instituted quarterly rule review and an annual segmentation penetration test, with east-west monitoring (A.8.16).

Results. The CBS and database are no longer reachable from user networks; any-any rules eliminated; lateral-movement paths to core systems closed. The RBI observation and ISO nonconformity were both resolved, and a subsequent red-team confirmed containment at the zone boundaries.

Illustrative Scenario 2, Indian Manufacturing Enterprise: IT/OT Segregation

Challenge. A manufacturer running SAP and plant control systems had its OT (PLCs/SCADA) on the same network as corporate IT. A ransomware incident at a peer (which halted production for days by crossing from IT to OT) prompted an urgent review; ISO 27001 flagged the lack of segregation as a critical risk.

Solution (14 weeks).

1. Applied a Purdue-model zoning: separated OT/control networks from corporate IT via a controlled DMZ/conduit, allowing only essential, inspected flows.
2. Placed plant historians and jump hosts in the conduit DMZ; blocked direct IT→OT traffic.
3. Segmented corporate IT (DMZ, user, server) with default-deny; isolated engineering workstations.
4. Added OT-aware monitoring and a segmentation test.

Results. A compromise of corporate IT can no longer propagate to plant control systems; production-halting ransomware risk dramatically reduced; the segregation satisfied the ISO 27001 auditor and became the template for the group's other plants.

16A. Advanced Implementation Guidance

Figure · Tiers

Maturity levels for segregation of networks

16A.1 Micro-Segmentation and Zero-Trust Networking

Traditional zone segmentation controls north-south traffic (between zones) but often leaves east-west traffic (between systems in the same zone) wide open, which is exactly where ransomware and attackers move. Micro-segmentation pushes policy down to the workload/host level: each workload only accepts the specific flows it needs, identity- or tag-based rather than IP-based. This is the network foundation of Zero Trust, no implicit trust from network location; every flow explicitly allowed. Implement incrementally: start by isolating the crown jewels and the highest-risk segments, then expand. Tools: host-based micro-segmentation agents, cloud-native security groups and network policies, and service-mesh policies for containerised workloads.

16A.2 Cloud Segmentation in Depth

In cloud, segmentation is built from VPCs/VNets, subnets, security groups/NSGs, network ACLs, and network policies (Kubernetes). Apply the same tiering: separate web/app/database tiers into subnets; restrict east-west with tight security groups (default-deny, allow only required ports/sources); isolate the management plane; and use private endpoints so data services aren't internet-exposed. A "flat VPC" with permissive security groups is the cloud equivalent of a flat LAN. Use CSPM/CNAPP tooling to detect over-permissive rules and exposure, and infrastructure-as-code so segmentation is version-controlled and reviewable.

16A.3 OT/ICS Segmentation (Purdue Model)

For manufacturing, utilities and critical infrastructure, IT/OT segregation is a top control. The Purdue model layers the environment (Levels 0–5) and inserts a controlled IDMZ (industrial DMZ) between enterprise IT (Levels 4–5) and operations/control (Levels 0–3). Only essential, inspected flows cross the IDMZ (via jump hosts, data diodes for one-way flows, and brokered protocols); direct IT→OT traffic is blocked. This prevents ransomware or an IT compromise from reaching, and halting or endangering, physical processes. Align with IEC 62443 zones-and-conduits.

16A.4 Segmentation Testing and Rule Lifecycle

Segmentation drifts: rules accrete, "temporary" any-any entries become permanent, and new systems land in the wrong zone. Counter with (1) segmentation penetration testing: actively attempting to cross zone boundaries to prove isolation (PCI DSS 11.4.5 requires this at least every 12 months where segmentation reduces CDE scope; 11.4.6 requires every six months for service providers); (2) a firewall-rule lifecycle, every rule has a justification, owner and review date; stale and overly-broad rules are removed at periodic review; and (3) change control (A.8.32) for all segmentation changes. Pair with east-west monitoring (A.8.16) to detect lateral movement and policy violations in real time.

16A.5 Network Segregation Maturity Model (L1–L5)

Certification does not require a set maturity level. Most organisations aim for L3; regulated BFSI and critical-infrastructure operators usually need L4 practices such as tested segmentation and east-west monitoring.

16A.6 Anatomy of a Flat-Network Breach

An attacker phishes a marketing employee and lands on their laptop. On a flat network, the laptop can reach the file servers, the database tier, and the domain controllers directly, so the attacker harvests credentials, moves laterally to the domain controller, and deploys ransomware estate-wide within hours. On a segmented network, the same laptop sits in a user zone with default-deny to the server and database tiers; the attacker hits a wall at the first zone boundary, the lateral movement is blocked and detected by east-west monitoring, and the incident is contained to one segment. Segmentation is the single architectural control that most reduces blast radius.

Key Takeaways

• Segmentation limits lateral movement: the difference between losing a segment and losing the estate.
• Divide by trust/sensitivity, separate from the internet (DMZ), and isolate the crown jewels behind default-deny gateways.
• East-west traffic is the gap: micro-segmentation and monitoring close it.
• IT/OT separation (Purdue/IEC 62443) is essential for manufacturing/critical infrastructure.
• Segmentation drifts: test it (segmentation pen-testing), review rules, and change-control changes.
• In India, A.8.22 supports RBI critical-system isolation, PCI CDE scoping, and DPDP exposure-limitation.

Multi-Framework Mapping

Implementation Roadmap

Phase 1, Discover & Design (Weeks 1–3)

• Inventory systems; map current traffic flows; identify crown jewels.
• Design the domain model (DMZ, user, server tiers, management, guest, OT).

Phase 2, Build Core Segmentation (Weeks 4–7)

• Stand up DMZ; isolate sensitive systems; implement default-deny gateways with justified flows.
• Isolate guest/wireless.

Phase 3, OT/Cloud & Hardening (Weeks 8–10)

• IT/OT separation (conduit/DMZ); cloud subnet/security-group segmentation.
• Separate management network.

Phase 4, Assure (Weeks 11–12+)

• Rule review + change control; east-west monitoring (8.16).
• Segmentation penetration test; KPI dashboard; internal audit dry-run.

FAQ

Q1: Is A.8.22 mandatory for certification? Not automatically: it is selected through risk treatment (clause 6.1.3) and recorded in your Statement of Applicability. Any organisation with a network of meaningful size will normally include it, and auditors then look for a real segmentation design and isolated sensitive systems, not a flat network.

Q2: VLANs or physical separation? Logical (VLAN/virtual) segregation is sufficient and efficient for most domains, provided switches/firewalls are correctly configured. Use physical separation for the highest-criticality and OT systems.

Q3: What's the single most valuable step? Isolate the crown jewels (databases, core systems, domain controllers) so they are not directly reachable from the user VLAN or the internet, this closes the most common lateral-movement path.

Q4: How does A.8.22 relate to PCI DSS? PCI uses segmentation to reduce scope: properly segmenting the CDE means fewer systems are in scope. Where you rely on segmentation, PCI DSS 11.4.5 requires penetration testing of the segmentation controls at least every 12 months (every six months for service providers, 11.4.6).

Q5: We're fully in the cloud, does this apply? Yes. Use VPCs/VNets, subnets, security groups/NSGs and network policies to segment tiers and restrict east-west traffic; a flat VPC is the cloud equivalent of a flat LAN.

Q6: Should guest Wi-Fi be more open than staff Wi-Fi? No. ISO 27002 recommends that guest Wi-Fi has at least the same restrictions as staff Wi-Fi. If the guest network is more open, staff will use it to get around controls, and their devices leave your monitored network.

Q7: How is this different from A.8.20? 8.20 is overall network security/management; 8.22 is specifically dividing the network into controlled trust domains. 8.22 is one of the most important measures within 8.20.

References and Further Reading

Primary standards

• ISO/IEC 27001:2022: Annex A control 8.22.
• ISO/IEC 27002:2022: Clause 8.22 (network domains, gateways, physical/logical segregation); related §8.20, §8.21, §8.23.

Supporting frameworks

• NIST SP 800-53 Rev 5: SC-7 (Boundary Protection) and enhancements; AC-4.
• NIST CSF 2.0: PR.IR-01.
• CIS Controls v8: Safeguards 12.2 and 13.4.
• PCI DSS v4.0.1: Requirement 1; 11.4.5 and 11.4.6 (segmentation testing).
• IEC 62443: Zones and conduits (OT segmentation).
• SOC 2 (TSC 2017): CC6.6; COBIT 2019: DSS05.02.

Indian regulations

• RBI: Cyber Security Framework in Banks (2016); Master Direction on IT Governance, Risk, Controls and Assurance Practices (2023).
• SEBI: Cybersecurity and Cyber Resilience Framework (2024). IRDAI: Information and Cyber Security Guidelines (2023).
• Digital Personal Data Protection Act, 2023: Section 8(5).
• NCIIPC: guidance for protected systems (critical information infrastructure).

Singahi resources: the A.8.22 toolkit and related guides for A.8.20 Networks security, A.8.21 Security of network services, A.8.23 Web filtering, and A.8.16 Monitoring activities.