Learn
An ISO 22301 business impact analysis (BIA) turns the question of what matters most into numbers an auditor can test. For each activity behind your products and services it records how the damage from stopping grows over time, the point at which that damage becomes unacceptable (the maximum tolerable period of disruption, MTPD), an earlier target for resuming at a minimum acceptable capacity (the recovery time objective, RTO), and the people, data, technology, sites, suppliers and money the activity needs. Clause 8.2.2 of ISO 22301:2019 requires it and leaves the method to you; ISO/TS 22317:2021 is ISO's guidance on running one. Two rules make the result survive an audit: every RTO sits inside its MTPD with time left to detect and decide, and nothing an activity depends on takes longer to recover than the activity's RTO.
This guide gives a business continuity manager or operational resilience lead a BIA that holds up when a certification auditor or a supervisor samples it. You get impact criteria and time bands that management will sign; a worked example for a payment institution's outgoing payments, from impact scores to an MTPD of 8 hours and an RTO of 4; the dependency check that catches the supplier who cannot keep up; a recovery point for each data set; and the way the same numbers serve DORA, NIS2 and APRA's CPS 230. A fill-in worksheet closes the page. For the rest of the standard, clause by clause, start with our guide to the ISO 22301 requirements.
| Output | What it is | How an auditor tests it |
|---|---|---|
| Impact criteria | Categories such as financial, customer, regulatory, contractual and reputational, with a scale for each and a line where impact becomes unacceptable | Asks who approved them, and when |
| Activity list | The activities that deliver each product or service in scope | Picks a product and asks which activities deliver it |
| Impact over time | For each activity, a score in every category at each time band | Checks the scores against the approved scale |
| MTPD | The first time band at which a category reaches the unacceptable line | Reads it off the impact record |
| RTO and minimum capacity | The target for resuming, at a stated and measurable level of service | Checks that the RTO sits inside the MTPD with room to detect and decide |
| Prioritised activities | The activities that need continuity arrangements, in order | Checks the order follows the time frames |
| Resources and dependencies | People, information and data, ICT, sites, equipment, suppliers and finance, each with its own recovery time | Checks that every dependency recovers inside the activity's RTO |
What does ISO 22301 require the business impact analysis to produce?
Clause 8.2.2 asks for a BIA process that determines your continuity priorities and requirements, and in practice that means the outputs in the table above. Three things in the wider standard shape how you run it. Clause 8.2.1 leaves the order of the BIA and the risk assessment to you, so you can analyse impact first and look at causes second, which keeps the priorities independent of whichever threats are in the news. The BIA feeds clause 8.3, where strategies and solutions are chosen to meet its time frames, and clause 8.4, where plans carry them out. And clause 8.6 sends exercise results, incidents and significant changes back into it, so the numbers are revisited whenever they may have moved.
The BIA and the risk assessment answer different questions. The BIA asks what happens if an activity stops, whatever the cause; the risk assessment in clause 8.2.3 asks what could stop it. DORA keeps the same separation: Article 11(5) asks for a business impact analysis of exposure to severe business disruptions, while Article 8 asks financial entities to identify and assess ICT risk. Mixing the two produces a risk register with recovery times in it, which satisfies neither.
Which terms does ISO 22301 define: MTPD, RTO, RPO or MBCO?
None of them. Clause 3 of ISO 22301:2019 lists its terms in alphabetical order, and ISO's own sample of the standard shows the sequence running from management system straight to measurement, and from products and services straight to requirement. There is no room in between for maximum tolerable period of disruption, maximum acceptable outage, minimum business continuity objective, recovery point objective or recovery time objective. The BIA clause describes the two time frames and gives MTPD and RTO only as labels in notes; it does not mention a recovery point objective at all. MAO and MBCO come from material written for the 2012 edition, which is why they still turn up in templates.
The practical consequence is that your BIA methodology has to define each term once, so that the payments team and IT mean the same thing by recovery time. Where a regulator uses a term, adopt its meaning.
| Concept | Definition for your methodology | DORA | APRA CPS 230 |
|---|---|---|---|
| MTPD | The time after which the impact of not resuming an activity becomes unacceptable | Not named; Article 12(6) asks that agreed service levels are met in extreme scenarios | Maximum period of disruption, paragraph 38(a) |
| RTO | The target time to resume an activity at minimum acceptable capacity; always shorter than the MTPD | Recovery time objective for each function, Article 12(6) | Must keep the operation within its tolerances |
| RPO | The most data you accept losing for a data set, measured in time | Recovery point objective for each function, Article 12(6) | Maximum extent of data loss, paragraph 38(b) |
| Minimum acceptable capacity | The level of service during recovery, in measurable terms | Agreed service levels, Article 12(6) | Minimum service levels, paragraph 38(c) |
How do you set impact categories and time bands?
Start with the criteria, before any department fills anything in. For each category, write what each score means in your own terms, and have top management approve the scale and the line at which impact becomes unacceptable. An illustrative scale for a payment institution:
| Score | Financial | Customers | Regulatory and contract | Reputation |
|---|---|---|---|---|
| 1 Minimal | Under EUR 10,000 | A delay few customers notice | None | None |
| 2 Minor | EUR 10,000 to 100,000 | Complaints rise | An internal service level missed | Local mentions |
| 3 Moderate | EUR 100,000 to 1 million | Customers miss their own deadlines | Contractual penalties | Trade press |
| 4 Major: unacceptable | EUR 1 to 5 million | Payments miss settlement | Notifiable to a supervisor or scheme | National press |
| 5 Severe | Over EUR 5 million | Customers leave | Supervisory action | Sustained national coverage |
Then choose time bands that match how your business fails. A payments business needs hours: 1, 4, 8 and 24 hours, then 3 days. An asset manager may need days. Consider when the disruption hits as well as how long it lasts: settlement cut-offs, month end, payroll and regulatory reporting dates turn an average-day MTPD into an optimistic one.
Run the analysis in workshops with the people who own each activity. They know which customer gives up first, and they are the ones who have to sign the result.
Worked example: how do you get from impact scores to an MTPD and RTO?
Take outgoing customer payments at a payment institution, an activity that has to make same-day settlement cut-offs. Using the approved criteria above, the activity owner scores the impact of a stoppage at each time band:
| Time band | Financial | Customers | Regulatory and contract | Reputation | Highest score |
|---|---|---|---|---|---|
| 1 hour | 1 | 1 | 1 | 1 | 1 |
| 4 hours | 2 | 3 | 2 | 1 | 3 |
| 8 hours | 3 | 4 | 4 | 2 | 4: unacceptable |
| 24 hours | 4 | 5 | 4 | 3 | 5 |
| 3 days | 5 | 5 | 5 | 4 | 5 |
Two categories reach 4 at 8 hours, because that is when customers miss the same-day cut-off and the scheme's rules start to bite. The MTPD is therefore 8 hours, and the RTO has to sit well inside it.
Work backwards from the MTPD. The last two exercises showed it takes about 30 minutes to detect a payment platform failure and another 30 to convene the crisis team and decide to invoke the plan. Recovering to minimum acceptable capacity takes up to 3 hours. That gives an RTO of 4 hours: one hour to detect and decide, three to recover. The 4 hours left before the MTPD are the margin for a slow decision, a restore that fails at the first attempt and a backlog that grows while you recover.
Define the minimum capacity in measurable terms: 60% of normal payment volume, with priority and time-critical payments first, rising to full volume within 24 hours. That figure decides how many staff, which systems and how much connectivity the recovery needs, and it is what clause 8.3 will ask the solutions to deliver.
How do dependencies change the answer?
Now list everything the activity needs and give each dependency its own recovery time, taken from evidence: a test result for an ICT service, the contract for a supplier, the staffing plan for a team. Then apply the second rule: nothing may take longer to recover than the activity's RTO.
| Dependency | Type | Recovers in | Inside the 4 hour RTO? | Recovery point |
|---|---|---|---|---|
| Payment engine, active and standby | ICT system | 1 hour, failover | Yes | Zero |
| Core ledger database | Data | 2 hours, restore | Yes | 5 minutes |
| Scheme gateway, run by a third-party provider | Supplier | 6 hours, per contract | No | Not applicable |
| Sanctions screening service | Supplier | 2 hours, per contract | Yes | Not applicable |
| Payments operations team, 6 of 10 people | People | 1 hour, remote working | Yes | Not applicable |
| Head office floor | Building | Not needed | Yes | Not applicable |
The scheme gateway fails. Its contract allows 6 hours, so in a real disruption the payments wait for the provider whatever the payment engine does. There are three honest ways out: a second provider or route, a contract term that matches the 4 hours (and the BIA is the evidence for that negotiation), or a decision by management to accept the risk, recorded with a review date. ISO 22301 does not let the gap stay silent: clause 8.3 asks for solutions that meet the BIA's time frames, and an auditor tracing the chain will find it.
Dependencies hide in two places. Group services are often left out because they feel internal, and suppliers have suppliers of their own. Treat group services exactly like external providers, and use your supplier reviews to find the fourth parties; our guide on how to perform a third-party risk assessment covers the method, and for financial entities the DORA register of information records the subcontracting chain for ICT services.
How do you set the RPO for each data set?
The recovery point objective is the most data you accept losing, measured in time: an RPO of 5 minutes means you can lose at most the last 5 minutes of transactions. Set it for each data set, because one activity uses several, and then check that the backup or replication design delivers it.
| Data set | RPO | What delivers it | Evidence |
|---|---|---|---|
| Payment instructions and their status | Close to zero | Synchronous replication to the standby site | Switchover test and reconciliation |
| Customer and beneficiary reference data | 24 hours | Daily backup to a segregated copy | Restore test |
| Sanctions screening results | 1 hour | Provider log retention and replay | Contract term and test record |
| Reporting warehouse | 72 hours | Rebuild from the source systems | Rebuild run |
ISO 22301 does not define the term, so put it in your methodology. Regulators do use it. DORA Article 12(6) requires recovery time and recovery point objectives for each function, set with regard to whether the function is critical or important and to the potential impact on market efficiency, and ensuring that agreed service levels are met in extreme scenarios. Article 12(1) then ties the scope and minimum frequency of backups to the criticality of the information. CPS 230 paragraph 38 asks for a tolerance for the maximum extent of data loss for each critical operation. The RPO also has to pass the dependency rule: if the backup runs nightly, no RPO shorter than a day is real.
Who should validate and approve the business impact analysis?
Look for three sign-offs, because an auditor will. Top management approves the impact criteria and the unacceptable line before the analysis starts. Each activity owner validates the results for their activity. Top management then approves the summary, with the prioritised activity list. A BIA written by the continuity team or by IT, with timescales nobody in the business agreed, shows in the first interview: ask the activity owner where the RTO came from.
For a financial entity the governance is written into the law. DORA Article 5(2)(e) makes the management body approve and periodically review the ICT business continuity policy and the ICT response and recovery plans, and Article 24 of Delegated Regulation (EU) 2024/1774 requires that policy to state its objectives in the light of the BIA results. Under CPS 230 paragraph 22, the Board approves the business continuity plan and the tolerance levels for critical operations.
How often must the business impact analysis be reviewed?
ISO 22301 sets no fixed interval. Clause 8.2.1 requires the business impact analysis and the risk assessment to be reviewed at planned intervals and when significant changes occur in the organisation or its context, and clause 8.6 sends the lessons of exercises, incidents and changes back into them. A yearly review is the practical minimum, because a certification body visits every year and will ask what changed. Triggers for an earlier review: a new product or channel, a new or changed supplier behind a prioritised activity, a reorganisation, a move of site or data centre, a real disruption, and an exercise that missed its RTO.
Financial entities have a firmer anchor. DORA Article 8(1) requires the classification of business functions and their supporting assets to be reviewed as needed and at least yearly, and Article 6(5) requires the ICT risk management framework, which includes the continuity policy, to be reviewed at least once a year. Keep the BIA on the same cycle so that the two never disagree about what is critical. Our guide to writing a DORA ICT risk management framework shows where that review sits.
How does the ISO 22301 BIA line up with DORA, NIS2 and CPS 230?
| Rule | What it asks of the BIA | What to add to an ISO 22301 BIA |
|---|---|---|
| DORA Article 11(5) | A BIA of exposure to severe business disruptions, using quantitative and qualitative criteria, internal and external data and scenario analysis, covering the criticality of business functions, support processes, third-party dependencies and information assets and their interdependencies; ICT designed in line with it | Severe-disruption scenarios; a reconciliation with the critical or important functions list and the register of information |
| DORA Article 12(6) | Recovery time and recovery point objectives for each function | An RPO for each data set, rolled up to each function |
| RTS (EU) 2024/1774, Articles 24 to 26 | The ICT continuity policy, the testing and the ICT response and recovery plans all built on the BIA results | A visible line from BIA to plan to test |
| NIS2, IR (EU) 2024/2690, Annex point 4.1.3 | A BIA of severe disruptions that sets continuity requirements for network and information systems, for the digital infrastructure and digital provider entities it covers | Continuity requirements for each system, derived from the BIA |
| APRA CPS 230, paragraphs 35 to 39 | Critical operations, including the minimum list in paragraph 36, each with three tolerance levels approved by the Board | A mapping from prioritised activities to critical operations, with MTPD, RPO and minimum capacity expressed as tolerances |
For a financial entity the DORA rows matter most, and they reach well beyond the BIA. Our comparison of ISO 22301 vs DORA goes through Articles 11 and 12 and the RTS article by article, with what a BCMS already covers and what to add.
What do the other results get wrong?
We read eight of the nine pages ranking for "ISO 22301 business impact analysis" in October 2026; the ninth refused automated access. Most are short, three are template sales pages, and the mistakes cluster in the same places.
Terms credited to the standard. One guide says ISO 22301:2019 works with MTPD, RTO, RPO and MBCO, presenting all four as the standard's own vocabulary. The 2019 edition defines none of them. A methodology that assumes the standard defines its terms usually leaves them undefined, and then two departments measure different things.
An example without its outer bound. The same guide's worked table gives each process an RTO and an RPO but no MTPD, so a reader cannot check the first rule. Its opening paragraph also calls an online retailer's 24 hour website less critical than a drinks company's marketing service, which its own table then contradicts by rating online sales critical from the first time band and marketing low.
Vocabulary the standard does not use. A page devoted to clause 8.2.2 tells readers to determine each activity's maximum acceptable downtime, a term the standard does not define, without saying how it relates to the MTPD.
The second rule, missing everywhere. None of the eight pages states that a supporting resource must recover inside the RTO of the activity that depends on it, and none leaves time in the MTPD for detecting a disruption and deciding to act. Both are where real BIAs fail when an auditor samples them.
Regulation left out. Only one of them mentions DORA at all, and none mentions recovery objectives per function under Article 12(6), the BIA point in the NIS2 Implementing Regulation or the CPS 230 tolerance levels, which is where a financial entity's BIA is now tested.
Fill-in BIA worksheet
Copy this for each activity. A blank cell is a gap an auditor will find.
| Field | Your answer | Check |
|---|---|---|
| Activity and owner | The owner signed the result | |
| Products or services it delivers | Matches the BCMS scope | |
| Impact scores at 1 hour, 4 hours, 8 hours, 24 hours and 3 days | Uses the approved scale | |
| MTPD | The first band at the unacceptable line | |
| Time to detect and decide | Taken from exercise records | |
| RTO | No longer than the MTPD minus the time to detect and decide, with margin | |
| Minimum acceptable capacity | Measurable: volume, staff, channels | |
| Peak periods and cut-offs | Reflected in the scores | |
| Dependencies, each with its recovery time | Every one inside the RTO | |
| Data sets, each with its RPO | Delivered by the backup or replication design | |
| Gaps and decisions | Solution chosen, or risk accepted by management with a review date |
How does Venvera help with the business impact analysis?
Venvera keeps the BIA's paper trail in one place: every requirement, owner, task, deadline and piece of evidence in one dashboard instead of Outlook, Excel and mail chains. The ISO 22301 module includes a BIA methodology policy template, puts the yearly BIA review on the compliance calendar with an owner and a lead time, and its gap assessment asks the questions in this guide: whether every RTO sits inside its MTPD, whether an RPO is set for each data set and whether minimum capacity is stated in measurable terms. Workshops, owner validations and approvals become tasks with owners and due dates, and the signed results sit as evidence against clause 8.2.2, where the auditor will look for them. Venvera records the BIA and its approvals; it does not calculate your recovery times or test your systems.
Start with a free compliance check, book a demo, or start a 14-day Professional trial with no credit card. Pricing starts at EUR 399 per month for two frameworks.
Frequently asked questions
Is a business impact analysis mandatory for ISO 22301?
Yes. Clause 8.2.2 requires a business impact analysis process, and the rest of clause 8 depends on its outputs. No certification audit gets past clause 8 without one.
What is the difference between the MTPD and the RTO?
The MTPD is the point at which the impact of not resuming an activity becomes unacceptable. The RTO is the earlier target for resuming it at minimum acceptable capacity. The RTO always sits inside the MTPD, with room to detect and decide.
Can the RTO equal the MTPD?
No. An RTO equal to the MTPD leaves no time to detect the disruption, decide to invoke the plan or recover from a first attempt that fails, so any delay at all takes the impact past the unacceptable line.
Does ISO 22301 require a recovery point objective?
The standard does not define the term and its BIA clause does not mention it, but data is one of the resources every solution must cover. DORA Article 12(6) requires an RPO for each function and CPS 230 a data loss tolerance for each critical operation, so set one for each data set.
What is minimum acceptable capacity?
The level of service you will run at during recovery, in measurable terms such as transactions per hour, staff or channels. Older material calls it the minimum business continuity objective. It decides how much the recovery solution has to deliver.
Should the BIA or the risk assessment come first?
Clause 8.2.1 lets you choose. Doing the BIA first keeps the priorities independent of particular threats; the risk assessment then asks what could disrupt the prioritised activities and their resources.
How many activities should a BIA cover?
Every activity that delivers a product or service inside the BCMS scope. A smaller firm often ends up with ten to twenty. Only the prioritised ones need continuity arrangements, but the others need a recorded reason for falling below the line.
Is a spreadsheet good enough for a BIA?
It can be, if it is versioned, approved and reviewed on schedule. Spreadsheets struggle with dependencies shared across many activities and with keeping approvals and evidence attached to the numbers.
Do we have to follow ISO/TS 22317?
No. ISO/TS 22317:2021 is guidance, and ISO describes it as not prescribing a uniform process. It is a sound method to adapt, and an auditor will accept any approach that produces the outputs clause 8.2.2 asks for.
How does the BIA relate to DORA's critical or important functions?
They must agree. If the BIA prioritises an activity that the DORA classification or the register of information does not treat as critical or important, or the other way round, a supervisor will ask which one is wrong.
Primary sources
The clause 3 term sequence is taken from ISO's official sample of ISO 22301:2019, and the description of ISO/TS 22317 from its catalogue entry. The regulatory provisions are from Regulation (EU) 2022/2554 (Articles 5, 6, 8, 11 and 12), Commission Delegated Regulation (EU) 2024/1774 (Articles 24 to 26), Commission Implementing Regulation (EU) 2024/2690 (Annex section 4) and APRA Prudential Standard CPS 230 (paragraphs 22 and 34 to 44). The worked example, its scores and its dependencies are illustrative. The descriptions of ISO 22301 clauses are our own summaries; read the standard before relying on a specific requirement.
