Business Continuity in the Ransomware Era: Backups Aren’t a Plan
Business continuity planning for ransomware comes down to whether your business can actually recover, and having backups does not prove that. Recovery means bringing critical systems back in the right order, within the downtime your leadership has agreed to.
Ransomware appeared in 48% of the breaches in Verizon’s 2026 Data Breach Investigations Report, and attackers now go after recovery itself. On 20 October 2026, CISA, the FBI and partners in Germany and the UK published an advisory on SafePay ransomware.It says the group has affected at least 600 organisations since August 2024, and that its operators may delete shadow copies and reset the storage devices that hold backups. Shadow copies are the built-in snapshots Windows keeps for restoring files.
A backup report shows that copies exist. It does not show whether they are still intact after an attack, or whether the account that runs your production logins can also reach the backup console. It does not show the order systems must come back in either. Finance may be the priority, but it cannot start until the identity service that handles logins is running. Restore tests, access reviews and a mapped recovery plan each close part of that gap, and together they are what tested recovery means.
Business Continuity Planning Starts Where the Backup Ends
A backup gives you a copy of your data to restore from. It does not decide what happens next, and in a ransomware recovery most of the hard decisions are still ahead.
Recovery order comes first, and the obvious choice is often wrong. The identity service usually has to be running before the applications that depend on it will let anyone log in. The restore point comes next, because the newest copy may not be a safe one. Each system needs a time limit too, and a named owner has to approve each restored system before it rejoins the network.
Business continuity planning is where those decisions get made before an incident. It is often paired with disaster recovery under the label BCDR. Business continuity keeps the organisation operating, and disaster recovery restores the IT systems that support it. The plan can still fail in three key areas.
Three Failure Points That Break Ransomware Recovery
Ransomware recoveries usually go wrong in the gaps around the backup. Three are worth checking first.
Restores That Have Never Been Tested
A backup job that reports success confirms one thing, that a copy was written. It does not establish that the copy is usable. The database may not open, the application may reject the data, and the restore may take far longer at full production size. If the first real restore happens during an attack, those problems surface while the business waits. A timed test restore of one real system brings them out earlier.
Backups Reachable Through the Same Admin Accounts as Production
Often the same administrators run production and the backup console through one directory login, so a single stolen account can open both. A separate admin identity for backups, with restricted permissions, reduces that exposure, though it does not guarantee isolation. Alerts on changes to retention settings and on deleted jobs help catch interference early.
Dependencies and Runbooks Nobody Documented
Applications lean on a license server, a DNS record, a service account or a certificate. If none of that is written down, a database can restore perfectly while the application still refuses to start. The runbook can be lost too. If it sits on an encrypted file server, the team is improvising, so CISA’s #StopRansomware Guide advises keeping a hard copy and an offline version.
Restore tests, access reviews and dependency mapping each catch different weaknesses, and a restore is only as dependable as the copy behind it. That makes the next question how well the backup copies themselves are protected.
Immutable Backups and Offsite Copies: What Each Protects and Where It Stops
CISA’s ransomware guide recommends offline, encrypted backups, and regular testing that they are available and intact. Immutable, offsite and offline copies all work toward that, but each covers a different risk, and no single one covers all of them. A sound data backup and recovery setup combines them to suit the environment.
Copy type | Protects against | Can still fail when |
Immutable backup | Edits or deletion until the retention period ends | Infected data that was locked in before anyone noticed, or lock settings that an admin can change |
Offsite copy | Losing the main site | Still reachable if it shares logins with production |
Offline copy | Attacks over the network | Slow to restore, and out of date between refreshes |
Separate backup identity | Theft of a production admin account | Both sides still rely on the same identity provider or recovery route |
Immutability needs the closest check. How strong the protection is depends on the product and its setup, so find out who can shorten the retention period or turn it off. Whichever mix of copies you choose, the business still has to decide how much downtime and data loss it can accept.
Setting RTO and RPO Before an Attack Sets Them for You
Two numbers sit under every recovery plan, and the business has to own both. The recovery time objective (RTO) is how long a system can stay offline before the damage turns serious. If order processing can be down for four hours and no longer, four hours is its RTO. The recovery point objective (RPO) is how much recent work the business can afford to lose. An RPO of 30 minutes means losing the last half hour of data is the most it will accept. IT chooses the tools to meet these numbers, but it cannot choose the numbers.
The Newest Backup May Carry the Attack
Attackers often sit inside an environment for a while before they encrypt anything, so the latest copy can already contain what they planted. Restoring from it can bring them straight back. The team has to estimate when the compromise began and restore from an earlier point, even if that loses more data than the RPO allowed.
Set the Numbers With the Business
A business impact analysis, where service owners say what an outage costs, is how targets for disaster recovery planning get set. Dependency mapping then shows what each service needs to run, and it often changes the restore order.
A target is only a claim until a test confirms it. If leadership approves a four-hour RTO and the first restore takes six because of a missing dependency, that gap needs an owner. Leadership then chooses whether to change the design, fix the process or reset the target. Two kinds of exercise can find such gaps, and each checks something different.
Tabletop Exercises vs Restore Tests: What Each One Proves
Tabletop exercises and restore tests both count as recovery testing in business continuity planning, but they answer different questions. One shows whether people make the right calls under pressure. The other shows whether systems actually come back.
Test | What it is | What it proves | What it cannot show |
Tabletop exercise | A facilitated discussion where the team walks through a realistic attack and says what it would do | Decisions, roles, escalation, communication | Whether the technology can restore the workload |
Restore test | Real systems and data recovered in a controlled environment | Data recovery, application function, dependencies, timing | Whether leadership and other teams would decide well under pressure |
A ransomware tabletop should put the team through moments like encryption found at the start of a shift, a backup console that will not open, an extortion note with a deadline, and a regulator asking what happened. It should end with the choice between restoring and rebuilding. Infrastructure, application, security and recovery owners form the core group, and legal, communications and senior leaders join when the scenario needs their decisions.
A restore test should meet three conditions:
· It runs in an isolated environment and is timed against the approved RTO
· It restores from the recovery point the team would really choose, not just the newest copy
· Users can log in and the application reaches what it depends on, because a server that merely starts does not count
Many disaster recovery solutions, including disaster recovery as a service, build drills like these into the setup. Both tests leave a list of gaps, and that list is the starting point for the checklist that follows.
Ransomware Recovery Readiness Checklist for IT Leaders
Use this as a quick self-audit. Any item you cannot tick with confidence is where to start.
Recovery targets
- Critical services are ranked through a business impact analysis
- Business owners have approved an RTO and RPO for each critical service.
- Dependencies are documented for each critical service
Protected backup copies
- At least one backup copy is immutable, its retention period is defined, and the people authorised to change that setting are known.
- At least one copy is offline or isolated, and the administrative routes that can still access it are documented.
- Backup administration uses separate identities from production, with alerts for access and on changes to backup settings
Recovery readiness
- A critical service has been restored in a controlled environment, timed against its approved RTO, with the application and its dependencies validated.
- The recovery point is selected based on the likely compromise window, with malware checks and security validation completed before recovered systems reconnect to production.
- An offline copy of the recovery plan and contact list is available.
Testing and follow-up
- Tabletop exercises and restore tests follow a documented schedule.
- Every gap identified during testing has an assigned owner and a target resolution date.
Start With One Restore, and Keep an Eye on the Backups
Attackers who want to block a recovery often tamper with the backups first. The network operations centre (NOC) keeps systems running and the security operations centre (SOC) watches for threats, so together they are well placed to spot backup settings changed without a ticket or unusual logins to the backup console. Each can have an ordinary cause, so look harder when other warning signs appear with them. Our post on NOC and SOC integration explains how the two teams work together. The first step is small. Restore one critical service from a protected copy in an isolated environment, time it, and note what broke and who owns the fix. Then do the next one.
That is how a business moves from “we have backups” to “we have tested recovery.”
Testing lowers the risk of a failed recovery, though no test finds every gap. Progression helps enterprise IT teams set recovery targets, protect backup copies and the accounts that manage them, and run restore drills. If your plan has never been tested from start to finish, talk to our team about your BC/DR readiness.
FAQs
- Are immutable backups enough to recover from ransomware?
Immutable backups can’t be changed or deleted for a set period, but they don’t prove the data is clean or that systems will return on time. You also need a safe restore point and regular restore tests against your agreed recovery targets. . - Can attackers delete backups with stolen admin credentials?
Yes, if those credentials have permission over the backup environment. Separate backup logins, tight permissions and monitoring reduce the risk, and properly configured immutability adds protection during the retention period. Check who can change its settings. - How do I set RTO and RPO for ransomware recovery?
Start with the business. For each critical system, owners say how long it can be down (RTO) and how much recent data they can lose (RPO). Write the answers down, then test whether your recovery setup meets them. Allow for older restore points, since the newest backup may be infected. . - How often should we test ransomware recovery?
There is no single right interval. CISA advises regular testing without fixing one schedule for everyone. Test critical systems more often, and again after big changes such as new systems, backup tools or providers. Document the schedule and results. - Who should attend a ransomware tabletop exercise?
The people who would make decisions in a real attack: infrastructure, application, security and recovery leads. Add legal, compliance, HR, communications and senior leaders when the scenario needs them, such as notifying customers.
