6 MIN READ
The phrase “we have backups” is doing a lot of work in too many incident reports. Usually it means one of the following. A snapshot somewhere, we think. The second drive in the server mirrors the first. The cloud folder duplicates itself, which someone checked once. None of those are the same as having a backup you can restore in the time you need, from a credential the threat actor has not touched, with data the threat actor has not also encrypted. The Maersk NotPetya postmortem, the Travelex ransomware disclosure, the HSE Ireland shutdown in 2021. Three different organisations, all of them with backups on paper, none of them with a recovery that arrived in the window the business needed.
Backups are the single most reliable determinant of whether a ransomware event, a cloud outage, a vendor compromise, or a disk failure becomes an incident or a catastrophe. Most organisations are not catastrophically under funded on security. They are catastrophically under tested on recovery. This is the practical guide to closing that gap.
What a backup actually is, and what it is not
A backup is an independent copy of data that you can use to restore service when the primary system is gone. Each of those words matters. The backup cannot share an identity, an account, a network, a hypervisor, a cloud account, or a domain with the system it backs up. If the threat actor can reach the backup by reaching the production system, the backup is not a backup. It is a second copy on the same blast radius. A snapshot of a running system is not a copy if the snapshot is taken from inside the system being backed up. A replication target that is online and reachable is not a copy if it sits encrypted with the same keys. A RAID array is not a copy, because RAID protects from a disk failure and not from ransomware, a malicious insider, a misconfigured delete, or a cloud account compromise. A backup that has never been restored serves as a theory. The only proof that you have one is that you have restored it.
The 3-2-1 model, and what extends it
The traditional rule is three copies, on two different media, with one offsite. It is older than most readers of this article, and it still earns its place. The reason 3-2-1 is necessary is that any single copy can be lost. Disk failures, accidental deletion, fire, ransomware, account takeover, vendor outages. Any of these can take one copy, and a disturbing number of them can take two at once. Three copies on two media with one offsite gives the operator a way to recover from a single point of failure and a second way to recover from a regional failure. What 3-2-1 does not do, on its own, is protect against a sophisticated threat actor. A modern attacker, with time and a foothold, hunts the backup infrastructure. The backup server, the backup credentials, the cloud sync folder, the snapshot repository, the management console, the service account that writes to object storage, the cloud native snapshot target. If those things are reachable from the same identity that has been compromised, the attacker finds them. 3-2-1 counts copies. It does not count independence. The extension the industry has settled on sits as 3-2-1-1-0. Three copies, two media, one offsite, one immutable or offline, zero errors on restore verification. The immutable or offline copy is the one that defends against an attacker who has been inside the environment for weeks. Immutable means the backup cannot be modified or deleted within its retention window, even by an administrator. Offline means the copy is physically or logically disconnected from production for most of its life. Either is sufficient. Both is better.
Two controls separate a working backup from a paper backup
Credential separation is the control that breaks the chain. The identity used to write backups cannot be the identity used to administer production. It cannot be the identity that runs the workloads being backed up, and it cannot be the identity that owns the object storage. It should be an isolated service account with the minimum permissions needed to write to the backup target, stored in a vault that requires out of band approval to access. If the production account is compromised, the backup account should not be. Immutability sits as the control that breaks the timeline. The backup target should not be deletable by the account that wrote to it, for the retention window that matters. Modern object stores support this with object lock. Backup products support it with their own WORM (write once, read many) modes. The point is that even an administrator with the credential should not be able to quietly destroy the last 30 days of backups. The attacker should not be able to either.
The bottom line
Independence, immutability, and a restore run on a timer against the RTO. Most organisations do not have a backup problem. They have a restore problem, and the restore problem is invisible until the incident. The fix is the boring work of testing, in conditions that resemble the real one, on a schedule the team actually keeps.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
