A business continuity plan is the difference between a bad Tuesday and a bad quarter. When a data center floods, a ransomware note lands, or your single largest supplier goes dark, the plan is what tells your teams which functions to save first, how long they have, and who makes the call. Everything else can wait.

The uncomfortable truth is that most continuity plans are written to pass an audit, not to survive an incident. They sit in a shared drive, untested, describing an organization that stopped existing two reorganizations ago. As COO, you own the version that actually has to work at 2 a.m. with half your executive team on a plane.

This guide walks through the parts that matter: figuring out what "critical" really means through a business impact analysis, setting honest recovery targets (RTO and RPO), building recovery strategies you can afford, and testing the plan until it stops surprising you. The goal is not a thicker binder. It is an operation that keeps serving customers while the crisis is still unfolding.

Start with the business impact analysis, not the threat list

Plenty of teams begin continuity planning by brainstorming threats: earthquakes, outages, pandemics, cyber attacks. That list is endless and it is the wrong starting point. You cannot protect against every threat, but you can protect the handful of functions that, if they stop, take the whole business down with them. That is what a business impact analysis (BIA) does — it ranks your operations by how much damage their absence causes, and how fast that damage compounds.

A weak BIA asks each department head "is your work important?" and gets a predictable answer: everyone's is. A strong BIA forces trade-offs by asking harder questions. If this process were down for four hours, what breaks? What revenue stops flowing, what contractual penalty triggers, what regulatory clock starts, what other teams grind to a halt because they depend on you? You are looking for the dependencies and the clocks, not the org chart.

Work through each core function and score it on impact over time. The point is to separate the genuinely critical from the merely urgent. Payroll is important, but it can slip a day; the payment gateway that books revenue cannot. Here is the kind of tiering a BIA produces:

The tiers are yours to define, but the discipline is universal: everything cannot be Tier 1. If half your functions land in Critical, the analysis was too soft. Push back until the list of things that truly cannot wait four hours is short enough that you could actually resource its recovery. This same prioritization logic underpins a broader operational risk program — continuity is the recovery arm of the risk work you should already be doing.

Set honest recovery targets: RTO and RPO

Two numbers turn a BIA into an engineering requirement. Recovery Time Objective (RTO) is how long a function can be down before the damage is unacceptable — the deadline to get it back. Recovery Point Objective (RPO) is how much data you can afford to lose, measured in time — if you back up every hour, your RPO is an hour, and an incident could cost you up to 60 minutes of transactions.

These are not the same thing, and confusing them is a common and expensive mistake. A four-hour RTO means "restore service within four hours." A five-minute RPO means "lose no more than five minutes of data." A system can have an aggressive RTO and a loose RPO, or the reverse, and the two drive completely different (and differently priced) technical solutions.

The COO's job is to keep these targets honest. Business leaders will ask for near-zero on both because zero sounds safe. Zero is also close to infinitely expensive. A one-minute RPO on a transactional database means continuous replication and real infrastructure spend; a 24-hour RPO on an internal wiki means a nightly backup. Match the target to the tier from your BIA, and make the cost of each tightening visible so the trade-off is a business decision, not a default. When someone insists on a 15-minute RTO for a Tier 3 function, that is your cue to walk them back to the impact analysis.

Build recovery strategies you can actually execute

A recovery strategy is the concrete "how" for each critical function: where the work happens when the primary site is gone, how data comes back, who is authorized to act, and what the fallback looks like. Vague strategies read well and fail live. "Ensure data is backed up" is not a strategy. "Hourly replication to a second region, with a documented, tested restore that a named on-call engineer can run in under 90 minutes" is.

Strong recovery strategies share a few traits. They are specific about the alternative — a named standby site, a cloud failover region, a pre-arranged remote-work setup — not a promise to "find somewhere." They assign authority in advance, so nobody waits for a sign-off from a leader who is unreachable. And they account for the people, not just the systems: a flawless technical failover is useless if the three people who know how to run it are all on the same disrupted team.

Cover the recurring failure domains deliberately:

• Facilities and workspace. Alternative locations, tested remote-work capability, and clarity on which roles must be physically somewhere versus which can work from anywhere.
• Data and systems. Backups you have actually restored from, geographic redundancy, and documented failover steps. An untested backup is a hope, not a control.
• People. Cross-training so no single person is a point of failure, plus a clear line of succession for decision-making authority during an incident.
• Suppliers. Pre-qualified alternates for anything single-sourced, because a supplier's outage is your outage. This is where continuity planning meets supply chain resilience — the strategies overlap, and treating them as one program saves duplicated work.

Budget matters here, and it is a real tension. Hot standby infrastructure that mirrors production is expensive; a documented manual workaround is cheap but slow. Tier your spending the way you tiered your functions — pay for instant failover only where the RTO demands it, and accept slower, cheaper recovery everywhere else.

Test the plan until it stops surprising you

A plan you have never exercised is a document, not a capability. Testing is where you find the expired contact list, the backup that will not restore, the failover that needs a password only one departed employee knew. The COO who insists on regular, realistic tests is buying down risk at a fraction of the cost of finding these gaps during an actual incident.

Testing works as a ladder, from cheap and frequent to expensive and rare:

• Tabletop exercises — a facilitated walk-through where the response team talks through a scenario. Low cost, quarterly, excellent for finding decision-making and communication gaps.
• Functional drills — actually exercise one component, such as restoring a database from backup or standing up the alternate site, without disrupting live operations.
• Full-scale simulations — a realistic exercise that tests the whole response, ideally at least annually. This is where you learn whether the plan survives contact with reality.

The measure of a good test is not that it passed. It is what it revealed. A tabletop where everyone nods along and nothing surprises anyone was probably too easy or too rehearsed. Inject a complication — the incident commander is unreachable, the primary comms channel is down, the disruption hits during your busiest week — and watch where the plan bends. Every gap you find in a drill is a gap you did not find during a real event.

Feed the findings back in. After every test and every real incident, run a short after-action review, capture what broke, and revise the plan. This is the same discipline that separates strong crisis management from improvisation: the response gets better because you deliberately learn from each rehearsal. Pair the test cadence with a fixed review — at minimum annually, and after any material change to your operations, technology, or org structure — so the plan never drifts too far from the business it is supposed to protect.

Make communication part of the plan, not an afterthought

Half of a continuity failure is operational; the other half is people not knowing what is happening. During a disruption, employees, customers, suppliers, and sometimes regulators all need timely, accurate information, and silence gets filled with rumor. Bake the communication protocol into the plan: who speaks, through which channel, to which audience, and with what pre-approved message.

Weak communication planning means someone drafts a customer notice from scratch while the site is down and the clock is running. Strong communication planning means the templates already exist, the contact lists are current, the notification channels are tested, and there is a clear rule for who has authority to send. Pre-written does not mean robotic — it means you are editing a solid draft under pressure instead of writing from a blank page. A dedicated crisis communication plan is worth building alongside the continuity plan; the two are read together during an incident.

Key takeaways

• Rank functions before threats. A business impact analysis tells you what to save first; the threat list is endless and secondary. If half your functions are "critical," the analysis was too soft.
• RTO and RPO are different numbers. RTO is how fast you must recover; RPO is how much data you can lose. Set each from the BIA tier, and make the cost of tightening either one visible.
• Specific recovery strategies beat aspirational ones. Name the standby site, the failover steps, and the authorized decision-maker in advance. Account for people, not just systems.
• An untested backup is a hope. Restore from it, run the failover, and stand up the alternate site before an incident forces you to.
• Test to find gaps, not to pass. A drill that surprises no one was too easy. Every gap found in a rehearsal is one you avoid in a real event.
• Communication is operational. Pre-approved templates, current contact lists, and clear speaking authority stop silence from compounding the crisis.
• The plan is a program, not a project. Review at least annually and after any material change, and feed every test and incident back into the next revision.

Frequently asked questions

What is the difference between a business continuity plan and a disaster recovery plan? Business continuity is the broader discipline: keeping the whole organization functioning — people, processes, communication, and suppliers — through a disruption. Disaster recovery is the narrower, IT-focused subset concerned with restoring systems and data. Disaster recovery lives inside a continuity plan; a good continuity plan needs disaster recovery but is not limited to it. How do RTO and RPO actually differ? Recovery Time Objective (RTO) is the maximum acceptable downtime — how long a function can be offline before the damage is unacceptable. Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time — if you replicate every hour, an incident could cost up to an hour of transactions. A system can have a tight RTO and a loose RPO, or the reverse, and each drives a different and differently priced technical solution. How often should we test the plan? Run low-cost tabletop exercises quarterly, functional drills on individual components a few times a year, and at least one full-scale simulation annually. Also test after any significant change to your operations, technology, or org structure. The cadence matters less than the discipline of feeding every finding back into the next revision of the plan. Who should own business continuity in the organization? Executive ownership typically sits with the COO, because continuity spans operations, technology, people, and suppliers — the same cross-functional territory the operating chief already manages. Day-to-day coordination often runs through a dedicated continuity manager or team with named department representatives, but the COO holds accountability for keeping it funded, tested, and current. How much should we spend on business continuity? Match the spend to the tier. Pay for instant, expensive failover only where the RTO genuinely demands it — usually a short list of Tier 1 functions — and accept slower, cheaper recovery (manual workarounds, next-day restores) everywhere else. The BIA is what justifies the budget: it shows leadership the cost of an outage against the cost of preventing one, which turns continuity spend into a defensible risk decision rather than an insurance line nobody wants to pay. What is the most common reason continuity plans fail? They are written and then never exercised. Plans go stale — contact lists expire, systems change, the people named in them leave — and the gaps only surface during a real incident, which is the worst possible time to find them. Regular, realistic testing and a fixed review cadence are what keep a plan from quietly becoming fiction. Continuity is also tightly linked to operational resilience and disciplined risk assessment; a plan built in isolation from those tends to drift.