Business impact analysis

A business impact analysis describes how interruption harms a process over time and exposes the dependencies needed to restore it. It does not begin by buying a backup site. Ask the process owner when delay becomes unacceptable, what minimum service is needed, and which people, data, vendors, power and communications make it possible. Record safety, service, contractual, reputational and financial impacts separately, then review assumptions with recovery operators. Maximum tolerable downtime describes the outer boundary before unacceptable harm. The recovery time objective is the service restoration target and should normally be inside that boundary to allow stabilization. The recovery point objective is the maximum tolerable age of restored data, not a return-to-service duration. RTO and RPO are not interchangeable.

Suppose a medicine-ordering process tolerates five minutes of lost updates, but four hours of outage prevents critical dispensing. Daily backup plus a replacement server restored in two hours may meet the time target while failing the data target. Near-real-time replication to another region does not ensure staff can sign in if the same identity provider is down. Draw the dependency path: network, identity, database, application, dispensing device, trained staff and vendor. Derive component targets from process consequences, then test capacity rather than relying on vendor promises. A clean data recovery point also matters after corruption; a fast restore of contaminated records does not restore trustworthy service.

BIA produces priorities but does not grant unlimited authority to displace another process. When resources are scarce, compare the consequences of competing operations and send the trade-off to the designated risk owner. State assumptions about alternate-site capacity, key availability, staff, communications contract and access to procedures outside the affected site. A tabletop exercise, parallel test and full interruption test provide different levels of evidence and operational risk; a disruptive test needs authorization and rollback planning. Update the BIA when a material service or dependency changes, rather than merely assigning a review date.