Building a Business Impact Analysis From Scratch: Nobody's Job Is as Critical as They Think

Every October, somebody decides it's time to write a Business Continuity Management plan, and the work starts in the wrong place: a backup generator, maybe a phone tree. All reasonable purchases. None of them tell you what you're protecting.

That's what a Business Impact Analysis is for. Strip away the acronym and it's a deceptively simple question asked systematically, over and over, across every function the business runs: if this stopped right now, how fast would it hurt, and how much? You look at each process and price an hour of its absence, in currency, not vibes. Then you map what it depends on to keep running at all. What comes out the other end is a ranked list. What goes in is usually a room full of people who already know the answer, and it's always their own department.

Everyone's Job Is the Most Critical Job

Ask the finance lead which process matters most and you'll hear about the general ledger close. Ask IT and it's the domain controller. Every department carries a genuine, sincerely held belief that their corner of the operation is the one holding civilization together, and they're usually not lying. They just haven't been asked to prove it with a number, and a good BIA process exists specifically to make them do that.

That's where the fun starts. The loudest voice in most planning meetings belongs to whoever has the best slide deck or the most seniority in the room, and a properly run BIA makes that irrelevant. You're not asking how important a process feels. You're asking what happens at hour four, and what happens at hour forty. So the spreadsheet needs revenue-per-hour, it needs contractual penalty clauses, and it needs a column for whether the outage puts anyone's safety at risk. Let the numbers argue it out instead of whoever's still talking after everyone else has run out of breath.

A payroll run that's four hours late is an inconvenience. Four days late, it's a resignation wave. A customer-facing system down for ten minutes might cost nothing anyone can measure. Down for three hours inside a contractual SLA window, it costs a specific, invoiceable amount. Write those numbers down next to each other and the org chart stops mattering quite so much.

The Boring Half Nobody Finishes

Ranking processes by impact is one exercise. Tracing what each one needs to keep running, the systems and the vendors, plus the one person who understands the weird legacy tool nobody ever documented, is a slower and much less glamorous job. Skip it and you'll rank your top process correctly and still fail to protect it, because nobody noticed it depends on a single supplier with no backup, or a spreadsheet macro that exactly one employee knows how to touch.

Here's the part that never makes the executive summary: most BCM plans fail quietly, long before any actual incident, because the BIA got rushed or skipped entirely. Someone writes a recovery plan around assumed priorities instead of measured ones, and the org ends up with a beautifully rehearsed failover procedure for a system that barely matters, and nothing at all for the one generating most of the revenue. You usually find out which is which during the outage itself, a bad time to learn it. A ranking exercise that stings a little in a conference room in October is a lot cheaper than the version that stings in production in March.

Do the BIA properly and the rest of the plan follows almost on its own: what to protect first, and which department gets real budget instead of a laminated poster on the break room wall. Skip it, and you'll spend a small fortune protecting whichever office shouted loudest, while the thing actually keeping the lights on quietly waits its turn to fail.