Backed Up Is Not the Same as Safe
Ransomware can reach your backups too. Having a recovery plan is not the same as having a recovery you can trust.
Key points
- CISA (the U.S. Cybersecurity and Infrastructure Security Agency) warns that modern ransomware gangs now routinely steal data before encrypting it, a tactic called "double extortion," giving criminals two ways to pressure victims.
- Backups protect against accidental data loss, but a ransomware attack can corrupt or destroy them if they share the same administrator login as the systems they are meant to protect.
- CISA's ransomware guide, updated in 2023, specifically recommends keeping offline, encrypted backups that attackers cannot reach through a network connection.
- Recovery after a cyberattack is not just a technical problem: organisations must first establish which systems and data can still be trusted before anything is switched back on.
- The NIST (National Institute of Standards and Technology) framework for resilience breaks the problem into four goals: anticipate threats, withstand disruption, recover safely, adapt so the same attack cannot succeed twice.
Picture a Monday morning where nobody can log in. Customer calls go unanswered. The warehouse management system is dark. IT staff are staring at alerts they have never seen before. Somewhere in the building, a manager is asking the question that haunts every organisation after a ransomware attack: "We have backups. Why can't we just restore?"
The honest answer is uncomfortable. Backups are designed for accidents, not adversaries.
What makes ransomware different from a hardware failure?
Ransomware is malicious software that locks a company's files and demands payment to release them. A broken hard drive loses data. Ransomware means a person was inside your systems, watching, chose their moment carefully.
CISA's ransomware guide is direct about what that looks like in practice. Criminals increasingly use what the agency calls "double extortion": they steal a copy of sensitive files first, then encrypt the originals. Pay or don't pay, the stolen data is already in their hands as a second pressure point. Some groups skip encryption entirely and simply threaten to publish what they took.
That changes the recovery calculation completely. A fire destroys files; you restore from backup and carry on. A ransomware gang may have been inside the network for weeks, reading emails and mapping servers, quietly deleting or corrupting backup copies before they ever trigger the visible attack. By the time alerts flash, the damage may stretch back far enough that no clean backup point is obvious.
Should ordinary people be worried about this?
Yes, because the organisations affected are often ones people depend on: hospitals, retailers, schools, local councils. Hospital systems under encryption can delay test results or force rescheduled procedures. A retailer hit before a peak sales period faces stalled orders alongside exposed customer data.
For individuals, the practical steps are straightforward. If a company you use contacts you about a breach linked to ransomware, take it seriously. Change your password for that service and any account where you reused it. Watch for unusual bank activity or unexpected emails asking you to confirm personal details, since stolen data frequently ends up in follow-up scams.
The backup problem nobody talks about
Here is the architecture flaw that catches organisations repeatedly. A backup system needs credentials, meaning login details, to connect to the production systems it protects. If those credentials belong to the same administrator account that manages everything else, an attacker who steals that account owns the backups too.
CISA's guidance is specific: backups should be offline (physically disconnected from the network), encrypted, and tested regularly, not just assumed to work. "Backup success does not automatically equal business recovery," as CSO Online noted in its recent examination of the resilience gap.
Testing matters because a backup that has never been restored is a promise, not a proof. Many organisations discover problems only when they need the backup most.
| Threat type | What it destroys | Backup protection | Extra steps needed |
|---|---|---|---|
| Hardware failure | Files on that device | Usually sufficient | Regular restore tests |
| Ransomware encryption | All reachable files | Partial, if online | Offline, isolated copies |
| Double extortion | Files plus confidentiality | None for leaked data | Incident response plan |
| Credential theft | Access to all systems | Undermined if shared | Separate backup credentials |
The NIST framework adds a point that gets missed in most backup conversations: recovery is not just restoring files, it is restoring a trustworthy environment. That means knowing when the attacker entered, confirming which accounts they touched, and rebuilding identity systems, the services that verify who is allowed to log in, before anything else comes back online.
That's the part most tabletop exercises skip. Recovering from a server failure is not the same skill as recovering after an attacker has held your administrator passwords for a fortnight. We covered a live example of how badly that gap bites in our 23 October report on the Qilin gang's claim against a Colorado supplier, where the victim organisation faced exactly this trust question about which systems were safe to bring back.
Criminals have got very good at making recovery slow and expensive. The organisations that fare best treat "can we trust what we're restoring?" as seriously as they treat "do we have a backup at all?"
