Your Business Continuity Plan Is Probably Useless. Here's How to Fix It.

Most businesses have a business continuity plan. Most of those plans were written, filed away, and never looked at again. When something actually goes wrong, the plan turns out to be a description of what should happen rather than a tested, working playbook for what does happen.

Here is why that happens, and what a plan that actually works looks like.

The Problem with Most BC Plans

Business continuity plans tend to fail for a few common reasons. First, they are written by people who were not present during previous incidents, so they make optimistic assumptions about recovery times. Second, they describe processes that have never been rehearsed, so staff do not know what to do when the moment arrives. Third, they are not kept up to date as the business changes, so the contact lists are wrong, the systems referenced no longer exist, and the backup procedures described are not what actually runs.

An untested plan is not a safety net. It is a false sense of security.

What a Good BC Plan Actually Contains

A working business continuity plan has several components that go beyond a document describing what should happen in an ideal world.

1. A Realistic Risk Assessment

Start with the scenarios that are most likely to affect your business: ransomware, internet outage, key person absence, office unavailability, supplier failure. For each scenario, document the likely impact, the acceptable downtime (your Recovery Time Objective), and the maximum data loss you can tolerate (your Recovery Point Objective).

These numbers matter because they drive your technical choices. If you can tolerate no more than four hours of downtime, your backup and recovery infrastructure needs to reflect that. If it currently takes 48 hours to restore from backup, there is a gap.

2. Documented Recovery Procedures

Write the steps required to recover each critical system in enough detail that someone unfamiliar with the system could follow them. This sounds obvious but most plans say something like "restore server from backup" without specifying which backup, which restore tool, what credentials are needed, and how long it typically takes.

The procedures should be stored somewhere accessible when your primary systems are down. A recovery plan that lives only on the server you are trying to restore is not useful.

3. Communication Plans

Who needs to be told what, and when? This includes internal staff, customers, suppliers, and in some cases regulators. Have a clear owner for each communication, and have contact details stored somewhere that does not depend on the systems you may be trying to recover.

4. Tested Backups

Backups that have never been restored are not backups. They are files that have never been proven to be restorable. Backup restoration should be tested at least quarterly, and the results should be documented. You want to know your restore time before you need it, not during an incident.

5. Regular Testing

The plan should be tested at least annually. A tabletop exercise, where key people walk through a scenario and talk through their responses, costs a couple of hours and will surface gaps in the plan. A full failover test costs more but gives you confidence that the technical components actually work.

After each test, update the plan. The gaps you find are exactly the information you need.

Where IT Fits

A managed IT provider should be an active part of your business continuity planning, not a reactive resource when things go wrong. This means helping you define your RTO and RPO, ensuring your backup infrastructure is designed to meet them, testing restores, and providing clear escalation paths during an incident.

If your current IT provider has never raised the topic of business continuity with you, that is worth reflecting on.