Your Disaster Recovery Plan Is Probably Useless (Here’s How to Fix It)

A lot of business owners have a disaster recovery plan. It’s usually a document that lives in a filing cabinet or a Google Drive folder, written by someone who left the company three years ago.

The plan says what to do if the servers go down. But nobody’s tested it. Nobody knows if the backups actually work. And when the actual disaster hits, the plan sits there gathering digital dust while everyone improvises.

That’s not a disaster recovery plan. That’s a false sense of security.

What Usually Happens When It Matters

A ransomware attack hits your network on a Tuesday morning. Your systems lock up. The screen shows a message: pay $50,000 or your files are gone forever.

Your team starts digging. The backups were supposed to happen every night. But when you check, the last working backup is three weeks old. Everything that’s happened since then—client files, invoices, contracts—is either encrypted or lost.

You have three choices, all of them bad:

• Pay the ransom, hope the attackers unlock your files, and hope they don’t sell your data to someone else anyway.
• Restore from the old backup and lose three weeks of work.
• Tell your clients and your insurance company that their data was compromised, and deal with what comes next.

This happens to businesses that have disaster recovery plans. It just happens faster to businesses that don’t.

The Problem With Most Plans

Plans fail because they’re built on assumptions nobody ever tests.

The backup system is supposed to run every night. But the job has been failing silently for months, and nobody noticed. The alert went to an email address that doesn’t exist anymore. The backup storage is full. Or the backup process never actually completes before the next day’s backup starts.

The plan says to restore from backup, but the person who configured the backups is no longer here. The password to the backup storage is written in a notebook that nobody can find. The restore process takes 18 hours, but the plan assumes it takes three.

These aren’t security failures. They’re organizational failures. A plan that nobody’s actually walked through is just a nice story about how things are supposed to work.

What an Actual Plan Looks Like

A working disaster recovery plan has three parts: backups that are actually tested, a clear procedure for what happens when they’re needed, and the people who know how to execute it.

Tested backups. This means more than just letting a backup job run in the background. It means actually restoring from backup, on a schedule, to a test environment. Actually checking that the restored files match the original. Actually timing how long it takes. Not once a year. Monthly, or as close to monthly as your team can manage.

If the restore fails, you find out now, in a drill, when it doesn’t matter. Not during the actual disaster.

An actual procedure. Not a story. A step-by-step list of what happens the moment someone realizes something is wrong. Who gets called first. What system gets shut down to contain the damage. What the communication is to clients. What gets restored in what order. Where the documentation lives. Who has access to it.

The procedure lives somewhere accessible, even if email is down. It’s on a printed sheet in the manager’s desk. It’s in a protected document in a service like Lastpass. It’s in a place you can actually reach when everything else is broken.

Someone who knows it. Not just the IT person. At least one other person in the business understands the backup process, can trigger the restore, and can oversee it. Because the IT person might be the one who triggered the alert that you’re under attack.

What Ransomware Actually Exploits

Ransomware doesn’t usually get in through a technical flaw. It gets in through the same wire fraud vector: a convincing email, someone clicking a link, a stolen password that multi-factor authentication could have stopped.

Once it’s in, it doesn’t immediately encrypt everything. It spreads slowly, learning your network, finding the backup storage, and disabling the backups before it locks anything down.

If your backups are tested monthly, the most recent working backup is maybe three weeks old.

If you’ve never tested them, the most recent working backup might be six months old. Or it might not exist at all.

The difference between an inconvenience and a business-ending disaster usually comes down to whether your last backup actually works.

How to Test Your Backups This Month

Pick a time when production systems are quiet. Tell your IT team that you’re going to restore from backup to a test environment, and time how long it actually takes.

Restore a random selection of files. Check that they match the originals. Spot-check client data. Make sure the database integrity looks good.

Document what you find. This isn’t about finding problems to blame people for. This is about knowing exactly where you stand.

If the restore fails, that’s valuable information. You just learned your backup isn’t working before you actually needed it to.

If the restore takes 18 hours, now you know. If the procedure doesn’t exist, now you can write it. If nobody else knows how to do it, now you can train someone else.

The goal isn’t a perfect plan. The goal is a plan that matches reality.

Insurance Wants to See This

Your cyber-insurance renewal is coming, and the renewal questionnaire will ask about disaster recovery. The carrier wants to know whether you have tested backups, whether you have a restoration procedure, and whether multiple people know how to execute it.

If you answer “yes” because you assume you have it, and you later need to file a claim and it turns out your backup was broken, the claim denial will be straightforward.

If you answer “yes” because you actually tested it last month and documented it, the claim process moves faster.

Build the Plan Before You Need It

The worst time to find out your disaster recovery plan is broken is when you’re under attack. The second-worst time is when you’re filing an insurance claim.

The right time is now, when nothing is broken and nobody is panicking.

Spend a morning testing your backups. Spend an afternoon writing the procedure. Get two people trained on it. Tell your cyber-insurance company that you have a tested disaster recovery plan.

Then, when the bad day comes, you’ll be ready. Not perfect. Not without problems. But ready.