The One-Page Business Continuity Plan (Filled Out, Not Blank)

Most continuity plan templates are a blank grid with headers like "Key Risk" and "Mitigation Strategy," which is exactly the kind of thing that gets bookmarked and never filled in. Below is one actually completed, for a fictional 12-person creative agency called Northfield Studio — adapt the specifics, keep the structure.

Northfield Studio — Business Continuity Plan

Last updated: [Date] · Owner: Priya Chen, Operations Lead · Review cadence: Annually, or after any major change

Risk 1 — Founder (Sam) unavailable, no notice

Likely cause: Medical emergency, family emergency, unexpected travel disruption.

First 24 hours: Priya (Ops Lead) and Marcus (Creative Director) jointly handle any decision that would normally go to Sam. Client-facing communications route through Marcus.

Access needed: Priya has emergency access to the business bank account (read-only) and the shared password vault's "Sam - Critical" folder, reviewed quarterly.

Who to notify: Board/investors (if applicable) within 48 hours if the absence extends past a week. Team notified same-day, framed factually and calmly.

Risk 2 — Priya (Ops Lead) unavailable, no notice

Likely cause: Same as above.

First 24 hours: Marcus takes over payroll approval (process documented in the shared Ops Runbook, section 3). Client billing questions route to Dana (Finance), who has view access to the billing system.

Access needed: Marcus has emergency access to the payroll platform, added [date], tested [date].

Who to notify: Payroll provider, if a payroll run falls during the gap — their support line is in the Ops Runbook.

Risk 3 — Primary project management tool goes down

Likely cause: Vendor outage.

First 24 hours: Fall back to the shared "Continuity Tracker" spreadsheet (linked in Ops Runbook, section 1) for active project status. Client deadlines within 48 hours get a direct check-in call, not an automated update.

Who owns this: Whoever notices first opens the fallback tracker and posts in #general that it's active.

Risk 4 — Office space unavailable (fire, flood, lease issue)

Likely cause: Building issue, natural event.

First 24 hours: Team already has remote-work equipment and access (confirmed working as of last equipment audit, [date]). No client-facing disruption expected if internet and laptops are available within 24 hours.

Access needed: None beyond what's already distributed — this is the lowest-risk item on this plan because the team already works remotely part of the week.

Risk 5 — A single largest client relationship is lost or at risk

Likely cause: Client business change, relationship breakdown, non-renewal.

First actions: Sam and Marcus jointly assess revenue impact within 48 hours using the client concentration figure tracked in the quarterly finance review. If the loss represents more than 15% of revenue, a specific contingency budget review is triggered (see Ops Runbook, section 5).

What makes this version different from a blank template

Named people, not roles in the abstract. "Priya (Ops Lead)" is more useful under real pressure than "the appropriate manager," because there's no ambiguity about who that actually means in the moment.

Specific first actions, not general principles. "Fall back to the shared spreadsheet linked in section 1" is something a stressed, distracted person can actually follow. "Maintain business continuity" is not.

Real access details, reviewed on a stated cadence. A plan that says someone has emergency access, without confirming when that access was last actually tested, risks being wrong exactly when it matters — access that quietly expired or was revoked in a routine security cleanup.

Concrete triggers for escalation ("if the absence extends past a week," "if the loss represents more than 15% of revenue") rather than vague judgment calls made under pressure with no prior guidance.

Adapting this for your own business

Replace the five risks above with your own actual highest-risk scenarios — identified the same way you'd approach any key-person risk assessment: what's the smallest number of disruptions that would cause the most damage. Most small businesses genuinely need three to six scenarios covered, not fifteen — comprehensiveness matters less than making sure the handful of scenarios that are actually plausible and actually damaging are covered specifically.

Where this plan should live, and who should know it exists

A continuity plan that only the person who wrote it knows exists provides much less protection than the same plan shared with the two or three people named in it. It's worth keeping in a location that's accessible even if the primary system referenced in the plan is the thing that's down — a printed copy or an entirely separate storage location, not solely inside the same tool that Risk 3 above assumes might be unavailable.

Testing the plan, not just writing it

A plan that's never been tested carries hidden gaps that only surface during a real disruption — the emergency access that was granted but never actually verified to work, the fallback spreadsheet nobody's opened since it was created, the assumption that a specific person would obviously know what to do that was never actually communicated to them directly. Once a year, picking one scenario from the plan and actually walking through the first steps — logging into the emergency access, opening the fallback tool — catches these gaps while there's time to fix them calmly, rather than during the actual event the plan exists for.

Keeping it short on purpose

The temptation, once the exercise starts, is to keep adding scenarios and detail until the plan becomes comprehensive and, not coincidentally, unreadable under real pressure. A one-page plan covering the four or five most plausible, most damaging scenarios specifically is more useful than a fifteen-page document covering every conceivable disruption in less depth — length is not the same as thoroughness here, and a plan nobody can quickly scan during an actual crisis fails at its one job regardless of how complete it is.

The short version

A continuity plan is genuinely useful when it names specific people, gives concrete first actions, and states clear triggers for escalation — not when it's a comprehensive but abstract risk matrix nobody can act on under real pressure. Starting from a real, filled-out example and adapting the specifics is a far shorter path to an actually-completed plan than starting from a blank template and an intimidating list of headers.