Ransomware attacks your backups first
The backup strategy most organisations run was designed for a hardware problem: a disk dies, a server catches fire, someone deletes the wrong folder, and you restore from last night. Ransomware is a different adversary, because it is an intelligent one. Before the operators encrypt anything, they look for your backups, and they treat destroying them as the main event. If the backups survive, you restore and they get nothing. If the backups do not, you negotiate.
That single fact reframes the whole problem. A backup is only real if an attacker who has domain administrator rights and has been inside your network for two weeks cannot reach it, cannot encrypt it, and cannot delete it. Most backup setups fail that test. The backup server is domain joined, the backup share is reachable from the file server, and the retention is short enough that by the time the encryption is noticed, the clean copies have already rotated out.
The properties that actually matter
Forget the marketing categories for a moment and reason from what the attacker can do. They have credentials, they have time, and they can run code on your servers. A backup survives that only if it has specific properties, and each one closes a route they would otherwise take.
- Immutable: once written, a copy cannot be altered or deleted before its retention expires, even by an administrator. Object lock on cloud storage and hardened repositories on backup appliances both provide this.
- Offline or isolated: at least one copy is not continuously reachable over the network the attacker controls. Air gap, or a separate account and credential domain the production identity cannot authenticate into.
- Out of the blast radius of your identity: the backup system does not trust the same directory that the attacker has compromised. If your domain admin can delete the backups, so can the intruder using that account.
- Retained long enough to outlast dwell time: attackers often sit in a network for weeks. If your retention is seven days and they were in for three, every copy you hold is already poisoned.
The 3-2-1 idea, and why the 1 is the whole game
The old rule of thumb still holds: three copies of the data, on two different media, with one kept off site. It survived because it is a hedge against correlated failure. What ransomware changes is the weight of that final copy. The off site, offline, immutable copy is no longer a nicety for the fire scenario, it is the copy that decides whether you have a recovery position at all.
The practical shape most small and mid sized organisations land on is a fast local copy for everyday restores, plus an immutable copy in cloud object storage with a lock the production identity cannot remove, plus a longer retention tier so a compromise discovered late still has a clean point to go back to. The important design question is not how many copies you keep, it is which copies an attacker with your admin credentials genuinely cannot touch.
A backup you have not restored is a hypothesis
The most common and most expensive discovery during an incident is that the backups exist but do not restore: the job had been failing silently for months, the database dumps are inconsistent because nothing quiesced the database before the copy, or the one system nobody backed up is the domain controller you now need first. None of this shows up until you try, and an incident is the worst possible time to find out.
The fix is unglamorous and it is the single highest value thing on this list: test restores on a schedule, from the immutable copy, into an isolated environment, and time them. A restore you have rehearsed is a capability. A backup you have never restored is a hope. Regular backups are one of the eight strategies in the ACSC Essential Eight precisely because the discipline, not the existence of a backup job, is what carries the risk.
Recovery time is the number nobody costed
Even with clean, immutable, tested backups, restoring a whole environment takes real time: staging clean infrastructure, restoring in dependency order, rebuilding identity, revalidating that the restored systems are not carrying the same foothold back in. For an organisation that has never measured it, the honest answer to how long we would be down is usually days, sometimes weeks, and that estimate almost always exceeds what the business assumed.
That gap between assumed and actual recovery time is where the pressure to pay comes from. The way to close it is to decide, per system, how long you can tolerate it being gone and how much data you can afford to lose, then build the backup and recovery design to meet those numbers rather than discovering them under duress. It turns backups from an IT housekeeping task into a business continuity decision the leadership team has actually made.
Where to start
You do not need a new platform to move your recovery position forward this quarter. Take one immutable, off site copy of your most important systems with a lock your production administrators cannot remove. Run one real restore from it and time it. Extend retention so it comfortably outlasts a plausible dwell time. Those three moves change the answer to the only question that matters on the worst day, which is whether you restore or negotiate.
Working out which systems must come back first, and building a recovery design that meets the time you can actually tolerate, is part of what a security posture assessment covers. It is worth doing before an incident forces the question, because the answers are far cheaper to reach on a quiet afternoon than at three in the morning with everything encrypted.