ISO 27001 Network Segregation: Control A.8.22 Evidence

Network segregation under ISO/IEC 27001 is a risk-based decision about which users, systems and services may communicate. Creating several subnets or cloud networks does not by itself demonstrate control. The boundaries need a purpose, the permitted flows need authority, and testing must show that prohibited paths are blocked in operation.

Annex A control 8.22 focuses on segregation of groups of information services, users and information systems. A good implementation limits exposure and lateral movement while still supporting necessary business communication.

Map older references to the current control

In ISO/IEC 27001:2013, network segregation appeared as A.13.1.3. In the 2022 control set it appears as A.8.22. Network security and security of network services now sit at A.8.20 and A.8.21.

An old network policy may still express useful intent, but changing a control label is not enough. Reassess the architecture, risk criteria, cloud services and remote access against the current environment. Update the Statement of Applicability and supporting records where necessary.

The Annex A control lookup can help owners see segregation alongside access control, network security, monitoring and cloud-service controls.

Define what segregation must achieve

Start with an outcome rather than a technology. Segregation may be used to:

• separate public services from internal systems;
• restrict access to sensitive or regulated information;
• isolate production from development and test;
• protect management interfaces and security tooling;
• separate user devices from servers or operational technology;
• contain untrusted, guest or unmanaged devices;
• limit third-party and support access;
• reduce the likely reach of malware or a compromised identity; and
• separate customers or tenants where the service model requires it.

Connect each objective to a risk scenario and the assets affected. This prevents arbitrary zones that add complexity but do not protect a defined outcome.

Use the broader network security guide to establish the inventory, ownership and service requirements around the segregated architecture.

Create zones from risk and trust needs

Group systems only after considering information classification, business criticality, administrative model, exposure, user population and obligations. Typical labels such as corporate, production, guest and management are useful only if their meaning is defined.

For each zone, record:

• purpose and accountable owner;
• included assets or selection criteria;
• trust assumptions and authentication expectations;
• permitted ingress, egress and internal flows;
• administrative access path;
• monitoring and logging requirements;
• connectivity to suppliers and external services; and
• review and change authority.

Avoid assuming that all assets within one zone can trust one another. Host controls, service identities and application authorisation may still be necessary. Network position is one signal, not a complete access decision.

Govern traffic as named business flows

Rules should represent understood communication, not a collection of ports accumulated over time. Describe a permitted flow using source, destination, service, direction, purpose, owner and expiry or review date where applicable.

Flow element	Design question	Operating evidence
Source and destination	Which systems or groups need to communicate?	Current objects, identities or selectors
Service	Which protocol or application action is necessary?	Deployed rule and observed traffic
Purpose	Which business or technical process requires it?	Approved request or architecture decision
Protection	Is authentication or encryption required in addition to filtering?	Configuration and connection test
Duration	Is the path permanent, temporary or emergency?	Expiry and removal record
Review	Who confirms continued need?	Dated owner decision and resulting change

Use least privilege for network paths, but recognise operational dependencies such as DNS, time, identity, monitoring and software update services. An undocumented supporting flow can cause outages or encourage broad emergency rules.

The firewall governance guide gives a detailed approach to rule ownership, recertification and change evidence.

Choose enforcement appropriate to the environment

Segregation can be physical, logical or both. Controls may include routing boundaries, firewalls, access-control lists, virtual networks, security groups, service-mesh policies, identity-aware gateways, wireless separation and host-based filtering.

The technology should match the risk and operational model. A physical separation can provide strong isolation but still fail through maintenance connections or portable media. Logical controls can be precise and automated but may be weakened by inherited rules, broad selectors or shared administration.

Document where enforcement occurs and which team owns it. Multiple overlapping layers are valuable only when configuration and troubleshooting responsibilities are clear.

Treat cloud segregation as configured infrastructure

Cloud boundaries may use accounts, subscriptions, projects, virtual networks, subnets, security groups, routing tables, private endpoints and service identities. Provider tenancy separation does not automatically create the customer’s required application or administrative separation.

Distinguish at least production traffic, management traffic and service-to-service communication where risk warrants it. Consider shared services, peering, transit networks, serverless components and provider-native management paths. Review both ingress and egress; a restricted inbound path can still coexist with excessive outbound access.

Infrastructure-as-code can provide strong evidence of approved design and change, but compare code with deployed state. Manual changes, inherited policies and provider defaults can create drift.

Protect administrative and third-party paths

Management zones often provide access to many other zones, so compromise can bypass ordinary separation. Restrict administrative sources, use named privileged identities, strong authentication and protected protocols, and monitor sessions or commands according to risk.

Supplier access should terminate at the systems and times required for the service. Avoid placing third parties directly inside a broad trusted zone. Define sponsorship, activation, expiry, monitoring and emergency revocation.

Remote connections are another route across boundaries. The remote access policy guide explains how to align approved access methods, identity controls and operating evidence.

Control changes and exceptions

Require a business or technical owner for each material flow. Changes should state the need, affected zones, risk, test and rollback plan. Where broad or temporary access is unavoidable, record the exception, compensating measures, approval and expiry.

Emergency rules are particularly likely to persist. Monitor their age and verify removal after the event. Periodic review should assess continuing need, not merely confirm that a rule still exists.

Reconcile diagrams, rule bases and observed communication. A current diagram with unrecorded active routes is not reliable, and an accurate rule export without business ownership cannot show appropriateness.

Prove that boundaries work

Testing should combine configuration inspection with safe path testing. For a risk-based sample:

1. Trace a permitted flow from approved need to the deployed rule.
2. Confirm the connection succeeds using the expected identity and protection.
3. Test a representative prohibited path and confirm it is blocked.
4. Verify that allowed and denied activity produces the expected monitoring record.
5. Inspect changes, review decisions and expired access.
6. Compare a network diagram or cloud architecture record with deployed routes.

Coordinate active tests to avoid disruption. In sensitive environments, use approved validation tooling, read-only queries or evidence from controlled exercises.

Useful audit questions include:

• Which risks determined the zones and their boundaries?
• How are new assets placed into the correct zone?
• Can an internal user or compromised workload reach management interfaces?
• How are cloud peering and inherited policies reviewed?
• Who owns each high-risk cross-zone flow?
• Are temporary and supplier paths removed when their purpose ends?
• Has the organisation tested blocked paths, not only reviewed diagrams?

Evaluate evidence consistently

A pass is supported when risk-defined zones have accountable owners, permitted flows have a current purpose, enforcement matches the design and sampled tests show that boundaries operate.

A partial result may exist when major zones are implemented but ownership is incomplete, diagrams lag the environment, cloud paths are not fully covered or temporary rules remain beyond approval.

A fail is likely when broad connectivity exists without risk rationale, critical administration is reachable from ordinary user networks, or the organisation cannot show that prohibited paths are blocked.

The risk score calculator can support consistent prioritisation of segregation findings, while the organisation remains responsible for its criteria and acceptance decisions.

Improve without creating unnecessary complexity

More segments are not automatically better. Excessive complexity can lead to fragile rules, emergency bypasses and poor ownership. Review whether each boundary reduces a defined risk and whether the organisation can operate it reliably.

The official ISO/IEC 27002 overview describes guidance for information-security controls. NIST SP 800-207 provides complementary zero-trust principles, including the view that network location alone should not grant implicit trust.

Effective segregation is visible as a maintained chain from risk to zones, approved flows, deployed enforcement and tested outcomes. That chain is much stronger audit evidence than the number of subnets on an architecture diagram.