Business Impact Analysis

Business impact analysis. This is the foundation of the whole business-resilience half of the domain, and skipping it is how you end up recovering the wrong thing.

Here is the scene. An organisation has spent heavily on a disaster recovery site and nightly replication for its email system, the project the I-T team felt most confident scoping. When a real disruption hits the order-management system, the one the business actually runs on, it turns out nobody had established how quickly it needed to be back, or that it mattered more than email. The recovery capability was real. It was pointed at the wrong thing.

A business impact analysis, a B-I-A, identifies the organisation’s critical business processes and analyses the impact of disrupting them over time. From that, it derives the recovery priorities and objectives: which processes must come back first, and how quickly, and with how little data lost. It is the foundation everything else rests on.

What exactly does it establish. First, the critical business processes: which ones actually matter.

Second, the impact of disrupting them, and crucially how that impact grows over time, an hour down versus a day down.

And third, from those, the recovery priorities and objectives, including the R-P-O and R-T-O we will meet in the next lesson. The B-I-A’s output answers the questions any recovery effort must answer first: what must we recover, how fast, and in what order.

Because it defines the requirements, the B-I-A must come first, before the recovery solution is designed. This is the same logic as requirements before build in Domain three: you establish what is needed, then design something to meet it.

Do it the other way, build a D-R capability and then discover what the business needed, and you protect whatever was easiest to scope, which is exactly how the organisation ended up protecting email while the order system waited. The B-I-A tells you the order system needs to be back within hours and email can wait a day. When a question asks the first step in continuity or D-R planning, it is the B-I-A.

And criticality is a business judgement, not a technical one. How badly does losing this process hurt, in lost revenue, regulatory breach, safety, or reputation, and how fast does that harm escalate. The people best placed to answer are the business process owners, who live with the consequences of the process being down.

So whose call is it. The business process owners determine criticality, because they feel the impact. I-T contributes essential technical input, what depends on what, what is feasible, but it does not decide what is critical. A D-R vendor supplies capability, not criticality judgements, and audit evaluates rather than sets it.

And without the B-I-A, you recover the convenient. Skip the analysis and you protect what was easiest to build, not what the business most needs, in the wrong order and to the wrong timescales. The B-I-A is what stops that.

So carry this away. The B-I-A identifies critical processes and the impact of disruption over time, and from that sets the recovery objectives. It comes first, before the recovery solution. And criticality is the business’s call, made by the process owners, not by I-T.