Most organisations believe their backups will save them from ransomware. Far fewer have proven it. The gap between having backups and being genuinely ransomware-ready is where recovery efforts collapse, often at the worst possible moment, when production is encrypted and the business is losing money by the hour. For leadership, the uncomfortable truth is that an untested backup is a hope, not a control, and ransomware actors have learned to attack the backups first.
Why ordinary backups are not enough
Traditional backup strategies were designed for accidental loss: a failed disk, a deleted file, a corrupted database. Ransomware is an adversary, not an accident. Attackers deliberately seek out and destroy or encrypt backups before they trigger the visible attack, precisely because they know intact backups would let you refuse to pay. A backup that sits on the same network, reachable with the same credentials, is exactly what the attacker will target. If your recovery plan assumes the backups will simply be there, it is built on the assumption the attacker is counting on you to make.
Readiness therefore means designing your backups to survive an active, intelligent adversary who has already compromised your environment. That is a fundamentally different design goal from protecting against hardware failure, and it changes almost every decision about how backups are stored, protected and tested.
Immutability and isolation
The two properties that matter most are immutability and isolation. Immutable backups cannot be altered or deleted for a defined retention period, even by an administrator, even by someone with valid credentials. This means that once data is written, ransomware cannot encrypt it and an attacker cannot wipe it. Isolation means at least one copy of your backups is kept separate from your production environment, ideally with separate credentials and limited network reachability, so that compromising production does not automatically compromise the backups.
Together these properties give you a copy of your data that the attacker cannot reach. This is the foundation of ransomware recovery. Without it, every other measure is built on sand, because a sufficiently determined attacker who controls your environment also controls your backups. With it, you retain the ability to recover on your own terms rather than the attacker's.
Testing recovery, not just backups
A backup that has never been restored is a theory. Ransomware readiness depends on regularly proving that you can recover, end to end, within the time the business can tolerate. That means restoring real systems to a clean environment, verifying the data is intact and usable, and measuring how long the whole process takes. Many organisations discover during a real incident that their restores are far slower than assumed, that dependencies between systems were never mapped, or that the most recent backups were themselves infected.
Test the restoration of complete services, not individual files. Restore in the correct order, accounting for dependencies, and confirm the recovered systems actually function rather than merely existing. Measure the elapsed time against your recovery objectives and close the gap if it is too large. A recovery exercise that surfaces these problems in a calm rehearsal is worth far more than the discovery of them during a live crisis.
- Ensure at least one backup copy is immutable and cannot be deleted or altered within its retention window.
- Keep an isolated copy with separate credentials and restricted network access, away from production.
- Run full recovery rehearsals on a regular schedule, restoring complete services to a clean environment.
- Map system dependencies and define the correct restoration order before you need it.
- Scan recovered data for malware so you do not reintroduce the threat during recovery.
- Measure actual recovery time against business tolerances and close the gap deliberately.
Recovery order and clean rebuilds
When the moment comes, the order of recovery matters enormously. Restoring applications before their underlying data services, or recovering systems into a network that is still compromised, can extend an outage or reinfect freshly restored systems. Define a recovery runbook that sequences the rebuild correctly: a clean network and identity foundation first, then core data services, then the applications that depend on them. Treat the recovery environment as untrusted until proven clean, and scan restored data before reconnecting it, so you do not carry the attacker's payload back into a rebuilt estate.
Decide in advance how you will determine that an environment is safe to return to service. Rebuilding from a known-clean foundation is usually safer than attempting to clean a compromised one, because you can never be fully certain you have removed every trace of an attacker who had administrative access.
The human and decision layer
Technology alone does not deliver recovery. Someone has to declare the incident, authorise the recovery, communicate with stakeholders and decide between competing priorities under intense pressure. Establish clear roles, decision rights and communication channels in advance, and rehearse them. Know who can authorise a recovery, who speaks to customers and regulators, and how you will operate if your normal collaboration tools are themselves unavailable. The organisations that recover fastest are those that have practised the decisions, not just the technology.
Common pitfalls
The recurring failures are predictable and severe. Backups stored on the same network with the same credentials, destroyed alongside production. Restores that have never been tested and turn out to be far slower than assumed. Backups that were themselves infected and reintroduce the malware on recovery. No defined recovery order, leading to repeated false starts. And no clear ownership of the recovery decision, so critical hours are lost to confusion. Each of these is well understood and entirely preventable with deliberate preparation.
What good looks like
A ransomware-ready organisation can answer, with evidence, a simple question: if our entire production estate were encrypted today, how quickly and how completely could we recover. The answer rests on immutable, isolated backups that the attacker cannot reach, on recovery rehearsals that prove the timeline, on a runbook that sequences the rebuild correctly, and on a tested decision and communication plan. Readiness is demonstrated, not assumed, and it is revisited as the estate changes.
Proving your recovery before an attack forces the issue is the single most valuable resilience investment most organisations can make. Need support applying this approach? Email sales@halfteck.com.