ASD Essentials IT.PRO-18.1 Isolate Systems in Criticality- and Trust-Based Network Zones with Approved, Monitored Pathways
What it says
Isolate systems within network zones based on business criticality and trust level, and restrict and monitor inbound and outbound access to explicitly approved pathways and services.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishIsolates systems in network zones by importance and trust, and watches traffic in and out, allowing only explicitly approved routes and services.
The organisation divides its network into separate zones, a little like locked doors inside a building. Each system goes in a zone that matches how critical and trusted it is. For example, internet-facing services, sign-in systems and critical systems do not share one open network. To meet this, firewalls block traffic between zones by default and allow only approved routes and services. Allowed traffic is watched, the zones are tested and the routes reviewed regularly.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
- Business systems
- User devices (does not apply)
Why it matters
A flat network has no internal zones. An attacker who gets in through a public web app or exposed remote access can go straight to the directory, admin and critical systems. Without monitoring, a hacked server calling out to the internet can go unnoticed.
How to implement
The network architect should define zones by function, business criticality and trust level, such as boundary, identity, critical services, admin and business zones.
Record each in-scope system's zone in a register.
Network engineers should build each zone as a separate network, enforced by firewalls or filtering routers rather than unfiltered virtual networks (VLANs).
Make service provider and remote access links end at set boundary points, and block unauthorised devices from joining.
Firewall administrators should block inbound and outbound traffic by default at every zone boundary.
Allow only approved routes, recorded with source, destination, service and reason, and limit internet, provider and staff network access to them.
Security operations should centrally log allowed and blocked connections at every zone boundary, and alert on traffic outside approved routes.
Investigate alerts, such as a server unexpectedly connecting out, and flag unused routes for review.
The security lead should arrange tests that try to cross every zone boundary, repeated after major network changes, and track gaps until fixed.
Each review cycle, firewall administrators should remove routes no longer justified from the rules and register.
Keep it running
The network team keeps the zone and route registers current, and sends every new system, rule change, remote access service and provider connection through change management. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems. This action doesn't cover staff devices, so treat the staff network as lower trust, reaching zones only by approved routes. Retest the zones after major network changes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the zone model, register and network diagrams, with sample systems from each ASD domain.
Look at
Whether systems sit on flat or shared networks, are missing from the model, or zones vary between sites.
Good evidence
Every sampled system sits in a zone that fits its function, criticality and trust level.
- Check 2 of 5What an auditor asks for
Ask for
Ask network engineers to show, from live settings, how each sampled zone boundary is enforced.
Look at
Whether zones exist only on paper, rely on unfiltered VLANs, or let unauthorised devices join.
Good evidence
Traffic crossing every sampled boundary passes through a filtering control, such as a firewall.
- Check 3 of 5What an auditor asks for
Ask for
Request rule sets for sample zone boundaries, including internet-facing ones, with the approved routes register.
Look at
Whether defaults allow traffic, rules are broad or unapproved, or systems are reachable outside approved routes.
Good evidence
Each boundary blocks by default, and every allowed route and service matches a recorded approval.
- Check 4 of 5What an auditor asks for
Ask for
Request sample boundary logs and alerts, with records of their review and follow-up.
Look at
Whether some boundaries log nothing, or logs and alerts are never reviewed or followed up.
Good evidence
Traffic in and out at every boundary is logged centrally, and unexpected connections are investigated.
- Check 5 of 5What an auditor asks for
Ask for
Request recent zone test reports, the set route review cycle and the rule changes that followed.
Look at
Whether testing is missing, partial or stale, no review cycle is set, or unjustified routes stay live.
Good evidence
Current tests cover every zone with gaps fixed, and scheduled reviews update the live rules.
ASD indicators of good practice (14)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(4)
- NE-1Systems are deployed on shared or flat network segments with no segregation between functions or trust levels.
- NE-2No access controls restrict network access from external or general user networks to in-scope systems.
- NE-3Segmentation is documented or administratively defined but not enforced by technical controls.
- NE-4Segmentation has not been validated through technical assessment.
Partially effective(5)
- PE-1Network segmentation has been implemented but does not cover all in-scope systems, or segments are defined inconsistently.
- PE-2Access controls exist between segments, but deny-by-default is not enforced, or some pathways are permitted without documented approval.
- PE-3Technical enforcement is in place for some segments but relies on a single mechanism that does not provide meaningful isolation.
- PE-4Validation has been performed for some segments but not consistently across in-scope systems, or validation is out of date.
- PE-5Pathways are reviewed, but findings are not actioned, or the review cycle is not defined by the organisation.
Fully effective(5)
- FE-1Systems within scope are deployed in network segments defined according to function, criticality and trust level, with segmentation applied consistently.
- FE-2Deny-by-default access controls are enforced between segments, with access from external and general user networks limited to documented and approved pathways.
- FE-3Segmentation is enforced through network-layer technical controls that provide meaningful isolation.
- FE-4Segmentation has been validated through technical assessment with results documented and gaps remediated.
- FE-5Approved pathways are reviewed on a regular cycle defined by the organisation, with unjustified pathways removed and changes reflected in the access control configuration.
Mappings
Closest match in ISO/IEC 27001: A.8.22, Network Segregation for Security, which this control covers in full and more.
ISO/IEC 27001: 2 mappings
This control is broader than A.8.22.
IT.PRO-18.1 requires systems to be isolated within network zones based on business criticality and trust level, with inbound and outbound access restricted to explicitly approved pathways and services and monitored. Its zoning requirement directly delivers the segregation of groups of information services, users and information systems required by Annex A 8.22. IT.PRO-18.1 is broader, as it also requires traffic into and out of each zone to be limited to approved pathways and monitored, which Annex A 8.22 does not state.
This control partially meets A.8.20.
IT.PRO-18.1 requires systems to be isolated within network zones by business criticality and trust level, with inbound and outbound access restricted and monitored to explicitly approved pathways and services. Zoning, traffic restriction and monitoring are specific measures for securing and controlling networks, so IT.PRO-18.1 directly contributes to Annex A 8.20. Annex A 8.20 is broader, also covering the security and management of networks and network devices themselves.
ASD Information Security Manual: 4 mappings
This control partially overlaps ISM-0520.
IT.PRO-18.1 requires systems to be isolated in network zones by criticality and trust, with access restricted to approved pathways; ISM-0520 requires network access controls that stop unauthorised network devices and IT equipment connecting, which supports that restriction.
This control partially overlaps ISM-1181.
IT.PRO-18.1 requires systems to be isolated in network zones by criticality and trust level, with access restricted and monitored; ISM-1181 requires networks to be segregated into multiple zones by the criticality of servers, services and data, the zoning part of that action.
This control partially overlaps ISM-1385.
IT.PRO-18.1 requires systems to be isolated in network zones by criticality and trust level, with access restricted to approved pathways; ISM-1385 requires administrative infrastructure to be segregated from the wider network and the internet, one case of that isolation.
This control partially overlaps ISM-1577.
IT.PRO-18.1 requires systems to be isolated in network zones by criticality and trust level; ISM-1577 requires an organisation's networks to be segregated from its service providers' networks, applying that trust-based separation at the service provider boundary.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.