9 Business Continuity Tips That Don't Suck

Most business continuity plans are a binder. A binder nobody has opened since the last audit. When something actually goes wrong — a ransomware event, an AWS region outage, a fiber cut, a key employee resigning in the middle of a project — the binder doesn't help. What helps is a small number of things you already did, on purpose, before the event. Here are nine.

1. Map Your Dependencies for Real

Not the dependencies you think you have. The ones you actually have. The typical failure mode: "our ERP is critical" — but nobody noticed that the ERP depends on an on-prem AD controller that depends on a DHCP server that depends on a switch in a closet nobody has touched in four years.

What we do: Pick the top five business processes. For each one, walk the dependency chain all the way down to physical infrastructure. Every hop is a single point of failure until proven otherwise. Write it down. Update it annually.

2. Write Runbooks the Way You'd Call a Friend

A runbook that reads like a legal document won't get followed at 3am. A runbook that starts with "1. Log into jump.company.com. 2. If you don't have access, call the on-call SRE at..." gets followed.

Short sentences. Concrete commands. Screenshots if the UI is unusual. A "what to do if this step fails" for each step. Store them somewhere you can get to without the thing that's broken — meaning not in Confluence on the internal network.

3. Have a Communications Plan That Doesn't Depend on Internal Email

During a ransomware event, your email is probably down. Or compromised. Or both. You need a pre-agreed channel that runs outside your production infrastructure.

Options we recommend: A Signal group for the incident response team, with every member's personal cell number. An out-of-band status page (Statuspage.io, Incident.io, or a simple static site on Cloudflare Pages). A printed phone tree for senior leadership. Yes, printed. Test it every six months.

4. Know Who Can Approve What in an Emergency

When the incident commander says "we need to restore from yesterday's backup, which will lose eight hours of transactions, yes or no," who answers? Is it the CTO? The CEO? A committee? If the answer isn't obvious, find out now, not during the incident.

Write down the decision authority for: data loss thresholds, external communication, regulatory notification, vendor engagement, and extended downtime. Get sign-off from the actual decision-makers, not their proxies.

5. Pre-Stage the Relationships You'll Need

During an active incident you will need: your cyber insurance carrier, an incident response firm, your outside counsel, your primary cloud account manager, and possibly the FBI (IC3 or a local field office). Call all of them when everything is fine. Get contact information. Know what your insurance actually covers before you need to file.

The difference between calling "my guy at Mandiant" and calling Mandiant's 800 number during a live incident is hours. Hours matter.

6. Test Your Backups by Restoring From Them

Not by running the verify flag. By restoring. To a scratch environment. Full stack. Monthly.

We see this fail constantly. Backups that claim to be fine turn out to have been silently failing for weeks. Databases that restore but won't start because a dependent file wasn't in the backup set. Tapes that can't be read because nobody remembered where the decryption key lives.

The first time you test a backup should not be the first time you need it.

7. Run Tabletop Exercises Twice a Year

Pick a scenario. Walk through it with the team as if it were real. No laptops. No tools. Just talking through the decisions.

Good scenarios: "the finance department receives a ransomware note Monday morning," "our primary cloud region is unreachable and the vendor is silent," "an employee in procurement is caught sending sensitive documents to a personal email the day they resign." Each one exposes a different gap.

Tabletops find problems that real incidents find too — only without the pressure and the cost. We've never run one that didn't surface at least one actionable improvement.

8. Document the Exit Plan for Every Critical Vendor

For every SaaS vendor in your stack, write down: how you export your data, how long the export takes, what format it comes in, and what the realistic cost and timeline would be to move to an alternative. Do it now, while you're not angry.

You will not use this plan often. Once or twice per decade. But when a vendor triples their price or gets acquired or has a security incident that destroys your trust, having already thought through the exit saves weeks.

9. Practice the Boring Failure Modes

Tabletop scenarios tend to focus on dramatic events (ransomware, fires). The real BC events we see most often are boring: a key employee leaves unexpectedly, a critical SaaS vendor has a multi-day outage, a contract expires without renewal and a system stops working at midnight.

Make sure your plan covers:

• What happens when the one person who knows how the payroll integration works goes on three weeks of PTO and becomes unreachable?
• What happens when your credit card processor has a four-hour outage during Black Friday?
• What happens when a SaaS contract auto-renews for three more years because nobody read the email?

These are the things that hit small and mid-sized organizations most often. They are also the easiest to prevent with process.

What We'd Actually Do

For an organization with no BC program today, the first 90 days:

1. Week 1-2: Inventory critical business processes and their top dependencies. Write them down. Five to ten processes is enough.
2. Week 3-4: Establish an incident communication channel outside production infrastructure. Signal group. Printed phone tree.
3. Week 5-8: Write runbooks for the top five incident types: ransomware, cloud outage, key employee loss, data breach, site unavailable. Short, concrete, readable.
4. Week 9-12: Run the first tabletop exercise. Fix whatever it exposes. Schedule the next one for six months out.

This is 90 days of part-time work that will serve you better than a $50,000 consultant-produced binder you never open.

Three Takeaways

1. Dependencies are the thing you don't know you have. Map them down to physical before you call anything continuity-ready.
2. Tabletops and restore drills are the only tests that matter. Everything else is paperwork.
3. Your comms plan must work without your production infrastructure. If it runs on the thing that might be broken, it's not a plan.