Business Impact Analysis (BIA)

What it is

A business impact analysis (BIA) works out what happens to the organization when a business process is disrupted, and how the damage grows over time. It identifies which processes are critical, how quickly they must be restored, and what resources they depend on.

The BIA does not ask how likely a disruption is; that is the risk assessment's job. It asks "if this stops, how bad is it, and how fast must we recover?" The answers drive continuity and recovery planning and inform impact ratings in the risk register.

How it works

Steps in a BIA

1. Identify business processes and their owners.
2. Collect information through interviews, questionnaires and workshops with process owners.
3. Assess impact over time: what happens after 1 hour, 4 hours, 1 day, 1 week.
4. Determine criticality and recovery objectives.
5. Identify dependencies: systems, data, people, sites, suppliers and upstream processes.
6. Validate results with process owners and approve with senior management.

Impact categories

Impacts are rarely linear. A payroll process may tolerate a day's outage but cause severe harm if payday is missed.

Recovery objectives

The RTO must be shorter than the MTD. A short RPO usually needs more frequent backups or replication, which costs more. The BIA lets the business balance cost against impact instead of letting IT choose.

Dependencies

A process is only as recoverable as its slowest dependency. If an application has an RTO of 4 hours but relies on an identity service with an RTO of 24 hours, the real recovery time is 24 hours. The BIA must surface these conflicts so the DRP can resolve them.

Who owns the BIA

Process owners provide and validate impact information, because they understand the business. Senior management approves the results, especially the ranking of critical processes. The practitioner or continuity team facilitates and checks that answers are consistent and realistic.

Owners tend to rate every process as critical. Asking for specific financial and operational effects at each time interval, and comparing answers across departments, gives a more honest result.

Keeping it current

The BIA should be reviewed regularly, often annually, and when processes, systems, suppliers or the organization change significantly. An outdated BIA produces recovery plans for a business that no longer exists.

A worked example

A retail bank's BIA finds that card authorization causes major customer harm and regulatory concern after 2 hours of disruption, so its MTD is set at 2 hours and its RTO at 1 hour. Data loss of even a few minutes would cause unreconciled transactions, so the RPO is near zero.

Mapping dependencies shows card authorization relies on a fraud scoring service that the DRP currently restores in 6 hours. The practitioner reports the conflict, and the business decides to fund real-time replication for the fraud service rather than accept the gap.

How the exam asks about this

• "What is the PRIMARY purpose of a BIA?" To identify critical processes, the impact of their disruption over time, and their recovery priorities.
• "Who should validate the results of a BIA?" The business process owners, with approval from senior management.
• "An application's RTO is longer than the process's MTD. What does this indicate?" Recovery capability does not meet business needs and must be improved or the risk formally accepted.