Editorial explainer · official sourcesmedium
3-2-1 backup: the defence that makes ransomware survivable
There is no single silver-bullet technology against ransomware, but there is one measure that, more than any other, decides whether an attack is a crisis or a catastrophe: backup done well. The reference rule, cited by NIST and CISA, is still 3-2-1 — three copies, two media, one offsite — now extended with at least one offline or immutable copy and with regular restore testing. An explainer on what the official guidance actually recommends, and why "having a backup" is not enough if it is not out of the attacker's reach.
The measure that decides the outcome
In the dossiers on Akira, on Qilin, on the Fairlife attack, the same watershed keeps returning: not how sophisticated the attacker is, but whether the victim can restart without paying. That is where backup stops being a tedious box-ticking exercise and becomes the most strategic defence an organisation has. CISA's #StopRansomware Guide puts it in writing: maintaining offline, encrypted backups of critical data is among the first recommendations for managing the risk, and the stated goal is to be able to recover without giving in to the ransom.
The starting point is an old rule that still holds, the one NIST and CISA cite as the baseline: 3-2-1. Three copies of the data, on two different types of media, with at least one copy kept offsite. It is the architectural minimum, not the finish line.
Why "having a backup" is not enough
Modern ransomware has learned to do one specific thing: before encrypting, it seeks out and destroys the backups. If the backup copies are reachable on the same network, with the same credentials, they are just as vulnerable as the data they are meant to protect. That is why 3-2-1 has been extended: at least one copy must be offline or immutable. Offline means physically or logically disconnected, out of reach of an attack that spreads across the network; immutable means written in a form that cannot be modified or deleted for a defined period, not even by someone holding the administrator keys. It is the copy that survives when everything else is encrypted.
Then there is the part almost everyone neglects, and that the guidance considers decisive: the tested restore. A backup that has never been tested is a hypothesis, not a guarantee. CISA's recommendations insist on periodically verifying the ability to restore data, with a concrete reference — being able to recover at least seven days of operations. The moment to discover that a backup is corrupt, incomplete or too slow to restore is not during an attack.
- 01Offline or immutable copyout of reach of whoever encrypts the network
- 02Encrypt the backupsdata protected even if the copies are stolen
- 03Tested restoreperiodic drill: at least seven days of operations
From backup to recovery plan
A solid backup is the foundation, but on its own it is not a plan. The Recover function of the NIST Cybersecurity Framework frames the rest: knowing which systems to restore first, in how much time, and with what dependencies. Two parameters in particular must be decided before, not during, the crisis — how long you can stay down, and how much data you are willing to lose by rolling back to the last good copy. These are the questions that turn "we have backups" into "we know exactly how we will restart."
A note on proportion, so as not to sell certainties that do not exist. Backup does not prevent the attack, nor does it undo the double-extortion problem: if the data was also exfiltrated, being able to restore it does not stop it from being published. Backup solves half the threat — the encryption, the operational lockout — and must therefore be paired with everything else: network segmentation, strong authentication on access, timely patching. But it is the half that decides whether an organisation, the next day, can still function. In most of the incidents we cover, the difference between a bad week and a disaster has been exactly this.
