BIA Business Impact Analysis.

What a BIA actually does

A Business Impact Analysis answers one question that the rest of the continuity programme depends on: if this activity stops, how bad does it get, and how fast? You take each business activity, walk it forward in time, and describe the consequences of its disruption at each interval. Some activities hurt within minutes, payment processing or a hospital admissions desk. Others can be down for days before anyone outside the team notices. The BIA is what separates the two, so that scarce recovery resources go where the harm accumulates fastest rather than where the loudest manager happens to sit.

The impact is assessed across several dimensions, not just lost revenue. Financial loss is the obvious one, but a serious BIA also captures regulatory and legal exposure, contractual penalties, safety, and reputational damage. A consequence that is trivial in euros can be existential in trust. The point of looking across dimensions is that the activity which tops the list on money is rarely the same one that tops the list on legal or safety, and the board needs to see all of them before it sets priorities.

From impact to objectives

The BIA does not stop at description. It produces the numbers the recovery strategy is built on. As impact rises over time, you reach the point where it becomes unacceptable. That threshold sets the recovery time objective, the maximum tolerable period the activity can stay down. The recovery point objective comes from the same exercise on the data side: how much recent work, measured in time, can be lost before the disruption causes unacceptable harm. The minimum business continuity objective describes the reduced level of operation you must sustain during disruption, not full service, but enough to stay viable.

These outputs are the formal input to the continuity strategy. A recovery time objective is a requirement placed on the recovery solution, not a wish. If the BIA says an activity must be back within a tight window, the strategy and the budget have to deliver that, or the organisation has to consciously accept the gap. This is why the BIA is the document that should be signed off by the business owners and read by the board, rather than written by IT in isolation.

Where the BIA sits in the standards

Under ISO 22301, the BIA is a required step in establishing a business continuity management system. The standard expects you to determine the activities that support the delivery of products and services, assess the impacts over time of not performing them, and use that to set prioritised timeframes for resumption. The BIA feeds directly into the risk assessment and the choice of continuity strategy. Under DORA, the same logic applies to digital operational resilience: financial entities are expected to understand the impact of disruption on their critical or important functions, and that understanding starts with an impact analysis.

A BIA is not a risk assessment, and conflating the two weakens both. The risk assessment asks what could cause a disruption and how likely it is. The BIA is deliberately threat-agnostic: it asks how much a disruption hurts regardless of cause, whether the trigger is a cyberattack, a flood, or a failed supplier. You run them as complementary exercises. The BIA tells you what must be protected and how quickly it must recover; the risk assessment tells you what is most likely to threaten it. Together they justify where continuity investment goes.

Practically, a BIA is repeated on a cycle and after major change, because activities, dependencies, and tolerances drift. The supplier that was peripheral last year is now in your critical path; the process you could lose for two days is now customer-facing. A BIA that is two restructures old is decoration.