Book a consultation
Book a consultation
October 2026 · 6 min read

From the business impact analysis to the continuity plan: how a recovery time becomes a call-tree order

The business impact analysis is where the risk framework and the continuity plan meet. Done well, it decides which teams are called first, how fast each must be back and how many people that takes. This article sets out what a BIA should record, how it links to the risk register and the continuity plan in both directions — and how Risk Core's two modules implement the link.

Last reviewed

1

What a BIA is for

ISO 22301:2019 asks, under clause 8.2.2, for a business impact analysis: for every activity that delivers the company's products and services, how long can the company live without it and how fast must it recover. The answers are what continuity plans, call-tree priorities and exercises should be built around. Clause 8.2.3 places the risk assessment next to it, and that is the point: the BIA says what matters most, the risk assessment says what threatens it.

In many firms the BIA is a document written once for an audit, and the continuity plan is written from the organisation chart. When an incident happens the call tree reaches the departments in the order someone listed them, not in the order the business can afford to lose them.

2

What a critical activity carries

  • MTPD — the maximum tolerable period of disruption: how long the activity can be down before the impact becomes unacceptable.
  • RTO — the recovery time objective: how fast it must be running again. It can never be longer than the MTPD.
  • RPO — the recovery point objective: how much data, measured in time, the activity can afford to lose.
  • Minimum staff and peak period — how many people the activity needs at its minimum level, and when in the year a disruption would hurt most.
  • Dependencies — the people, sites, systems, suppliers and data the activity relies on. A dependency that stops the activity when it fails, with nothing to stand in, is a single point of failure; a single point of failure with no workaround becomes an action item.
  • A criticality tier, computed. The group sets MTPD bands once; each activity's MTPD falls into a band, and that band is its tier. A tier then means the same thing in every company of the group.
Figure 13 — From the BIA to the continuity plan, and backThe BIA records each critical activity with its MTPD, RTO, RPO, minimum staffing and dependencies; the system computes the criticality tier from the group's MTPD bands. BCP Core reads the approved version: the call tree reaches tier-1 activities first, staffing is checked against the minimum, and exercises cover the linked hazards. Two links run back: closing an incident creates a draft loss event, and each BCP level change is a KRI observation. ERM CORE — THE BIA (DESK WORK, APPROVED ONCE A YEAR) CRITICAL ACTIVITY What it carries MTPD — how long it can be down RTO — how fast it must be back RPO — how much data it can lose Minimum staff · peak period Dependencies: people, site, system, supplier, data · SPOF flagged THE SYSTEM COMPUTES Criticality tier From the group's MTPD bands, so a tier means the same in every company RTO can never be longer than MTPD BCP CORE — DURING AN INCIDENT Call tree Tier-1 activities' teams are reached first Staffing Check-ins counted against minimum staffing Exercises Scenarios must cover the linked hazards reads TWO LINKS RUN BACK TO ERM CORE — NOTHING IS RE-KEYED INCIDENT CLOSED A draft loss event is created For the Entity Risk Manager to complete with amounts and validate BCP LEVEL CHANGED A KRI observation is recorded Normal → Green · Standby → Amber · Activated → Red; the level note is the explanation Each activity links to the RCSA risks that threaten it; the register shows which risks protect a critical activity. Approval is the entity's own act; every version is kept.
Figure 13 — From the BIA to the continuity plan, and backThe BIA records each critical activity with its MTPD, RTO, RPO, minimum staffing and dependencies; the system computes the criticality tier from the group's MTPD bands. BCP Core reads the approved version: the call tree reaches tier-1 activities first, staffing is checked against the minimum, and exercises cover the linked hazards. Two links run back: closing an incident creates a draft loss event, and each BCP level change is a KRI observation. ERM CORE — THE BIA CRITICAL ACTIVITY What it carries MTPD · RTO · RPO · minimum staff · peak period Dependencies: people, site, system, supplier, data — single points of failure flagged THE SYSTEM COMPUTES Criticality tier From the group's MTPD bands; RTO can never be longer than MTPD BCP Core reads the approved version Call tree Tier-1 teams are reached first Staffing Check-ins vs minimum staffing Exercises Must cover the linked hazards TWO LINKS RUN BACK — NOTHING IS RE-KEYED INCIDENT CLOSED A draft loss event is created For the Entity Risk Manager to complete and validate BCP LEVEL CHANGED A KRI observation is recorded Normal → Green · Standby → Amber · Activated → Red; the level note is the explanation Approval is the entity's own act; every version is kept.

Figure 13From the BIA to the continuity plan, and backThe BIA records each critical activity and the system computes its criticality tier from the group's MTPD bands. The continuity module reads the approved version: the call tree reaches tier-1 activities first, staffing is checked against the minimum, exercises cover the linked hazards. Two links run back: a closed incident becomes a draft loss event, and each level change becomes a KRI observation.

3

Links in both directions

  • Activity to risks. Each critical activity is linked to the risks in the register that threaten it; the BIA then shows each linked risk's residual score, read from the RCSA, and each risk shows that it protects a critical activity.
  • Activity to hazards. Each activity is linked to the hazard types its continuity scenarios must cover, from the group's shared taxonomy, so every company names a hazard the same way.
  • Approval creates a version. The BIA takes effect when the entity's own risk manager or continuity head approves it; each approval is a version with its date and approver, earlier versions are kept, and the company can always show which BIA applied at any date. It is approved at least once a year.
4

What the continuity plan reads

Once approved, the BIA is the continuity plan's source of truth. The call tree reaches the teams that own tier-1 activities first and escalates them on shorter timers. During an incident, staff check-ins are counted against each activity's minimum staffing, so executives can see which critical activities are short-handed without seeing names. Exercises are planned to cover the hazards the activities are linked to. And two links run back to the risk side: closing an incident creates a draft loss event for the risk manager to complete, and every change of continuity level for a hazard is recorded as an observation on that hazard's indicator.

5

Where it usually breaks

  • RTO longer than MTPD. The recovery target is set by what the IT team can promise rather than by what the business can tolerate, and nobody notices the contradiction.
  • A tier chosen by the department. Every unit rates itself critical. The call tree has no first call.
  • Dependencies without a single-point-of-failure flag. The one supplier, the one person with the password, the one site — listed, but never turned into an action.
  • No version. The BIA is edited in place. When the regulator asks which analysis applied on the day of the incident, there is no answer.
6

In Risk Core

Risk Core — powered by Qirin X · ComplyWise. The BIA is desk work in ERM Core: unit heads and Risk Champions draft their own team's activities with MTPD, RTO, RPO, minimum staff and peak period; the system computes the criticality tier from the group's MTPD bands and refuses an RTO longer than the MTPD; dependencies are recorded in five kinds with a single-point-of-failure flag, and a SPOF with no workaround creates an action item; activities link to the entity's own risks and to the shared hazard types; and approval by the entity's own Entity Risk Manager or BCP head creates a new version, with every earlier version kept.

BCP Core reads the approved version. The call tree reaches tier-1 activities first and escalates them on their own timers; during an incident, check-ins are counted against minimum staffing per activity, as counts, never names, readable by HR and executives; exercises cover the linked hazards. Closing an incident creates a draft loss event in ERM Core, and each hazard's BCP level is recorded as a KRI observation. A parent company reads a subsidiary's BIA through report-up and cannot approve or change it.

Platform summary and the ComplyWise services around it: Risk Core. Product documentation: BIA overview, Critical activities and Linking to risks and hazards on Risk Core Docs.

7

The series

Six articles, one stage at a time. Each one explains the framework first and ends with how Risk Core implements it.

  1. 1

    Enterprise risk management in practice: the six-stage risk life cycle

    ERM in practice · 1 of 6 · October 2026

  2. 2

    RCSA in practice: a risk score nobody can type

    ERM in practice · 2 of 6 · October 2026

  3. 3

    Loss events in practice: the tier is computed, the month is always filed

    ERM in practice · 3 of 6 · October 2026

  4. 4

    Key risk indicators in practice: three bands, versioned thresholds, every Red is an action

    ERM in practice · 4 of 6 · October 2026

  5. 5

    From the business impact analysis to the continuity plan: how a recovery time becomes a call-tree order

    ERM in practice · 5 of 6 · October 2026

  6. 6

    Group risk governance in practice: each company runs its own, the parent reads up

    ERM in practice · 6 of 6 · October 2026

8

Frequently asked questions

What is the difference between MTPD, RTO and RPO?
MTPD is how long the business can tolerate the activity being down before the impact becomes unacceptable. RTO is the target for having it running again, and must be shorter than or equal to the MTPD. RPO is how much data, measured in time, can be lost — the gap between the last usable backup and the disruption.
How often should a business impact analysis be reviewed?
At least once a year, and after any significant change to products, systems, suppliers or structure. Each approval should be kept as a version so the company can show which analysis applied at any date.
What is a single point of failure in a BIA?
A dependency — a person, site, system, supplier or data set — whose failure stops the activity with nothing able to stand in. A single point of failure with no workaround should become an action item with an owner and a due date.
How does the BIA connect to the risk register?
Each critical activity is linked to the risks that threaten it. The BIA then shows the residual score of each linked risk, and the register shows which risks protect a critical activity — so the risk assessment and the continuity analysis describe the same business.
9

Sources

  1. Risk Core Docs — BIA overview: purpose under ISO 22301 cl. 8.2.2, the annual cycle, how BCP Core uses the result
  2. Risk Core Docs — Critical activities: MTPD, RTO, RPO, minimum staff; the computed criticality tier
  3. Risk Core Docs — Linking BIA activities to RCSA risks and hazard types
  4. Risk Core Docs — External KRIs from BCP Core: Normal to Green, Standby to Amber, Activated to Red
  5. Risk Core Docs — Product rules: the seven rules Risk Core enforces in the database
  6. Risk Core Docs — Standards mapping: COSO ERM (2017), ISO 22301:2019 and the Basel event types
  7. ISO 22301:2019 — Security and resilience — Business continuity management systems — Requirements

Accessed and last reviewed . Each figure and table cell is traced to a source above.

All insights

Planning a regulated business? Start with a 30-minute assessment.

Book a consultation business@complywise.co.th