Annex A 8.22: Segregation Of Networks

Annex a 8.22: segregation of networks requirement means you must design and operate network segmentation so that systems with different risk levels (users, servers, production, third parties, admin, OT/IoT) are separated, and only explicitly permitted traffic can cross those boundaries. Operationalize it by defining segmentation zones, enforcing them with technical controls, and retaining evidence that segmentation rules are reviewed, tested, and effective. ¹

Key takeaways:

• Define segmentation zones and trust boundaries that match your data classification, threat model, and architecture.
• Enforce “deny by default” between zones using firewalls, security groups, VLAN/VRF, NAC, and identity-aware controls.
• Keep audit-ready evidence: diagrams, rulebases, approvals, periodic reviews, and test results showing segmentation works.

Segregation of networks is an operator control: auditors expect working boundaries, not a policy statement. Under annex a 8.22: segregation of networks requirement, you need to prevent broad, flat network access that allows a compromise in one area (like an end-user subnet or a third-party connection) to move laterally into sensitive environments such as production, regulated data stores, or administrative management planes. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate this control into three decisions you can govern: (1) what the network zones are, (2) what “allowed flows” exist between zones and why, and (3) how you prove the segmentation stays enforced as environments change. You do not need to be the network engineer, but you do need to set the requirement, verify that engineering implemented it, and retain repeatable evidence for internal audit, customers, and certification. ²

This page gives requirement-level implementation guidance you can hand to Infrastructure/Security Engineering with clear acceptance criteria and an evidence checklist.

Regulatory text

Provided excerpt: “ISO/IEC 27001:2022 Annex A control 8.22 implementation expectation (Segregation Of Networks).” ¹

What the operator must do: implement network segmentation appropriate to risk so that systems and users are separated into zones and communications between zones are controlled. Practically, that means you document trust boundaries, enforce them with technical controls (not just conventions), and validate that only authorized traffic crosses those boundaries. ¹

Plain-English interpretation (what “good” looks like)

A strong implementation has these characteristics:

• Clear zones: you can point to a diagram and say “this is user space, this is production, this is admin, this is third-party access,” and those boundaries are real in the network fabric and cloud controls.
• Explicit allowed flows: cross-zone traffic is permitted by exception, tied to a business need (app-to-db, bastion-to-target, monitoring-to-host), and logged.
• No “flat” default: a random laptop, contractor VPN session, or compromised web server cannot freely scan or reach internal services.
• Ongoing control: segmentation rules change through change management, get reviewed, and are tested for effectiveness after significant changes.

Who it applies to

Entity scope: Any organization implementing ISO/IEC 27001 as an ISMS, especially service organizations where customer data, multi-tenant systems, and third-party connectivity are common. ²

Operational contexts where auditors focus:

• Production vs. non-production: preventing dev/test access paths into production data and systems.
• Administrative planes: isolating identity systems, jump hosts/bastions, hypervisor management, cloud control planes, and network device management.
• Third-party connections: suppliers with VPNs, support tools, managed service providers, EDI links, and remote maintenance.
• Cloud environments: VPC/VNet segmentation, security groups/NSGs, route tables, private endpoints, and peering boundaries.
• User networks: corporate devices, BYOD, guest Wi-Fi, and remote access.

What you actually need to do (step-by-step)

Use this sequence as an implementation “work order” with clear deliverables.

1) Define segmentation objectives and “crown jewels”

• Identify systems that require strong isolation (customer data stores, production control plane, IAM, key management, finance/HR, security tooling).
• Define what a segmentation failure would enable (lateral movement, data exfiltration, privilege escalation).
• Set a simple rule: higher-trust zones never assume lower-trust zones are safe.

Output: segmentation scope statement + high-level list of protected zones/systems.

2) Establish standard network zones and trust boundaries

Start with a manageable set; expand later. Common zones:

• End-user zone (workstations)
• Server zone (shared services)
• Production application zone
• Production data zone (databases, object storage private endpoints)
• Admin/management zone (bastions, privileged access workstations, network management)
• Security tooling zone (SIEM collectors, scanners)
• Third-party access zone (vendor VPN termination, support portals)
• Guest/BYOD zone
• OT/IoT zone (if applicable)

Output: a zone taxonomy with a short description and an owner per zone.

3) Document allowed flows (traffic matrix) with approvals

Build a Network Segmentation & Flow Matrix:

• Source zone → destination zone
• Protocol/ports
• Authentication method (mTLS, SSH keys, SSO, service account)
• Logging requirement
• Business justification
• Data sensitivity impacted
• Approver (system owner + security)

Rule of thumb: if you cannot justify a flow, it should not exist.

Output: approved flow matrix that becomes the baseline for firewall/security group rules.

4) Implement enforcement controls (by environment)

Pick controls that fit the architecture; auditors care that boundaries are enforced and managed.

On-prem / traditional:

• VLAN/VRF segmentation, internal firewalls, ACLs
• NAC for device posture and network admission
• Separate management interfaces and management networks

Cloud:

• Separate VPC/VNet per environment or per trust zone where feasible
• Security groups/NSGs as primary “east-west” controls
• Route table controls, private endpoints, restricted peering
• Centralized firewall appliances or cloud-native firewall services for cross-zone flows

Remote/third-party:

• VPN termination into a dedicated third-party zone
• Jump host/bastion required for admin access
• Session recording/logging where possible
• Time-bound access with ticket references

Output: implemented controls mapped to zones and flows.

5) Put segmentation under change control

Segmentation degrades because rules get added ad hoc.

Minimum governance:

• Firewall/security group changes require a ticket, justification, approver, and planned rollback.
• Emergency changes get retrospective review.
• Rule owners are defined (network team owns infrastructure, app team owns app flows, security owns policy and exceptions).

Output: change management procedure specific to network rule changes (or an addendum to your standard change process).

6) Test that segmentation actually works

Testing is your fastest audit win because it demonstrates operation.

Good tests:

• Attempted connectivity tests between zones that should be blocked (document source, destination, method, result).
• Verification that only documented ports are open between zones.
• Validation of third-party access scope (prove a vendor account cannot access production data networks directly).

Output: periodic segmentation test reports and remediation tickets.

7) Monitor and review

Operational expectations:

• Logs for cross-zone firewall decisions and remote access.
• Alerting on new inbound rules, overly broad CIDRs, “allow any” rules, new peering, or new VPN tunnels.
• Periodic review of the flow matrix and rulebase for stale rules.

Output: review records, alert runbooks, and evidence of follow-up on findings.

Required evidence and artifacts to retain

Auditors typically ask for “show me it exists, show me it’s enforced, show me you keep it current.”

Maintain:

• Network segmentation policy/standard referencing annex a 8.22: segregation of networks requirement. ¹
• Current network diagrams (logical zone diagram plus key connectivity paths).
• Flow matrix with approvals and last review date.
• Firewall/NSG/security group configuration exports (or screenshots) that map to the flow matrix.
• Change tickets for rule changes (including emergency changes).
• Access model evidence for third parties (VPN configs, jump host requirement, account provisioning/termination records).
• Testing evidence: segmentation validation results, vulnerability scan segmentation checks, internal pen test observations (if available).
• Exception register: documented exceptions with compensating controls and expiration.

Common exam/audit questions and hangups

Use these to pre-brief engineering and avoid surprises.

1. “Show the boundary between prod and non-prod.”
   Hangup: shared subnets, shared security groups, or peered networks with broad routes.

2. “How do you prevent lateral movement from user devices to servers?”
   Hangup: “it’s on a different VLAN” but there is no L3 enforcement, or ACLs allow broad access.

3. “How is third-party access segmented and monitored?”
   Hangup: vendor VPN drops into the same network as employees, or vendor accounts are not time-bound.

4. “How do you govern firewall rule changes?”
   Hangup: no approvals, no periodic review, no owner for each rule.

5. “Prove it works.”
   Hangup: no testing results; teams rely on “configuration should block it.”

Frequent implementation mistakes (and how to avoid them)

• Mistake: Flat network with “internal = trusted.”
  Avoidance: define zones and require explicit cross-zone rules tied to a flow matrix.

• Mistake: Segmentation exists on paper only.
  Avoidance: keep a direct mapping from diagram → flow matrix → enforced rule objects.

• Mistake: Overly permissive rules (any/any, broad CIDRs, wide port ranges).
  Avoidance: require minimum necessary ports, narrow sources, and business justification in change tickets.

• Mistake: Third-party connections bypass controls.
  Avoidance: terminate into a dedicated zone, require a bastion, and log sessions; review access periodically.

• Mistake: Cloud sprawl breaks consistency.
  Avoidance: standardize “landing zone” patterns (accounts/subscriptions, VPC/VNet design) and guardrails for security group creation.

Enforcement context and risk implications

No public enforcement cases are provided for this specific control in the supplied sources, so this guidance focuses on certification and customer-audit risk. ¹

Risk you are managing:

• Lateral movement: segmentation limits blast radius after credential theft or endpoint compromise.
• Privilege escalation paths: isolating admin planes reduces the chance an attacker reaches domain controllers, cloud management APIs, or secrets stores.
• Third-party risk: segmentation prevents supplier access from becoming a backdoor to sensitive environments.

Practical 30/60/90-day execution plan

Use this as a delivery plan across GRC, Security, and Infrastructure. Time buckets are planning aids, not a claim about required duration.

First 30 days (Immediate)

• Name an owner for network segmentation governance (often Security Architecture or Network Security).
• Inventory and label key environments: production, non-production, admin, third-party connectivity.
• Produce the first logical segmentation diagram and a draft zone taxonomy.
• Start the flow matrix with the highest-risk flows: user → prod, third-party → internal, non-prod → prod, admin → everything.
• Freeze “any/any” expansions: require approval for new broad rules.

Next 60 days (Near-term)

• Implement or tighten enforcement for the top-risk boundaries:
  • production isolated from non-production
  • admin/management isolated from user networks
  • third-party access isolated and routed through controlled ingress
• Put rule changes under change management with required justification fields.
• Stand up initial testing: basic “block checks” for prohibited paths and validation for allowed paths.

Next 90 days (Operationalize)

• Expand segmentation to additional zones (security tools, OT/IoT, shared services) based on risk.
• Build a recurring review cadence:
  • rulebase review (stale rules, broad rules)
  • flow matrix review (new apps, decommissioned services)
  • evidence capture for audits (exports, tickets, test results)
• Add detective controls: alerts for new inbound rules, peering changes, and VPN configuration changes.
• If you manage third parties, align segmentation evidence with third-party due diligence packets (network diagrams + access scope + monitoring narrative).

How Daydream fits (without changing your architecture)

Most teams fail annex a 8.22: segregation of networks requirement during audits for one reason: they cannot produce coherent evidence that ties intent (policy/diagram) to enforcement (rules) to operation (reviews/tests). Daydream helps you run this like a control, with a single place to track zone definitions, flow approvals, exceptions, review tasks, and evidence collection cycles, so you are not rebuilding the story for every audit.

Frequently Asked Questions

Do we need separate VPCs/VNets for segregation of networks?

Not always. Auditors look for enforced boundaries and controlled flows; separate networks can help, but security groups/NSGs plus routing controls can also meet the requirement if they are consistently governed and tested. ¹

Is VLAN segmentation alone enough?

VLANs help with organization, but you typically need L3/L4 enforcement (ACLs/firewalls/security groups) to prove that unauthorized traffic is blocked. Keep evidence of the rules that enforce the boundary and tests that validate the block. ²

How should we handle third-party remote access under Annex A 8.22?

Terminate third-party access into a dedicated zone, restrict reachable destinations to approved systems, and require a controlled path (such as a bastion) for administrative actions. Retain access approvals, configuration evidence, and logs for cross-zone sessions. ²

What evidence is most persuasive in an ISO 27001 audit for network segregation?

A current zone diagram, an approved flow matrix, and rulebase exports that clearly implement those flows, plus recent test results showing prohibited paths are blocked. Change tickets that show governance over rule changes close the loop. ¹

We’re a SaaS company with mostly managed cloud services. Does segregation still apply?

Yes. Your “network” includes VPC/VNet design, security group/NSG boundaries, private endpoints, and administrative access paths to cloud consoles and CI/CD runners. Document the zones and prove that cross-zone access is intentionally permitted, not incidental. ²

How do we treat Kubernetes clusters in segmentation?

Treat the cluster as multiple planes: separate the control plane access path, segment node/network access, and control pod-to-pod and namespace-to-namespace traffic with network policies where applicable. Make the allowed flows explicit and test them the same way you test firewall boundaries. ²

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview