A.8.22 Segregation of networks: requirements and evidence

What A.8.22 segregation of networks asks for and why assessors test it

A.8.22 asks the organization to separate groups of information services, users and information systems within its networks, and to control the traffic that crosses each security boundary according to business needs. The control is about boundaries: deciding which groups of systems and people belong in which network domain, and then enforcing what may pass between them. If your audit is approaching and the network has grown flat over the years, with production, office, guest, vendor and development hosts sharing address space, expect an assessor to ask where those boundaries are drawn and how they are enforced. The risk is lateral movement. In a flat network, one compromised laptop, a vulnerable web server or a stolen vendor credential can reach databases, domain controllers and backup systems directly. Segregation limits how far an attacker can move before a gateway, filter or policy stops them. Assessors usually test this by asking for a current network diagram tied to the documented segments, the rules on each gateway with their business justification, and evidence that those rules are reviewed. The 2013 edition covered this under A.13.1.3, Segregation in networks. NIST's crosswalk relates A.8.22 to AC-4 and SC-7, and ENISA's NIS2 mapping links it to network segmentation in Implementing Regulation (EU) 2024/2690. Treat both mappings as context only, since NIST itself cautions that mapped controls are not always equivalent, and confirm with your certification body how it reads the control. Do not confuse A.8.22 with its neighbors. A.8.20 Networks security covers how network devices are hardened, administered and monitored. A.8.31 covers separating development, test and production environments. A.8.22 is narrower and more structural: it asks whether the network itself is divided into domains with controlled crossings. Hard parts are usually undocumented legacy flat networks that nobody has mapped, cloud virtual networks and wireless segments extended from the office without matching boundaries, and third-party access paths such as VPN tunnels, remote support connections and vendor-managed devices that bypass the intended design. Inventory those paths first.

Which networks, systems and third parties fall inside A.8.22 scope

A.8.22 applies wherever the organization groups services, users and systems into separate network domains and controls the traffic between them. The cards below cover the parallel scope components most organizations must decide on, and the boundary choices that change how much work each one creates.

Production service networks

Networks that host the services customers use are usually the first domain an assessor examines. Decide whether each application tier, database tier and shared service sits in its own segment, and document which flows cross each boundary and why. Check whether production data stores can be reached from user networks or from development environments, since those paths are where segregation most often breaks. Confirm that every permitted flow maps to a business need recorded in the network documentation.

User and office networks

Staff laptops, office Wi-Fi and guest access create the largest population of endpoints on the network. Decide whether guest, contractor and corporate users each receive a separate domain with no route to production services by default. Verify that user segments cannot reach management interfaces or backup repositories. Assessors typically ask for the firewall rules that enforce these separations and for evidence that the rules were reviewed.

Management and administration networks

Hypervisor consoles, firewall administration, directory controllers and out-of-band management interfaces control everything else, so they carry the highest risk if exposed. Decide whether administration traffic runs on a dedicated segment reachable only from named jump hosts. Confirm that privileged sessions cannot originate from general user networks. Record who may change these rules and how changes are approved.

Backup and monitoring networks

Backup targets and log collectors often hold copies of sensitive data, so their placement is a scoping decision, not a technical afterthought. Decide whether backup and monitoring traffic gets its own domain, and whether those domains are inside or outside the ISMS boundary. Check that the systems that collect logs can receive events from production but cannot be used to reach production. Document the decision so that the Statement of Applicability can point to it.

Wireless and cloud virtual networks

Wireless access points and cloud virtual networks, including VPCs, virtual networks and security groups, are often managed by different teams than the core data center network. Decide whether each SSID, subnet and cloud account is a separate domain with its own gateway. Confirm that cloud accounts used for production cannot route to development or sandbox accounts without a controlled gateway. Ask for the cloud network configuration as evidence, not only the architecture diagram.

Third-party and vendor connections

Site-to-site VPNs, supplier remote access and managed service provider links place outside parties on the internal network. Decide whether each connection terminates in a dedicated segment with an allowlist of permitted services, and whether the ISMS boundary includes the supplier-managed side. Confirm that vendor accounts expire and that their traffic is logged at the gateway. Where a supplier controls the path, verify the contractual terms that give the organization evidence of segregation.

How an assessor tests A.8.22 and what they ask to see

This table sets out each test an assessor typically runs on segregated networks, the evidence they request for it, and the findings that most often come up. Read it as a preparation checklist: for each row, confirm you can produce the named evidence before the audit starts, because a segregation claim that cannot be shown in a sampled test usually becomes a finding.

Test area	Test approach	Evidence requested	Common findings
Network design and zone inventory	Walk through the network diagram and compare it with live configuration to confirm each zone, its members and its purpose.	Current network diagrams, zone inventory with owners, and the business reason for each separated group.	Diagrams that predate recent changes, systems missing from any zone, and zones with no documented owner.
Gateway rule sets against business needs	Sample firewall and gateway rules and trace each one back to a stated service or user need.	Exported rule sets, rule descriptions, and the business justification linked to each sampled rule.	Any-to-any rules, rules with no description, and allow rules that outlive the project they were written for.
Blocked path testing	Attempt a sampled connection from one zone to another that should be denied, and record the result.	Test scripts or screenshots of blocked connection attempts, with timestamps and the zone pairs tested.	Paths that succeed when they should fail, or tests that were never run from the source zone.
Wireless network separation	Check that guest, corporate and device networks are isolated from each other and from internal systems.	SSID and VLAN mapping, wireless controller settings for client isolation, and a sampled test from guest to internal addresses.	Guest networks reaching internal hosts, shared VLANs across SSIDs, and access points left at default settings.
Cloud network separation	Review virtual networks, subnets, security groups and peering to confirm that production, test and management planes are separated.	Cloud network topology export, security group rules, peering and transit routing records, and account or subscription boundaries.	Production and development sharing one virtual network, management ports open to broad ranges, and forgotten peering links.
Rule change records	Select a sample of recent rule changes and check each was requested, approved, tested and recorded.	Change tickets, approvals, rule diffs, and the date each change went live.	Emergency changes with no later review, rules added without approval, and changes that do not match the ticket.
Logs of permitted and denied traffic	Check that denied and permitted cross-boundary traffic is logged, retained and reviewed, and that reviews leave a record.	Sampled log entries for denied and permitted flows, retention settings, and review sign-offs or alert records.	Logging turned off for some rules, no evidence of review, and logs kept too briefly to cover the audit period.
Third-party and exception access	Trace vendor and remote access paths into zones and confirm each has an owner, scope and end date.	Register of third-party connections, exception approvals with expiry dates, and access review records.	Undocumented exceptions, vendor accounts still active after contracts ended, and remote paths bypassing the gateway.

How to segregate networks for A.8.22, step by step

This sequence turns the requirement to separate groups of services, users and systems into a documented, enforced and reviewed network design. Each step produces an artifact an assessor can inspect, from the first asset inventory to the owner-approved rule set.

Inventory networks, assets and connections
Start by listing every network the organization operates or relies on: data center segments, office and guest Wi-Fi, cloud virtual networks and subnets, VPN ranges, and connections to suppliers and partners. For each network, record the systems it hosts, the owner and the traffic it carries. Network engineers and system owners usually do this together, and the output is a network inventory with a diagram that shows how the segments connect. The step is done when every system in the asset register maps to at least one network segment and no segment is unexplained.
Classify services, users and systems into domains
Group the inventoried items into security domains based on sensitivity, function and trust level. Typical groupings include production workloads, administrative management networks, user workstations, development and test, payment or regulated data, and untrusted or guest access. Record the criteria used for each domain so that placement decisions can be explained later. The output is a zone register that lists each domain, its members, its purpose and its data classification. The step is complete when the register is approved by the information security owner and each system has exactly one home domain.
Define permitted flows between domains
For each pair of domains, decide which traffic is needed for business purposes, which protocols and ports it uses, and in which direction it may flow. Application owners should confirm each flow, because undocumented dependencies are the most common reason segmentation breaks in production. The output is a flow matrix or set of flow records that state the source, destination, service, justification and approver. Ask the business owner to sign off each flow that crosses a security boundary. The step is done when every cross-domain connection has a stated business reason and a named approver.
Configure gateways and default-deny rules
Place controlled gateways, such as firewalls, routers with access lists, or cloud security groups and network policies, at each boundary between domains. Set the default action to deny, then add allow rules that match the approved flow matrix and nothing else. Use address aliases or object groups so that rules follow named domains rather than scattered addresses. Wireless and cloud networks need the same treatment: guest Wi-Fi should reach only the internet, and cloud subnets should reach only the services in the flow matrix. The output is a rule export from each gateway that can be compared line by line with the flow matrix. The step is complete when the comparison shows no rule without a flow and no approved flow without a rule.
Enable logging and set up rule review
Turn on logging for rule matches at each boundary, especially denied traffic and any rule that permits administrative protocols across domains. Forward those logs to the central monitoring platform so that someone reviews them, and define who reviews them and how often. Schedule a periodic review of the rule set against the flow matrix to catch drift, expired exceptions and rules added outside change management. The output is a logging configuration record and a review record for each cycle, noting findings and actions taken. Confirm with your own tooling how long logs are retained and whether they are protected from alteration.
Document the design and assign rule owners
Write down the final segmentation design: the zone register, the flow matrix, the gateway inventory, the default-deny policy and the logging and review arrangements. Name an owner for each gateway and for each domain, with responsibility for approving changes to its rules. Link the design to the network security and change management procedures so that future changes follow the same path. The output is a current network segmentation document with an owner list and a version history. The step is complete when the document has been approved, every rule set has a named owner, and the people who operate the gateways know where the document lives.

Evidence that passes an A.8.22 test and how to keep it current

An assessor testing A.8.22 wants to see that the segregation design exists, that every gateway rule traces to an approved need, and that the rules in production match what was approved. The six artifacts below connect those points, and each one goes stale unless it is tied to a routine or a change process.

Current network diagram and zone register

The diagram shows each security zone, the groups of services, users and systems placed in it, and the boundaries between zones. The zone register lists each zone with its owner, purpose and the systems it contains. Assessors compare these against live configuration, so a diagram that shows a flat network with a few labels will not support the control. Keep it current by requiring a diagram and register update in the same change ticket that adds a subnet, VLAN, VPC or wireless network. Review both at least once a year and after any reorganization.

Approved flow matrix

The flow matrix lists which source zone may reach which destination zone, on which ports and protocols, and for what business reason. It is the document that shows traffic between security boundaries is controlled according to business needs, which is the core of the control text. Each row should name an approver. Keep it current by treating a new row as a change request, and by checking the matrix against gateway rules during each periodic review so that unapproved flows are caught.

Gateway rule exports with owners and justifications

Export the rulesets from each firewall, router, cloud security group and wireless controller that enforces a boundary. Each rule should carry an owner and a written justification that maps to a row in the flow matrix. In OPNsense, aliases can group address sets so the export stays readable. Rules without an owner or a reason are the findings assessors write most often. Keep exports current on a schedule, such as monthly or at each change window, and store them with a timestamp so a reviewer can see what was in force on a given date.

Change records for rule modifications

Each addition, edit or removal of a gateway rule needs a record showing who requested it, the business reason, the approver, the test performed and the rollback plan. These records prove that segregation is maintained through change rather than drift. Auditors often sample them against the rule exports, so the ticket number should appear in the rule description or the commit message of the configuration repository. Keep them current by refusing rule changes that arrive without a ticket, and by reconciling exports against tickets each month.

Test results showing blocked paths

Testing should show that traffic which is not approved is actually refused, not only that approved traffic works. Record tests from a host in one zone to restricted services in another, including guest or wireless networks reaching internal systems and cloud accounts reaching each other. Keep the test scripts under version control and rerun them after each rule change and on a fixed schedule. Record the date, tester, expected result and actual result. A test that has never failed deserves a second look, because it may not be testing anything.

Logs of cross-boundary denials and permitted flows

Logs of denied and allowed traffic across zone boundaries show that the controls operate in practice and that anomalies reach a reviewer. Enable logging on boundary rules, forward the events to a central store, and set a retention period that your policy defines. Confirm the logs record the source zone, destination, rule identifier and action. Review denials for patterns, such as repeated attempts from a guest network toward a production subnet, and record the review. Keep the logging configuration itself in the evidence set, since an assessor may ask whether it changed.

What meeting A.8.22 costs in money and effort

This table compares the main cost components of segregating networks under A.8.22, who is paid for each, whether it recurs, and what moves it up or down. Read it as a checklist for a written quote: most of the effort sits in design, rule migration and evidence upkeep, not in the firewall license. No prices or durations are given because none were supplied, so ask each provider for figures tied to your scope.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Gateway and firewall licenses or hardware	Licenses recur on renewal; hardware is one-time with replacement cycles	Number of security boundaries, throughput needs, high availability pairs, and whether WAF or logging modules are added	Use open-source gateways such as OPNsense where they meet the need, and confirm support terms; open source removes license spend, not configuration effort
Engineering time for design and rule migration	One-time for the initial build, recurring for each new zone or service	Number of existing flat networks, undocumented rules, legacy services that need new paths, and cloud and wireless segments	Document zones and allowed flows before migrating; reuse aliases and templates; scope the first phase to the most sensitive systems
Testing time for path validation	One-time per boundary, repeated after material change	Number of permitted and denied flows to test, whether tests are scripted, and how often change management reopens zones	Script allow and deny tests so they can be rerun; agree the test matrix in the design stage
Evidence upkeep	Recurring for as long as the ISMS operates	Frequency of rule changes, log retention settings, review cadence, and how many systems export logs into the evidence store	Export rule sets and review sign-offs from version control on a schedule; keep the evidence format fixed so reviews stay quick
External penetration or configuration review	Recurring, usually tied to the testing plan or auditor expectations	Scope of the review, whether it covers cloud and wireless segments, and whether firewall rules are reviewed or only exposed services	Define the scope in writing before work starts; ask whether rule-base review is included or priced separately
Auditor sampling time	Recurring within each audit cycle	Number of segments, rule sets and change records the auditor samples, and how quickly evidence can be produced	Keep a current network diagram, rule inventory and sample change records ready before the audit; confirm the certification body's sampling approach in advance
Implementation partner fees	One-time for the build, optional recurring for retainers	Fixed-scope versus open-ended work, number of environments, and whether the partner also runs tests	Request a written, fixed scope with deliverables; separate build, testing and evidence support into distinct line items

Which self-hosted open-source tools support segregation evidence

A stateful packet filter is the tool most directly tied to segregation, because it decides which traffic may cross from one network segment to another. OPNsense is an open-source firewall platform under the BSD-2-Clause licence, and its filter rules pass, block or reject traffic by source, destination, port and protocol. Rules can refer to aliases, which group addresses such as a management subnet or a database tier, so a reviewer can read the policy as a set of named business flows rather than raw addresses.

Pass, block and reject actions: Each rule states what happens to matching traffic, so the allowed paths between zones are explicit and can be reviewed.
Aliases for address groups: Named groups of hosts or networks keep the rule set readable when zones change.
Per-rule logging: Where logging is enabled for a rule, each match can be reviewed in the live log view, which gives evidence that the boundary was exercised.
Default deny between zones: A closing deny rule at the end of each inter-zone policy shows that unlisted traffic is not permitted.

Confirm the licence terms for the OPNsense release in use, and export the rule set and log samples as dated evidence for the assessor.

Where segregation programs usually fall short at audit

Most segregation weaknesses found in A.8.22 reviews are not missing firewalls. They are gaps in inventory, rule hygiene, guest and cloud boundaries, third-party access and change records. Each card names one gap, the fix that closes it and the evidence an assessor can check.

No maintained zone inventory

Many organizations cannot list their network zones, the systems in each zone or the business reason for each boundary. Without that list, no one can say whether a rule is supposed to exist. Build a zone register that names each segment, its owner, the services and user groups it holds and the gateways that border it. Review it at a set interval and after major changes. The evidence is the dated register, the owner sign-offs and a reconciliation showing that live address ranges match the documented zones.

Any-to-any rules left from migrations

Firewall rule sets often carry broad allow rules added during a network move or an emergency fix and never removed. These rules quietly undo the separation the design intended. Export the active rule base, flag rules with any source, any destination or open port ranges, and require each remaining rule to name a business purpose and owner. In OPNsense, aliases for address groups keep rules readable, and per-rule logging lets you show which rules actually match. The evidence is the rule export, the list of removed rules and match counts over a review period.

Guest wireless bridged to internal segments

Guest wireless networks are frequently placed on the same VLAN or bridge as staff or server networks, or allowed to reach internal address ranges for printing and convenience. Place guest SSIDs on their own VLAN with a gateway that permits internet egress only, and block traffic to internal ranges by default. Test the boundary from a guest client by attempting connections to internal hosts. The evidence is the VLAN and gateway configuration, the blocked-connection logs and the recorded test results from the guest client.

Cloud subnets without documented flows

In cloud accounts, VPCs and subnets are often created quickly, with security groups copied between projects and no written record of which workloads must talk to which. Document the permitted flows between each subnet and workload tier, then express them as infrastructure as code so that changes go through review. Check for security groups open to all addresses and for peering routes that bypass the intended gateway. The evidence is the flow matrix, the infrastructure as code repository history and a scan report showing no unintended routes.

Third-party remote access outside rule review

Vendor VPN tunnels, jump hosts and remote support sessions frequently bypass the normal firewall change process, so the access exists without an owner or an expiry date. Route all third-party access through a named gateway, require an approved ticket for each account, and set an end date on every grant. Review the list of active tunnels and accounts on a fixed schedule and remove those with no current need. The evidence is the access register, approval records, session logs and the review record showing revoked accounts.

Rule changes without records

When a firewall or cloud rule changes, many teams cannot show who requested the change, who approved it, why it was made or whether it was tested. Without that trail, an assessor cannot tell an authorized boundary change from an unauthorized one. Require every change to reference a request, record the approver and the business reason, and keep the configuration under version control with exported diffs. Compare the running configuration to the approved copy on a schedule. The evidence is the change tickets linked to configuration commits, approval records and periodic drift reports.

Who does what for A.8.22: your team, a partner and the auditor

Your organization owns the control. Its people decide how the network is divided into security domains, which groups of services, users and systems belong in each, and which traffic between them is allowed for business reasons. A.8.22 asks that segregation follow business needs, so those needs must come from the business owners of each service and not from the implementer. Your team also accepts the residual risk on every boundary and signs off each gateway rule that opens a path between zones.

Zone design: Decide the security domains and the reason each system sits in its zone, and keep the reasoning in the network documentation.
Rule approvals: Approve every allow rule that crosses a boundary, with the business owner named on the request.
Risk decisions: Record who accepts the risk of each boundary and any exception, with a review date.
Statement of Applicability: Write the A.8.22 entry in your own words, stating how segregation is implemented and where the evidence sits.
Ongoing review: Confirm that zones and rules still match the business after changes to services, staff or cloud accounts.

Before engaging anyone, confirm that a named person in your organization can answer for each zone and each approved rule.

Common questions about A.8.22 segregation of networks

How much effort does network segregation take for a small team?

The effort depends on how many distinct groups of services, users and systems the team runs, and on how many network boundaries already exist. A small team usually starts by listing its information services, the users who need them and the systems that hold sensitive data, then deciding which of those groups should sit behind a controlled gateway. For a single office with one cloud account, the first pass is often a short design exercise followed by firewall rules, VLAN or subnet changes and documentation. Ongoing effort is smaller but recurs: rule reviews, new-service onboarding and checks that traffic between zones still matches the business need. Ask any partner for a written breakdown of design, configuration, testing and documentation so you can compare the work with your own staffing.

Can a flat network pass A.8.22 if it is documented?

Documentation alone is unlikely to satisfy A.8.22. The control asks that groups of information services, users and systems are segregated and that traffic between security boundaries is controlled according to business needs. A written statement that the network is flat describes the gap rather than closing it. An auditor will expect to see defined boundaries, the rules that govern traffic across them and evidence that those rules are applied. If your organization has a flat network for a sound reason, the defensible position is to document the risk assessment, the compensating controls and the decision to accept the risk, then confirm with your certification body how it will test that decision. Your own risk treatment records are the place to start.

Does the team need an implementation partner, or can it do the work alone?

Many teams can design and run segregation in house if they have engineers who understand routing, firewall policy and the organization's systems. An implementation partner is useful when internal staff lack time, when the environment spans several clouds or sites, or when the team wants an independent view of its design. In either case, the organization owns the control, its risk decisions and its Statement of Applicability. A partner prepares systems, configurations and evidence, while only an independent auditor or certification body issues reports or certificates. DeployOpen implements and documents self-hosted open-source platforms in the client's own infrastructure under fixed-scope engagements agreed in writing before work starts.

How long does segregation work take?

The duration depends on scope, meaning the number of networks, sites, cloud accounts and services involved, along with how well current traffic flows are understood. There is no fixed timeline that applies to every organization. A fixed-scope timeline is agreed in writing with the client before work starts, based on the deliverables and the access the team can provide. When you request a quote, ask for milestones covering discovery, design review, change windows, testing and handover of evidence. Changes to production traffic often need approval windows, so confirm those constraints early.

Do cloud and wireless networks count for A.8.22?

Yes, the control applies to the organization's networks in whatever form they take, which includes cloud virtual networks and wireless networks. A cloud account with production and development workloads in the same virtual network has the same segregation question as an on-premises VLAN. Wireless should separate corporate users, guests and any systems that handle sensitive data, with controlled gateways between them. Confirm with your certification body how it wants cloud and wireless boundaries described in your scope and in the evidence you provide. Your cloud provider's network controls can help, but the organization still decides which groups are separated and how traffic between them is governed.

How does A.8.22 relate to NIS2 and NIST mappings?

A.8.22 is mapped to several other frameworks, which can help teams reuse evidence. ENISA's mapping for its NIS2 technical implementation guidance links A.8.22 to point 6.8, which covers network segmentation in Commission Implementing Regulation (EU) 2024/2690. NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.22 to AC-4 (Information Flow Enforcement) and SC-7 (Boundary Protection). Both ISO/IEC 27001:2022 to CSF 2.0 mappings in NIST's OLIR catalog, which NIST does not endorse, map A.8.22 to PR.IR-01. NIST cautions that mapped controls are not always equivalent, so treat these links as starting points. Check each requirement's wording against your own design before claiming that one piece of evidence satisfies several frameworks.

What should we send to get a quote for network segregation?

A useful quote request describes the environment and the goal. Send a current network diagram or inventory, the number of sites, cloud accounts and wireless networks, a list of the main information services and the groups of users and systems that access them, and any existing firewall or gateway products. Include your current ISO 27001 status, whether you hold a Statement of Applicability, and the date by which you need evidence. Note any change windows, change approval rules and systems that cannot be interrupted. A fixed-scope quote follows from the written scope, so the clearer these inputs are, the more precisely the scope and deliverables can be agreed.

How DeployOpen scopes, implements and prepares A.8.22 evidence

DeployOpen works on A.8.22 Segregation of networks as an implementation partner. We plan the network domains, build the gateways and filtering between them in your own infrastructure, and document the evidence an independent auditor will test. Your organization keeps ownership of the control, and only an independent certification body can issue a certificate.

How we scope

Written scope names the service groups, user groups and systems to be separated, agreed before work starts
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any build
Scope records which cloud accounts, data centers, wireless networks and segments the control covers
Ongoing support for the segregation design is available as a retainer after the initial scope

How we build

We plan network domains and document which traffic may cross each security boundary and why
Gateways between domains are configured with rules by source, destination, port and protocol, with aliases for groups
Rule-match logging is enabled so each allowed or blocked flow between domains can be reviewed later
Runtime detection on Linux hosts can flag unexpected network connections that break the intended separation

How we hand over

Network diagrams, zone definitions and the rule set are documented as versioned records in your repository
Test results show that blocked paths between domains fail as designed, with the test steps retained
Evidence mapping links each domain and gateway rule to the A.8.22 control and to your Statement of Applicability
A handover session walks your security and operations staff through the rules, logs and change process

How we support

Rule changes go through your change management process, with DeployOpen supplying impact notes for review
Periodic review of rule sets and log samples is available as a retainer, aligned to your audit cycle
Re-testing after upgrades, new cloud networks or new wireless segments is scoped as additional work
Your certification body remains the party that assesses the control, and we prepare the records it will request