Seven of the Essential Eight work to stop an incident. Regular backups is the one that decides what happens when the other seven did not, which makes it the strategy with the worst ratio of attention paid to consequences carried.
It is also the one most often rated higher than it deserves, because a dashboard full of successful backup jobs looks like evidence and is not.
The Only Strategy Aimed at Recovery
The Essential Eight groups its strategies under three objectives. Four prevent malware delivery and execution, three limit the extent of an incident, and exactly one — regular backups — exists to recover data and system availability.
That asymmetry is deliberate. Prevention fails eventually, and the difference between an organisation that treats a ransomware incident as a bad fortnight and one that treats it as an existential event is almost entirely down to this strategy.
It is also the strategy whose failure is most total. A partial gap in patching degrades your posture. A backup you cannot restore from provides nothing at all.
Data, Software and Configuration
The common misreading is to back up data and stop there. The strategy covers important data, software and configuration settings — all three.
Data alone does not get you running. After a destructive incident you need the systems that process the data, which means operating system builds, application installations and the configuration that makes them yours: firewall rules, directory structure, access policies, integration settings, certificates.
Teams who backed up only data discover this during recovery, when the restore completes and there is nowhere to put it. Rebuilding configuration from memory, under pressure, with the people who knew it unavailable, is where recovery timelines go from days to weeks.
Why Isolation Is the Control That Matters
Modern ransomware looks for backups first. If the account that runs your backups is a domain account with broad rights, and the backup target is reachable from the environment being encrypted, then your backups are inside the blast radius.
The control the maturity model is pointing at is this: an account compromise in the production environment must not be able to modify or destroy the backups. That generally means separate credentials that production accounts cannot assume, restricted network paths to the backup target, and retention that unprivileged accounts cannot shorten.
This is the detail most often missing in organisations that otherwise take backups seriously. The jobs run, the copies exist, and a sufficiently privileged intruder can delete all of them in one action.
Can you prove a restore, not just a backup?
Share your work email and we'll walk your backup scope, isolation and restoration testing against what the recovery strategy actually asks for.
Retention Against Dwell Time
Retention is usually set from a storage budget or a compliance minimum. Neither is the right input for this strategy.
The right input is how long an intrusion could plausibly go unnoticed in your environment. If an adversary has been present for weeks before triggering encryption, and your retention is shorter than that, every copy you hold may already contain their access. Restoring from it restores the compromise.
The practical question is: what is the oldest clean point we could return to, and are we confident it is clean? That is a different conversation from how many days of storage you are paying for, and it usually argues for longer retention on a smaller, well-chosen set rather than short retention on everything.
Testing Restoration, Not Backup
A successful backup job proves that data was copied. It proves nothing about whether you can get it back.
Restoration testing means actually restoring — to a usable state, within a time you have measured, with the result verified by someone who can tell whether the restored system is correct. The specific things it surfaces, reliably, are:
- Media or snapshots that are present but unreadable
- Dependencies restored in an order that does not work
- Configuration that was never in scope and is now missing
- Restore times an order of magnitude longer than assumed
- Credentials needed for recovery that are themselves only in the destroyed environment
The last one is a recurring, avoidable disaster: recovery procedures stored in the system being recovered, or the password manager accessible only through the identity provider that is down.
Test on a schedule, record the test, and record how long it took. The record is both the evidence an assessment wants and the number you will plan around during a real incident.
What an Assessor Looks For
An assessor looks for scope first — that software and configuration are covered, not only data. Schedule and retention, with the retention rationale. Restoration test records with dates and measured duration. And the access model, demonstrating that backups are protected from the accounts that could destroy them.
The weakest point in most submissions is the restoration record. Organisations will have a backup policy, a schedule and a monitoring dashboard, and no evidence that anyone has ever restored from it.
Backup Questions Teams Ask
They count if they meet the same requirements, and that is worth checking rather than assuming. Many SaaS platforms replicate for availability rather than providing recovery from malicious deletion, and several have retention windows shorter than a plausible dwell time. The questions are the same regardless of where it runs: is software and configuration in scope as well as data, can a compromised administrator destroy the copies, how long is retention, and has a restore been tested and timed.
At least annually for the full scope, and more often for the systems whose loss would stop the business. The valuable part is less the frequency than the realism — a test that restores a single file proves far less than one that stands up a working system from backup and has someone verify it is correct. Record the duration every time, because that number is what you will plan the incident around.
That an account compromise in production cannot modify or destroy the backups. Practically: credentials for the backup system that production accounts cannot assume, restricted network paths to the backup target, and retention settings that an unprivileged account cannot shorten. The test to apply is simple — if an intruder obtained domain administrator rights this afternoon, could they delete every copy? If the answer is yes, the strategy is not implemented regardless of how reliably the jobs run.
Long enough to reach a point before a compromise began, which means retention is driven by plausible dwell time rather than by a storage budget or a compliance minimum. If an adversary could have been present for weeks before triggering encryption and your retention is shorter than that, every copy may already contain their access. This usually argues for longer retention on a carefully chosen critical set rather than uniformly short retention across everything.
Make recovery something you can evidence
Book a demo and we'll show how Konfirmity tracks backup scope, retention, isolation and restoration test records as evidence rather than as a policy document.
Book a demo
Prove It Before You Need It
Prove it before you need it: the gap between a backup programme and a recovery capability is a tested restore, and it is a gap most organisations do not know they have because nothing in their monitoring reports it.
Restore something real, time it, write down what broke, and fix that. It is among the few security claims you can demonstrate in an afternoon, and it is the one that decides the outcome when the other seven strategies did not hold. The rest of the set is covered in the maturity model guide, and the assessment guide covers the evidence each strategy needs.
