Your Disaster Recovery Plan Is Probably Missing These 5 Things

A medical office in California’s Central Valley had done everything “right.” They had a backup appliance in the server closet, a disaster recovery plan in a binder on the office manager’s shelf, and cyber liability insurance. Then ransomware hit on a Friday night. By Monday morning, they discovered three devastating things: their backups had been encrypted along with everything else, nobody knew who to call first, and the binder on the shelf hadn’t been updated in four years. It took them eleven days to get back to full operations. Their plan existed — it just didn’t work.

This story isn’t unusual. Most small businesses we talk to have a disaster recovery plan. The problem is that having a plan and having a plan that actually works are two very different things. After years of helping businesses recover from ransomware attacks, hardware failures, and natural disasters, we’ve identified five critical gaps that show up in almost every DR plan we review.

1. Tested Restores — The Gap That Kills Recovery

Here’s a question that makes IT managers uncomfortable: When was the last time you actually restored data from your backups? Not checked that the backup job completed — actually pulled files from a backup and confirmed they were intact and usable.

Backups are not the same as restores. A backup job can report “success” every single night while silently writing corrupted data, skipping critical databases, or failing to capture application configurations. We’ve seen businesses discover mid-crisis that their backup software had been backing up empty folders for months, or that their database dumps were incomplete because a service wasn’t stopped properly before the snapshot ran.

What goes wrong without it: You find out your backups are worthless at the worst possible moment — when you’re already in a disaster. There is no second chance. If the backup is bad, the data is gone.

How to fix it: Schedule a formal restore test every quarter, and do one full restore test a year. Pick a random set of files, a database, and a full system image, then restore them to an isolated environment and verify they work. Document the results and the time it took. This single habit is the difference between a disaster recovery plan and a disaster recovery fantasy.

2. Off-Site and Immutable Backups — Because Ransomware Hunts Your Backups First

Modern ransomware is not the blunt instrument it was five years ago. Today’s variants are designed to sit quietly on your network for days or weeks, methodically identifying and encrypting backup repositories before ever touching production data. If your backups live on a network share, a NAS device in the same building, or a USB drive plugged into the server, ransomware will find them and encrypt them right alongside everything else.

What goes wrong without it: The business pays the ransom — sometimes hundreds of thousands of dollars — because there is literally no other copy of the data. And paying is not a recovery plan: the decryption tools attackers hand over are often slow, buggy, or incomplete, and some files never come back. Without a clean, separate backup, you’re at the mercy of criminals.

How to fix it: Implement the 3-2-1 backup rule: three copies of your data, on two different types of media, with one copy stored off-site. The off-site copy should be immutable — meaning it cannot be modified or deleted by anyone, including administrators, for a defined retention period. Cloud-based immutable storage from providers like Wasabi, Backblaze B2, or Azure Blob with immutability policies gives you a copy that cannot be altered or deleted for the length of that retention window — even by an attacker who has taken administrative control of your network.

3. A Communication Plan — Who Calls Who When Email Is Down?

Picture this: your server is down, your email is offline, and your VoIP phone system runs through that same server. How do you contact your employees? How do you reach your clients? How does your IT provider know there’s an emergency if you can’t send them a ticket?

Most disaster recovery plans focus entirely on technology — which systems to restore first, where backups are stored, which vendor to call for hardware. But they completely ignore the human side of disaster response. In a real crisis, communication breaks down faster than technology does.

What goes wrong without it: Employees don’t know whether to come into the office or stay home. Clients call the main number and get silence. Key decision-makers can’t be reached because their contact info is stored in the email system that’s currently offline. Hours are wasted on confusion that should have been spent on recovery.

How to fix it: Create a communication plan that lives outside your IT systems. Print a one-page “emergency contact card” with personal cell phone numbers for all key staff, your IT provider’s emergency line, your insurance company’s claims number, and your legal counsel. Give a copy to every manager. Designate a specific person responsible for client communication and another for employee updates. Establish a backup communication channel — a group text thread or a free messaging app like Signal — that works even when your entire network is down.

4. Recovery Objectives That Match Business Reality

Two numbers drive every disaster recovery plan that actually works, and most plans define neither of them.

A Recovery Time Objective (RTO) is the target time within which a system must be back in service after an outage — the goal you design and buy toward. It is not the same thing as the longest your business could limp along without that system; that figure is your maximum tolerable downtime, and your RTO needs to sit comfortably inside it. A Recovery Point Objective (RPO) is the amount of data you can afford to lose, measured in time. If your backup runs once a night, your RPO is up to 24 hours — and a Friday afternoon failure costs you the whole day’s work, re-entered by hand.

Most DR plans either don’t define these at all, or they list generic numbers with no connection to how the business actually operates.

Here’s the uncomfortable truth: your backup solution has a built-in recovery speed and a built-in backup frequency, and neither may match what your business needs. If your accounting system has a 4-hour RTO but your backup solution takes 18 hours to perform a full restore, you don’t have a disaster recovery plan — you have a gap.

What goes wrong without it: Leadership assumes they’ll be back online in a few hours. The actual restore takes two days. Clients leave. Revenue stops. Add up what an hour of downtime costs you — staff who cannot work, revenue you cannot take, and the overtime to catch up afterwards. For most small offices that lands somewhere between several hundred and a few thousand dollars an hour, which is almost always more than the technology that would have closed the gap.

How to fix it: Sit down with your department heads and map out every critical system — email, line-of-business applications, phone system, file storage, accounting software. For each one, ask two questions: “How quickly do we need this back before it costs us real money or puts us at legal risk?” and “How much of this data could we afford to lose and re-enter — an hour’s worth, a day’s?” Those two answers are your RTO and your RPO. Then compare them to how long your current solution actually takes to restore that system, and how often it actually takes a copy. If there’s a gap, you need a faster recovery solution or more frequent backups — not a thicker binder.

5. Documentation of Critical Systems — The Knowledge That Walks Out the Door

If your longest-tenured IT person left tomorrow, could someone else rebuild your network? Do you know where all your administrator passwords are stored? Do you have a current network diagram? Do you know which vendor to call for your firewall, your phone system, your line-of-business application?

In most small businesses, critical IT knowledge lives in one person’s head. That’s not a plan — that’s a single point of failure.

What goes wrong without it: During a disaster, recovery stalls because nobody knows the admin password for the backup appliance, or which port the database runs on, or who the vendor contact is for the EHR system. Every unknown adds hours to the recovery timeline. We’ve seen businesses lose an entire day just trying to track down a single password during a crisis.

How to fix it: Create and maintain a disaster recovery runbook that includes: all administrator credentials stored in a secure password manager with emergency access procedures; a current network diagram showing servers, switches, firewalls, and cloud services; vendor contact information with account numbers and support contract details; step-by-step recovery procedures for each critical system; and configuration details for firewalls, VPNs, and other network infrastructure. Review and update this documentation quarterly. Store a copy off-site — either printed in a secure location or in a cloud-based vault that’s independent of your primary systems.

The Real Cost of “Good Enough”

The businesses that recover quickly from disasters aren’t the ones with the most expensive technology. They’re the ones that tested their plan before they needed it. Every gap in your DR plan is a gamble — and the stakes are your business continuity, your client relationships, and in regulated industries like healthcare and finance, your compliance standing.

The good news is that none of these five fixes are complicated or prohibitively expensive. A restore test takes a few hours. An immutable cloud backup costs a fraction of a single day’s downtime. A communication card is a sheet of paper. RTOs and RPOs are a conversation. Documentation is a discipline. The only thing standing between your current plan and one that actually works is the decision to close these gaps — before you’re forced to discover them the hard way.

Related Questions