Essential Eight Series Part 8: Backups and Recovery: The Control That Only Works If You've Tested It
Every organisation has backups.
Almost every post-incident conversation starts the same way.
Yes, we had backups. No, we didn't know they weren't working.
Backups are the most psychologically comfortable control in the Essential 8 because they feel like a safety net. You set them up, you get confirmation that jobs are completing, and you move on. The problem is that a backup job completing successfully and a backup that can actually restore your environment under real conditions are two very different things.
The Essential 8 exists to make this distinction explicit. This control isn't asking whether you have backups. It's asking whether you have backups that work, that can't be compromised, and that you've actually recovered from.
Most organisations can only confidently answer yes to the first part.
What ransomware does to backups
Ransomware operators understood years ago that backups were the primary recovery path, so they started targeting backup infrastructure first.
The pattern in a well-executed ransomware deployment isn't to encrypt everything immediately. It's to establish persistence, move laterally, identify and access backup systems, and then encrypt or delete backup data before triggering the visible payload. By the time the ransom note appears, the safety net is already gone.
On-premises backup servers connected to the same network as production systems are particularly vulnerable to this. Backup agents running with elevated credentials, backup consoles accessible from standard management networks, tape libraries with network-connected management interfaces. All of these represent paths to the backup infrastructure that a lateral-moving attacker can follow.
This is why the Essential 8 specifically requires that backups be disconnected from systems they protect, and why the architecture of how backups are stored matters as much as whether they're running.
Immutability is not optional
The term immutable gets used loosely in vendor marketing, so it's worth being precise about what it means in this context.
A truly immutable backup is one where the data cannot be modified or deleted by any process, including administrator-level processes on the systems being backed up, for a defined retention period. The immutability is enforced at the storage layer, not the application layer, and not by access controls that an attacker with sufficient privilege could modify.
Object lock on cloud storage is one implementation of this. The critical distinction is whether the lock can be removed by credentials that exist within your environment. If an attacker who has compromised your domain admin account can also reach and modify your backup retention settings, the immutability is weaker than it appears.
The architecture that actually solves this separates the backup control plane from the production environment entirely. Backup policy, retention settings, and recovery capabilities managed through infrastructure that has no authentication dependency on the environment it's protecting. A compromised domain doesn't give an attacker any leverage over the backup system because the backup system doesn't trust the domain.
This is a meaningful architectural shift from traditional on-premises backup thinking, and it's the direction the Essential 8 guidance is pointing toward when it talks about backups being disconnected from systems and accounts they protect.
The offline copy requirement
The Essential 8 requires at least one backup copy to be offline, or offsite, or both.
For organisations running purely on-premises infrastructure, this typically means tape or some form of physical media rotation. For organisations running in or toward cloud, it means ensuring that backup storage exists in a location with no live connectivity to production systems, and preferably in a separate cloud tenancy or account with its own access controls.
The specific risk this addresses is ransomware or a destructive attack that propagates across everything connected to the network, including cloud-connected backup targets. An S3 bucket or blob storage target that is continuously connected and writable from the production environment is not an offline copy, regardless of where it physically sits.
Separation of accounts, separation of credentials, and where possible separation of cloud tenancy are the relevant design principles here.
The testing problem
This is where most environments have the most exposure, and where the honest conversation is hardest to have.
Backup testing in most organisations consists of verifying that jobs complete, occasionally spot-checking that individual files can be restored, and perhaps an annual DR exercise that tests recovery of one or two systems under controlled conditions with significant preparation time.
That is not the same as knowing what your actual recovery time looks like under realistic conditions.
The questions worth answering honestly: How long does it take to restore your domain controllers from backup? Your email platform? Your core line of business application? Have you ever actually done it from scratch, starting from bare metal or a clean cloud environment, without the institutional knowledge of the engineer who built the system originally?
Most organisations haven't. Which means their recovery time objective is an estimate, not a measurement.
The Essential 8 requires that backups be tested, and that restoration is tested, not just that backup jobs are monitored. The distinction matters because monitoring job completion tells you data is being written somewhere. Testing restoration tells you the data can actually be used.
Recovery time is a business conversation
One of the more useful outputs of proper backup testing is that it forces a realistic conversation about recovery time that most businesses haven't had.
The gap between what leadership assumes recovery looks like and what the technical team knows it actually looks like is frequently significant. Assumptions of hours where reality is days. Assumptions of full recovery where reality is partial recovery with significant data loss.
Having that conversation before an incident, with real numbers from actual restoration tests, is considerably more useful than having it during one.
It also frames the investment case for backup architecture improvements differently. The question isn't whether better backup infrastructure is worth the cost. It's whether the current recovery time, if it were measured honestly, is acceptable to the business.
What this control mandates
The Essential 8 maturity levels on this control ask for backups to be comprehensive, to be stored in a way that prevents them from being modified or deleted by compromised production systems, to include at least one copy that is disconnected, and to be tested including restoration testing.
Meeting that bar requires thinking about backup architecture as a security control, not just an operational one. The questions that matter are not just whether jobs are running but whether the backup system could survive a full compromise of the production environment and whether you could actually rebuild from it.
Cloud-native backup platforms designed around this threat model, where backup infrastructure has no authentication dependency on the environment it protects, where immutability is enforced at the storage layer, and where recovery can be initiated from a completely separate control plane, address these requirements more naturally than traditional backup architectures extended toward the cloud.
The architecture isn't the point of this piece. The point is knowing whether your current architecture can answer yes to those questions, and being honest about it if it can't.
Closing the series
This is the eighth and final control in the Essential 8, and it sits at the end of the framework for a reason. Every other control exists to prevent or limit an incident. This one exists for when those controls weren't enough.
The organisations that recover well from ransomware and destructive attacks aren't the ones that were lucky. They're the ones that treated recovery as something that needed to be engineered and tested, not assumed.
Over the course of this series we've worked through the full Essential 8 from vulnerability management through to backups, trying to be honest about where the controls are strong, where the practical gaps are, and what realistic implementation looks like.
We hope it's been useful. If any of these controls have raised questions about your own environment, or if you'd like to talk through where your organisation sits against the framework, we're happy to help. Reach out to the Murdoch Webster team directly, or visit mwtg.com.au to find out more about how we work with organisations on Essential 8 assessment and implementation.