Business Impact Analysis: Surveying the Ground Before You Build
Business impact analysis is the least fashionable part of continuity work and the part that determines whether everything else is aimed correctly. It is the survey you conduct before you spend, and its purpose is to answer one question for every significant process in the organisation: if this stopped, what would it cost us, how fast would the cost accumulate, and what does it depend on to run?
The method is more interview than algorithm. You sit with the people who own each business process — not the systems, the processes: taking orders, paying suppliers, dispatching trucks, settling trades, admitting patients — and you ask them to describe what happens when the process halts. Not in the abstract. Specifically. At one hour of outage, what breaks? At four hours? At a day? The shape of that curve matters enormously. Some processes degrade gracefully: an outage of the internal expenses tool is an annoyance at hour one and still merely an annoyance at hour eight. Others fall off a cliff: a settlement system that misses a market cutoff does not cause linear harm; it causes a discrete, large, and sometimes irreversible loss the moment the deadline passes.
That cliff-versus-slope distinction is one of the most valuable things an impact analysis produces, because it tells you whether your RTO needs to be comfortably inside a deadline or merely 'reasonably quick.' A process with a hard external cutoff — a regulatory filing, a payment-network window, a shipping cutoff — has an RTO dictated by the clock on the wall, not by internal preference. Miss it by a minute and miss it by an hour cost the same. For those processes, the objective is not negotiable downward no matter how much the infrastructure costs, because the alternative is a guaranteed, bounded, external penalty.
The analysis also quantifies, as far as it honestly can, the cost of downtime and the cost of lost data. These will rarely be precise, and precision is not the goal; the goal is order of magnitude and relative ranking. Is this process's outage a thousand-dollar-per-hour problem or a million-dollar-per-hour problem? Would losing an hour of its data mean re-keying a few forms, or would it mean money that has genuinely left the building with no record of where it went? These figures feed directly into the negotiation from the previous module: they are the consequence side of the curve, the raw material from which a business owner sets a defensible objective.
The most important discovery an impact analysis makes, however, is usually not a cost. It is a dependency. Every process rests on a stack of systems, and those systems rest on other systems, and somewhere in that stack is almost always a component that no one thinks about because it never fails — a directory service, a certificate authority, a shared message queue, a single database that turns out to sit beneath six 'independent' applications. The survey's job is to trace these chains until it finds the load-bearing walls. When it finds one, the finding reorders everything: a humble, low-traffic service that six critical processes depend upon is not a low-tier service. It is as critical as the most critical thing standing on top of it, because none of them recover until it does.
This is why the analysis must map dependencies explicitly rather than trusting the org chart or the traffic graphs. Importance does not announce itself through visibility. The systems people worry about are the ones customers touch; the systems that take the whole enterprise down are frequently the quiet infrastructure two layers below, owned by no one in particular, documented nowhere, and assumed by everyone to be someone else's concern. An outage finds these dependencies instantly and expensively. A good impact analysis finds them first, on paper, when the discovery costs only an uncomfortable meeting.
A final discipline: the analysis is perishable. Organisations add systems, retire others, and rewire dependencies constantly, and an impact analysis is a photograph of a moving thing. A survey from three years ago describes a company that no longer exists. Revisit it on a schedule and after any significant change, and treat the dependency map in particular as something that decays the moment you stop maintaining it. The survey is not a document you produce once and file. It is a practice you keep, because the ground you are surveying will not hold still for you.