What Business Continuity Management Actually Is (and Isn't)

The last few posts here were about hardening infrastructure, the redundant power and backup links you build so the box running your business doesn't just die. Fair enough. There's a question none of that work answers, though, and it usually gets buried under three disciplines everyone treats as synonyms: incident response, disaster recovery, and business continuity management. They aren't the same thing. Each runs on a different clock, answers a different question, and comes with people who quietly consider the other two amateurs.

Incident response is the adrenaline layer. Something breaks, pagers go off, and a handful of engineers pile onto a call to start pulling levers. The clock runs in minutes and hours. Success means the root cause gets found and the fix ships; the green dashboard is just the receipt. Ask an incident responder what happens next and you'll usually get a shrug. Once the system is back, the rest is somebody else's paperwork, and they're not wrong. That's genuinely where the job ends.

Disaster recovery starts where the firefight stops working. The system isn't just misbehaving, it's gone, and DR exists to get specific infrastructure and data back: failover to a secondary site, restore from a backup, rebuild a cluster from images nobody tested since last spring. The clock stretches into days. DR people talk in RTOs and RPOs and privately regard incident response as the discipline that solves the easy part and leaves the real restoration work behind.

Business continuity management looks at both of those and asks a question neither one is designed to answer. What does the business do while the system is down? Payroll still has to run, and orders still need shipping, while support tickets keep arriving and the contracts you signed don't pause just because a data center caught fire. BCM's clock runs in days and weeks, sometimes a full quarter, and it treats “this system might not come back for a month” as a planning assumption instead of a nightmare scenario someone else will surely prevent.

Three conferences, one shared condescension

All three fields have professionalized themselves into their own consultants, their own conference circuit, and their own slightly condescending opinion of the other two. Incident response thinks DR is slow bureaucracy. DR thinks incident response is cowboys who never document anything. Both look at BCM people as the ones building spreadsheets about backup office space while real professionals still have root access. That condescension carries the joke, and it also explains why so many companies stay exposed.

Here's the uncomfortable part. A company can run brilliant incident response and airtight disaster recovery, hitting every restoration SLA it has ever promised, and still go under. None of that tells you how the business keeps serving customers and paying salaries if the outage runs three weeks instead of three hours. The failover region might share the same outage. The backup vendor might be down for the same reason you are, and even a clean restoration can take eleven days, longer than plenty of contracts survive in silence. Incident response and disaster recovery are engineering answers to an engineering problem: get the system back. Business continuity is the only one of the three built to keep the business alive whether the system comes back or not.

That distinction sounds obvious in writing and gets ignored anyway, because BCM work is boring in exactly the way firefighting and server rebuilds are not. There's no dashboard turning green. There's a binder, or a wiki page nobody reads until the day they need it, spelling out which customers get called by hand and which slice of revenue simply stops until further notice. Nobody puts that on a highlight reel. That work decides whether there's a company left to write next year's incident report.

So next time someone tells you their DR plan has this covered, ask what happens if DR itself doesn't finish on time. Watch how fast the room gets quiet.