ISO 22301:2019 · Clause 8.2

Business Impact Analysis:
The Heart of the BCMS

Q: What is a business impact analysis in ISO 22301?

The BIA is the analysis required by Clause 8.2 of ISO 22301:2019. It ranks an organisation’s products, services, and activities by the impact their disruption would cause over time, identifies the prioritised activities and the resources they depend on — people, sites, technology, data, suppliers — and sets the recovery targets: the maximum tolerable period of disruption (MTPD), the recovery time objective (RTO), and the recovery point objective (RPO). Every later element of the BCMS — strategies, plans, exercises — must trace back to it, which is why auditors and bank vendor-risk teams ask for the BIA first.

Q: What is the difference between RTO and MTPD?

MTPD is the tolerance; RTO is the plan. The MTPD marks the point where the impact of non-delivery becomes unacceptable — breach of a regulatory obligation, irreversible customer loss, contractual default. The RTO is the target you commit to recover within, and it must sit inside the MTPD with a deliberate buffer, because real recoveries overrun. If an activity’s MTPD is 24 hours and its RTO is also 24 hours, any slippage breaches the tolerance — a design flaw auditors flag.

Q: What is the difference between RTO and RPO?

RTO is about time without the service; RPO is about data lost when it returns. An RTO of 4 hours means the activity must be running again within 4 hours of invocation. An RPO of 15 minutes means systems must be recoverable to a point no more than 15 minutes before the disruption — which dictates replication and backup frequency. The two are independent: a reporting service might tolerate a 24-hour RTO but only a 1-hour RPO, while a telephony service needs a fast RTO with no meaningful RPO at all.

Q: How often should the BIA be reviewed?

At planned intervals — annually is the working norm — and additionally whenever significant change occurs: a new product or market, a new site, a major technology migration, or a new critical supplier. ISO 22301 requires review at planned intervals and on significant change rather than fixing a frequency, but a BIA that predates your last organisational change is one of the most common certification nonconformities, and the first staleness check a vendor-risk assessor performs.

Q: Who should be involved in a BIA workshop?

The people who run each activity — operations leads, product owners, customer-facing managers — supported by IT for dependency and recovery-capability detail, plus risk or compliance for regulatory impact context. Top management does not need to sit in every workshop, but must arbitrate the inevitable priority conflicts and sign off the consolidated recovery targets. The common failure is delegating the whole exercise to IT or to a junior coordinator: the result is a systems inventory, not an impact analysis.

Q: How much does a BIA engagement cost?

It depends on the number of products, activities, and sites in scope and how much dependency mapping already exists — so every engagement is custom-scoped, with a fixed, all-inclusive quote after a short scoping call. A standalone BIA (workshops, impact analysis, recovery-target register, dependency map, and management sign-off pack) is also the most common first phase of a full ISO 22301 implementation, in which case it is scoped and quoted as part of that wider engagement — see the implementation roadmap for how it sequences.

Every defensible recovery decision in ISO 22301 traces back to one analysis. The business impact analysis ranks your products and services by the damage disruption causes over time, exposes the people, sites, technology, and suppliers they depend on, and sets the RTO, RPO, and MTPD targets the rest of the management system exists to meet. Get the BIA right and the BCMS almost builds itself — get it wrong and everything downstream inherits the error.

Written from the BIA workshops our consultants ran preparing ADIB (Abu Dhabi Islamic Bank), Mashreq Bank, and AMEX for ISO 22301 in the Middle East.

Get a BCM Scoping Call Explore the ISO 22301 Hub

500+audits across India, USA, UK, Australia & UAE

250+SOC 2 attestations to date

3recovery targets per activity (RTO · RPO · MTPD)

ISO/IEC 22301:2019 · Clause 8.2 · Last reviewed June 2026

Key Takeaways

The business impact analysis (BIA) is the engine of ISO 22301: it ranks products and services by the impact of disruption over time, identifies prioritised activities and their dependencies, and sets the RTO, RPO, and MTPD targets every later decision must trace back to.
Impact over time is the core technique — disruption damage grows non-linearly, and the point where it becomes unacceptable defines the MTPD. The RTO is then set inside that limit with a deliberate buffer.
RTO answers “how fast must we be running again?”, RPO answers “how much data can we afford to lose?”, and MTPD answers “how long before the damage becomes unacceptable?” — three different questions that teams routinely conflate.
A BIA is collected in facilitated workshops with activity owners, not by emailing spreadsheets — and its outputs are only real once top management has signed off the recovery targets and funded the strategies that meet them.
Built on the BIA method our consultants used preparing ADIB (Abu Dhabi Islamic Bank), Mashreq Bank, and AMEX for ISO 22301 in the Middle East — the artefact a bank’s vendor-risk team asks to see first.

Direct Answer

What a Business Impact Analysis Actually Is

A business impact analysis answers one question with evidence: if this activity stopped, how bad would it get, and how quickly? It is not a risk assessment — it deliberately ignores what might cause the outage and studies only the consequences of the outage itself, category by category: financial loss, regulatory breach, contractual default, reputational damage, operational knock-on effects.

From those consequences the BIA derives three things: the prioritised activities (what must come back first), the dependencies those activities cannot run without, and the recovery targets — MTPD, RTO, and RPO — that the continuity strategies in Clause 8.3 must then meet. That is why ISO 22301 sequences the BIA before strategies, plans, and exercises: it is the load-bearing analysis the auditor traces every later decision back to.

The companion risk assessment (also Clause 8.2) then asks what could plausibly cause such disruption — the two analyses run together, and both are covered in context in the clause-by-clause requirements guide. For where the BIA sits in the build sequence, see the implementation roadmap.

The Core Technique

Impact Over Time

Disruption damage is not linear. An hour without merchant onboarding costs almost nothing; a week without it breaches contracts. An hour without payment authorisation is already a scheme-reportable event. The BIA captures this by scoring each impact category at fixed time horizons — 4 hours, 24 hours, 3 days, 1 week, 2 weeks is a common set — using an agreed scale from negligible to unacceptable.

Two readings come straight off that curve. The horizon at which any impact category first turns unacceptable is the activity’s MTPD. And comparing curves across activities produces the priority tiers — the defensible answer to “what do we recover first?” that replaces the loudest-voice version of criticality with one management can sign.

Score the worst credible case, not the average day: a payroll outage is trivial mid-month and severe at month-end, and the BIA must record the peak and its timing sensitivity, because disruptions do not schedule themselves politely.

The Recovery Targets

RTO, RPO, MTPD — Defined Precisely

Four terms carry the whole analysis, and conflating them is the most common BIA error. The working rule: MTPD is the tolerance, RTO is the commitment inside it, RPO is the data you may lose, MBCO is what “recovered” must actually deliver.

Term	Stands for	Precise definition	The question it answers
MTPD	Maximum tolerable period of disruption	The time it would take for the adverse impacts of not delivering a product, service, or activity to become unacceptable to the organisation — the breaking point. Set first, from the impact-over-time analysis; every other target must fit inside it.	How long before the damage becomes unacceptable?
RTO	Recovery time objective	The target time after invocation within which a prioritised activity must resume — at full or an agreed minimum level. Always set shorter than the MTPD, so recovery overruns burn buffer rather than breach the tolerance.	How fast must we be running again?
RPO	Recovery point objective	The maximum acceptable data loss expressed as time — the gap between the last recoverable point and the moment of disruption. It is what dictates backup frequency and replication design, not the other way round.	How much data can we afford to lose?
MBCO	Minimum business continuity objective	The minimum level of products or services that is acceptable while recovery is under way — for example, processing payments but deferring onboarding. It defines what “resumed” means for each RTO.	How much of the service is enough while we recover?

Relationship to remember: RPO concerns data, RTO and MTPD concern time, and RTO < MTPD always — the gap between them is your overrun buffer.

Prioritised Activities & Dependencies

What Each Activity Cannot Run Without

A recovery target without a dependency map is unbuildable — strategies must replace or protect specific resources, not abstractions. The BIA captures four dependency classes per prioritised activity.

People

Named roles, minimum staffing levels per activity, single points of knowledge, and deputies. The BIA records how many people an activity genuinely needs in its first 24 hours — usually far fewer than its normal headcount, and never zero.

Sites & facilities

The buildings, work areas, and physical infrastructure each activity runs from — and whether it can run from anywhere else. Site dependencies decide alternate-workplace and work-from-home strategies later.

Technology & data

Applications, infrastructure, and the data each activity cannot operate without — mapped to the RPO they require. This mapping is what aligns IT disaster recovery to business priorities instead of system inventories.

Suppliers & third parties

The external services prioritised activities depend on — cloud platforms, payment schemes, logistics, outsourced operations. Each inherits a continuity requirement under Clause 8.1: contractual clauses, assessments, or substitution arrangements.

The Method

How a BIA Workshop Actually Runs

Six steps, run with the people who own the activities — never by survey. For a single-scope organisation this is typically two to three weeks of workshops and consolidation inside the wider implementation.

Prepare the inventory

List the products and services in the BCMS scope and the activities that deliver them. Agree the impact categories — financial, regulatory, contractual, reputational, operational — and the time horizons to score against (for example 4 hours, 24 hours, 3 days, 1 week, 2 weeks).

Run owner workshops

Facilitated sessions with the people who run each activity — not a survey. Owners describe what stops, who is affected, and which obligations are breached as an outage stretches across each time horizon.

Score impact over time

Rate each impact category at each horizon using the agreed scale, recording the worst credible case rather than the average day. The point where any category reaches “unacceptable” marks the activity’s MTPD.

Set MTPD, RTO, then RPO

Fix the MTPD from the scoring, set the RTO inside it with a deliberate buffer, and define the RPO from how much data the activity can lose before recovery becomes reconstruction. Record the MBCO that “resumed” must deliver.

Map the dependencies

For each prioritised activity, capture the people, sites, technology, data, and suppliers it cannot run without — the resource picture the continuity strategies will have to replace or protect.

Consolidate & obtain sign-off

Resolve conflicts (every owner believes their activity is critical), tier the activities, and take the consolidated BIA to top management for sign-off — the approval that turns analysis into recovery targets the organisation is committed to funding.

From Analysis to Action

How BIA Outputs Drive Every Strategy Decision

The BIA is only finished when its outputs are consumed. Auditors test this traceability explicitly: each recovery target must lead to a resourced strategy, a documented plan, and exercise evidence that the target holds.

BIA output	What it drives downstream
Prioritised activities & tiers	The structure and recovery order of every business continuity plan — what comes back first, second, third.
MTPD per activity	Invocation criteria and escalation thresholds — how long teams may attempt in-place fixes before plans are invoked.
RTO per activity	Continuity strategy selection and resourcing under Clause 8.3 — an RTO an existing capability cannot meet forces a strategy decision: invest, contract, or accept the gap formally.
RPO per activity	Backup frequency, replication architecture, and the IT disaster-recovery design — and the evidence IT must produce in recovery tests.
Dependency map	Supplier-continuity clauses and assessments (Clause 8.1), alternate-site and workforce arrangements, and the scenarios the exercise programme must cover.

An RTO without a resourced strategy behind it is a wish, not a target — the gap auditors and bank vendor-risk teams probe first.

From the Audit Floor

Six BIA Mistakes That Surface at Stage 2

Each of these produces recovery targets that cannot survive an auditor’s first “show me how you arrived at this number” — and most are baked in during week one.

Emailing spreadsheets instead of running workshops

Self-assessed templates come back inflated, inconsistent, and unchallenged. Impact scoring needs a facilitator in the room asking “what actually stops, and who notices?” — the question that separates inconvenience from impact.

Recovery targets set by IT alone

IT can say how fast a system restores today; only the business can say how fast the activity must return. An RTO without business validation and management sign-off is an infrastructure statistic, not a recovery target.

Averaging impacts instead of taking the worst credible case

A payroll outage is trivial for three weeks of the month and severe in the run-up to payday. Scoring the average hides the peak — the BIA must capture impact at the worst credible time, and note the timing sensitivity.

Analysing hundreds of micro-activities

A BIA that dissects every task produces noise no strategy can act on. Keep the unit of analysis at the level where recovery decisions are made — typically 10 to 30 activities for a single-scope organisation.

Letting the BIA go stale

New products, new sites, new critical suppliers — each invalidates part of the analysis. Auditors check that the BIA review date postdates the last significant organisational change, and a stale BIA is among the most common nonconformities.

Skipping management sign-off

Unsigned recovery targets are opinions. Sign-off is what commits the organisation to funding strategies that meet the targets — and it is the first record both certification auditors and bank vendor-risk teams ask to see.

Worked Example

A Payments Platform’s BIA, Tiered

An anonymised composite from real Gulf engagements: five activities, five very different curves — and the tiering that tells the recovery teams exactly what comes back first.

Prioritised activity	Impact over time	MTPD	RTO	RPO	Tier
Payment authorisation & processing (24×7)	Severe within the hour — transactions fail at scale, scheme obligations and merchant SLAs breach	4 hours	1 hour	Near-zero (synchronous replication)	Tier 0
Settlement & scheme reconciliation	Low for hours; regulatory and counterparty impact compounds past the daily cut-off	24 hours	8 hours	15 minutes	Tier 1
Customer support (voice & chat)	Reputational impact builds with queue times; complaint-handling obligations engage by day two	24 hours	4 hours	Not data-bound (telephony reroute)	Tier 1
Merchant onboarding & KYC	Pipeline and contractual impact accumulates over days; no immediate harm to live merchants	3 days	24 hours	4 hours	Tier 2
Finance & internal reporting	Tolerable within the week outside statutory deadlines; escalates at period-end	5 days	72 hours	24 hours	Tier 3

Illustrative targets from an anonymised composite — your numbers must come from your own impact-over-time analysis, not from a benchmark table. Note the design choices: every RTO sits inside its MTPD with buffer, and RPOs differ by an order of magnitude across tiers, which is what keeps the replication bill proportionate to actual impact.

“You can tell within ten minutes whether a BIA was a workshop or a spreadsheet. Workshop BIAs have arguments in them — an owner who fought for a four-hour RTO and lost to the impact data. Those are the BIAs that survive an auditor, because the numbers have reasons.”

Surendra Pal SinghCISO & DPO, TCSA — CISA, ISO 27001 / 27701 / 42001 Lead Auditor

See verified client reviews and audit outcomes from 500+ engagements across India, USA, UK, Australia and UAE.

Business Impact Analysis — Frequently Asked Questions

RTO, RPO, MTPD, and method answers from the consultants who run BIA workshops for Middle East banks.

What is a business impact analysis in ISO 22301?

The BIA is the analysis required by Clause 8.2 of ISO 22301:2019. It ranks an organisation’s products, services, and activities by the impact their disruption would cause over time, identifies the prioritised activities and the resources they depend on — people, sites, technology, data, suppliers — and sets the recovery targets: the maximum tolerable period of disruption (MTPD), the recovery time objective (RTO), and the recovery point objective (RPO). Every later element of the BCMS — strategies, plans, exercises — must trace back to it, which is why auditors and bank vendor-risk teams ask for the BIA first.

What is the difference between RTO and MTPD?

MTPD is the tolerance; RTO is the plan. The MTPD marks the point where the impact of non-delivery becomes unacceptable — breach of a regulatory obligation, irreversible customer loss, contractual default. The RTO is the target you commit to recover within, and it must sit inside the MTPD with a deliberate buffer, because real recoveries overrun. If an activity’s MTPD is 24 hours and its RTO is also 24 hours, any slippage breaches the tolerance — a design flaw auditors flag.

What is the difference between RTO and RPO?

RTO is about time without the service; RPO is about data lost when it returns. An RTO of 4 hours means the activity must be running again within 4 hours of invocation. An RPO of 15 minutes means systems must be recoverable to a point no more than 15 minutes before the disruption — which dictates replication and backup frequency. The two are independent: a reporting service might tolerate a 24-hour RTO but only a 1-hour RPO, while a telephony service needs a fast RTO with no meaningful RPO at all.

How often should the BIA be reviewed?

At planned intervals — annually is the working norm — and additionally whenever significant change occurs: a new product or market, a new site, a major technology migration, or a new critical supplier. ISO 22301 requires review at planned intervals and on significant change rather than fixing a frequency, but a BIA that predates your last organisational change is one of the most common certification nonconformities, and the first staleness check a vendor-risk assessor performs.

Who should be involved in a BIA workshop?

The people who run each activity — operations leads, product owners, customer-facing managers — supported by IT for dependency and recovery-capability detail, plus risk or compliance for regulatory impact context. Top management does not need to sit in every workshop, but must arbitrate the inevitable priority conflicts and sign off the consolidated recovery targets. The common failure is delegating the whole exercise to IT or to a junior coordinator: the result is a systems inventory, not an impact analysis.

How much does a BIA engagement cost?

It depends on the number of products, activities, and sites in scope and how much dependency mapping already exists — so every engagement is custom-scoped, with a fixed, all-inclusive quote after a short scoping call. A standalone BIA (workshops, impact analysis, recovery-target register, dependency map, and management sign-off pack) is also the most common first phase of a full ISO 22301 implementation, in which case it is scoped and quoted as part of that wider engagement — see the implementation roadmap for how it sequences.

Keep Exploring

Get in touch

Book a free consultation or send us your requirements. We respond within 24 hours.

Quick Call

Pick a time slot

Send Requirements

Get a custom quote in 24 hours

We're Online

Business Impact Analysis:The Heart of the BCMS