Business continuity vs. disaster recovery
The two terms get used interchangeably, and they shouldn't be. Business continuity is keeping the business operating during a disruption — invoicing, answering customers, making payroll — even if that means paper forms and cell phones for a few days. Disaster recovery is restoring the IT — servers, data, applications — after something breaks them. DR is a chapter inside the continuity plan, not a synonym for it; we cover that chapter in depth in our disaster recovery guide.
The distinction matters because each fails differently. A business with great backups but no continuity plan restores its server in two days — and discovers nobody knew how to take an order, answer the phones, or pay anyone during those two days. A continuity plan's job is to make the disruption survivable while the recovery happens.
What follows is the complete template. Seven sections, each short. Copy it straight off this page into a document, or grab the editable copy at /downloads/business-continuity-plan-template.docx and fill in the blanks.
The template, sections 1–3: purpose, people, priorities
1. Purpose & scope
Three sentences, not three pages:
- What this plan covers: which locations, teams, and operations.
- When it activates: who can declare a disruption, and what counts as one (any event stopping normal operations for more than ___ hours).
- Where it lives: the plan's locations — printed copies count, and matter. A continuity plan stored only on the server it's written to protect is a punchline, not a plan.
2. Roles & contact tree
For each role, fill in a name, a backup person, and a cell number — office extensions die with the office:
- Incident lead (decides, declares, deactivates): name ___ / cell ___ / backup ___
- Communications lead (staff, customers, vendors): name ___ / cell ___ / backup ___
- IT contact (internal person or your provider's emergency line): name ___ / cell ___ / backup ___
- Facilities / site contact: name ___ / cell ___ / backup ___
- Finance contact (payroll, banking, insurance): name ___ / cell ___ / backup ___
Then the external list: bank fraud line, insurance carrier and policy number, landlord, key vendors' support numbers, internet provider's outage line. Keep a copy of this section somewhere reachable when email isn't — printed, and in personal phones.
3. Critical functions & maximum tolerable downtime
List the five to eight functions the business cannot live without — not every task, just the ones whose stoppage does real damage. For each:
- Function: ___ (e.g., taking customer orders, payroll, patient scheduling, shipping)
- Owner: ___
- Maximum tolerable downtime: ___ (the honest number — hours? a day? a week?)
- Depends on: ___ (the systems, people, or vendors it needs)
Be ruthless here. If everything is critical, nothing is, and the plan can't tell anyone what to fix first at 6 a.m.
The template, sections 4–5: IT dependencies and workarounds
4. IT dependencies & recovery targets
For each system named in section 3's "depends on" column, record what you need from recovery. Two definitions first: RTO (recovery time objective) is how fast the system must be back; RPO (recovery point objective) is how much data you can afford to lose, measured backward from the failure to the last good backup.
- System: ___ (e.g., accounting software, email, file server, line-of-business app)
- What stops without it: ___
- RTO: ___ hours/days
- RPO: ___ hours/days
- Backed up how, and where: ___ (method and location — if you're unsure what should go here, our backup types guide explains the options and why at least one copy must be offsite and immutable)
- Restore last tested: ___ (a date, not a feeling)
This section is also the conversation to have with your IT provider: your RTO and RPO numbers either match what your current backup setup can deliver, or they don't — and it's vastly better to learn that here than mid-incident.
5. Workarounds for the top scenarios
For each scenario: what triggers it, the immediate workaround, who decides, and how long the workaround holds.
- Internet down at the office. Workaround: ___ (typically: phone hotspots for critical staff, work from home, a printed list of which systems are cloud-based and still reachable from elsewhere). Decision owner: ___. Holds for: ___.
- Building inaccessible (fire, flood, power, weather). Workaround: ___ (who works from where, how calls get forwarded, where the team assembles or checks in). Decision owner: ___. Holds for: ___.
- Ransomware / major IT outage. Immediate steps: disconnect affected machines, call the IT contact in section 2, do not wipe anything, and operate critical functions manually per section 3 while recovery runs — the full sequence is in our ransomware recovery guide. Decision owner: ___.
- Key vendor down (the payment processor, the supplier, the software you rent). Vendor: ___. Workaround: ___. Alternate vendor and account details: ___.
Resist inventing twenty scenarios. These four cover the mechanics of most disruptions; a plan that handles them handles the weird ones too.
The template, sections 6–7: communication and testing
The last two sections are the ones most templates treat as afterthoughts — and the ones that determine whether the plan works under pressure. Silence during an outage costs more customer trust than the outage itself, and an untested plan is a rumor.
6. Communication plan
- Staff: who notifies everyone, by what channel that isn't company email (text tree, group chat, phone), and how often updates come.
- Customers: who speaks, where (website banner, social, direct calls to the top accounts), and the pre-drafted two-sentence holding statement: "We're experiencing a disruption affecting ___. Here's what still works, and we'll update you by ___." Writing it now, calm, beats writing it then, not.
- Vendors and bank: who calls which ones, and in what order.
- Insurer: notify early — cyber and business-interruption policies have notification deadlines, and late notice is a coverage fight you don't need during an outage.
7. Testing schedule
- Tabletop exercise: ___ (at least annually — pick a scenario, gather the section-2 people for ninety minutes, walk the plan aloud, write down everything wrong).
- Backup restore test: ___ (quarterly is a good default; an untested backup is a hope, not a control).
- Contact tree check: ___ (twice a year — people change numbers and jobs).
- After-action review: within two weeks of any real disruption or test, update the plan with what you learned and bump the version date on page one.
Filling it in over one afternoon
The reason most businesses don't have a continuity plan isn't difficulty — it's the belief that doing it properly takes a consultant and a quarter. It takes about three hours:
- Book the time and the right four people: owner, whoever runs operations, whoever runs the money, and your IT person or provider. Order lunch.
- First hour — sections 2 and 3. Names, cell numbers, and the critical-functions list. Expect a genuinely useful argument about what's actually critical; that argument is the planning.
- Second hour — sections 4 and 5. Your IT provider can pre-fill most of section 4 — ask for current RTO/RPO and the last restore-test date, and pay attention if those answers come slowly.
- Third hour — sections 1, 6, 7, plus printing copies and saving one outside your own systems.
Aim for done, not perfect. An 80% plan that exists, printed, with real cell numbers in it, outperforms the perfect plan that's still a to-do. You'll fix the gaps at the first tabletop — that's what it's for.
One more thing before the meeting ends: schedule the first tabletop right then, eight to twelve weeks out, while everyone's calendar is open. Plans that leave the room without a test date tend to be discovered, badly out of date, during the real thing.
Keeping it alive
A continuity plan ages like milk, not wine. The drift is silent: people leave, numbers change, that new cloud system never makes it into section 4, and two years later the plan describes a company that no longer exists.
- Revisit annually at minimum — same four people, one hour, walk every section.
- Update on triggers, not just the calendar: a new system or vendor, a new location, anyone in the contact tree leaving, and after every test or real incident.
- Version and date the front page so anyone holding a copy knows whether to trust it.
If you'd like a second set of eyes on section 4 — whether your backup reality can actually deliver the RTO and RPO you just wrote down — that gap analysis is exactly the kind of thing we do in a 20-minute intro call.