What makes a good business continuity plan?
The short answer
A good business continuity plan is short enough to use under pressure and current enough to trust. It says who activates it and when, who to contact, how impact grows over time, what degraded mode looks like, how long it holds, and which workarounds keep critical services running. It comes out of planning, exercises and real dependency data.
Why nobody opens the plan
I lived with those plans for years. Fifteen pages, written for the auditor, reviewed once a year, owners from two reorganizations ago. Then an incident hits at 9pm. Information is incomplete, the phones keep ringing, and the plan stays closed.
That has little to do with discipline. Under stress, with incomplete information, people can't work through a long document. A 15-page static document can't orchestrate a live incident. What people use is what they can read in a minute: who to call, what is affected, what to do next.
Outdated plans add a second problem. In an infrastructure-wide failure, coordinating hundreds of plans with changed owners adds complexity at the moment it should disappear.
Different plans do different jobs
One template for everything is part of the problem. Different situations need different kinds of planning:
- Technical reconstruction needs step-by-step guidance. Here detail helps.
- Executive crisis management needs role clarity, authority and escalation paths.
- Ransom decisions need the legal, ethical, financial and reputational questions thought through before the pressure hits.
- Critical infrastructure decisions** need thresholds and trade-offs discussed in advance.
A business continuity plan for a critical service sits in between. Some organizations call it a contingency plan, and hospitals call it a downtime procedure. It has to tell the people who run the service what to do while technology is down.
What a usable continuity plan contains
A plan people open during an incident answers six questions on one screen:
- When do we activate it, and who decides?
A threshold anyone can check, such as "the service is unavailable for more than 30 minutes," plus who has the authority to call it. - Who do we call?
The people who know this service, with out-of-band contact details. The company crisis team is a separate list. - How does impact grow over time?
When financial, customer or regulatory harm starts, and when it becomes intolerable. - What else is affected?
The services and teams downstream of the same failure. - What does degraded mode look like, and how long can we hold it?
The minimum service and how long the workaround lasts. - Which workarounds cover which dependencies?
One per critical dependency, with the information and people each one needs.
Everything else, such as background, methodology and the full contact tree, goes in an appendix or stays out.
Keep it current without a yearly rewrite
Plans go stale because the business changes faster than the review cycle. A new supplier arrives, an application is replaced, a team reorganizes. The plan still describes last year.
Tie the plan to the dependency data instead of rewriting it by hand. When a dependency changes, the plan should show it and flag the workaround that is now missing. The owner reviews a change, and nobody has to start from a blank page.
Plans are the outcome of planning
The value of a continuity plan sits in the conversations that produced it: what matters, what we do when it stops, who decides. Exercises test that thinking, and they work best when they start from the capabilities you want to test.
You may ignore the document in the moment. You benefit from every hard conversation that went into it.
A practical way to begin
- Pick one critical service and cut its plan down to one screen or two pages.
- Write the activation trigger as a threshold anyone can check, and name who decides.
- List the people who know the service, with out-of-band contact details.
- For each critical dependency, record the workaround and how long it holds.
- Walk through the plan with the team in a 60-minute session, and fix whatever felt unclear.
How we do this in resimate
resimate builds continuity plans from the business impact and dependencies already in your connected view, so nobody starts from a blank page. It proposes workarounds based on your actual context. When a dependency changes, the plan detects it and flags the missing workaround. During an incident the plan is built for activation: impact clock running, contacts one tap away. Teams go live in 4 to 6 weeks, on the data they already have.