River
Y CombinatorBacked by Y Combinator
FREE TEMPLATE

Business Continuity Plan Template

Five documents and five sheets built around what is unavailable rather than what went wrong, with every recovery target traced to a deadline somebody else set.

Free download  ·  No account needed

Critical Process Register

Bellhaven Logistics, 180 staff, two warehouses

Organising axisUnavailability class, not scenario
Dependencies mapped14, of which 6 are single points of failure
Open gaps4, one with no date because the decision is unmade

Where each hour figure comes from

ProcessDeadline it feedsWorst momentToleranceTargetVerdict
Carrier tenderingTender cutoff 15:00, a miss rolls the load14:40 weekdays20 min15 minMet
PayrollBank cutoff, 3 working days out16:00 on the 24th90 min60 minMet
Wave release and pickingSame-day dispatch, orders before 13:0011:00 Friday2 h90 minUnmeasured
Customs entry filingFiled before the vessel dischargesFiler absent4 h4 hGap
Month-end billingCustomer portal closes, 5th working day12:00 on the 5th3 h2 hMet
Proof of deliveryUnposted PODs cannot be billed at all4th working day8 h4 hUntested
Stock accuracy reportNo hard external deadlineMonth end72 h72 hMet

The two columns no other template has

Deadline it feeds is where the tolerance comes from, so the number is checkable against a contract instead of trusted. Worst moment is why payroll has ninety minutes rather than three weeks.

Stock accuracy earns a row precisely because it has no hard deadline. Seventy-two hours of slack, written down, is the process not to spend money protecting.

Every template in this genre makes you pick disasters. Flood, fire, ransomware, supplier failure, pandemic, key-person loss, and the same content written once per scenario with a hole wherever imagination ran out. There are only four classes of unavailability: a system, a site, a person, a supplier. Ransomware, a billing dispute and a data centre fire all ask the same question about your warehouse system, and it has the same answer in all three cases. Four columns, no hole.

Then the recovery target, which every template asks you to assign and none of them tells you where to get. It is downstream of a tolerance, and NIST says so directly: because the objective must ensure the tolerable downtime is not exceeded, it must normally be shorter than it. The tolerance is the interval to the first hard external deadline the process feeds. A carrier cutoff at three, a bank submission window, a portal that closes on the fifth working day.

And tolerance depends on when the outage starts, which nothing else in this genre carries. Payroll has three weeks of slack on the fifth and ninety minutes at four o'clock on the twenty-fourth. Every row carries the worst moment instead of the average one. Send River the system inventory and the org chart, or take the documents and CSV sheets blank, beside the procedures the plan depends on existing and the audit that ranks what only one person knows.

Fourteen dependencies, six single points, four honest gaps

Criticality is a property of dependencies rather than of processes, so the map is built before the register and not after it.

Single Point of Failure Map

Illustrative rows for a fictional third-party logistics business, Bellhaven Logistics. One row per dependency, never per process.

DependencyClassAlternatesHas performed itVerdictGap closes
Warehouse management systemSystem0n/aSingle point14 Dec
EDI mapping for the 4 largest customersPerson0n/aSingle point14 Dec
Customs entry filingPerson1No, not in 3 yearsSingle point31 Jan
Tilbury site powerSite0n/aSingle pointno date set
Temperature logger platformSupplier1NoAlternate untested20 Dec
ACH payment file submissionPerson1YesPair requiredclosed
Yard slot booking systemSystem1YesAlternate provenclosed
Night shift supervisor, WakefieldPerson2Yes, both this yearCoveredclosed

The customs filer is the row that justifies two columns instead of one. A second person holds the certificate, so an alternate count alone shows this dependency as covered. They have not filed an entry in three years, which is a credential rather than a competence, and only one of those two things files correctly under time pressure.

The EDI mapping came out of the map, not out of an interview. Nothing in an org chart records that exactly one person can read the orders from your four largest customers. A system with one operator is a countable fact, available from an admin export without asking anybody.

Tilbury site power carries no date. The capital decision has not been made, and writing a plausible date there would make every real date on the sheet unverifiable.

Degraded Mode Playbook

Not how to restore the system. What the business does while it is still down.

ProcessWhat runs insteadHolds forWhat accumulatesRehearsed
Carrier tenderingEmail tenders against the standing rate cardIndefinitelyNothing, the email tender is equivalent4 Nov
Goods receiptWhiteboard slot board at the gateTwo daysBooking history and detention evidence18 Sep
Month-end billingBill from the warehouse extract directlyOne cycleLedger postings, credit control notes6 Oct
Wave release and pickingPrinted pick list from the last stock extractOne shiftStock movements, paper confirmationsnever
Proof of deliveryPaper POD signed and photographedOne weekUnposted PODs, so nothing can be billednever
Temperature recordsHourly manual readings signed at the bayWhile staffing allowsNothing if the round is keptnever
Chilled handlingNo degraded mode existsn/aRefused loads, customer notificationsnever
EDI order intakeNo degraded mode existsn/aEvery order received during the outagenever

Holds for is the column that gets left out and it is usually the most important thing on the row. Picking from a printed list works for exactly one shift, because after that the stock extract is too stale to pick against safely. A playbook without that column reads as though the workaround is a substitute.

Two rows say no degraded mode exists, and that is the honest answer. Inventing a workaround for the chilled bay would make the plan read as complete while the site refuses loads at the gate. Both rows appear again in the gap list, which is the pattern to expect.

Carrier tendering degrades cleanly because the workaround was the real process until 2023. An older process the company already ran is the strongest evidence a fallback works.

Exercise Log

One dependency made unavailable, against the clock. Never a simulated disaster.

DateMade unavailableTold in advanceTargetActualWhat broke that nobody predicted
4 NovCarrier tendering portalNo15 min10 min2 of 11 carriers reject email tenders
6 OctFinance systemYes2 h90 minNobody in finance held a warehouse licence seat
18 SepYard slot booking systemYes60 min30 minThe whiteboard was locked in an absent office
12 AugThe certified customs filerNo4 h3 h 40The broker retainer had lapsed in March
22 JulOne ACH signatoryYes60 min45 minThe emergency mandate needs renewing after use
19 FebWarehouse management systemYes90 minAborted at 4 hThe last stock extract was 31 hours old
not yetTilbury site powern/a2 hNever testedCannot be exercised without a generator
not yetEDI mappingn/a45 minNever testedCannot be exercised until the maps are written

The February abort is the most useful row here. It failed not because the system was slow to come back, but because the degraded mode needed a stock position and the newest one was thirty-one hours old. The workaround was documented, approved, and unusable, and no amount of reading the plan would have found that.

The last column is the actual output. The measured duration confirms a number you already had. What broke that nobody predicted tells you something you did not know, and it is never in the step the plan describes: a locked office, a lapsed retainer, a missing licence seat.

Five of the six completed exercises were unannounced. An announced exercise measures the plan; an unannounced one measures whether anybody can find it.

Contact Tree

Every row carries a channel that works with no company system running.

RoleOut-of-band channelInside the companyAuthorityVerified
Declare a disruptionPersonal mobile, printed card at both gatesYesActivates the plan, authorises spend to 250003 Nov
Deputy declaring authorityPersonal mobile on the printed cardYesSame authority after 30 minutes unreachable3 Nov
Second contact outside the companyRetained broker out-of-hours numberNoFiles customs entries under their own certificate14 Oct
Warehouse system vendorEscalation number and account number on the cardNoNone, escalation only14 Oct
Staff notificationSMS list exported monthly to both gate PCsYesNone, receive only3 Nov
Customer notificationMobile numbers in the printed customer packYesCommits a revised dispatch time3 Nov
Bank relationship managerBranch switchboard on the cardNoConfirms whether a submitted file clearedunverified
Chilled bay escalationSite engineer's personal mobile on the cardPartlyRefuses or diverts loads at the gateunverified

The vendor account number is on a printed card for one reason. It is stored inside the system you need to call about, which is the most common way an emergency contact list fails: everything on it is correct and none of it is reachable.

Staff and customer notification are two trees, not one directory. They fail differently. Staff email and internal chat usually go down together, so the fallback is a phone list exported on a schedule, because a stale list is indistinguishable from no list at all.

Verified is a date on which the out-of-band channel was actually used. Two rows say unverified, which is a number nobody has dialled rather than a number nobody has checked.

What's in the pack

01

Single Point of Failure Map

One row per dependency across all four unavailability classes, with qualified alternates counted and a separate column for whether the alternate has actually performed the work. Those two disagree constantly, and the disagreement is the finding worth having.

02

Critical Process Register

The deadline each process feeds, the worst moment in the week, the tolerance measured from there, the target set inside it, and the honest estimate of recovery today. Four verdicts rather than two, because Unmeasured ranks below Gap.

03

Degraded Mode Playbook

What the business does while the thing is still down, which is a different document from how to restore it. Each row carries how long the workaround holds, what accumulates while it runs, and what has to be reconciled afterwards.

04

Contact Tree

An out-of-band channel on every row, staff and customer notification kept as separate trees, decision authority recorded next to reachability, and at least one branch that reaches somebody outside the company entirely.

05

Exercise Log

One dependency made unavailable against the clock, never a simulated disaster. The column that matters most records what broke that nobody predicted, which is never in the step the plan describes.

06

Where Recovery Targets Come From

The reference behind every hour figure. It keeps the tolerance and target vocabulary straight, lists the seven kinds of hard external deadline worth hunting for, and explains why the same process has two tolerances. Plus what to do when the estimate is worse than the target.

07

Continuity Standard and Continuity Plan

Four rules on one page, plus a filled plan for a fictional logistics business so the format is arguable against something real. It carries four open gaps, one of them with no date at all because the decision has not been made.

08

Key Person Risk Note and Recovery Runbook

The class that actually happens, since most companies see more resignations in three years than system outages, written up with its three failure modes separated. A resignation is this class with notice attached, which is where the handover itself picks it up.

How to use it

  1. 1

    Open in River, or take it blank

    Install the pack in River and hand it your inventory, or download the five documents and five CSV sheets and work them yourself.

  2. 2

    Send the inventory and org chart

    A list of the tools you pay for and who does what. An export of who holds administrator rights is the single best evidence of where work concentrates.

  3. 3

    Answer the deadline question

    For each critical process, the first hard external cutoff it feeds. You are looking that up in a contract or a tariff rather than deciding it.

  4. 4

    Exercise one dependency

    Make one thing unavailable for two hours and run the workaround against the clock. Record what broke that nobody predicted, because something always does.

Frequently asked questions

Is this free, and what do I get?

Free, and there is no signup gate on the download. Five documents and five spreadsheets. The AI half is optional: send a system inventory and an org chart, and River maps the dependencies, finds the ones with a single person or account behind them, and works out what stops. More in the template library.

Why not organise the plan by disaster scenario?

Because it makes you write the same thing repeatedly and still misses whatever you failed to imagine. A vendor outage, a ransomware event and a billing dispute all take the same system away, so they all get the same answer. Four unavailability classes cover every scenario anybody names and the ones nobody does.

Where does the recovery time objective actually come from?

The first hard external deadline the process feeds. A carrier tender cutoff at three in the afternoon, a bank submission window three working days out, a customer portal that stops accepting invoices on the fifth working day. Those are written in contracts and tariffs already, so the tolerance is checkable rather than negotiated.

What if we cannot meet the target we derived?

Write the gap down with an owner and a date. Do not loosen the target until the two agree, which is how these documents become fiction and leaves no trace on the page. NIST prescribes the honest version: document the situation and plan its mitigation when the tolerance is inflexible.

What is a degraded mode playbook, and why is it separate?

Restoring the system ends the outage; degraded mode is what the business does during it, and where the system is vendor hosted the restore is not yours anyway. The health information security rules make an emergency mode operation plan required while leaving the criticality analysis merely addressable.

Does the contact list really need somebody outside the company?

Yes, and a regulator wrote it down. FINRA requires two emergency contacts, and a firm with only one associated person must name a second from outside the firm entirely: their attorney, accountant or clearing contact. A tree that only reaches inside has no branch surviving the company being unreachable.

How do we test this without running a full disaster exercise?

Make one thing unavailable and run the workaround against the clock. Two hours, one dependency, unannounced where it is safe. Every exercise in the log found something nobody predicted, and it was never in the step the plan described: a locked whiteboard, a lapsed retainer, a stock extract thirty-one hours old.

Stop picking disasters

Take the documents and CSV sheets blank, or install this pack in River and send it a system inventory and an org chart.

Edit with AI