Offline Backups and DISP — What “Regular and Tested” Actually Means Under ML2

The backup running every night for three years is the one nobody’s actually tried to restore — and that’s the gap DISP is designed to expose.

Why Backups Sit Last in the Essential Eight — and Why That’s Misleading

Regular backups sit at the very end of the Essential Eight’s eight strategies, and that position can create a subtle but misleading impression: that it’s the least important, a fallback item to tidy up once the “real” controls are handled. The opposite is closer to the truth. Backups are your last line of defence — the control that determines whether a serious incident is a costly but recoverable disruption, or a business-ending event. If every other control fails and an attacker succeeds in encrypting or destroying your data, your backups are the only thing standing between your business and total loss. Given how frequently ransomware and destructive attacks succeed despite genuinely good preventative controls elsewhere, treating this as a lower priority is exactly backwards.

What “Regular” Actually Means

At the baseline maturity level, the expectation is straightforward on paper: backups of important data, software, and configuration settings should be performed at least daily for servers and cloud services, or a documented business case needs to explain why a particular asset doesn’t require that frequency. Backups need to be retained for a defined period — generally at least ninety days unless a specific regulatory or business requirement justifies something different — and stored in a way that’s genuinely separated from your production environment, not simply sitting on the same network as the systems being protected.

This last point is where “regular” backups quietly stop being effective. A backup that’s technically automated and running daily, but stored on the same network, same credentials, and same administrative access as your production systems, offers far less protection than it appears to. Modern ransomware operators are aware backups are the primary obstacle to a successful extortion attempt, and they actively hunt for and target backup systems before deploying their main attack — precisely because a business with an intact, isolated backup has far less reason to pay a ransom.

What Changes at Maturity Level 2

This is the level DISP now mandates for every applicant, and it introduces the specific requirement most SME backup setups genuinely fail to meet: backups must be protected from unauthorised access, including from your own administrator accounts. In practice, this means unprivileged user accounts shouldn’t be able to access backup systems at all (or should only be able to access their own data within them), and — critically — even privileged administrator accounts used for everyday IT management shouldn’t have unrestricted access to modify or delete backup data.

The reasoning behind this is directly tied to how real attacks unfold. If an attacker compromises an administrator account — which is exactly the kind of account ransomware operators specifically target — a backup system that trusts that same administrator credential offers no meaningful protection at all. The attacker who gained the keys to your production environment gains the keys to your backups too, and can delete or corrupt them before triggering the main attack, removing your recovery option entirely. ML2’s backup isolation requirement exists specifically to close this gap: your backup access needs to be genuinely separated from your standard administrative privileges, not just logically labelled as a “backup system” while sharing the same underlying access.

ML2 also raises expectations around integrity verification and testing frequency — backup integrity needs to be actively verified, and recovery processes tested more often than a once-a-year formality, reflecting the reality that a backup regime only earns trust through demonstrated, repeated proof it actually works.

The Testing Gap Nobody Notices Until It’s Too Late

Across every maturity level, the Essential Eight is explicit that restoration must actually be tested as part of disaster recovery exercises — not just backups performed, but the full restoration of systems, software, and important data verified back to a common point in time, and the results of that testing documented. This is, without question, the most commonly skipped part of the entire control, and it’s the part that matters most.

Backups fail silently and often. A backup job can run “successfully” every single night for years while actually capturing corrupted data, missing critical configuration settings, or excluding a system nobody remembered to add to the backup scope in the first place. None of this becomes visible through the backup process itself — it only becomes visible when someone actually tries to restore from it. Businesses that have diligently collected backups for years without ever testing a genuine restoration routinely discover, at the worst possible moment, that the backups don’t actually work — a pattern experienced security professionals see often enough that it’s become a familiar, grim cautionary tale rather than an edge case.

For DISP purposes, this isn’t just a practical risk — it’s a specific evidence gap. “We have backups running” without a documented, dated restoration test and a record of the outcome doesn’t satisfy the requirement, however diligently the backup job itself has actually been executing.

What a Compliant, Genuinely Useful Backup Regime Looks Like for an SME

Closing this gap doesn’t require enterprise-grade infrastructure — it requires a deliberately designed process:

1. Follow the 3-2-1 principle as your baseline: at least three copies of important data, stored across two different mediums, with at least one copy kept offline or otherwise isolated from your production network.
2. Genuinely separate backup access from everyday administrative credentials. This is the specific ML2 requirement most setups miss — confirm that the account managing your day-to-day IT environment cannot also freely delete or modify your backup data.
3. Cover the full scope of what “important” actually means for your business — not just user files, but server configurations, SaaS platform data, and system settings that would be needed to genuinely restore operations, not just recover documents.
4. Automate the backup process itself to remove reliance on someone remembering to run it manually, reducing the risk of gaps introduced by human error.
5. Schedule and actually conduct restoration tests, at minimum annually and ideally more frequently for your most critical systems, and document the outcome — what was tested, what worked, what didn’t, and what was fixed as a result.
6. Treat a failed test as valuable information, not a problem to hide. A restoration test that reveals a gap is doing exactly what it’s meant to — it’s far better to find that gap during a scheduled test than during a genuine incident.

DefencIQ is a Brisbane-based cybersecurity and defence compliance consultancy specialising in DISP membership and Essential Eight Maturity Level 2 compliance for Australian SMEs. Visit defenciq.com.au to learn more.