HIVE80lab — Ops notes

Business continuity plan template: the one page that survives the outage

Continuity plans fail the same way audit remediations do: they are written once, they are too big to finish, and nobody can execute them from memory under stress. The fix is the same shape. A small team does not need a 40-page BCP binder — it needs one page that names your seven critical functions, the workaround for each, who runs it, and how you know you are back. Everything else is appendices nobody opens at 2 a.m. This template is that page, with the tables filled in from a real outage. If your outage half is thinner than your paperwork, the Ops Starter Kit supplies the incident procedures that plug straight into rows 6 and 7.

1. The binder is where plans go to die

A binder gets edited by committee, cited by auditors, and abandoned by operators. The tell is simple: if the plan has never been opened during an incident, it is a compliance document, not a continuity plan. Write the one-pager so a tired person can run it — short sentences, named people, no "as appropriate." Keep the risk register, the insurance papers, and the vendor contracts in the appendix; keep what you do in the first hour of a real outage on the sheet of paper (or one PDF screen) the whole team can see. The single-point-of-failure audit tells you what to put in the rows; this page tells you how to run them.

2. The seven-function table

List every function whose loss costs money or trust within a day, and cap the list at seven. More than seven means you are listing systems, not functions — "email dies" is a system, "cannot invoice" is a function. Each row gets five columns:

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.

3. RTO and RPO you can actually keep

Two numbers per row, and they must be ones your tooling can honor. RTO (recovery time objective) is how long a function may be down before revenue or promises break. RPO (recovery point objective) 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 1 hour old. The honest starter set for a ten-person team: invoicing RTO 1 day / RPO 1 day; support RTO 4 hours / RPO none; production data RTO 1 hour / RPO 1 hour. If a row cannot meet its numbers, the row earns a decision (pay for better tooling) or an accepted risk with a name and a date — not silence.

4. Workarounds you rehearse, quarterly

Three workarounds get rehearsed, because they cover the realistic calendar: (1) email down — everyone forwards to the shared inbox alias and client comms move to SMS or the phone tree; (2) office/building unavailable — the team runs the day fully remote, laptops home nightly, which is the real rehearsal; (3) 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 ("SMS tree was missing two numbers — fixed"). Unrehearsed workarounds are fiction with formatting. Fold the key-person rehearsal into the tabletop exercise you already run; the schedule lives in the drill schedule template.

5. Continuity roles, one line

Four roles, four names, one line each — and they may repeat across roles but never inside one: Decider (declares continuity mode and ends it), Comms (sends customer and vendor updates on cadence), Restorer (runs the technical recovery and owns "how we know we're back"), Runner (keeps the workaround staffed hour to hour). Small teams collapse these to two or three people; the failure mode to avoid is the same person deciding, talking, and restoring — the comms then only happens when the technical work pauses, which is exactly when it matters most. If nobody on the team has ever run an outage end-to-end, that is what the Custom Incident Runbook is for: your estate, written as procedures someone else can execute.

6. The comms tree

Three audiences, three senders, one cadence — decided on a calm day: customers get the status note from the Comms role (one sender only; two voices contradict), on a stated cadence ("next update at 4 p.m., even if nothing changed"), with the workaround and the expected shape of the fix — never a root cause you have not confirmed; staff get the phone tree or group message with their row assignments; critical vendors (payment processor, host, landlord, insurance) get a named contact per row. Draft the two templates now, in the calm: the first-hour note ("we are aware, we are working, here is the workaround, next update at X") and the close-out note ("resolved at X, affected Y, what changed"). The post-mortem template reuses the close-out as its timeline spine.

7. The monthly 20-minute check

Continuity rots quietly: names change, tools change, the workaround that worked in March relies on a shared inbox nobody has opened since. Once a month, twenty minutes: read the seven rows aloud; confirm every name still works there; confirm the "how we know we're back" observable for the two riskiest rows; confirm the comms senders are still employed; check the last restore-drill date is under 90 days. Any stale cell gets fixed in the meeting or gets an owner and a date — the check fails silently otherwise. Log the result as one line in the ops journal; the point is contact with the plan, not paperwork about the plan. The maintenance window policy is where tooling changes that touch rows get announced, so the plan stays current without heroics.

8. Worked example: nine-person agency, three-day building outage

A nine-person design/build agency, mid-invoice week, loses its building to a burst pipe: three days, no desks, half the team's chargers left behind. The plan on the wall said exactly what happened next. Invoicing (RTO 1 day) ran from the billing SaaS on laptops from home — nobody had ever logged in from outside the office, but the rehearsal in quarter two found the two expired SSO sessions and fixed the password-manager shares, so Monday's run took eleven minutes instead of a lost morning. Support (RTO 4 hours) fell back to the shared inbox with two people staffed and a "delayed" badge on every ticket; the end-condition observable (queue under one day for 24 straight hours) ended the mode on day two. The key-person row fired for real when the only person who knew the build pipeline was on a flight; the named backup ran deploys from the written instructions, slower, with one wrong deploy rolled back in nine minutes by the drill habit. Client comms went out at the promised cadence from one sender; two clients later cited the updates as why they stayed. Total direct cost: about 90 lost person-hours. The counterfactual is the same outage without the page: a lost invoice week, support silence that costs the two accounts, and a founder doing all of it badly from their phone.

9. Five continuity numbers

Where this fits

The restore half of continuity lives in the backup & restore drill checklist, the rehearsal calendar in the drill schedule template, and the failure patterns they expose in tabletop failure points; the first-hour moves are the First 30 Minutes quick-start. If you would rather have the whole loop — the audit that finds the gaps, the plan that closes them — run by an outside pair, that is the Small-Team Ops Audit; and 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. The Ops Starter Kit covers the incident half of the page; Vol. 2 covers the on-call rotation that inherits it.