Contribute to the cybersecurity survey asking the questions others didn't dare to... Click here

ISO 27001 Control 8.22: Segregation of Networks

How to Stop an Attacker Roaming Freely Around Your Environment

ISO 27001 Control 8.22 Segregation of networks is about one simple idea:

If someone (or something) gets into one part of your network, they shouldn’t automatically get into everything else.

Without sensible network segregation, a single compromised laptop, admin account, or exposed web server can quickly turn into a full-blown breach across your entire environment. This control expects you to break your network into sensible zones, based on trust, sensitivity and business need – then strictly control how traffic moves between them.

This guide explains what ISO 27001 Control 8.22 is really asking for, and how to put practical, risk-based network segregation in place without tying your operations in knots.


What ISO 27001 Control 8.22 Actually Requires

In plain English, ISO 27001 Control 8.22 – Segregation of networks expects you to:

  • Divide your network into separate security domains (segments or zones).
  • Base those domains on trust level, criticality and sensitivity – not just convenience.
  • Control and monitor traffic between those domains using appropriate security gateways.
  • Treat “edge” networks (internet, partners, wireless, guests) as less trusted by default.

The goal is to:

  • Limit lateral movement if something is compromised.
  • Ensure only authorised flows exist between parts of your network.
  • Support compliance and data protection by keeping sensitive systems in tighter zones.

Step 1 – Work Out Your Security Domains

Start by looking at how your network is used today. For ISO 27001 Control 8.22, you’re trying to identify logical groups of systems and users that make sense to isolate.

Common domains include:

  • External / public
    – Internet, DMZ / perimeter zones, public-facing websites and APIs.
  • User / corporate
    – General user workstations, standard internal services, collaboration tools.
  • Restricted / sensitive
    – Finance systems, HR systems, systems handling personal or customer data, key line-of-business apps.
  • Infrastructure and management
    – Directory services, authentication, backup servers, monitoring, network management.
  • Guest and BYOD
    – Guest Wi-Fi, contractor devices, personally owned devices.
  • OT / production / plant (if relevant)
    – Industrial control systems, SCADA, shop-floor or plant networks.

You don’t need dozens of segments to “do” segregation – but you do need clear, justified zones which you can explain to an auditor in terms of risk and business need.


Step 2 – Choose Logical, Physical, or Hybrid Segregation

Network segregation doesn’t always mean pulling in lots of extra cables. ISO 27001 Control 8.22 is happy with logical or physical segregation, as long as it’s effective.

Typical options:

  • Logical segregation (most common)
    – VLANs to separate different groups of devices.
    – Separate subnets for user, server, guest and management networks.
    – Routing and firewall rules controlling traffic between segments.
  • Physical segregation
    – Dedicated switches, cabling and network hardware for high-sensitivity or safety-critical systems.
    – Completely separate networks for OT/ICS environments or particularly sensitive data.
  • Hybrid
    – A mix of VLANs and physical segregation – for example, shared switching core but physically separate firewalls and links for certain domains.

Your choices should be driven by risk and practicality:

  • The higher the impact of compromise, the stronger and clearer the separation should be.
  • For especially sensitive or safety-critical systems, physical segregation is often easier to justify.

Step 3 – Define and Enforce Traffic Flows Between Segments

There is no point in segregating networks if you then allow any-to-any traffic between them.

For ISO 27001 Control 8.22, you should:

  • Document allowed flows
    – For each pair of segments (e.g. “User → Finance”, “User → DMZ”, “Guest → Internal”), define:
    • What traffic is allowed (protocols, ports, directions).
    • Why it’s needed (business purpose).
    • Who owns and approves it.
  • Enforce using security gateways
    – Firewalls at key boundaries between segments.
    – Filtering routers or ACLs on routers and layer 3 switches.
    – Application proxies or gateways (e.g. reverse proxies, WAFs) where appropriate.
  • Apply “default deny” between domains
    – Start with “no traffic allowed between segments”, then add only what is needed.
    – Avoid open ranges like “allow all to this subnet” unless there’s a very strong reason.
  • Review and prune regularly
    – Over time, rulesets get messy. Schedule periodic reviews to remove redundant or overly broad rules.

If you can show an auditor a simple diagram with clearly defined segments and annotated, justified flows, you’re in a strong position for ISO 27001 Control 8.22.


Step 4 – Treat Wireless and Guest Networks as Untrusted

Wireless is inherently leakier than wired networks. Signals can extend beyond your walls, and devices are more easily compromised or unmanaged.

To align with ISO 27001 Control 8.22:

  • Segment wireless from the start
    – Separate SSIDs and VLANs for internal, guest, and contractor access.
    – Treat guest/BYOD networks as external – as if they were the internet.
  • Restrict coverage and strength
    – Tune radio coverage so it doesn’t significantly extend beyond your controlled areas where possible.
    – Use directional antennas or power control if needed.
  • Secure internal Wi-Fi
    – Use enterprise-grade authentication (e.g. 802.1X) rather than shared passwords.
    – Enforce strong encryption (e.g. modern WPA2 Enterprise or WPA3).
  • Use secure gateways for access into internal networks
    – For very sensitive environments, require users to authenticate through VPN or ZTNA gateways even from “internal” Wi-Fi.
    – Keep guest traffic completely off internal networks; route it straight to the internet via strict controls.

The simple rule for ISO 27001 Control 8.22: wireless is never automatically “trusted” – it always passes through clearly defined security boundaries.


Step 5 – Control Third-Party, Cloud and Partner Connections

Modern networks often extend well beyond your own walls. Segregation has to apply to external links too.

For ISO 27001 Control 8.22, consider:

  • Third-party access
    – Create dedicated zones for suppliers and partners who need access.
    – Limit what they can reach to specific applications or subnets, not your entire internal network.
    – Use VPNs or ZTNA with strong authentication and clear roles.
  • Cloud connectivity
    – Use separate virtual networks, subnets or security groups within cloud environments to mimic your on-premise segmentation.
    – Treat connectivity between on-prem and cloud as a controlled boundary (VPN, private link, or secure gateway).
  • External APIs and integrations
    – Place systems that talk directly to external APIs in DMZ-like zones where possible.
    – Don’t give them unnecessary direct access deep into your internal network.
  • Zero trust principles
    – Move away from “inside = trusted / outside = untrusted” thinking.
    – Treat each connection as something that must be explicitly authenticated and authorised, regardless of origin.

Segregation that ignores third parties and cloud links is only half-implemented – exactly what ISO 27001 Control 8.22 is trying to avoid.


Step 6 – Align Segregation with Access Control and Data Classification

Network segregation should mirror your access control and data classification model, not fight against it.

To make ISO 27001 Control 8.22 work smoothly:

  • Map segments to sensitivity
    – Put systems handling similar data classifications in the same or related segments.
    – Use tighter segmentation for systems with personal, financial, or regulated data.
  • Map segments to role-based access
    – Ensure only the roles that need to access a given segment can do so.
    – Use jump hosts, bastion hosts or admin networks for privileged access, not direct logins from user networks.
  • Build this into design patterns
    – When new systems are introduced, part of the design review should be:
    • “Which network segment should this live in?”
    • “Which other segments does it need to talk to, and why?”

This makes segregation a natural part of how you design and deploy systems, not a retrofit.


Step 7 – Monitor, Test and Evolve Your Segregation

Like everything else in an ISMS, segregation under ISO 27001 Control 8.22 isn’t “set and forget”.

You should:

  • Monitor traffic between segments
    – Use firewall and router logs to spot unusual or excessive cross-segment traffic.
    – Alert on unexpected connections between sensitive zones.
  • Test your boundaries
    – Include network segmentation checks in vulnerability assessments and penetration tests.
    – Confirm that systems in one segment cannot reach others except where explicitly allowed.
  • Keep documentation up to date
    – Maintain up-to-date diagrams and descriptions of your segments and gateways.
    – Update them when you add new sites, cloud regions, or major applications.
  • Refine over time
    – Start with a few clear segments; split further where you see concentration of risk.
    – Don’t be afraid to simplify if the current design is overcomplicated and hard to manage.

This ongoing tuning is what shows an auditor that ISO 27001 Control 8.22 is actively managed, not just written up in a network design document from years ago.


Quick Implementation Checklist for ISO 27001 Control 8.22

Use this checklist to see how you’re doing on segregation of networks:

  • ISO 27001 Control 8.22 (Segregation of networks) is covered in your network security / architecture standards.
  • You have defined network security domains (e.g. public/DMZ, user, sensitive, management, guest, OT).
  • Those domains are enforced using logical and/or physical segregation (VLANs, subnets, separate hardware where needed).
  • Traffic between segments is controlled via firewalls, filtering routers, or gateways, with “default deny” where practical.
  • Allowed flows between segments are documented, justified and reviewed periodically.
  • Wireless networks are segmented and treated as less trusted by default, with strong encryption and access controls.
  • Guest and third-party access is isolated from core internal networks and limited to specific services.
  • Cloud and external connections are integrated into your segmentation model, not treated as “inside”.
  • Segregation aligns with data classification and access control – sensitive systems live in more restricted segments.
  • Segmentation boundaries are monitored, tested and updated as your environment evolves.

Bringing It All Together

ISO 27001 Control 8.22 – Segregation of networks – is about recognising that a flat network is a gift to an attacker (or a misconfigured system).

If you:

  • Define sensible network domains,
  • Use logical or physical segregation to separate them,
  • Tighten and monitor the paths between those domains, and
  • Extend the same thinking to wireless, cloud and third parties,

you’ll dramatically reduce the impact of any one system being compromised – and you’ll be able to show clearly that network segregation is an intentional, well-managed part of your ISMS, not just whatever your switches happened to be doing by default.