Business continuity plan: what a small company should actually write

A business continuity plan says how the company keeps operating — or gets back to operating — when something significant breaks. Not a strategy document: a list of what matters, how long you can survive without it, and what specifically you would do. The version that gets written to satisfy a customer questionnaire and never read again is worse than nothing, because it creates the belief that the question has been handled.

For a small company the useful plan is short. It is built from one honest exercise: name the handful of activities that generate your revenue or meet your obligations, and work out what each of them depends on.

What the plan has to contain

• Critical activities, ranked. Not everything the company does — the few things whose interruption you would notice within a day.
• Maximum tolerable downtime for each: how long you can be without it before the damage stops being recoverable.
• Dependencies per activity: people, systems, suppliers, premises, data. This is where the real risks appear.
• Scenarios you have actually thought about: loss of a system, loss of premises, loss of a key person, loss of a critical supplier, a cyber incident.
• Who declares an incident and starts the plan, with a deputy — the person named is often the one unreachable.
• Recovery steps per scenario, concrete enough to follow under pressure.
• A contact list that lives outside the systems it covers. A list stored only in the email you cannot reach is the classic failure.
• Communication: what you tell staff, customers and suppliers, who says it, and through what channel.
• A testing schedule, and space to record the result.
• Owner and review date.

The single most common gap is the dependency nobody mapped: one supplier with no alternative, one person who holds the only credentials, one system whose data you have never tested restoring. Finding those three is most of the value of the whole exercise — and you can do it in an afternoon, before writing any document at all.

Building it

1. List what the business must be able to do — usually four to eight activities. Deliver, invoice, pay people, answer customers.
2. For each, ask how long you could survive without it. Answers in hours and days are more useful than a category.
3. Map dependencies honestly, including the ones that are awkward: the founder, the one developer, the single supplier.
4. Pick the scenarios that actually threaten those dependencies rather than a generic list of disasters.
5. For each scenario, write what you would do in the first hour, the first day, and the first week.
6. Fix what you can now instead of documenting it: a second signatory, a tested backup, a named alternative supplier. Mitigation beats a plan describing the problem.
7. Put the contact list somewhere reachable when your systems are not — printed, or on a phone.
8. Test one scenario a year, however briefly. An untested plan is an assumption.
9. Review after any real incident, and annually.

Testing is the part that matters

Most plans fail on contact with reality in the same small ways: the phone number is old, the backup restores but takes three days, the person named has left, nobody can access the document because it lives in the system that is down. A ninety-minute tabletop exercise — walk one scenario through with the people involved, out loud — finds these reliably and costs almost nothing. Do that once a year and the plan is worth more than any amount of additional writing.

In Ettex, the plan lives in Ettex Docs with version history and threaded comments while it is agreed, plus a share link so it is not buried. The dependency and scenario registers — activity, tolerable downtime, dependency, owner, mitigation, last tested — fit Ettex Records as typed tables with saved views and revision history. Contacts belong in Ettex Contacts, exported so a copy exists outside the systems the plan covers, and the testing schedule goes in Ettex Calendar. Where the plan is a customer requirement, it is signed off through Ettex Signature.

Plainly: Ettex is not a continuity or resilience product. There is no incident management, no alerting or paging, no dependency mapping, no automated failover, and using Ettex does not make you compliant with any continuity standard. It is a document, a register and a calendar — and an offline copy of the contact list is your responsibility, not a feature. It shares its trigger with the incident response plan, and the two should name the same people.

Why plans fail

• Written for a customer questionnaire, never for use.
• Everything listed as critical, so nothing is prioritised.
• Dependencies mapped for systems but not for people and suppliers.
• Contact list stored only inside the systems the plan is meant to survive.
• Recovery steps written as intentions — "restore from backup" — without anyone having tested how long that takes.
• No named person to declare an incident, so the first hour is spent deciding who decides.
• Never tested, so the first test is the real event.
• Not reviewed after an incident, discarding the only genuine information you will ever get.

Continuity is the wider question: how the business keeps operating. The disaster recovery plan is the narrower technical half — which systems come back, in what order, and to what point in time. A continuity plan that assumes systems will simply be restored, without the second document existing, is a statement of hope.

The plan needs two inputs it cannot generate itself. A business impact analysis produces the recovery order — without it the plan lists everything and prioritises nothing — and the disaster recovery plan covers the technical half: which systems come back, in what order, to what point in time.

Two inputs the plan cannot generate itself. A business impact analysis produces the recovery order, and an escalation matrix names who is woken and when — a plan without either lists everything and prioritises nothing.

A business continuity plan is worth what its dependency list and its testing are worth. Name the critical few, find the single points of failure, fix what you can, keep the contacts reachable offline — and walk one scenario a year.