ISO 27001 A.8.22: Separate networks around meaningful security boundaries

What A.8.22 requires in practice

Annex A control A.8.22 calls for the organisation's networks to be divided so that information services, users and information systems sit in separate groups. The idea is simple: being on the network should not automatically mean being able to reach everything on it.

To meet it, an organisation decides which groupings matter, based on factors such as sensitivity, criticality, trust and permitted use. It then defines the boundary between groups and what communication, if any, is allowed across it. Separation can be physical, logical or both, and the choice depends on the environment.

The outputs are a justified grouping approach, defined boundaries, recorded reasons and owners for the connections that remain open, and evidence that the separation behaves as designed. Whether and how far the control is applied follows the risk treatment and the Statement of Applicability. Wireless, virtual and partner connections count where they could rejoin groups that were meant to stay apart.

Group systems by a justified security need

Consider differences in trust, sensitivity, criticality and permitted use. A visitor device, an employee workstation and a sensitive application may need different treatment even when they occupy the same building. Organisational departments can inform the design, but the reporting structure alone may not describe the important security relationships.

Define each boundary and the communication allowed across it. Some groups need limited interaction to perform legitimate work. Record the business reason and responsible owner for those paths so a future reviewer can distinguish necessary connectivity from a historical convenience that no longer has a purpose.

Enforce separation in the operating environment

Physical separation and logical controls can both contribute, depending on the environment. The label assigned to a network segment does not prove the restriction is effective. Appropriate rules at the boundary need to reflect the intended design and remain controlled through change.

Include wireless, virtual and partner connections where relevant. A carefully separated office network can be undermined by another route that joins the same groups without equivalent restrictions. Coordinate the design with networks security and network-service requirements, including the responsibilities of external providers.

Why network separation matters to the business

Separation limits how far a problem can travel. If a visitor device, a compromised workstation or a supplier link sits in the same open space as sensitive systems, one weakness can expose the whole business. Properly separated networks give smaller incidents, simpler investigations and a more credible story for customers who ask how their information is isolated from everything else. They can also reduce the scope of some customer or regulatory assessments, because fewer systems need the strictest treatment. For auditors, the quality of a boundary is a quick indicator of whether network design follows risk or habit.

How to implement A.8.22

Good separation starts with decisions about information, not with equipment. The sequence below works for a single office or a multi-site operation. Treat the first pass as a proportionate design exercise, then refine it with real traffic observations. Keep each step short enough to be repeated whenever the environment changes.

1. Identify the groups that deserve different treatment, considering sensitivity, criticality and who uses them, rather than copying the organisation chart.
2. Define the boundary for each group and the minimum communication that must cross it.
3. Record the business reason and an owner for every permitted path.
4. Implement the separation using physical or logical means suited to the environment, and include wireless and virtual networks.
5. Check partner and supplier connections to confirm they do not rejoin separated groups.
6. Verify through authorised checks that permitted traffic works and restricted traffic is refused.
7. Control boundary rule changes through change management, retiring paths that no longer have a purpose.
8. Review the design when systems, suppliers or ways of working change.

Evidence an auditor expects for A.8.22

Auditors want to see that boundaries exist in operation, not only on paper. Useful evidence includes:

• a rationale for how groups were defined
• boundary rules with recorded owners and business reasons for open paths
• results of authorised checks that restricted communication is actually refused
• observation of how guest or visitor access behaves
• change records for recent boundary rule changes

A conversation with the person who maintains the boundary, explaining why a given path is open, is often the most revealing test.

Common nonconformities with A.8.22

Typical findings show boundaries that look sound in a diagram but leak in practice. Most arise because a boundary was drawn once and then eroded through convenience, so an auditor tests what actually passes across it rather than what the plan says.

• Segments named for separation but allowing wide communication in both directions.
• Open paths with no recorded reason or owner, left over from past projects.
• Guest wireless arrangements judged by the sign-in page rather than tested behaviour.
• Virtual or partner routes bypassing the designed boundary.
• Separation never verified after rule changes.

Illustrative manufacturing example: office systems and production support

Illustrative office example: guest wireless access

A hypothetical software company provides wireless access for visitors. The network name clearly says guest, but its configuration does not provide the intended separation from internal resources. Staff have judged the arrangement by the sign-in screen rather than by the actual network behaviour.

The company confirms the required visitor service, implements suitable separation and tests representative access using an approved guest device. It also checks that staff have a practical authorised route for their own work. The result supports visitor connectivity without assuming that a friendly network name or different password establishes a security boundary.

Manage exceptions without dissolving the boundary

Troubleshooting and new integrations can create pressure for broad temporary access. Define how such changes are authorised, limited and reviewed. An exception should state its purpose and closure condition, rather than remain indefinitely because nobody knows which application might still use it.

Involve business and system owners when tightening rules. Removing a connection without understanding a legitimate dependency can interrupt operations and encourage bypasses. A controlled process should preserve necessary work while limiting unrelated access. Connect this with change management.

Test the intended relationships

Useful evidence includes the grouping rationale, relevant diagrams, permitted-flow decisions, implemented rules and test results. These are practical evidence methods rather than required separate document titles. Protect technical detail according to its sensitivity, especially when sharing architecture information beyond the responsible teams.

An authorised test should check a permitted communication and a representative communication that should be restricted. Define source, destination, method and operational safeguards in advance. Check important alternative routes where appropriate; a successful test of one boundary does not prove every possible path is controlled.

Common failures include unrestricted communication between nominally separate segments, stale exceptions and unreviewed partner connections. Review the design after material business or architecture changes through operational control. Segregation reduces relevant exposure, but it does not remove the need for sound access control, system configuration and monitoring within each group.