Business Continuity Plan Template for Small Businesses

What a continuity plan is for (and what it isn't)

A continuity plan answers a few questions in advance, so nobody has to argue about them on the day. You don't need to predict every disaster to answer them:

• What do we protect first?
• How long can each thing stop before real harm is done?
• How do we keep it going by hand, or from somewhere else?
• Who decides, and who tells clients, staff and suppliers?

The cause matters less than you'd think. A flood, a cyber attack and a burst pipe in the server cupboard all leave you with the same problems: no office, no systems, no data or no people. Plan for those losses and you've covered most causes at once.

It's also different from a disaster recovery plan. Disaster recovery is usually about getting IT systems and data back. Continuity covers the rest of the business while that happens: people, premises, clients, suppliers and money. Business Wales makes the same distinction and says the two should line up.

Business continuity plan template (copy this)

Copy this into Word or Google Docs and fill in the brackets. Keep it short. Where detail already lives somewhere else, such as a supplier contract or an IT runbook, say where it is and don't copy it in.

BUSINESS CONTINUITY PLAN: [Business name]
Version: [ ]   Last reviewed: [date]   Next review: [date]   Plan owner: [name]

1. SCOPE
   What this plan covers:       [the whole business / one site / one service]
   What it doesn't cover:       [anything handled by another plan]

2. WHEN THE PLAN STARTS
   Start the plan when:         [e.g. a critical activity has stopped, or will stop,
                                 for longer than its recovery target]
   Who can start it:            [name]          Deputy: [name]
   Who leads once started:      [name]          Deputy: [name]

3. ROLES AND CONTACTS
   Role                Name        Deputy       How to reach them out of hours
   Plan lead           [ ]         [ ]          [ ]
   Client contact      [ ]         [ ]          [ ]
   Staff contact       [ ]         [ ]          [ ]
   IT and systems      [ ]         [ ]          [ ]
   Key suppliers       [IT support, bank, landlord, insurer: company and phone]

4. CRITICAL ACTIVITIES (most important first)
   Activity   Owner   Longest it can stop   Recovery target   How it runs meanwhile
   [ ]        [ ]     [ ]                   [ ]               [ ]
   [ ]        [ ]     [ ]                   [ ]               [ ]

5. WHAT EACH ACTIVITY NEEDS
   Activity   People   Systems and data   Suppliers   Place to work
   [ ]        [ ]      [ ]                [ ]         [ ]

6. KEY PEOPLE AND COVER
   Person or role   What only they hold   Who covers this week   Written down? (Y/N)
   [ ]              [ ]                   [ ]                    [ ]

7. THE FIRST HOUR
   [ ] Check everyone is safe and accounted for
   [ ] Plan lead decides whether to start the plan
   [ ] Work out which critical activities are affected
   [ ] Switch those activities to their fallback
   [ ] Tell staff what to do and when the next update is
   [ ] Tell affected clients and suppliers
   [ ] Start a log: time, decision, who made it

8. WHO WE TELL, AND HOW
   Staff:      [channel that doesn't depend on the office or main system]
   Clients:    [who calls whom; first message wording kept in section 9]
   Suppliers and insurer:   [ ]

9. WHERE THINGS ARE KEPT
   Backups:                 [what, where, how often, last restore test]
   Printed copy of plan:    [at least one place away from the office]
   Contact lists, wording, account details: [where; never the passwords themselves]

10. TESTING AND CHANGES
   Last test: [date, what was tested, result]   Next test: [date, owner]
   Changes since last version: [ ]

Two rules hold the plan together. Every critical activity has one owner. And nothing in the plan depends on the thing that's broken: if your contact list lives only in the system that's down, you don't have a contact list.

How to decide what's critical

Section 4 is the heart of the plan, and it's where people get stuck. List the activities that keep you in business, then score each one. Formal planning calls this a business impact analysis. For a small firm it can be an hour round a table.

Start with the work clients pay for, then add what keeps money moving (invoicing, payroll, paying suppliers) and what you're obliged to keep doing by contract or law. Leave out internal tidying, reporting and anything that can wait a fortnight without anyone noticing.

Aim for three to eight critical activities. If everything comes out critical, you've scored the wish and not the harm. Ask what would actually happen on day two.

Recovery times, in plain words

Continuity plans use a few terms that sound more technical than they are. You only need two for each critical activity.

Set the recovery target with some room to spare. If the longest a job can stop is three days, aim for one, because the first day usually goes on working out what's happened.

These terms come from formal business continuity practice, set out in the international standard ISO 22301. A small business doesn't need to follow the standard to borrow its ideas, and we don't suggest certifying against it unless a client asks.

A worked example (typical, made up)

Here's how section 4 might look for a typical 12-person marketing agency. The firm and figures are invented to show the format.

Look at what this table forces. Somebody has to own the printed phone list and keep it current. Someone has to know whether the cloud copy of the files is complete. Those small jobs are what make the plan work, and they're easy to give an owner once they're written down.

Write it in a day

You don't need weeks. A first version written in a day, and tested within a month, is worth more than a perfect plan that's always nearly finished.

Key-person risk: the gap that is easy to miss

In a small business, one of the hardest disruptions to plan for has nothing to do with buildings or servers. It's the one person who knows how payroll works being away without warning, on a plane or gone. If the owner is that person for several things at once, the plan has a single point of failure with a name.

Section 6 of the template exists for this. Go through each critical activity and ask three questions:

1. Who could do this tomorrow if its usual owner couldn't? Name a person, not a role.
2. Is it written down well enough for them to follow? If not, a one-page SOP is enough to start.
3. Can they get in? Logins, bank access, supplier accounts and admin rights are where cover breaks down. Say where access is managed and who holds it, and never write passwords into the plan.

Don't leave the owner out. Banking authority, supplier relationships and approval rights often sit with one person by habit. Fill in the row for the day the owner isn't there, then fix what it shows. Why founders struggle to scale covers how that dependency builds up, and the knowledge only one person holds is what invisible workflows are about.

For roles that need cover for good, not just for a week, a succession plan takes this further. When someone's actually leaving, use a handover document.

Test it before you need it

A plan you've never tried is a set of assumptions. Testing doesn't mean switching anything off. Start small:

• A walk-through (about an hour). Sit the owners of each critical activity round a table, describe a situation ("the office can't open this morning, and the main system is down") and talk through the plan step by step. Note every "we'd have to check".
• A single fallback test. Pick one critical activity and actually run it the fallback way for an hour: issue an invoice from the saved template, or call three clients from the printed list.
• A restore test. Get back one real file from your backup. Until you've restored something, all you know is that the backup runs.

For cyber attacks specifically, the UK's National Cyber Security Centre offers a free, ready-made exercise called Exercise in a Box, and its small organisations guide covers backing up data. Both are aimed at organisations without security specialists.

Write down the date, what you tested, what failed and who's fixing it. Over a year or two, try each critical activity at least once.

Keep it current

Review the plan once a year and after any real disruption. Also update it whenever one of these changes:

• Someone named in the plan leaves or changes role
• You move premises or start working differently (more remote work, say)
• You add or replace a key system or supplier
• A client contract adds promises about how quickly you'll respond or restore service

That last one is easy to miss. If a client contract says you'll restore their service within a set time, your recovery target for that work can't be longer. Read your contracts, and check what your insurer asks for at renewal too. Business Wales notes that insurers may ask to see a continuity plan.

Your plan and your risk register should talk to each other. The register lists what could go wrong and how likely it is. The plan says what you'll do when one of those things happens anyway.

How ready is your plan?