A business continuity plan is a written answer to one question: if the person or system holding your business together disappears tomorrow, what happens next? Most founders answer that question once, save the document, and never look at it again. That is not continuity planning. That is continuity theater.
Key takeaways
- A continuity plan that lives in a folder and never gets tested is a document, not a system — the only version that counts is the one you've rehearsed and revised.
- Decision rights matter more than task lists: if no one is named as the fallback decision-maker, the plan fails at exactly the moment it's needed.
- Over-documenting low-risk functions while leaving your top single points of failure unquantified is the most common way founders feel prepared and stay exposed.
- You cannot prioritize continuity work until you know what each gap costs you per year, which is why the fix starts with a cost calculation, not a template.
The five mistakes below are the ones founders make most often. Each one comes with the fix, and each fix runs through the same starting point: quantifying the gap before you write another word of documentation.
Mistake 1: Treating the plan as a one-time document
The plan gets written after a scare — a hospital stay, a key employee quitting, a supplier going dark — and then it gets filed. Six months later the org chart has changed, the tools have changed, and the plan describes a company that no longer exists.
The fix: Give the plan a review cadence tied to something that already happens. Quarterly, alongside a financial review, is enough. Add one rule: any time a role changes hands or a tool is replaced, the plan gets a one-line amendment the same week. A plan that is edited four times a year stays true. A plan that is edited once is a historical artifact.
Mistake 2: Ignoring decision rights
Most continuity plans list tasks: who invoices, who ships, who answers support. Very few name who decides. In a real disruption, tasks are the easy part — the paralysis happens when someone has to choose between refunding a customer, delaying a launch, or spending money they weren't authorized to spend.
The fix: For each of your three most critical functions, write one sentence: "If I am unavailable, [name] may decide [specific category of decision] up to [a limit you define]." That sentence is worth more than three pages of process notes. If you cannot name the person, that is the gap — not the missing process documentation.
Mistake 3: Failing to test it
Untested plans fail in predictable ways. The backup contact turns out to be wrong. The password is in the founder's head. The one person who knows the vendor portal login is on vacation with the founder's spouse. You discover all of this during the emergency instead of before it.
The fix: Run a tabletop test — a ninety-minute conversation where you walk through a specific scenario and ask, for each step, "who does this, and do they have access right now?" You are not looking for perfection. You are looking for the three places where the answer is "I'd have to figure it out." Those three places are your real plan.
Mistake 4: Over-documenting low-risk functions
Founders tend to document what is easy to document. Social media posting gets a full SOP. The single supplier who represents your entire inventory pipeline gets a paragraph. Effort flows toward what feels productive, not toward what is fragile.
The fix: Rank your functions by consequence, not by complexity. Ask of each one: "If this stopped for two weeks, would revenue stop too?" Everything that fails that test gets a note. Everything that passes gets a full procedure. Most founders find their documentation effort is inverted.
Mistake 5: Never quantifying the cost of the gap
This is the expensive one. A plan can be complete on paper and still leave you exposed, because "we have a plan" and "we know what a failure costs" are different statements.
Consider a founder who did everything the templates asked. The plan was written, the roles were named, the passwords were stored. Then they got sick for six weeks. The business lost a meaningful amount of revenue anyway, because the plan had never identified that three functions — the founder's sales calls, the founder's approval of pricing exceptions, and the founder's relationship with the largest account — were single points of failure with no fallback. The document said "founder handles sales." It never said what happens when the founder cannot.
The lesson is not that the plan was badly written. It is that the plan was never priced.
The quick-reference audit
| Situation | What to do | Why it matters |
|---|---|---|
| Plan hasn't been opened in six months | Set a quarterly review and amend on every role or tool change | A stale plan describes a company you no longer run |
| Roles are named but decision-makers aren't | Write one decision-rights sentence per critical function | Paralysis costs more than missing process docs |
| Plan has never been rehearsed | Run a ninety-minute tabletop scenario test | You find the broken contact before the emergency does |
| Documentation is heaviest on low-risk work | Re-rank functions by revenue consequence, then document | Effort should follow fragility, not familiarity |
| You don't know what a gap costs | Calculate the annual cost of each gap before prioritizing | Unpriced risk can't be sequenced or justified |
Where to start: price the gap first
The reason most continuity plans stall is that everything looks equally urgent, so nothing gets prioritized. The way out is to attach a number to each gap — annualized — and then work the list from the top.
That is exactly what the free RADAR bottleneck cost calculator at https://tools.exiuss.com/radar is built for. You enter six inputs about how your week actually runs, and it breaks out the annual cost of manual work, urgent problems, decision bottlenecks, missed revenue, and tools you pay for and don't use — your Chaos Tax. Run it once with your continuity gaps in mind and you'll see which single point of failure is actually costing you the most per year, rather than the one that feels scariest.
The paid diagnosis takes it further: it names your chaos archetype, places you on a sovereignty maturity scale, and returns a thirty-day recovery plan tagged Systemize, Delegate, Automate, or Eliminate — which maps cleanly onto continuity work. Systemize is your documentation. Delegate is your decision rights. Automate is your failover. Eliminate is the low-risk function you should stop documenting because you should stop doing it.
Turning a static plan into a living system in 30 days
- Days 1–5: Run the RADAR calculator. Write down the top three costs it surfaces and mark which ones are continuity gaps rather than general inefficiency.
- Days 6–10: For each of your three most critical functions, write the decision-rights sentence. If you can't name a person, that function is your first single point of failure.
- Days 11–15: Run one tabletop test on the most expensive gap. Note every "I'd have to figure it out" moment.
- Days 16–22: Fix access. Passwords stored, vendor logins shared properly, backup contacts verified by actually contacting them.
- Days 23–27: Strip documentation from one low-risk function and reinvest that time in the highest-cost gap on your list.
- Days 28–30: Schedule the next review. Put it on the calendar with a name attached. Then re-run the calculator quarterly to see whether your Chaos Tax is falling.
The Chaos Tax stops today — but only if you stop treating continuity as a document and start treating it as a number you are actively reducing.
Quick checklist
- Run the free RADAR calculator and write down your three largest annual costs
- Mark which of those three are continuity gaps rather than general inefficiency
- Write one decision-rights sentence for each critical function
- Run a ninety-minute tabletop test on your most expensive gap
- Verify every backup contact and access credential actually works
- Put the next quarterly review on the calendar with a named owner