Business Impact Analysis
Identifying what you cannot afford to lose — before you lose it.
Overview
An RTO or RPO that has not been validated against actual business impact is not an objective — it is a guess. BIA is the work that converts guesses into defensible requirements. Answer the five questions below with the analytical depth that the BIA process requires.
Read before you answer
A Business Impact Analysis (BIA) is the foundational analytical exercise that underpins all meaningful BCP and DR planning. Its purpose is to identify which business functions and processes are critical to the organisation's survival or regulatory compliance, quantify the impact of their disruption over time, and determine the recovery objectives — RTO and RPO — that recovery plans must be designed to meet. Without a BIA, RTOs and RPOs are guesses; with a rigorous BIA, they are business decisions grounded in evidence of actual impact. The BIA also identifies the dependencies of critical processes — the systems, data, suppliers, staff, and facilities that each process relies on — which is the input to dependency mapping and recovery architecture design.
RTO (Recovery Time Objective) is the maximum acceptable duration of a process or system outage before the impact becomes unacceptable to the organisation. RPO (Recovery Point Objective) is the maximum acceptable data loss, expressed as a point in time: if the RPO for a critical database is four hours, the organisation must be able to restore that database to a state no older than four hours before the disruption. RTOs and RPOs are not the same across all processes: a payment processing system might have an RTO of two hours and an RPO of zero (no data loss acceptable); an internal reporting system might have an RTO of five days. The cost of meeting a given RTO or RPO scales steeply: a two-hour RTO requires near-real-time replication and hot standby infrastructure; a 24-hour RTO can be met with daily backups and a cold standby. The BIA makes these trade-offs explicit by quantifying the business impact at each time interval, allowing the organisation to make an informed investment decision.
Conducting a BIA requires structured engagement with business process owners — not just the IT team. The analysis methodology typically involves interviews or workshops with each business unit to identify: the processes they perform, the maximum tolerable period of disruption (MTPD) for each, the minimum service level required to be considered operational, the downstream and upstream dependencies of each process, and the financial, regulatory, operational, and reputational impact of disruption at 1 hour, 4 hours, 24 hours, 72 hours, and one week. The outputs of the BIA — a ranked list of critical processes with RTOs, RPOs, and dependency maps — are the specification that the DR architecture, recovery procedures, and testing programme must be designed to satisfy. A BIA that is not translated into these downstream artefacts has not fulfilled its purpose.