How to Create a Business Continuity Plan That Saves Your Company

How to create a business continuity plan that survives contact with reality

The last time a client asked me to build a business continuity plan from scratch, it took eleven days and one very awkward meeting with their CFO. Not because the process is complicated. Because everyone wants to jump straight to the template, and nobody wants to answer the question that actually matters: what stops earning money first when things go wrong?

That question is where a real business continuity plan starts. Not the PDF. Not the Word file with the header logo. The uncomfortable conversation about which process bleeds cash in hour one, and which one can wait until Thursday.

Most guides hand you a checklist and call it done. I've seen those checklists sit in a shared drive for two years, untouched, until a ransomware attack forced a company to improvise its entire recovery on a whiteboard. So let me show you the version that actually gets used. Including the parts I got wrong the first time.

Business continuity plan vs disaster recovery plan: what's the actual difference?

The two get bundled together so often that I've watched experienced operations managers use them interchangeably in meetings. They're not the same thing, and confusing them leads to a specific, predictable failure.

A business continuity plan covers the whole organization: people, suppliers, premises, communication, manual workarounds. A disaster recovery plan is narrower. It covers your IT infrastructure — servers, backups, failover, data restoration. The BC plan says "we'll process orders manually for 48 hours." The DR plan says "the ERP will be back on the secondary site by hour six."

Where the confusion costs you

Here's the failure I see most: a company invests heavily in backup infrastructure, feels secure, and then discovers during an actual outage that nobody knows who's allowed to authorize a manual payment. The servers came back in four hours. The business was still frozen for two days because the decision-making chain was never written down.

Both documents belong in the same binder, but they answer different questions. If you can't articulate which process depends on which system, you're not ready to write either one.

The four phases of business continuity planning

You'll see five-step, six-step, seven-step frameworks floating around. The step count is marketing. Underneath, there are really four phases, and skipping any of them leaves a hole.

Phase 1 — Analysis: figure out what actually matters

This is the business impact analysis, and it's the phase everyone rushes. You map each business process, then ask two questions per process: how long can this be down before it hurts, and how much data can we afford to lose?

The answers become two numbers you'll use for everything downstream:

• RTO (Recovery Time Objective) — the maximum tolerable downtime for a process. Order processing: 4 hours. Payroll: 5 days.
• RPO (Recovery Point Objective) — how much data loss is acceptable. Customer transactions: 15 minutes. Internal reporting: 24 hours.

I'll be blunt: if your RTO for every process is "as soon as possible," you haven't done the analysis. You've written a wish. Real RTOs are uncomfortable trade-offs, and the CFO meeting is where they get made.

Phase 2 — Design: build the response

Now you write the plan itself. Not a novel. A working document with named owners, contact chains, and specific triggers. "If the primary data center is unreachable for more than 90 minutes, the incident lead activates the alternate site" is a plan. "We will respond appropriately" is a slogan.

Phase 3 — Implementation: make the resources real

This is where budget either appears or doesn't. Alternate workspaces, backup generators, cross-trained staff, a second supplier for your single-source component. Every one of these has a cost, and this phase is where the plan collides with the annual budget.

Phase 4 — Testing and maintenance: the phase that gets skipped

And then it gets skipped again the following year. I've made this mistake myself. We wrote a solid plan in 2023, tested it once, and then didn't touch it for eighteen months. By the time we ran the next exercise, two of the three named contacts had left the company and the "alternate workspace" had been converted into a storage room.

How to build your first draft (and what goes in it)

Forget searching for a business continuity plan template for the first hour. Open a blank document and work through these sections in order. The template can come later, once you know what you're budgeting for.

Scope and assumptions

State plainly what the plan covers and what it doesn't. A plan that quietly assumes the building is still standing is not a plan — it's a hope. Write the assumptions down so the next person can challenge them.

The BIA summary table

Here's the structure I use with clients. It's simple enough to fill in during a workshop and specific enough to drive decisions afterward.

Process	RTO	RPO	Dependencies	Owner
Order intake	4 hours	15 minutes	ERP, payment gateway, 2 staff	Sales ops lead
Customer support	8 hours	1 hour	CRM, phone system	Support manager
Payroll	5 days	24 hours	HR system, bank file export	HR director
Invoicing	3 days	24 hours	Accounting software	Finance lead

Recovery strategies and the response team

For each critical process, name the workaround. Manual order entry? A temporary phone line? A pre-arranged agreement with a partner site? Then list the response team with roles, not just names — roles survive people leaving.

One detail most drafts miss: who decides to activate the plan? If nobody has explicit authority to declare an incident, you'll lose the first hour to debate. Pick a person and a backup. Say it out loud in the meeting.

Testing: the part that separates a document from a capability

A plan you've never rehearsed is a hypothesis. Testing is how you turn it into something you can rely on, and there are three levels you can work through over time.

• Tabletop exercise — a discussion-based walkthrough. Two hours, a whiteboard, one scenario. This is where you start, and honestly, it catches more gaps than any other method.
• Simulation — you actually activate the alternate procedures. Manual order processing for a day. Failover to the secondary site during business hours.
• Full test — ideally out of hours, ideally once a year, ideally painful enough that you learn something.

Whatever you run, define what "success" looks like beforehand. In our last tabletop, the metric was simple: could the team identify, within 15 minutes, who needed to be called and what they needed to do? They couldn't. We fixed one contact list and the next run hit it in nine minutes.

The mistakes I made so you don't have to

Three failures worth naming, because each one cost real time.

Writing a plan nobody could find. The first draft lived in a folder structure so deep that during an actual incident, the on-call engineer spent twelve minutes locating it. Now the first page is printed and taped inside the server room door.

Ignoring suppliers. We mapped our own processes perfectly and forgot that two of them depended on a single logistics provider with no backup. One of those providers had a fire. We learned the hard way that supplier risk belongs in the BIA.

Treating the review as annual. A plan is a living document. Every new hire, every system migration, every office move changes an assumption. We now trigger a review whenever the org chart shifts, not on a calendar date.

What is a BCP in healthcare, and why is it different?

In clinical settings, continuity planning carries an extra dimension: patient safety runs parallel to operational recovery. A hospital losing its electronic records system can't simply pause admissions. The BIA in healthcare must prioritize clinical workflows — medication administration, emergency intake, surgical scheduling — and account for the fact that physical infrastructure like power, oxygen, and sterile supply has no workaround.

The general method still applies. RTO and RPO per process, named owners, tested procedures. The stakes just make the testing non-negotiable.

Getting started this week without hiring anyone

Block three hours. Gather the people who own your critical processes — not the whole company, four or five people will do. Write the process list on a whiteboard, and for each one, ask the two questions: how long can this be down, and how much data can we lose?

The first draft will be rough. That's fine. A rough plan reviewed in a month is worth more than a polished plan that never leaves the drafting stage. The document isn't the deliverable. The capability is.

And if you take nothing else from this: schedule the tabletop exercise before you finish writing the plan. Because the day you finish drafting is the day the momentum dies, and the exercise is the only thing that pulls it back.