Building a Business Continuity Plan That Actually Works

Before documenting any recovery steps, decide two numbers for each critical system: how long it can be down before it seriously hurts the business, and how much data loss is tolerable if you have to restore from a backup. These are your recovery time and recovery point targets, and they should come from a conversation with whoever depends on the system, not from what's technically easiest to promise.

A system with a same-day recovery target needs a very different plan than one that can tolerate being down for a week, and writing the recovery steps before setting the target usually produces a plan built around convenience rather than actual business need.

Structure the document around the failure someone is facing in the moment: 'our primary system is unreachable,' 'we've lost access to our office,' 'a key vendor has failed to deliver.' Someone in a crisis doesn't yet know whether the outage is caused by a server failure, a cyberattack, or a power outage, and a plan organized by cause forces them to diagnose the problem before they can even find the right page.

Each section should open with the first three things to do, in order, before any explanation of why. Under pressure, people read the first few lines and act. Context can come after.

'Operations' or 'IT' is not a decision-maker during an actual disruption if three people could plausibly answer to that title and none of them knows they're expected to act. Name an actual person for each critical decision point, along with a named backup, and make sure both people know they're on the list before you need them.

Revisit these names every time someone in a listed role leaves or changes position. A continuity plan pointing at someone who left the company eight months ago is worse than having no plan, because it creates false confidence that someone has already thought through the problem.

A plan that's never been tested is a plan you're hoping works. Run a tabletop exercise at least once a year: pick a scenario, walk the team through the plan step by step without actually triggering the systems involved, and time how long each decision takes to make. The gaps that show up in a tabletop exercise, an unreachable backup contact, a step that assumes access nobody currently has, are far cheaper to find in a rehearsal than during an actual outage.

Document what the tabletop exposes and fix it before the next one, or the exercise becomes theater instead of a genuine test.

Run a tabletop exercise in this order:

1. Pick one realistic scenario, such as a primary system becoming unreachable.
2. Walk the team through the plan step by step without triggering the real systems involved.
3. Time how long each decision takes to make.
4. Write down every gap, such as an unreachable backup contact or a step that assumes access nobody currently has.
5. Update the plan and the named contacts before the next exercise.

A continuity plan stored only on the system it's meant to help you recover from is not a continuity plan, it's a single point of failure with extra steps. Keep a copy accessible outside your primary systems, in a tool like Trainual or Process Street that's independently hosted, and make sure the people named in it know where to find that copy without needing to log into anything that might be the thing that's down.

Print a physical copy of the contact list at minimum, even if the rest of the plan stays digital. If the outage is the kind that also takes down your internet or your primary communication tool, a phone number on paper is worth more than a perfectly formatted document nobody can currently open.