A binder is where continuity plans go to die. A small team does not need forty pages of BCP — it needs one page that names your seven critical functions, the workaround for each, who runs it, and how you know you're back. The test of a real plan is simple: has it ever been opened during an incident? If not, it is a compliance document. This template is that page, built to be executed from memory at 2 a.m.
Full template with worked example: Business Continuity Plan Template — HIVE80lab Ops Notes. The restore half of the story lives in the free Backup & Restore Drill Checklist — your RPO is only real after it passes.
1. The seven-function table
List every function whose loss costs money or trust within a day, cap the list at seven. More than seven means you're listing systems, not functions — "email dies" is a system, "cannot invoice" is a function. Each row gets five columns:
- Function — one line a newcomer understands: "Invoice clients," "Take support tickets."
- How it dies — the realistic failure, not the dramatic one: "Billing SaaS down," not "meteor."
- The workaround — a verb, a tool you actually have, and a number: "Switch support to shared inbox, two people staffed, badge every ticket 'delayed'."
- Who runs it — one name, one backup name. A row without two names fails on the first sick day.
- How we know we're back — the observable that ends the workaround.
That last column does more work than any other: workarounds without an end-condition become the new normal, and the workaround is almost always more expensive than the primary path.
2. RTO and RPO you can actually keep
Two numbers per row — and they must be numbers your tooling can honor. RTO is how long a function may stay down before revenue or promises break. RPO is how much data you can afford to lose, which is really a statement about your backup cadence, not your ambitions. Write the pair only after you have tested what restores: an RPO of "1 hour" is fiction until the restore drill proves your last verified restore point was one hour old. If a row cannot meet its numbers, it earns a decision — pay for better tooling, or accept the risk with a name and a date. Never silence.
3. Workarounds you rehearse, quarterly
Three rehearsals cover the realistic calendar:
- Email down — everyone forwards to the shared-inbox alias; client comms move to the phone tree.
- Building unavailable — the day runs fully remote. Laptops home nightly is the rehearsal.
- Key person unavailable — the named backup runs the person's top function for a morning, from written instructions alone.
Thirty minutes each, once a quarter, findings written as one line under the row. Unrehearsed workarounds are fiction with formatting.
4. Four roles, one line each
Decider (declares and ends continuity mode), Comms (customer and vendor updates on cadence), Restorer (runs recovery and owns the "how we know we're back" observable), Runner (keeps the workaround staffed hour to hour). Roles may repeat across people but never within one — the failure mode to avoid is one person deciding, talking, and restoring, because comms then only happen when the technical work pauses.
5. The comms tree
Three audiences, three senders, one cadence — decided on a calm day. Customers get the status note from one sender only, on a promised cadence ("next update at 3 p.m., even if nothing changed"), with the workaround and the expected shape of the fix — never an unconfirmed root cause. Draft the two templates now: the first-hour note and the close-out note. The close-out becomes the spine of your post-mortem.
6. The 20-minute monthly check
Continuity rots quietly: names change, tools change, the March workaround depends on a shared inbox nobody has opened since. Once a month: read the seven rows aloud, confirm every name, confirm the end-observables for the two riskiest rows, confirm the comms senders are still employed, and check the last restore-drill date is under 90 days. Stale cells get fixed in the meeting or get an owner and a date. Log one line. The point is contact with the plan, not paperwork about the plan.
Worked example: nine-person agency, three-day building outage
A nine-person agency loses its building mid-invoice week. The plan on the wall ran the response: invoicing fell back to the billing SaaS from home laptops — the quarter-two rehearsal had already caught two expired SSO logins, so Monday's switch took eleven minutes instead of a lost morning. Support ran from the shared inbox with a "delayed" badge on every ticket until the queue held under one day for 24 hours — the written end-condition that ended the mode. When the only person who knew the build pipeline was on a flight, the named backup deployed from written instructions, slower, one rollback in nine minutes. Two clients later cited the promised-cadence updates as why they stayed. Total direct cost: about 90 person-hours.
The counterfactual — same outage, no page — is a lost invoice week, support silence that costs two accounts, and a founder running everything badly from a phone.
Five continuity numbers
- Rows rehearsed this quarter (target: 3 of 3)
- Stale cells found in the monthly check (target: 0 carried over; two in a row means the check is done by memory, not by plan)
- Declaration-to-workaround time (target: under 60 minutes for the top three rows)
- Verified restore point age at drill time (target: under your stated RPO — the only backup number that counts)
- Days since last real execution (a plan run in anger and amended within the week is your strongest continuity asset)
The full template — the table, the roles line, the comms tree, and the worked outage — is here: Business Continuity Plan Template. If you'd rather have an outside pair find the gaps and write the plan with you, that's the Small-Team Ops Audit; when any row says "if this fires, we lose the week," the Custom Incident Runbook turns it into a procedure your team can run without you.
Top comments (0)