Most plans are written to pass an audit and fail the first real test. The difference is tiering, measured recovery times, and one test nobody wants to run.
There are a great many business continuity templates available and most of them are fine. The template is not the problem. The problem is that a template produces a document, and a document is not a plan, and the difference only becomes apparent on the one morning you needed it to be a plan.
Three things separate the two. Everything else in this article is detail.
One: tier things, and be mean about it
The single most common defect is a plan in which everything is critical. It is easy to see how it happens. You ask each department head how long they could manage without their system, and each of them, reasonably, says not long.
The result is a plan that commits to a four-hour recovery for eleven systems, which is a commitment nobody has costed and nobody can meet. In the actual incident, the team improvises a priority order under pressure, which is precisely what the plan existed to prevent.
Keep Tier 1 to three or four systems. The test for Tier 1 is not "would this be painful". It is "does revenue stop, does a legal deadline get missed, or does someone get hurt". Painful goes in Tier 2.
This conversation is uncomfortable because it requires telling somebody their system is not the most important one. Have it in the planning meeting, where it is a discussion, rather than at 7am during an outage, where it is an argument.
Two: your recovery time is a measurement, not an aspiration
Every plan contains an RTO, the time within which a system will be back, and an RPO, the amount of data you are prepared to lose. In most plans both numbers were chosen because they sounded reasonable.
The honest version of each is a number that came from an actual restore. We have yet to see a first measured restore come in at or under the documented figure. The gap is typically two to four times, and it is caused by things nobody models: the backup restores but the application does not start because a dependency is missing, the credentials needed to bring it up were stored in the system that is down, the restore runs at a speed the network cannot sustain, or the only person who has done it before is on holiday.
An untested recovery time is not a plan, it is a hope with a number attached.
Measure one Tier 1 system. Write down what it actually took. Then either change the number in the plan or change the architecture until the number is true. Both are legitimate; pretending is not.
Three: test in a way that can fail
Most organisations do the first rung and call it an annual test. Walking the plan round a table is genuinely useful: it finds wrong phone numbers, people who have left, and steps that assume knowledge nobody has. It finds nothing about whether the technology works.
The rung most people stop before is the last, and it is the only one that finds the dependency nobody documented. Take a Tier 1 system away during working hours, with warning, and run the manual process for three hours. You will discover which other systems quietly call it, which team has no fallback at all, and whether the documented workaround was ever tried.
Do this once a year on one system, rotating. It is the single highest-value hour in the whole discipline.
What the plan should actually contain
Shorter than you expect. A continuity plan people can use in an incident is five pages, not fifty. The fifty-page version is a compliance artefact and it is fine to have one, but it is not the thing you reach for.
Page one: who decides. Named individuals, in order, with mobile numbers. Who declares an incident, who can authorise spend, who talks to clients, who talks to staff. Deputies for each, because incidents are not scheduled around holidays.
Page two: the tiers. The list from above, with the measured recovery times. One page.
Page three: the first hour. What to do before anyone knows what is wrong. Who to call, where to gather, how to communicate if the usual channel is the thing that is down. This page gets used more than any other.
Page four: per Tier 1 system. Half a page each: what it does, where it runs, who to call at the vendor with the account number, how it is recovered, who has the credentials.
Page five: communications. Three pre-written drafts: to staff, to clients, to anyone with a regulatory interest. Written on a calm day. The worst time to compose a careful sentence is during the thing it describes.
Then print it. A continuity plan whose only copy is in the file share is a continuity plan you have a fifty percent chance of being able to read.
The dependencies that catch people
Four worth checking specifically, because they recur.
Credentials inside the failed system. The password manager that is cloud-hosted and depends on the identity provider that is down. There needs to be an offline break-glass copy, held physically, with a documented procedure for using it and an alert when it is used.
Communication that runs on the same platform. If email and chat are both Microsoft 365 and Microsoft 365 is the incident, you need a third channel agreed in advance. A group on a different platform, or a phone tree. Decide now, not then.
Your provider's own continuity. If your IT is outsourced, your continuity depends on theirs. Ask what happens if their office is unavailable, and whether they have ever tested it.
One person. Almost every organisation has a system that one person understands. Write down who, for which system, and treat each entry as a risk with an owner, because it is.
Maintenance, realistically
Annual review is standard advice and annual review alone produces a plan that is wrong for eleven months of the year.
Attach the plan to events instead. When a Tier 1 system changes, the plan page for it is part of the change. When somebody on the contact list leaves, the plan is on the offboarding checklist. When you run the annual test, the findings are written back that week rather than queued.
Then the annual review is a tidy-up rather than a rewrite, which is the only way it gets done properly.
If you only do one thing this quarter
Restore your most important system into an isolated environment and time it. You will learn more in that half day than from any amount of document work, and whatever you find will reorder the rest of your plan for you.
