Business Impact Analysis (BIA) Guide: Critical Processes, RTO, RPO and Dependencies

A Business Impact Analysis (BIA) is the foundation of business continuity planning. It answers three questions: which processes are critical, how long they can be unavailable, and how much data loss is survivable. Without it, a continuity plan is guesswork with a template.

This guide covers how to run a BIA, how RTO and RPO are actually derived, and how to map dependencies across many BIAs so the numbers survive contact with reality.

What a BIA Delivers

• Critical processes, ranked by consequence to the organisation — revenue, safety, regulation, reputation.
• MTPD — the Maximum Tolerable Period of Disruption, beyond which impact becomes unacceptable.
• RTO — the Recovery Time Objective, set below MTPD with margin.
• RPO — the Recovery Point Objective: maximum tolerable data loss, expressed as time.
• Minimum resources needed to run each process at a reduced but acceptable level.
• Dependencies — people, systems, data, facilities and third parties.

1. Identify critical processes & owners
2. Define RTO (recovery time) & RPO (data loss)
3. Map dependencies (people, systems, vendors)
4. Prioritize recovery order
5. Document in BIA report & link to recovery plans

How to Conduct a BIA

1. Set Scope and Method Before Interviewing

Agree what is in scope, the impact categories you will assess, and the scales — before the first workshop. Two BIAs run on different scales cannot be compared, and comparison is the entire point when you are deciding recovery order across the organisation.

Under ISO 22301 the methodology must be documented and repeatable. Practically, that means a second analyst working from your method would reach comparable answers.

2. Identify Processes and Owners

List business processes at a consistent level of granularity — order-to-cash, payroll, customer support, claims handling, production scheduling. Getting the level right matters: too coarse and every process looks critical, too fine and you drown in entries nobody maintains. Most organisations land between 30 and 150 processes.

Each needs an owner who can speak to consequence, not just to how the work is done.

3. Analyse Impact Over Time

This is the analytical core, and the step most often reduced to asking people how important their process is. Everyone's process is important. Ask instead how consequence accumulates during an outage.

For each process, assess impact at defined intervals — 1 hour, 4 hours, 24 hours, 72 hours, one week — across each category:

Impact is rarely linear. Most processes tolerate a period with little consequence, then cross a threshold sharply — a payment run misses a cut-off, a regulatory deadline passes, perishable stock spoils. The location of that knee is what the BIA exists to find.

4. Derive MTPD, RTO and RPO

Once the curve exists, the numbers follow:

1. MTPD is where impact crosses the unacceptable threshold defined in your criteria.
2. RTO is set below MTPD, with margin. An RTO equal to MTPD assumes recovery goes perfectly, which is the one assumption an incident reliably falsifies.
3. RPO is a separate question — how much work can be reconstructed from other sources, or re-keyed, or absorbed. It comes from data-loss tolerance, not from downtime tolerance.

A worked example. Order capture is tolerable for two hours, painful at eight, and triggers contractual penalties at 24. MTPD is 24 hours; RTO is set at 8. Separately, the business can reconstruct at most 15 minutes of orders from email and call records, so RPO is 15 minutes. The two numbers are unrelated to each other, and both come from the business.

Neither is an IT decision. They are inputs to the recovery architecture, and they determine its cost — a 15-minute RPO implies near-synchronous replication, a 24-hour RPO implies nightly backup is enough. Choosing the technology first and back-filling the objectives inverts the exercise, and is the most common finding in continuity audits.

Be realistic about cost. Aggressive objectives applied indiscriminately produce a recovery budget nobody will approve, which produces a plan nobody funds.

5. Map Dependencies

For each process, document what it needs to run:

• People — named roles and deputies, skills that exist in only one head, locations.
• Systems — applications, and what those applications depend on: infrastructure, network, facilities.
• Data — including upstream feeds that must be recovered before the process can restart.
• Suppliers — and their own recovery commitments.
• Other internal processes — where circular dependencies hide.

Mapping Dependencies Across Multiple BIAs

A BIA that stops at its own process is only half done, because recovery order is determined by dependencies, and dependencies cross the boundaries any single interview can see.

The failure that invalidates plans quietly is the dependency chain longer than its weakest link. A process with a four-hour RTO depending on an application with an eight-hour RTO does not have a four-hour RTO — it has an eight-hour one, and the plan documents a fiction. The same applies to suppliers: a vendor with a 72-hour recovery commitment caps every process depending on them at 72 hours, whatever your BIA says.

To find these you need to traverse the chain, which means asking questions no individual BIA can answer:

• Which processes depend on this application, and what is the tightest RTO among them?
• Which processes does this supplier support, and does their commitment meet the tightest one?
• Where does a stated RTO exceed what the chain can actually achieve?
• Which dependencies support the largest number of critical processes — the concentration points?

Per-department spreadsheets cannot do this, because each one sees only its own process. Holding every BIA in one structure makes the roll-up automatic: the achievable RTO is computed from the chain, and conflicts appear as a list rather than as a discovery during an incident.

Resolve each conflict explicitly — invest to improve the dependency, renegotiate the supplier commitment, accept the longer RTO formally, or re-engineer the process to remove the dependency. Leaving it unresolved means the plan promises something the infrastructure cannot deliver.

6. Prioritise Recovery Order

Use RTO and criticality together to sequence recovery, and respect the dependency graph — a process cannot recover before what it depends on. Document the order in the BIA and in the runbooks, so during an incident you follow a decision made calmly rather than debating it under pressure.

7. Document, Review and Maintain

A BIA reflects the organisation on the day it was done. Refresh it on a cadence — annually for most, more often for volatile areas — and on trigger events: a new system, a material process change, a new critical supplier, a merger, a real incident.

Reviewing means re-testing the assumptions, not re-confirming last year's numbers. An incident in particular is free data about whether your estimates were right.

Common Mistakes

• Asking importance instead of impact over time. Everything comes back critical and nothing is prioritised.
• Letting IT set RTO and RPO. They become descriptions of current capability rather than requirements.
• Confusing RTO with RPO. They answer different questions and are frequently conflated in documentation.
• Ignoring the dependency chain. Stated RTOs the infrastructure cannot deliver.
• Forgetting people. Systems recover; the two people who know the manual workaround are unavailable.
• One-and-done. A BIA older than the last reorganisation is a historical document.
• Inconsistent scales. Departments using different definitions produce results that cannot be compared, which defeats the exercise.

From BIA to Plan

The BIA produces the requirements; the BCP meets them; exercises prove it. When the BIA, recovery plans, exercises and incident log sit in one platform, the numbers stay connected to the plans that depend on them, and dependency conflicts surface as reports rather than surprises.

For more, see Business Continuity, our ISO 22301 coverage, and Risk OS — or request a demo.