In short
Skip the disaster plan and prepare for the interruptions that actually occur: a tool being unavailable, a key person unreachable, a supplier failing, or data being lost. For each of the three or four things that would genuinely stop you, write down how the work gets done manually, who decides to switch, and how clients are told. One page per dependency is enough. A plan short enough to be found and read during an outage beats a thorough one that nobody opens.
Key takeaways
- Plan for outages, not disasters. The common events are unglamorous and far more likely.
- Identify what would stop delivery. Usually three or four dependencies, not twenty.
- Write the manual fallback down. During an outage nobody has time to work it out.
- Name who decides to switch to the fallback, or the decision waits for someone unavailable.
- Test the restore, not the backup. Untested backups fail at exactly the wrong moment.
Most continuity plans prepare for the wrong thing
Business continuity planning has an image problem. The term suggests fire, flood and catastrophe, so small businesses either produce a document about evacuation routes, or reasonably conclude that the whole subject is for organisations with more to lose.
Meanwhile the events that actually interrupt small businesses are mundane and frequent:
- A tool everyone depends on is unavailable for most of a working day.
- The one person who runs a critical process is suddenly unreachable.
- A subcontractor misses a delivery you had committed to a client.
- A file, folder or dataset is deleted or corrupted, and the backup turns out not to cover it.
- A payment provider or bank blocks an account for a week during a review.
None of these is a disaster. All of them can stop delivery for a day or more, and each has occurred to businesses of every size in the last year. A plan for these is short, cheap, and gets used, which is more than can be said for the version about floods.
Prepare for the Tuesday when the tool is down, not for the fire. The Tuesday will happen, probably this year.
Find what would actually stop you
Start with a list of dependencies and a single question: if this were unavailable for a day, what would stop?
| Dependency | Question to ask |
|---|---|
| Systems and tools | Which one, if unavailable, would halt delivery rather than inconvenience it? |
| People | Who, if unreachable for a week, would stop work? This is your key person list |
| Suppliers and subcontractors | Which have no alternative you could reach this week? |
| Data | What would be genuinely unrecoverable if it were lost tomorrow? |
| Money | How long could you operate if incoming payments stopped for a month? |
Most small businesses find three or four dependencies that genuinely qualify, and a longer list of things that would be irritating but survivable. Sorting one from the other is the useful part, because it makes the planning finite. A plan covering twenty dependencies will not be written; a plan covering four will.
Sort the qualifying items by how quickly the pain arrives. Something that stops delivery within two hours needs a different level of preparation from something that becomes a problem after a fortnight.
Write the manual fallback
For each dependency that matters, document how the work continues without it. This is the core of the plan and the part that gets skipped, because during normal operation it feels hypothetical.
The fallback matters most for automated processes, and the reason is uncomfortable. Automating a process removes the need to know how it was done by hand, so within a couple of years the knowledge has gone: the people who did it manually have moved on, and nobody currently employed has ever performed the steps. This is a known cost of automation, which is why a documented manual fallback belongs in the automation project itself, as noted in automation maturity.
A workable fallback page contains four things:
- How to do it by hand, step by step, at the level of detail someone unfamiliar could follow.
- What breaks or is degraded while running this way, so expectations are set internally.
- What has to be reconciled afterwards, because manual work during an outage usually creates a data catch-up.
- What the fallback depends on, which must not be the thing that is down. A procedure stored only in the system that failed is not a fallback.
Page per critical dependency. Anything longer will not be read by a stressed person on the day, and a plan that is not read on the day has no function.
Who decides, and how clients are told
Two elements make the difference between a plan and a document, and both are about people rather than procedure.
Who decides to switch. Outages create a period of waiting: the tool might come back in ten minutes, so nobody wants to start the disruptive manual process. That wait routinely consumes half a day. Naming one person who can call it, with a stated trigger such as two hours of downtime or an unknown recovery estimate, converts a drifting judgement into a decision. Without it, the decision waits for whoever is most senior, who may be exactly the person unreachable.
How clients are told. Drafted in advance, when nobody is panicking. Who contacts them, what is said, and what is not. The principle is the same as complaint handling: silence during an interruption does more damage than the interruption, and clients who are told early are consistently more tolerant than clients who discover it themselves. The sequence in a complaint process that protects the relationship applies almost unchanged.
Backups: test the restore
Most businesses have backups. Considerably fewer have restores, and the difference only becomes apparent at the moment it matters most.
Four checks, twice a year:
- Restore something real to a separate location, and confirm it opens and is complete. This is the whole test. A backup job reporting success proves that a job ran, not that data is recoverable.
- Check the coverage. Cloud tools are frequently assumed to be backed up and frequently are not, beyond a limited deletion window. Personal drives and local files are almost never included.
- Check the retention period against how long problems take to notice. A corruption discovered after ninety days is not helped by a thirty-day retention.
- Confirm someone other than one person can perform the restore, and that they have the access to do it. A recovery process that depends on credentials only one person holds is a single point of failure inside your single-point-of-failure plan.
That last point connects directly to access management: recovery access is exactly the kind that gets held by one person and never reviewed.
Keeping it short enough to use
The failure mode of continuity planning is thoroughness. A forty-page document is written once, filed, never updated, and not opened during the incident it was written for, because nobody can find the relevant section while a client is waiting.
Four rules keep it usable:
| Rule | Reason |
|---|---|
| One page per dependency, no preamble | Readable in five minutes under pressure |
| Stored somewhere reachable when systems are down | A plan inside the failed system is not a plan. Printed, or on a phone, or in a separate service |
| Reviewed twice a year and after any real incident | Dependencies change faster than plans do |
| Rehearsed once, cheaply | Thirty minutes talking through a scenario finds the gaps a document review misses |
The rehearsal is the highest-value half hour in the whole exercise. Talking through a plausible scenario out loud, with the people who would be involved, reliably surfaces two or three assumptions that do not hold: a credential nobody else has, a client contact that lives in one inbox, a fallback that depends on the system that is down.
None of this requires a formal programme. It requires knowing which three or four things would stop you, writing a page on each, and testing the restore. The Mayim Ops assessment scores resilience alongside documentation and systems, because continuity is mostly a documentation question with a deadline attached.
Frequently asked questions
What should a small business continuity plan include?
For each dependency that would stop delivery: how the work continues manually, who decides to switch to that method, how clients are informed, and how you return to normal afterwards. One page per dependency, covering the three or four that matter, is more useful than a comprehensive document.
What is a manual fallback?
A documented way of performing a process by hand when the system that normally does it is unavailable. It matters most for automated processes, because automation removes the knowledge of how the work was done before, and the people who remember eventually leave.
How often should you test backups?
Test the restore, not the backup, at least twice a year. A backup that runs successfully but cannot be restored is common and is discovered at the worst possible moment. Restore something real to a separate location and check it opens and is complete.
What are the most likely business interruptions?
A critical tool or service being unavailable for hours, a key person suddenly unreachable, a supplier or subcontractor failing to deliver, and loss or corruption of data. These are far more likely than the catastrophic events continuity plans traditionally address, and they are the ones worth preparing for.
How long should a continuity plan be?
One page per dependency. Long plans are not read during an incident, which is the only time they are needed. If it cannot be found and understood by a stressed person in five minutes, it does not function as a plan.