How BIA Results Inform Your Risk Assessment: A Practical Guide for DORA and ISO 22301
The business impact analysis (BIA) and the enterprise risk register are two distinct documents that answer different questions. The BIA measures what a disruption to a process does to the business and how fast the process must recover. The risk register catalogues risks, such as a tornado or a vendor failure, each with a probability, an impact and a treatment. The BIA informs the risk assessment; it does not replace it. A vendor change shows the difference: it rarely means redoing the BIA, but it always means reassessing vendor risk against the recovery times the BIA has already set.
How do the BIA and the risk register differ?
The BIA usually lives in a continuity tool or spreadsheet owned by the resilience team. The risk register lives in a GRC platform or spreadsheet owned by the risk function. Each is updated on its own cycle.
The vocabularies differ, but they are driven by shared concerns. Continuity teams speak of critical activities, the maximum tolerable period of disruption (MTPD) and the recovery time objective (RTO). Risk teams speak of assets, impact ratings and appetite, and may call a recovery expectation a tolerance. An RTO is an RTO whatever each team calls it.
But the scope is different. The BIA covers business processes and asks what a disruption does to each, whatever the cause. The register covers risks, and only some risks touch any given process. Vendor risk provides the clearest example: a process may depend on one vendor, several or none. The two overlap, and the BIA feeds the risk assessment, but neither contains the other.
The register also needs something the BIA does not supply: probability. Without it a risk cannot be rated or prioritized, because a 1% chance and a 50% chance of the same disruption call for different treatment.
Which BIA outputs inform the risk assessment?
Seven BIA outputs inform the risk assessment. The register references them rather than copying them as fields, and adds the threat, the probability and the treatment.
| BIA output | What the risk assessment takes from it | How it is used | Owner |
|---|---|---|---|
| Critical process or activity | Scope of the assessment | Defines which risks are in scope: those that could disrupt the process. The process itself is not a register entry. | BC lead supplies, risk owner uses |
| Impact tier or MTPD | Impact rating | Informs the impact score. Probability is rated separately and combined with impact to rate the risk. | Risk owner |
| Recovery time objective (RTO) | Risk tolerance threshold | Gives the recovery expectation that a vendor SLA or recovery capability is compared against. A shortfall is a risk to rate and treat. | Risk owner with BC lead |
| Recovery point objective (RPO) | Control requirement | Specifies the backup and data controls the assessment tests for. | IT or ICT risk |
| Upstream dependencies (systems, suppliers, sites, people) | Threats to assess, third-party risks, single points of failure | Each critical dependency prompts the question of what could fail it. Only credible threats become register entries. Supplier dependencies feed third-party risk management. | BC lead, third-party risk |
| Minimum operating level | Residual risk target | Defines what "acceptable" looks like during disruption. | Process owner |
| Known gaps found in the BIA | Treatment actions | Each gap is assessed for probability and impact. Where it is a risk, the treatment action carries an owner and a date. | Risk owner |
Reference a BIA output from a register entry only if it changes an impact rating, a tolerance threshold, a control requirement or a treatment action.
Recovery procedures, call trees and workaround steps stay in the business continuity plan. The register holds the threat, its probability, its impact and its treatment. Where a risk touches a process, cite the BIA process ID and the relevant plan by reference ID so a reader can move between the documents.
How do you keep both sides current?
Review should be event-driven as well as calendar-driven. The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) takes the same approach. Article 6(5) requires the ICT risk management framework to be documented and reviewed at least once a year, or periodically for microenterprises, and after major ICT-related incidents, supervisory instructions, or conclusions drawn from relevant digital operational resilience testing or audit processes. Article 8(3) requires financial entities other than microenterprises to perform a risk assessment upon each major change in the network and information system infrastructure or in the processes or procedures affecting their ICT-supported business functions. Article 13(3) requires lessons from testing and real incidents, including challenges met when continuity plans are activated, to feed the ICT risk assessment process on a continuous basis.
- The register runs on its own cycle. Risks are reassessed periodically against facts and data: incident records, test results, vendor performance and changes in the threat picture.
- BIA results are an input, not a trigger. A new critical process, a shortened RTO or a changed dependency gives the risk assessment new impact and recovery expectations to test against. The BIA and wider business continuity planning run in parallel on their own cycle.
- Events reassess only the risks they touch. Organisational change, new regulation, a major outsourcing decision or an exercise finding sends the affected risks back for assessment, not the whole register.
Agree who owns each document and each risk. The process owner confirms that the impact and recovery expectations used match the current BIA. Review the register on a fixed cycle, and any risk an event touches when it occurs.
How do the two documents evidence DORA and ISO 22301?
DORA applies to in-scope financial entities. ISO 22301:2019 is a voluntary standard. Neither prescribes a register field mapping, so the table maps each element, from the BIA or from the risk assessment, to the provisions it supports.
| BIA or risk assessment element | DORA | ISO 22301:2019 |
|---|---|---|
| Business impact analysis | Article 11(5) | Clause 8.2.2 business impact analysis |
| Critical or important functions and their dependencies | Article 8(1) identification and documentation of ICT-supported business functions and their dependencies. Article 8(5) processes that depend on ICT third-party providers. Article 28(3) register of information on contractual arrangements for ICT services. | Clause 8.2.2 |
| RTO, RPO and tolerance thresholds | Article 6(8)(b) ICT risk tolerance and impact tolerance. Article 12(1) backup policies and procedures. Article 12(6) recovery time and recovery point objectives. | Clause 8.2.2 (prioritised timeframes). Clause 8.3 business continuity strategies and solutions. |
| Risks to those functions, their probability and their treatment | Article 6 ICT risk management framework | Clause 8.2.3 risk assessment. Clause 6.1 actions to address risks and opportunities. |
| Testing and exercising evidence | Article 11(6) annual testing of continuity and recovery plans. Article 24(6) annual testing of | Clause 8.5 exercise programme. Clause 9.1 |
| ICT systems supporting critical or important functions. Article 26(1) threat-led penetration testing. | monitoring, measurement, analysis and evaluation. |
Article 11(5) requires a BIA, so the BIA is itself regulatory evidence as well as an input to the risk assessment. Article 26(1) threat-led penetration testing applies only to entities that competent authorities identify, and then at least every three years. Articles 11(6) and 24(6) set annual testing.
What does this look like in practice?
A payments firm moves settlement processing to a new third-party vendor. The BIA gave settlement a two-hour RTO. If the process, dependency model, criticality, and recovery expectation have not changed, the BIA can stand. But the immediate question is whether the new vendor can meet that number.
The risk owner takes the RTO from the BIA and compares it with the vendor's service level agreement (SLA), which commits to recovery within eight hours. The six-hour gap is a vendor risk. The register entry records the threat (a vendor outage), the probability of one, the impact on settlement drawn from the BIA, and the resulting rating.
Treatment follows from the rating. The firm may negotiate a shorter recovery commitment, arrange a fallback vendor or a manual workaround, or accept the risk with the process owner's sign-off. Whichever it chooses, the decision is recorded against the vendor risk. The BIA is revisited only if the business concludes that the two-hour RTO itself was wrong.
Without the comparison, the two-hour RTO would have stayed in the continuity tool while the vendor's eight-hour SLA sat unexamined in a contract file.
Where do you start if you are on spreadsheets today?
- Add one cross-reference column to each sheet, not merged fields. On the BIA sheet, list the related risk IDs for each process. On the register, list the affected BIA process IDs for each risk. A risk touches only some processes, so each side holds its own data.
- Start with vendors. For each critical vendor in the BIA's dependencies, compare the vendor SLA recovery time with the process RTO. Every shortfall is a vendor risk to rate and treat, and under DORA, those vendors fall within ICT third-party risk management obligations.
- Write the review rules down. A one-page rule states how often the register is reviewed, which events send affected risks back for assessment, and who owns each.
Is business continuity a subset of risk management?
Partly. ISO 22301:2019 clause 8.2.3 requires a risk assessment of threats to prioritised activities, while clause 8.2.2 adds the BIA, which sets recovery timeframes that a risk register does not produce on its own.
Should the BIA or the risk assessment come first under ISO 22301?
The standard sets out the BIA at clause 8.2.2 and the risk assessment at 8.2.3, and the risk assessment examines risks to the activities the BIA has prioritised. Run the BIA first and use its outputs to scope the risk assessment.
Does DORA require a business impact analysis?
Yes. Article 11(5) of DORA requires financial entities to assess the effect of severe business disruptions using quantitative and qualitative criteria, and to design and use ICT assets and services in full alignment with that analysis. Article 12(6) then requires recovery time and recovery point objectives for each function.
Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, L 333, 27 December 2022, p. 1. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
ISO 22301:2019, Security and resilience: Business continuity management systems: Requirements. 2nd edition, International Organization for Standardization, October 2019. https://www.iso.org/standard/75106.html
This article was written by Mitratech. Learn more at mitratech.com.
More on
