Modern ransomware does not just encrypt your files. Before it triggers, it looks for your backups and tries to delete or encrypt them too, because the operators know that a business which can restore will not pay. So the real question is not “do you have backups”, it is “can you restore after an attacker has actively tried to stop you”. That is a higher bar, and it is the one that matters.
Getting this right is part of our infrastructure and backup work, and it is one of the Essential Eight strategies most often claimed and least often tested.
The 3-2-1 rule, updated for ransomware
The classic rule still holds, with a modern emphasis:
- 3 copies of your data, including the live one.
- 2 different media or platforms, so a single failure or a single compromised system does not take everything.
- 1 copy off-site, and critically, 1 copy that cannot be changed or deleted once written.
That last point is the update. Off-site is not enough on its own if the attacker reaches it with valid credentials. The copy that saves you is the one that is immutable.
Immutability is the feature that counts
Immutable, or write-once-read-many (WORM), storage means a backup cannot be altered or deleted until a set retention period passes, even by an administrator, even by someone holding your credentials. This single control defeats the “delete the backups first” playbook.
Practical options for Australian SMEs:
- Immutable cloud object storage with a locked retention policy, available in Azure and other major clouds hosted in Australian regions.
- Microsoft 365 Backup or a third-party SaaS backup for Exchange, SharePoint, OneDrive, and Teams. Microsoft’s own retention is not a backup, and the native recycle bins are the first thing an attacker clears.
- Backup accounts kept separate from your everyday identity, with their own phishing-resistant MFA, so a compromised admin cannot reach them.
The test that most organisations skip
A backup you have never restored is a hope, not a plan. The failure mode is depressingly common: the backups ran green for two years, and the first real restore reveals the database was never included, or nobody has the encryption key, or the restore takes nine days when the business can survive two.
Restore testing turns hope into evidence:
- Restore a real workload to an isolated environment on a schedule, at least quarterly.
- Record how long a full restore actually takes, and compare it to how long the business can genuinely be down.
- Keep the evidence. If you sell to government or carry cyber insurance, “tested on this date, restored in this many hours” is worth far more than a policy document.
Know your two numbers
Every backup plan comes down to two figures, agreed with the business rather than assumed by IT:
- Recovery point objective: how much data, measured in time, you can afford to lose.
- Recovery time objective: how long you can afford to be down.
Once those are written down, the right backup frequency, retention, and storage tier stop being guesswork. Most SME arguments about backup are really arguments about these two numbers that nobody has ever stated out loud.
What to do this quarter
- Add one immutable, off-site copy with a locked retention period, protected by a separate identity and phishing-resistant MFA.
- Run a real restore test into an isolated environment, time it, and write down the result.
- Agree a recovery point and recovery time objective with the business, and size your backups to meet them.
Ransomware resilience is not about buying more backup software, it is about the copy an attacker cannot touch and the restore you have actually proven. Pair it with phishing-resistant MFA and you have closed the two gaps that most often turn an incident into a catastrophe. If you would like your backups reviewed and restore-tested, request a review.