Yes. AI is good at interviewing you about what would stop the business, turning your answers into a plan with named owners, recovery times and fallback steps, and testing that plan with realistic scenarios. It cannot know your suppliers, logins or contracts, so you supply those facts and check every contact and step. For a small firm, the finished plan is six to ten pages.
Most small plans fail for two reasons: they are written once and never tested, and they plan for dramatic disasters instead of likely ones, such as the one person who runs payroll being off sick, a stolen laptop or a supplier shutting down. That last one is not hypothetical: the AI calendar tool Clockwise closed on 27 March 2026 and deleted user data rather than transferring it.
The ten sections of a small firm's continuity plan
This template is sized for businesses and charities of roughly 2 to 30 people. Each section below lists what to write, why it matters and how to verify it, because an unverified continuity plan is a list of assumptions. The worked example running through the page is illustrative: a small charity running a befriending service for older people, with three staff (a coordinator and two part-time befriending officers), about 40 volunteers, an office in a community centre and two grants paying most of its costs.
1. Critical activities and how long each can stop
- Write: the five to eight activities that must continue, and for each, the longest it can stop before real harm is done (the "maximum tolerable outage").
- Why: everything else in the plan is ranked by this. Not every activity is urgent; newsletters can wait a month, a welfare call to an isolated client cannot wait a week.
- Verify: ask the person who does each activity what actually happens if it stops for a day, a week and a month. Owners often underestimate how quickly clients notice.
2. Recovery targets and the minimum service level
- Write: for each critical activity, how quickly you aim to restore it and the reduced version you would run in the meantime, such as "welfare calls to the 25 highest-need clients only".
- Why: a minimum service level stops the team trying to do everything and doing nothing well.
- Verify: check that each target is possible with the people and tools you would have left. A four-hour target that depends on the one person who is off sick is not a target.
3. People: cover and what only one person knows
- Write: a deputy for every critical activity, and a list of tasks only one person knows how to do.
- Why: in small organisations, the likeliest disruption is a person being unavailable.
- Verify: ask each deputy to do the task once, with the usual person watching. Capture the steps as you go; writing SOPs with AI turns rough notes into instructions a deputy can follow.
4. Premises and working elsewhere
- Write: where people work if the office is closed, what they need there, and anything physical that cannot move (paper files, a franking machine, stock).
- Why: a closed building is common: a burst pipe, a power cut, the community centre booked out for an emergency.
- Verify: have everyone work from home for a day. The gaps appear by mid-morning.
5. IT, data and account access
- Write: each system you depend on, where its data lives, how it is backed up, who holds admin access and how account recovery works if two-factor codes go to a lost phone.
- Why: losing access to an account is now as disruptive as losing a building.
- Verify: restore one file from backup, and have a second admin log in to each critical system. This backup checklist covers the details.
6. Suppliers and single points of failure
- Write: every supplier whose failure would stop a critical activity, what you would do if they failed and how quickly you could switch.
- Why: small firms rely on a handful of software and service suppliers, and some of those will close, change terms or be bought.
- Verify: for each software supplier, export your data once and check you can open it elsewhere. Record the export steps. AI supplier management covers tracking supplier risk over time.
7. Money: the payments that must still go out
- Write: the payments that cannot be missed (wages, rent, key suppliers), who can authorise them if the usual approver is away, and how many weeks of costs your cash reserve covers.
- Why: many disruptions are really cash disruptions, such as a late grant payment or a large customer failing to pay.
- Verify: check the second bank signatory can log in and approve a payment today. For the cash picture, a 13-week cash flow forecast shows how long the reserve really lasts.
8. Communications: who tells whom
- Write: a contact tree (who calls whom), how you reach clients, volunteers, funders and suppliers, and short message templates for the likeliest scenarios.
- Why: in an incident, silence causes more damage than the incident. Pre-written messages save the worst hour.
- Verify: ring every number in the tree once a quarter. Staff change phones more often than plans change.
9. Scenario playbooks for the likeliest problems
- Write: one page each for your four or five most likely scenarios: first hour, first day, first week.
- Why: a playbook turns the rest of the plan into actions in the right order.
- Verify: a tabletop test, explained below.
10. Testing and review log
- Write: date, what was tested, what failed, what changed, next review date.
- Why: it is the only evidence that the plan still works, and it is what funders and insurers ask about.
- Verify: if the last entry is more than a year old, the plan is out of date.
Let the AI interview you to fill the template
The fastest way to fill the template is to have an AI assistant ask the questions. Use a paid plan or switch off the model-training setting, and describe people by role; you do not need names, phone numbers or account details in the chat. Add those to the final document yourself.
You are helping a small organisation write a business continuity plan using the
ten-section template below. Interview me one question at a time. Start with
section 1 (critical activities) and ask follow-up questions when my answer is vague,
such as "what would happen to clients if this stopped for a week?"
After each section, summarise what you've recorded as a short table and ask me to
confirm it before moving on.
Do not invent suppliers, contacts, systems or timescales. If I don't know something,
record it as [UNKNOWN - owner to find out].
Template: [paste the ten section headings]An illustrative stretch of the interview for the befriending charity:
AI: Which activities would cause harm to clients if they stopped for a week?
Coordinator: Weekly welfare calls, matching volunteers to new clients, and
volunteer rota changes when someone's ill.
AI: If welfare calls stopped for a week, what is the realistic worst case?
Coordinator: Some clients have no other contact. A fall might go unnoticed.
AI: Where does the list of clients due a call live, and who can open it?
Coordinator: In our case database. I'm the only admin. The call rota is a
spreadsheet in my Google account.
AI: Recorded. Flag: the call rota sits in one person's account. Should I add this
to section 3 (what only one person knows) and section 5 (account access)?That last flag is the kind of thing a person writing alone skips past. The AI noticed because the prompt told it to ask where things live and who can reach them. The whole interview took about 90 minutes, spread over two sessions.
The charity's critical activities, filled in
| Activity | Can stop for | Recovery target | Minimum service meanwhile | Owner / deputy |
|---|---|---|---|---|
| Welfare calls | 2 days | Same day | Calls to the 25 highest-need clients, by volunteers from a printed list | Befriending officer A / coordinator |
| Volunteer rota changes | 1 day | Same day | Phone cascade from a printed volunteer list | Coordinator / befriending officer B |
| Safeguarding concerns | None | Immediate | Named safeguarding lead and deputy, reachable by phone | Coordinator / chair of trustees |
| New client matching | 2 weeks | 1 week | Waiting list with a welcome call | Befriending officer B / coordinator |
| Payroll and bills | 1 week | Before pay day | Treasurer approves payments | Coordinator / treasurer |
| Funder reports | 1 month | Before deadline | Ask funder for an extension early | Coordinator / chair |
Filling in the "deputy" column produced the plan's most useful finding: four of six activities depended on the coordinator, and two of them had no deputy who had ever done the task.
Run a tabletop test with the AI as the game master
A tabletop test is a meeting where you talk through a scenario as it unfolds and use the plan to respond. AI is a good game master because it can play out consequences and add complications you would not think to set yourself.
Act as the facilitator for a 30-minute business continuity tabletop exercise.
Here is our plan: [paste plan]. Scenario: [scenario].
Present the situation in stages ("It is 9am Monday..."). At each stage, ask what we
do, then tell us the realistic consequences of our answer, including anything the
plan does not cover. Add one complication halfway through.
At the end, list every gap you saw, ranked by how much harm it could cause.The charity chose "the coordinator is taken to hospital on a Sunday night and will be off for at least three weeks". Illustrative stages the AI presented:
- 9am Monday: the office phone diverts to the coordinator's mobile, which is switched off. Three volunteers are calling in sick for Monday visits.
- 11am: the befriending officer needs Monday's call list. The spreadsheet is in the coordinator's account.
- Complication, 2pm: a volunteer reports a safeguarding concern about a client. The plan names the coordinator as safeguarding lead.
- Thursday: payroll needs approving by Friday.
The test took 35 minutes and found three gaps: the phone divert went to one mobile only, the call list lived in a personal account, and the deputy safeguarding lead was named in the plan but had never been told. None of the fixes cost anything: a hunt group so the office number rings two phones, the rota moved to a shared drive, and a conversation with the chair of trustees. The team noted the fixes in the test log.
Messages to write now, not during the incident
Section 8 is the one people skip, and it is the one that matters most in the first hour. Ask the AI to draft a short message for each audience and each playbook scenario, then edit them into your own voice. The charity's two most-used drafts, lightly edited:
To volunteers (text message): "Hello from the befriending team. Our office is closed today because of [reason]. Please carry on with your planned visits. If you need to cancel or have a concern about a client, ring [deputy's number] rather than the office line. We'll update you by 4pm."
To clients due a call (read out by a volunteer): "Hello, it's [name] from the befriending service. Our usual caller can't ring today, so I'm calling instead to check you're all right. Is there anything you need this week?"
Two details made these worth writing in advance. The volunteer message gives a named number other than the office line, because in most scenarios the office line is the thing that is broken. The client script is short enough for a volunteer who has never met the client to read without sounding like a call centre. Store the messages in the printed plan as well as on the shared drive, and add one for funders: a two-line note that you have had a disruption, what you are doing, and when you will update them. Funders who hear early are usually flexible about deadlines; funders who hear late are not.
A subscription box and a toy shop test their playbooks
The template stays the same; what fills section 9 changes with the business. Two quick illustrations:
- A subscription box company. Its most damaging scenario is its fulfilment partner failing three days before the monthly dispatch. The playbook covers a list of two alternative packers with their lead times, a pre-written customer email ("your box will ship five days late, and here's what we're doing"), and a rule for whether to delay the payment date. Its section 6 also lists the subscription billing app, because if billing stops, cash stops.
- A toy shop. A card terminal and till failure on a December Saturday would cost it a large share of the week's takings. Its playbook is short: switch the till to its offline mode, bring out the spare terminal on a mobile connection, open the cash float, and log manual sales on paper for entry later. The test was simple and useful: the spare terminal had never been charged or set up.
Where AI-written continuity plans go wrong
AI drafts of continuity plans are fluent, and some of their confident details are wrong. Check for these before anyone signs off:
- Invented contacts and suppliers. Plausible-looking phone numbers, a named IT support firm you do not use. The prompt's "do not invent" rule helps; check every contact anyway.
- An IT department that doesn't exist. "The IT team will restore systems from backup" in a firm with no IT team and a backup nobody has ever restored.
- Dramatic scenarios instead of likely ones. Earthquakes and pandemics in, sick coordinators and lost phones out. Ask the AI to rank scenarios by likelihood for a business of your size and type, then choose your own.
- Recovery times picked for how they sound. "All systems restored within 4 hours" is meaningless without a tested restore.
- A plan stored only where the disaster happens. If the plan lives on the shared drive and the shared drive is what failed, you have no plan. Keep a printed copy with two people and an offline copy on a phone.
- Insurance assumed, not checked. The plan says "insurance will cover lost income"; the policy may not include business interruption at all. Read the policy wording, or see what cyber insurers ask about incidents if IT failure is your big risk.
Keep the plan alive with a quarterly half hour
A plan written once is out of date within a year. The charity put three recurring tasks in its calendar:
- Every quarter (30 minutes): ring the contact tree, confirm every deputy is still in post, check backups ran, and check the second admin can still log in.
- Every year (half a day): a tabletop test on a new scenario, a restore test, and a full read-through of the plan with the AI asked: "Which parts of this plan no longer match these changes?", pasting in a list of what changed during the year.
- Whenever something changes: a new key system, a person leaving, a new funder or premises. When someone leaves, the account handover is part of the plan; this offboarding checklist covers shared logins and AI tools.
If a funder or large client asks for formal assurance, the international standard for business continuity management systems is ISO 22301, currently the 2019 edition with a 2024 amendment. Most small organisations will never need certification, but the standard's structure of finding critical activities, planning, testing and reviewing is the same one this template follows.
What the charity's first plan took
For the charity, the first plan took about seven hours in total: 90 minutes of AI interview, two hours writing up and checking contacts, 35 minutes of tabletop test, an hour of fixes and an hour producing a one-page version for volunteers. The AI cost was a chat plan at about $20 a month. The fixes cost almost nothing, which is typical: most small-firm continuity gaps are about who knows what and where things are kept, not about buying equipment. The expensive part of continuity is the disruption you did not plan for.
Continuity planning questions small firms ask
Is a continuity plan the same as a disaster recovery plan?
Not quite. Disaster recovery usually means getting IT systems and data back after an incident. A continuity plan is wider: how the whole business keeps serving customers while something is broken, including people, premises, suppliers, money and communication. For a small firm, the IT recovery steps are simply one section of the continuity plan.
Do funders, clients or insurers ask to see a plan?
Increasingly, yes. Grant funders, larger clients and some insurers ask whether you have a continuity plan and when it was last tested. A short plan with a dated test log answers the question far better than a long one nobody has opened. If a client asks for formal certification, the relevant international standard is ISO 22301.
Should the plan be shared with all staff?
Share a short version with everyone: who to call, where to go, and the first steps for the most likely scenarios. Keep the full plan, which includes supplier contacts and account recovery details, with the people who own each section. Never put passwords in the plan itself; point to the password manager and who can open it.
How often should we test it?
Run a 30 to 45 minute tabletop test at least once a year, choosing a different scenario each time, and a quick check of contacts and access every quarter. Test again after any big change such as a new key system, new premises or a key person leaving. Record every test and what it changed.
Further reads
- How to Write a Health and Safety Policy With AI and What to Check — The safety policy that sits alongside your continuity plan.
- Compliance Calendar: Track Licences, Insurance and Certificates — Put plan reviews and tests on a calendar that reminds you.
- Does Your Business Insurance Cover AI Mistakes? — Check what your insurance covers before you rely on it.
- How to Map a Business Process Before You Automate It — Map critical processes properly before planning their recovery.
- How to Write an AI Policy for a Small Charity — Set rules for AI use in a small charity.
- How to Create SOPs From Screen Recordings With AI — Capture how one person does a task before they're unavailable.
- How to Draft Risk Assessments With AI and What a Human Must Check — Feed AI the real facts of the job, get a structured first draft of hazards and controls, then run the human checks that make it safe to sign and use.
- Opening and Closing Checklists: Build Them With AI in an Hour — Turn a walk-through of your premises into opening and closing checks that staff can follow, record and hand over between shifts.
- How to Summarise Long Documents With AI Without Missing Details — A six-step method for summarising long documents with AI that keeps the numbers, dates and conditions, shown on an 84-page insurance policy.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: ISO 22301:2019 and its 2024 amendment, listings on iso.org; Clockwise shutdown announcement; general business continuity practice for small organisations.