If one server or account in your business is compromised, what prevents an attacker from reaching everything else?
That question is worth asking after The Australian reported a cyber breach involving an isolated NSW Health server. The report describes a police investigation and carries a statement from NSW Health about the position on patient data.
It does not provide a technical account of the attack. In particular, describing a server as isolated does not tell us whether it was separated before the breach or disconnected during the response. We should not treat that wording as proof that a particular security control succeeded or failed.
There is nevertheless a useful lesson for organisations of any size: systems need boundaries, and those boundaries need to work when something goes wrong.
What is currently known?
As at 4 November 2026, Alexandra Feiam's NewsWire report, published by The Australian, says NSW Health confirmed a breach affecting an isolated server. It reports that the breach was declared a major incident and was being investigated by the NSW Police Cyber Crime Squad.
The report quotes NSW Health stating: “No patient data has been impacted at this time”. It also reports the department's position that patient data was not currently at risk from the limited breach. Those are attributed statements about the assessment at that stage, rather than an independent forensic finding by this blog.
The published account does not establish the initial access method, affected software, the server's connections or the timing and nature of its isolation. An investigation can change what is known. An initial assessment about patient data should not be extended into a claim that no information of any kind was accessed.
I have not located a standalone official incident statement to supplement that reporting. The analysis below concerns general security principles; it is not a reconstruction of NSW Health's environment.
There is also no verified basis in the material reviewed for connecting this incident to October's PHP vulnerabilities. The NSW Government's 22 October PHP response statement concerns a separate response and does not establish a link to this incident.
What does isolation actually mean?
Several different controls can be described loosely as separation:
- Network segmentation divides a network into smaller sections. Rules then govern which systems can communicate across those sections.
- Server or workload isolation separates individual applications or computing environments. Its value depends on the access that remains between them and to their management systems.
- Access-control boundaries restrict what an identity can do. An account may be allowed to submit an enquiry without being allowed to read customer records or administer the server.
- Emergency isolation restricts an affected device or service during incident response, potentially interrupting normal business functions to limit further activity.
These are related controls, but they do different jobs. An application may still need a narrowly defined connection to another service. That does not justify giving it general access to the rest of the organisation.
The ACSC's network segmentation overview distinguishes dividing a network from enforcing rules between systems. Putting two systems in different zones is only useful if the rules actually restrict access.
How an attacker can move beyond the first system
Imagine an attacker gains access to a website server. The server holds a reusable administrator credential, and the same credential opens the business's shared files. A compromise that began with the website now has a route to internal information.
That is a general example, not a description of the NSW Health incident. It illustrates lateral movement: using an initial foothold to reach other systems. Shared credentials, broad permissions and unnecessary connections can make that movement easier.
The ACSC's implementation guidance recommends restricting communication to what hosts and services need, with enforcement and monitoring across more than one layer. A diagram showing separate boxes is not enough if an unrestricted connection or privileged account bypasses the boundary.
Why this matters to a small business
A business with ten employees may have a public website, Microsoft 365 or Google Workspace, accounting software, shared customer files, laptops and backups. It may never operate a traditional server room. It still has access relationships to manage.
A website form might send email through an external service. An accounting integration might read customer details. An IT provider might administer several platforms. Each relationship should have a defined purpose, limited permissions and a way to revoke access.
Network rules alone do not govern every cloud service. Account roles, application permissions and administrative access also determine how far a compromise can spread. Two services hosted separately may still share a powerful login identity.
The aim is proportionate separation. A small business needs to understand its important dependencies and remove unnecessary paths between them, rather than reproduce an enterprise network design.
Five practical ways to limit the damage
1. Separate public services from internal systems
Ask whether the website host needs any connection to office devices or sensitive business records. Where an integration is necessary, define the specific service and data it can access. Avoid keeping general-purpose administrator credentials on a public server.
My article on the October PHP vulnerabilities and simpler business websites examines reducing publicly exposed application components. Separation addresses the next question: what can an exposed component reach if it is compromised? These are complementary design decisions, without implying that PHP caused this incident.
2. Give accounts and applications only the access they need
A form-processing account should not need permission to administer the business's email or browse all customer files. An employee's access should match their role, and it should be reviewed when that role changes or ends.
Include service accounts, integrations and supplier access in the review. Permissions that nobody remembers granting are still permissions an attacker may be able to use.
3. Protect administrator identities
Use separate administrative identities for privileged work, rather than carrying those permissions through everyday email and web browsing. Enable phishing-resistant multi-factor authentication where supported, with a recovery process that does not provide an easy bypass. The ACSC's MFA guidance explains why stronger authentication methods matter.
MFA protects an entry point; it does not make excessive permissions harmless. Limit which services an administrator can reach, review that access and retain useful authentication logs.
4. Protect the recovery route
A compromised everyday account should not be able to delete every backup. Check whether backup administration has separate credentials and whether retained copies can be altered or removed through the same accounts that manage production systems.
The ACSC's network defence guidance recommends separate backup administration credentials and testing recovery. Ask the provider what would remain recoverable after a privileged account compromise, and request evidence from a restoration exercise. A successful backup notification does not answer that question.
5. Prepare to contain an incident
Know who can disable an account, revoke sessions, restrict an integration or isolate a device, and how to contact them if normal email is unavailable. Record which business functions those actions will interrupt and who can authorise the response.
Agree what logs are collected, who reviews unusual activity and how evidence will be preserved. A containment plan needs named people and usable access, as well as written instructions. As the UK NCSC's guidance on limiting compromise explains, visibility, response capability and protected administrative controls help limit disruption.
Segmentation is not a complete defence
Separation can be undermined by compromised privileged credentials, permissive trust relationships, exposed management interfaces or cloud identities with access across several services. Rules also drift as integrations and business requirements change.
Review and test the boundaries with your provider. Establish which connections are allowed, why they exist and whether monitoring would reveal unexpected activity. Avoid interpreting a firewall, a separate hosting account or a cloud subscription as proof that the whole arrangement is contained.
Questions to ask your IT provider
- If our website server is compromised, can it access internal systems or sensitive records?
- What backups survive compromise of an ordinary account, and what survives compromise of an administrator?
- Which people, service accounts and suppliers have privileged access across multiple services?
- Can we promptly isolate a device, disable an integration and revoke active sessions?
- Who investigates unusual activity, and what logs will be available?
Where several suppliers are involved, make the handover explicit. My article on outsourced IT and third-party cyber security risk discusses why responsibilities and evidence matter alongside the service description.
Plan for what happens after a control fails
Preventive controls deserve attention. So does the consequence of an attacker getting past one of them.
Thoughtful separation, limited permissions and a workable response plan can reduce the potential impact of a compromise. They give the business more options than hoping the first affected system is also the last.
Solway Web Consulting can help review the connections between website hosting, business services and administrative access. Contact Solway Web Consulting to discuss an infrastructure or cyber security review.
Tags: security, small-business, australia, infrastructure