You're mid-morning on a Tuesday when the message lands in your inbox: the payment processor that handles 80% of your revenue has been offline for six hours. No ETA. Your support queue is filling up with customers who can't check out. Somewhere in the back of your mind, a question surfaces that you've been putting off for months: what exactly happens next?
Most small companies answer that question with improvisation. I know, because I used to be one of them. Then a hosting outage took our store down for a full business day, and I watched two years of customer trust get tested in eight hours. That week I built my first business continuity plan. It was clumsy, half of it was wrong, and it still saved us the next time something broke.
This is what I'd tell you before you write yours: the plan matters less than the exercise of writing it. The document is almost a byproduct.
Key takeaways
- A business continuity plan keeps your critical operations running during a disruption — it's not the same as disaster recovery, which only covers IT systems.
- Five core components: a continuity team, a business impact analysis, recovery procedures, a communication plan, and a testing schedule.
- Small companies don't need a 60-page document. A four-page plan that gets tested beats a binder that gathers dust.
- Test at least once a quarter. An untested plan is a hypothesis, not a plan.
- Your first draft will be wrong. That's expected.
Why most business continuity plans fail before they're even finished
The failure mode is almost never the writing. It's the scope.
People sit down to draft a business continuity plan, and within an hour they're trying to plan for everything: fire, flood, cyberattack, pandemic, key employee quitting, supplier collapse. The document balloons to thirty pages, nobody reads it, and it dies in a shared drive folder named "BCP_final_v3_REAL.docx".
Here's the thing: a continuity plan isn't a catalogue of catastrophes. It's a short list of the things your business absolutely cannot stop doing, and a set of answers for how you'd keep doing them when the normal way breaks.
What actually counts as a disruption
In my experience working on this with a handful of small teams, the disruptions that hurt are boring. Not the dramatic ones.
- Your accountant is out for three weeks and nobody else has the bank credentials
- The one person who knows how your order system works is on a plane
- A key supplier goes quiet for ten days
- The office is inaccessible, but everyone's laptops are inside it
- Your domain registrar locks your account over a billing dispute
None of these are disasters in the cinematic sense. All of them can cost you a month of momentum. Plan for these first. Add the dramatic scenarios later, once the basics are covered.
The plan you don't test is fiction
I'll be blunt about a mistake I made early on: I wrote a beautiful plan, printed it, filed it, and felt productive. Then an actual outage hit, and I discovered the emergency contact list was six months out of date. Two of the numbers were wrong. The document was worthless at the exact moment it needed to work.
Since then I've treated the plan as a living thing. Every quarter, we run one scenario — a tabletop exercise, an hour, no drama — and see what breaks. Every single time, something breaks. That's the point.
What are the 5 key components of a business continuity plan?
Strip away the frameworks and templates, and a working plan comes down to five pieces. If any one is missing, the plan has a hole.
1. A continuity team with named people and backups
Someone has to be in charge when things go sideways. In a small company, that person might also be the person who handles support — that's fine, but write down who does what. Critically, name a backup for each role. Single points of failure are the enemy.
2. A business impact analysis
This sounds intimidating. It isn't. It's a list: which functions are essential, how long can each be down before it hurts, and what does it depend on? Your order processing might tolerate four hours offline. Your payroll might tolerate two days. Your customer support inbox might tolerate six hours before people start leaving.
Rank them. That ranking drives everything else in the plan.
3. Recovery procedures for each critical function
This is the operational meat. For your top three or four critical functions, write down the steps someone would take if the normal system were unavailable. Manual workarounds, backup tools, temporary processes. Steps, not principles.
4. A communication plan
Who do you tell what, and how? Staff, customers, suppliers, and — depending on your sector — regulators. Write down the channels you'd use if your primary one is down. Have a second email domain you control. Keep a printed contact list somewhere it won't get lost.
5. A testing and update schedule
Quarterly tabletop exercises, one live test per year, and a review of the plan every six months. Put the dates in the calendar now. A schedule that isn't scheduled doesn't happen.
| Dimension | Business continuity plan (BCP) | Disaster recovery plan (DRP) |
|---|---|---|
| Scope | The whole business — people, processes, suppliers, communications | IT systems, data, and infrastructure |
| Primary question | How do we keep operating? | How do we restore our systems? |
| Typical owner | Operations lead or general manager | IT lead or external provider |
| Time horizon | Hours to months | Hours to days |
| Overlap | The DRP is a chapter inside the BCP. Not a separate document living in a different folder nobody opens. | |
That last row is the one people get wrong most often. They build a DRP, call it a BCP, and discover during an incident that nobody planned for how customer communication works while the systems are down.
How do I write a business continuity plan? A four-step method that works
You don't need specialist software or a consultant. You need two afternoons and a spreadsheet. Here's the order I follow, refined after getting it wrong more than once.
Step 1 — Identify what matters and what it depends on
List your revenue-generating activities and the operational activities that support them. For each one, ask: what does it depend on? A person, a system, a supplier, a physical space, a licence? Write the dependency down. That dependency is what you'll plan around.
Step 2 — Assess the impact of downtime
For each critical activity, estimate two numbers: the maximum tolerable downtime, and the cost per hour of being down. Neither will be precise. Rough is fine — you're ranking, not auditing. But taking fifteen minutes to put a number on "an hour of checkout being offline costs us roughly X" changes how seriously the rest of the plan gets taken.
Step 3 — Write procedures for the top three
Not all of them. Three. For your three most critical functions, write the actual steps someone would follow if the primary path failed. Test the draft on someone who doesn't know the function — if they can't follow it, it's too vague.
Step 4 — Test, revise, repeat
Run a scenario. See what breaks. Fix the plan. Then put the next scenario in the calendar. This loop is the whole game; a plan that never gets exercised is decoration.
Total time for a small business: roughly two afternoons for the first draft, then an hour per quarter to keep it alive. If you have ten employees or fewer, that's realistic and it's enough.
Can you provide an example of a business continuity plan?
Here's a stripped-down version of what a plan looks like for a small e-commerce business with eight staff. It fits on four pages.
The scenario
A payment provider outage takes card processing offline for six hours on a weekday. Orders can be received but not paid.
The plan, in short form
- Continuity lead: Marta (operations). Backup: Dev (founder).
- Trigger: payment failure rate above 20% for more than thirty minutes.
- Immediate action: switch the checkout to the backup provider, which we keep configured and test monthly.
- If the backup fails too: post a banner explaining the delay, collect orders by email with payment on dispatch, and manually reconcile at the end of the day.
- Customer comms: template email ready to go, plain language, no over-promising on timeline. Support lead sends it within an hour of the trigger being hit.
- Internal comms: WhatsApp group "Incident" — everyone knows to check it when something looks wrong.
- Post-incident: thirty-minute debrief within 48 hours, written notes filed alongside the plan.
That's it. Not glamorous. But the last time we had a payment hiccup, our support team knew exactly what to send and when. That alone prevented the wave of angry follow-ups that would otherwise have eaten the whole afternoon.
Where templates help and where they hurt
A template gets you moving. There are plenty around — the standard ones from national emergency-management agencies, the ones bundled with free BCP software trials, the Word documents you can find in five minutes. Use one for structure, then gut the sections that don't apply to you. Don't keep placeholder text. Don't keep sections you can't fill in with real names and real numbers. A filled-in template with three sections is worth more than a complete one where every entry says "TBD".
How often should you update the plan — and what usually goes stale
Twice a year for a full review, plus an immediate update after any real incident. The stuff that rots fastest, in my experience, is the boring admin: phone numbers, supplier contacts, credentials, and the person who's supposed to be on point. We lost an afternoon once trying to reach a supplier contact who'd left the company seven months earlier. Nobody had updated the list.
Put the review date in the same calendar you actually use. Not a separate spreadsheet — the calendar you open every morning. Otherwise it slips.
If you're a sole trader or a two-person outfit, you can compress this to a single page: your critical activities, your backup for each one, and the phone numbers of people who could help. That's still a continuity plan. Size isn't the point.
The thing nobody tells you about continuity planning
The real value of writing a plan is not the document. It's the afternoon you spend discovering that your entire customer support function depends on one person's memory, or that your backup payment provider hasn't worked since a configuration change nine months ago. Those discoveries happen before the incident, in a calm room, which is the only time they're cheap to fix.
The document is just the receipt.
So here's a question worth sitting with: if your three most critical activities all stopped tomorrow morning, how long would it take you to know what to do? If the answer is "I'd figure it out", you're not in bad company — most businesses are there right now. But you're one bad Tuesday away from finding out how expensive that is.
Two afternoons. That's the barrier. Start there.