How to segment a government office LAN without breaking services

A typical Queensland Health regional office in Brisbane, a small Service NSW branch in Parramatta, or a back-office unit in Canberra's Russell Offices precinct all share the same quiet truth: the local area network connects printers, kiosks, payroll terminals, building management sensors, and the desktops of policy officers, often without anyone re-examining the design for years. Staff come and go, contractors arrive with laptops, and a new case management platform quietly lands on the same flat network that has run the photocopier since 2014. That flat design is what network segmentation is meant to fix, and it is exactly what the Australian Government Information Security Manual and the Protective Security Policy Framework expect public sector agencies to maintain.

The argument for splitting a LAN into zones is no longer academic. Cyber incidents affecting local councils, water utilities, and state departments have shown how a single compromised device can pivot through shared switches into back-office finance or citizen records. Segmentation reduces that blast radius, limits lateral movement, and makes the difference between a contained event and a multi-week response.

This article walks through the core ideas behind LAN segmentation for Australian government offices, the practical steps to plan a clean design, and the operational habits that keep the architecture from drifting back into a single broadcast domain a year after rollout.

Why segmentation matters for public sector networks

Government networks sit in a peculiar spot. They must remain open enough for inter-agency collaboration, shared service providers, and visiting contractors, yet closed enough to keep citizen identifiers, salary data, and cabinet material from drifting where they should not. The PSPF and the Essential Eight maturity model both push agencies toward a posture where sensitive traffic is isolated, default-deny rules apply between user groups, and any new connection is justified rather than assumed.

In practice, segmentation also helps with audit and procurement. A clear zoning scheme maps neatly onto the Information Security Registered Assessors Program controls, the NSW Government Digital Assurance Framework, or the equivalent Victorian DHS cyber assurance process. When an auditor asks which systems hold personal data, a well-segmented network already has the answer in its IP plan.

For chief information security officers based in places like Adelaide's Lot Fourteen or the Riverside Centre in Hobart, segmentation is also a way to manage risk across multi-tenant buildings. A single floor might host a federal tenant, a state tenant, and a private sector partner under the same roof, each with different trust levels.

Core concepts: VLANs, subnets, and trust zones

The vocabulary around LAN segmentation can feel overlapping, so it helps to settle the terms early. A VLAN is a logical broadcast domain carved out on managed switches using IEEE 802.1Q tagging. A subnet is the IP address range that sits inside that VLAN. A trust zone is a broader grouping, such as user workstations, server room, guest Wi-Fi, or operational technology, that bundles several VLANs and subnets under a shared security policy.

In a typical Australian government office, you would expect to see a handful of well-understood zones, even if the exact names vary between departments.

• User endpoints and privileged workstations for ongoing staff and sysadmins
• Servers, databases, and line-of-business applications that hold citizen data
• Building management systems, IP CCTV, and IoT devices sharing the cabling plant
• Guest, contractor, and unmanaged devices, including BYOD tablets in meeting rooms

Each of these zones carries a different risk profile, and the firewall policy between them should reflect that. Servers holding identifiable records are not on the same broadcast domain as a printer that anyone can plug a USB stick into.

Mapping assets, users, and data flows

The hardest part of a segmentation project is rarely the switch configuration. It is the asset and dependency mapping that comes before it. Agencies that have already invested in ERP selection for departments usually have a useful starting point, because the ERP rollout forces them to list servers, integrations, and user roles.

Start by listing physical sites, from the CBD tower in Melbourne's Collins Street to a regional depot in Townsville or Broome. For each site, capture which business units sit there, which line-of-business applications are hosted locally, and which services depend on a central data centre. Pay attention to legacy systems that were never designed for modern firewalls, such as older SCADA equipment in a water utility or a building access system that uses proprietary multicast traffic.

User roles matter as much as devices. A policy officer, a finance approver, a contractor doing a six-month project, and a visiting auditor all need different paths through the network. Where possible, group roles rather than individuals, and tie those groups to identity groups in the agency directory so that firewall rules can be enforced through 802.1X and role-based access control.

Designing the policy, firewall rules, and gateway posture

Once the inventory is in place, the policy design becomes a paper exercise that is easier to revise than switch configs. Start with a default-deny posture between zones, then write the minimum set of allow rules that business operations need. Each rule should specify source zone, destination zone, service, port, and the business reason, with a review date attached.

Routing between zones typically sits on the office's perimeter or internal firewall pair, although some larger agencies in Canberra and Sydney use a dedicated internal segmentation gateway. Where the budget allows, microsegmentation on the server hypervisor can add a second layer for crown-jewel systems, but it is rarely a starting point for a small office.

The table below compares three common approaches that Australian government offices tend to weigh against each other.

Approach	Typical scale	Strengths	Limitations	Best fit for
VLAN-based segmentation	Whole office LAN	Low cost, well understood by networking teams, works on existing switches	Relies on switch configuration discipline, weak isolation if trunk ports are misconfigured	Standard departmental offices with a few hundred endpoints
Firewall-zone segmentation	Office plus data centre	Strong traffic filtering, clear policy documentation, supports IRAP evidence	Higher cost, requires specialist skills, can become a bottleneck	Agencies with mixed tenants or operational technology
Microsegmentation	Data centre and cloud	Fine-grained controls, identity-aware, supports zero-trust goals	Complex to operate, often vendor-locked, needs strong asset visibility	Departments moving sensitive workloads into hybrid cloud

A practical tip is to keep the design boring. The more exotic the design, the harder it will be to hand over when a network engineer leaves for another role in the WA public service or a private sector offer.

Rolling it out without breaking the photocopier

Cutover is where most segmentation projects stall, because staff notice when the printer disappears from their workstation or when a long-running report server can no longer reach a database. A phased approach tends to work better than a big-bang weekend change. Start with read-only zones, such as guest Wi-Fi or a lab network, where an outage is embarrassing but not damaging. Then move to the printer fleet, which is usually a forgiving test bed.

Document the old flat design with screenshots and switch port lists before any change. Run parallel VLANs where possible, and use switch port descriptions that reference both the old and new VLAN IDs. Keep a rollback window of at least two weeks, because some Windows services and print queues only reveal their hard-coded assumptions after a few reboots.

Communicate with the people who will feel the change. A friendly notice on the intranet for the Brisbane or Perth office, a printed cheat sheet near the printer, and a clear escalation path to the service desk all reduce the number of tickets that arrive on Monday morning. The agencies that skip this step usually end up with segmentation on paper and the old flat network smuggled back in by an overworked technician.

Measuring success and keeping the design current

Segmentation is not a project that ends at cutover. New staff, new contractors, and new applications will constantly push against the rules, and the architecture will drift unless someone owns it. The most useful KPIs for government IT in this area tend to focus on how cleanly the design is holding up, rather than raw traffic volumes.

Metrics worth tracking over time:

• Percentage of switch ports assigned to a documented VLAN, with an owner named
• Number of firewall rules without a business justification attached
• Time taken to onboard a new contractor device
• Coverage of 802.1X authentication across user zones

A short quarterly review with the cyber security team, the network team, and a representative from facilities management is usually enough to catch drift. Pair that review with the annual IRAP or PSPF assurance cycle so that segmentation evidence lines up with the controls the agency already reports on.

The reward for keeping the design healthy is what originally made the case for segmentation. A compromised laptop in a regional office cannot reach payroll. A misconfigured contractor device cannot reach the case management database. A ransomware event in a peer agency does not automatically become a multi-department incident.

If your team is reviewing how your office LAN is zoned, or if you are planning a wider refresh that touches ERP, identity, or operational technology, the team behind this site is happy to compare notes. You can reach out through the contact page to share what you are working on or to ask about specific controls.