What is a Business Impact Analysis (BIA)?

A business impact analysis (BIA) is the process of working out which of your activities matter most, how quickly they would need to recover after a disruption, and what they depend on. It's the foundation of any continuity programme: without it, every recovery decision is guesswork.

What a BIA is for

A BIA answers a deceptively hard question: if we were disrupted, what would we protect first, and how fast? Instead of trying to recover everything at once (impossible) or protecting whatever feels important (subjective), it ranks your activities by the impact of losing them over time, so priorities are based on evidence rather than the loudest voice in the room.

What a BIA produces

A good BIA gives you four things for each critical activity:

• A criticality ranking: how badly a disruption hurts, and how quickly that hurt escalates (financial, operational, reputational, regulatory).
• Recovery objectives: the RTO, RPO and MTPD that say how fast the activity must be back and how much data loss is tolerable.
• Dependencies: the people, applications, suppliers, data and facilities the activity relies on. A process is only as recoverable as the things it depends on, so this is where hidden single points of failure surface.
• Minimum resources: what you need to run the activity at an acceptable, possibly reduced, level during recovery.

Those outputs are exactly what your recovery strategies and continuity plans are built from. The BIA is upstream of everything else.

How a BIA works, in practice

The shape is consistent even if the detail varies:

1. Identify activities. List the processes and services the organisation delivers, at a sensible level of granularity.
2. Assess impact over time. For each, judge how the harm of an outage grows: an hour, a day, a week. This is what reveals the MTPD.
3. Set recovery objectives. Derive the RTO and RPO from that impact curve, inside the MTPD.
4. Map dependencies. Trace what each activity needs, including the suppliers and systems you don't control.
5. Prioritise. Turn all of it into a defensible order of recovery.

Where BIAs go wrong

• Too granular, too soon. Analysing hundreds of micro-tasks buries the signal. Start at the level of business services.
• Optimistic RTOs. Everyone wants "immediately". A BIA forces the honest trade-off between how fast and how much it costs.
• Ignoring dependencies. A four-hour RTO on a process means nothing if a supplier it relies on needs three days.
• Done once, never revisited. The business changes; a BIA that's two years stale no longer reflects what's critical.

Why it comes first

The BIA is the reason a continuity programme is defensible to an auditor or a regulator. It's the documented link between what matters and what you're prepared to recover, and it's an explicit requirement of ISO 22301 and of regimes like DORA and NIS2, which expect recovery objectives to be BIA-derived and then tested.

ResiliencePilot runs the BIA as living data, keeping criticality, recovery objectives and dependencies current rather than trapped in a spreadsheet. See the ISO 22301 solution or book a demo.