Writing a Business Continuity Plan You'll Actually Follow

A continuity plan is not a disaster recovery plan

The two terms get used interchangeably, and that confusion is why so many plans fail in practice. They answer different questions and belong to different owners.

• Disaster recovery (DR) is the technical discipline of restoring systems and data — servers, databases, applications, network — after a failure. It is measured in recovery time and recovery point objectives (RTO/RPO) and owned by IT.
• Business continuity (BCP) is the broader discipline of keeping the organization operating while that restoration happens. It covers people, communications, facilities, third parties, and the manual workarounds that let the business keep taking orders and serving customers when systems are down.

Put plainly: DR brings the ERP back online; BCP decides how the warehouse keeps shipping during the eight hours it takes. A company can have flawless managed backup and disaster recovery and still lose customers because nobody knew how to take orders on paper, who was authorized to speak to the press, or where staff should report when the office was inaccessible. DR is a subset of continuity, not a synonym for it. Both belong in the plan, and the plan's job is to connect them.

Let the business impact analysis set your priorities

The single most common reason continuity plans become shelfware is that they treat every system as equally critical. When everything is a priority, nothing is, and the plan is too large to execute. The business impact analysis (BIA) is the tool that fixes this. It is not a technical inventory — it is a business exercise that ranks processes by the damage their disruption causes over time.

For each critical business process, work through four questions with the process owner, not just IT:

1. What breaks if this stops? Revenue, safety, legal or regulatory exposure, contractual penalties, reputation. Quantify where you can.
2. How fast does the damage escalate? Some processes tolerate a day; some cause real harm within an hour. This curve sets the RTO — the maximum time the process can be down.
3. How much recent work can you afford to lose or re-create? This sets the RPO — the point in time you must be able to recover to.
4. What does this process depend on? Applications, data, people with specific knowledge, suppliers, connectivity, facilities.

The output is a tiered list: a small set of tier-1 processes with aggressive RTO/RPO targets, and a longer tail that can wait. Protection cost rises steeply as those numbers approach zero, so tiering is also how you avoid paying premium recovery prices to protect a process that could sit idle for two days without harm.

Figure: the BIA fixes two points on the timeline — how far back you must recover (RPO) and how fast each tier must return (RTO) — so recovery runs in priority order, not all at once.

Build the plan from components, not prose

A continuity plan people follow is a set of operational artifacts, not a narrative document. Keep it short, specific, and structured so a stressed team can act from it at 2 a.m. These are the components that matter.

Roles and authority

Name the people, not the job titles alone, and give each role a designated backup so the plan does not collapse when one person is on a plane.

• A continuity coordinator who declares an event and owns the response.
• Process recovery leads for each tier-1 function.
• A communications lead who owns all internal and external messaging.
• Clear decision authority: who can approve emergency spend, invoke a supplier contract, or authorize working from an alternate site.

Ambiguity about who is in charge is the biggest amplifier of a bad day. Settle it in writing before the event.

Communications plan

Assume your primary systems — email, phones, chat — may be the thing that is down. Pre-define:

• Contact trees with phone numbers and personal backups, stored somewhere reachable when the network is not.
• Out-of-band channels the team defaults to when corporate email is unavailable.
• Pre-approved holding statements for customers, partners, and regulators, so legally sensitive language is not drafted under pressure.
• A single source of truth for status, so leadership is not pulling responders away for updates.

Alternate operating procedures

This is the heart of continuity and the part DR plans skip. For each tier-1 process, document how the business runs while systems are being restored: the manual workaround, the paper form, the alternate work location or remote-work fallback, the degraded-mode process the team switches to. If the answer is "we would figure it out," you do not have a continuity plan for that process.

Dependency mapping

Most recoveries stall on an overlooked dependency — an expired certificate, a license server, an authentication service, a single supplier. Map upstream and downstream dependencies for each critical process, including third parties, and note the alternates. A process is only as available as its least-available dependency.

Recovery procedures

Here the plan hands off to DR and, when the trigger is an attack, to incident response. Recovery steps should be checklists, not essays: the exact order of restoration by tier, the systems and credentials needed, the validation gates before a system is trusted again, and the point at which you fail back from workaround to normal operations. Restoring from backups you have verified are clean — not last night's possibly-encrypted copy — is a gate, not an assumption.

A plan is a living document or it is fiction

The fastest way to produce shelfware is to write the plan once, satisfy the auditor, and file it. Environments change constantly, and a plan describing last year's systems and last year's staff will fail on contact with reality. Keep it current:

• Review on a schedule — at least annually, and tie the review to a named owner with a due date.
• Update on change. Any material change — a new critical application, a migration, a reorg, a key supplier swap, staff turnover in a named role — should trigger a plan update, not wait for the annual cycle.
• Version and distribute. Everyone with a role needs the current version, stored where they can reach it during an outage, not only on the file share that may be down.
• Keep contact data fresh. Broken contact lists are the most common failure a real event exposes, and the cheapest to prevent.

For organizations without a full-time risk owner, a virtual CISO can hold the plan between events and keep the review discipline honest.

Test it before an event tests it for you

A plan you have never exercised is a hypothesis, not a capability. Testing is what converts an assumed RTO into a proven one and surfaces the gaps cheaply. Run a range of exercises, matched to effort:

1. Tabletop exercises — a facilitated, discussion-based walkthrough of a realistic scenario with no systems touched. Inject complications in stages ("the backups are also encrypted," "the coordinator is unreachable") and have each role state exactly what they would do and with what. Run at least annually.
2. Walkthrough and simulation drills — actually invoke a communications tree, stand up an alternate work location, or run a process in degraded mode for an hour.
3. Full recovery tests — restore a tier-1 workload end to end in an isolated environment and time it against the documented RTO. If reality exceeds the objective, the objective is fiction until you close the gap.

Track every stall, guess, or missing piece of information as a finding with an owner and a deadline, exactly as you would a real incident. Ninety minutes of structured practice routinely exposes broken assumptions before an attacker or an outage finds them for you.

Make the plan operational

A business continuity plan is not a compliance artifact you produce once. It is a BIA that sets priorities, a small set of clear components that people can execute, a document you keep current, and a set of exercises that prove it works. If you cannot state your tier-1 RTO/RPO targets today, or you have never run a tabletop, that gap is exactly where the risk lives.

intSignal builds and operates continuity programs that hold up under pressure — from the impact analysis and recovery architecture to the tabletop that proves it. Explore our business continuity services, or talk to our team to build a plan your people will actually follow when it matters.