What is a business impact analysis (BIA)?

A business impact analysis is the first analysis in a continuity program, and every recovery number after it should trace back to it. The recovery times in the plan, the backup schedule, the order the systems come back in and the recovery clause in a supplier contract are either derived from the BIA or made up.

It ends with four numbers for each process. The maximum tolerable period of disruption (MTPD) is how long the process can be stopped before the harm becomes unacceptable. The recovery time objective (RTO) is the time within which it has to be running again, at least at a minimum level, and it sits inside the MTPD. The recovery point objective (RPO) is how much data, measured in time, the process can afford to lose. The minimum level is the capacity it restarts at.

Check the edition before citing anything. ISO 22301:2019, with its 2024 climate amendment, is current, and a revision was approved as a work item in November 2025 with no publication date yet. The vocabulary was reissued as ISO 22300:2025 on 6 November 2025. The 2019 edition of ISO 22301 also stopped defining MTPD as a term while still requiring the idea, which is one reason older names such as MAO survive.

Why a business impact analysis matters

Without one, other things decide recovery. The IT team's server list, or whoever shouts loudest, sets the order systems come back in. Backups run as often as the budget allows, whatever the data needs. And plans promise recovery times that the systems and suppliers underneath them cannot meet, which nobody discovers until the day it matters.

The same outage does different harm to different processes, and the harm grows at different speeds. A day without systems costs a dairy factory's export paperwork almost nothing. The same day costs its milk intake far more, because farm vats keep filling whether or not the tankers can unload. Only a rating over time shows which process has to come back first.

A cyber incident is a continuity event like any other. In June 2020 ransomware disrupted Lion, the Australian beer, dairy and drinks company, which said its teams were "implementing new manual processes and investigating all alternative options". With a BIA, an organisation decides in advance which manual processes it will need, and how soon.

Who asks for one, and under which document:

• An ISO 22301 certification auditor reads clause 8.2.2: impact criteria, the activities behind each product and service, their impact over time, the time frame after which not resuming becomes unacceptable, and the resources and dependencies they need, suppliers included.
• An ISO/IEC 27001:2022 auditor reaches it through Annex A control 5.30, ICT readiness for business continuity. The ISO/IEC 27002 guidance for that control expects ICT continuity to be planned from the BIA's impact criteria, prioritised activities and recovery objectives.
• Under Article 11(5) of the Digital Operational Resilience Act (DORA), which has applied since 17 January 2025, EU financial entities must conduct a business impact analysis of their exposure to severe business disruptions. DORA is the one regulation here that names the BIA.
• APRA-regulated entities set tolerance levels for each critical operation under CPS 230 paragraph 37, approved by the Board. Neither CPS 230 nor its practice guide uses the phrase "business impact analysis"; a BIA is how the numbers get produced.
• UK firms under the Financial Conduct Authority's operational resilience rules set an impact tolerance for each important business service.
• US federal agencies follow NIST SP 800-34 Rev. 1, where conducting the BIA is the second of seven contingency planning steps.
• As plain practice, customers' supplier requirements, insurers at renewal and boards ask for the same analysis.

NIST IR 8286D-upd1 (February 2025) extends the method beyond availability, to the confidentiality and integrity harm of losing an asset. This guide stays with the continuity BIA.

How a business impact analysis works, step by step

The standards agree on the shape and differ mostly in vocabulary: ISO 22301 sets the requirement, ISO/TS 22317:2021 gives the guidance, NIST SP 800-34 Rev. 1 gives a free template, and the Business Continuity Institute's Good Practice Guidelines describe the practice. Four ideas explain the steps, so they come first.

Where a BIA sits in a continuity program

ISO 22301's clause 8 runs in order: operational planning and control (8.1), business impact analysis and risk assessment (8.2), business continuity strategies and solutions (8.3), plans and procedures (8.4), the exercise programme (8.5), and evaluation of the documentation and capabilities (8.6). The BIA sits at the front beside the risk assessment, and everything after it takes its numbers from the analysis. NIST SP 800-34 Rev. 1 runs the same order in seven steps, with the BIA second, straight after the policy statement.

The return line matters as much as the forward ones. The 2019 edition of ISO 22301 added a requirement to review the BIA and the risk assessment at planned intervals and when significant changes occur, and it made information from both an input to management review in clause 9.3.

The four numbers on one timeline

Put the four numbers on one clock and they stop being confusing. The disruption sits at zero. The RPO looks backwards from it: anything written after the last good copy is gone. The RTO and the MTPD look forwards.

NIST states the rule that ties those two: "Because the RTO must ensure that the MTD is not exceeded, the RTO must normally be shorter than the MTD." Its reason is the one most BIAs miss. A system coming back does not mean the work has caught up. Reprocessing, clearing queues and keying paper records all take time, and that time has to fit between the RTO and the MTPD. The UK's Financial Conduct Authority says the same about its own rules: "It's common therefore to see recovery time objectives set well within impact tolerances to ensure you can remain within tolerance." Some practitioners call the interval work recovery time (WRT) and write MTD = RTO + WRT, a shorthand that neither ISO 22301 nor SP 800-34 uses.

The RPO is measured on a different axis. In NIST's words, "Unlike RTO, RPO is not considered as part of MTD." APRA's practice guide CPG 230 notes that it is normally used to set how often point-in-time backups run.

The fourth number is the level the process restarts at. ISO 22301:2012 called it the minimum business continuity objective (MBCO). The 2019 edition speaks of resuming at a specified minimum acceptable capacity, and CPG 230 calls it the recovery level objective. All three mean the capacity the process must reach by the RTO, usually through a manual workaround and well short of normal.

The same line under different names

The MTPD is the number with the most names. NIST SP 800-34 Rev. 1 calls it the maximum tolerable downtime (MTD), and notes that its first edition used maximum allowable outage (MAO). ISO 22301:2012 defined MTPD, and the term is still the common one in practice. ISO 22301:2019 asks for the idea without a term: the time frame within which not resuming would become unacceptable. Regulators add their own. APRA's CPS 230 asks for the maximum period of disruption an entity would tolerate, CPG 230 Table 4 maps that to maximum allowable disruption, and the FCA asks for an impact tolerance.

One difference is real rather than verbal. Regulators set the line for a critical operation or an important business service, and a board approves it; ISO and NIST set it for an activity or a process. A regulated entity needs both. The guide to APRA CPS 230 covers critical operations and the three tolerance levels in full.

The levels a BIA works at

The BCI's Good Practice Guidelines, Edition 7.0, describe three variations: a product and service BIA, a process BIA and an activities BIA. They mark the process BIA as optional and generally performed by process-driven organisations such as manufacturers. NIST adds a view underneath, separating continuity of operations (COOP) from systems: "COOP functions are subject to a process-focused BIA; federal information systems are subject to a system-focused BIA." The system BIA in SP 800-34 maps one information system's components to the processes it supports.

The levels nest, and the time frames tighten as you go down. A process cannot recover later than the product it serves needs. An activity cannot recover later than its process, and a system cannot recover later than the activities that run on it. Start at the top and the system targets fall out of the analysis. Start at the bottom, with the server list, and you get recovery times nobody can trace to a customer.

The ten steps

The method is ten steps, and each leaves behind something the next step needs.

Two of the steps carry most of the weight. Step 2 writes the criteria before anyone rates: what each impact level means in each category, and which level is unacceptable. NIST IR 8286D-upd1 puts this on senior leaders, who "define clear criteria for criticality and sensitivity", and it adds: "it is usually more important to be consistent than to be exactly precise in analytic results."

Step 6 then reads the MTPD off the ratings instead of asking anyone for it. The SP 800-34 template expects "specific time frames, identified in hourly increments", a useful discipline: nobody can test "as soon as possible".

A worked example: a dairy co-operative's milk intake in spring

Brindlebrook Dairy Co-operative is owned by about 230 farmer-suppliers in south-west Victoria, and its one factory makes milk powder for export and cheese for domestic retail. The co-op and everyone in it are fictional. The season is real: in September 2025 Rabobank named October as the peak milk volume month for both Australia and New Zealand, the spring flush.

In June 2026 the board asked which operations could survive a week without IT, and in July the largest export customer's renewed supplier requirements asked for a documented BIA and an annual continuity exercise. Imogen Tait, the Risk and Continuity Lead, runs the work. Craig Mendes, the Chief Operating Officer, sponsors it and approves the results.

Scope and criteria (steps 1 and 2). The terms of reference, agreed on 21 July 2026, cover both product lines, the factory site and its eleven processes, rated at five horizons: 1 hour, 4 hours, 24 hours, 3 days and 1 week. Each process owner gives a 45-minute interview, then enters their own ratings. The COO approved the criteria on 4 August 2026: five categories rated 0 to 5, with level 4, Major, as the unacceptable line, defined in each category's own terms. Financial Major is a loss above AUD 500,000. Operational Major is any supplier forced to dump milk, or a customer shipment missed. Reputational Major is a formal complaint from the suppliers' representatives, or regional media coverage. Legal and regulatory Major is a reportable food safety breach or a lost traceability record. Health and safety Major is a lost-time injury. Every process is rated at its worst credible time.

Products and processes (steps 3 and 4). Export milk powder ranks first on revenue and contract penalties, cheese second, and both rest on milk collection and intake. Its owner is Bec Hollis, the Milk Supply Manager, and its peak runs from 1 September to 30 November.

The ratings (step 5). On 18 August 2026 Bec Hollis rated milk intake at the spring peak, with the laboratory manager beside her. In spring the tankers collect from every farm daily, and a vat fills in about a day and a half. After 24 hours without intake the tanker queue cannot reach the last farms before their vats are full, so operational impact reaches Major at 24 hours.

The MTPD and the RTO (step 6). The MTPD is 24 hours, the first horizon at which any category reaches Major. The RTO is 4 hours, the last horizon at which none does. The 20 hours between them are for catch-up: clearing the tanker queue and keying the paper records.

The peak is what makes those numbers right. In June and July the tankers collect every second day, operational impact reaches Major only at 3 days, and the same process would carry an MTPD of 3 days and an RTO of 24 hours. A plan built on that average-day rating would have failed in October. NIST IR 8286D-upd1 asks for the worst case, "such as a disruption to an e-commerce website on the busiest day of the sales year". The approved BIA rates the peak.

The RPO and the minimum level (step 7). Bec Hollis wrote the RPO in business terms first: no more than one tanker's intake records, which at the peak is 30 minutes. The minimum level is about half normal intake, farms nearest vat capacity first, on paper intake sheets and the standby analyser.

The dependencies (step 8). The weighbridge terminal has a spare on site and comes back in 2 hours. The milk analyser has a standby instrument and comes back in 1 hour. The intake and laboratory system is the problem, and the number that shows it came from an exercise, not an estimate. In May 2026 the IT team under Sunil Rao, the IT Manager, ran a restore exercise, and the system took 9 hours to come back from its nightly backup: 5 hours past the RTO, with up to 24 hours of records at risk against a 30-minute RPO. The paper workaround reaches the minimum level inside 4 hours, so the RTO holds. Nothing on paper brings back the records written since the last backup, so the RPO fails.

Pelham Bulk Haulage supplies the tankers and drivers, criticality High, and its contract carries no recovery commitment. The intake technicians run two per shift from a roster of nine, and the site is the receival bay. The vital records, the supplier list with vat sizes and the day's run sheets, are printed weekly so they exist when the system does not.

Approval and hand-off (steps 9 and 10). Milk intake is tier 1, and Craig Mendes approved the BIA on 26 August 2026 without having written it. On 9 September the Chief Financial Officer approved a standby intake system with database log shipping every five minutes, live by 30 November; until then the paper sheets were reissued and the technicians trained on the standby analyser. The receival bay continuity plan takes its RTO, RPO and MTPD from milk intake, the strictest of the processes it covers. The gap went on the risk register, owned by Sunil Rao until the standby is live. Procurement opened a contract variation with Pelham for a recovery commitment and a fallback depot, and the third-party risk management guide takes it from there.

Here is the approved BIA as an auditor reads it. Its fields follow the NIST SP 800-34 Rev. 1 template plus what clause 8.2.2 asks for, so it doubles as a template.

Testing the numbers. On 22 September 2026 the co-op ran a tabletop exercise on one scenario: the intake system encrypted at 05:00 on a spring-flush Tuesday. It found that the paper intake sheet, last revised in 2023, had no field for the antibiotic test result, and that one of the two early-shift technicians had never run the standby analyser. Both findings closed before 1 October, and the MTPD and RTO stood. The next review is due in August 2027, or earlier on a new intake system, a change of haulier, a second site, or an exercise that disproves a number.

Common mistakes

Eight mistakes recur, and they share one root: a number someone asserted, instead of one derived from criteria and checked against what the process depends on. At the co-op, asking cold and rating against the criteria gave these two answers.

1. Starting from the server list. A BIA built from systems produces RTOs nobody can trace to a process or a customer. Start from products, services and processes and derive the system targets from them, which is how SP 800-34 separates the process BIA from the system BIA.
2. Asking "how long can you be down?" Every owner answers "not at all", and every process becomes tier 1. Write the criteria first, have them approved, rate at fixed horizons and read the MTPD off the ratings.
3. Rating an average day. Rate the worst credible time and record when it is. At the co-op it moves the MTPD of milk intake from three days to one.
4. Setting the RTO equal to the MTPD. Systems come back before the work does. Leave room for catch-up between the two, as NIST and the FCA both say.
5. Writing the RPO to match the backups. If the backup runs nightly, an RPO of 24 hours describes the backup schedule instead of the business. State what the business can afford to lose, then test the backups against it. The difference is the finding.
6. Mixing the BIA with the risk assessment. A BIA that lists threats and likelihoods stops measuring consequence. Rate consequence whatever the cause, and run the risk assessment of disruption beside it, the way clause 8.2 pairs them.
7. Leaving out suppliers and people. A process fails without its haulier or its two trained technicians as surely as without its system. List every dependency with a recovery time, and check that the contract commits the supplier to it.
8. Approved by its author, then filed. Have an accountable manager who did not write the BIA approve it, and review it at planned intervals, on significant change and whenever an exercise disproves a number. CPG 230 paragraph 33 expects APRA entities to reassess tolerance levels as they learn from disruptions, testing and scenario analysis.

A business impact analysis compared with its neighbours

The confusion with risk assessments, continuity plans, disaster recovery plans and regulators' tolerances clears once you ask two questions of each: what does it look at, and what does it produce?

The neighbour people confuse it with most is the risk assessment, and the two look at the same process from opposite ends. The risk assessment starts from causes: what could stop the process, and how likely each cause is. The BIA starts from the process and sets the cause aside: what stopping costs, hour by hour. ISO 22301 places them side by side in clause 8.2. NIST IR 8286D-upd1 draws the boundary: "The BIA does not directly address the identified risks, but the BIA-determined criticality and sensitivity of a system will influence risk management requirements", and through them how cybersecurity risks are prioritised and remediated. The cyber risk assessment guide covers the causes end.

Standards and references

ISO 22301:2019, Security and resilience. Business continuity management systems. Requirements (30 October 2019). The certifiable requirement. Clause 8.2.2 is the BIA, 8.2.3 the risk assessment of disruption, 8.2.1 the review at planned intervals, and 9.3 management review. Amendment 1:2024 (February 2024) touches clauses 4.1 and 4.2 only, on climate change. A revision was approved as a work item in November 2025, with no publication date known.

ISO/TS 22317:2021, Guidelines for business impact analysis (17 November 2021). The guidance on running the analysis, which says it does not prescribe a uniform process. It was confirmed without change in 2025, as was ISO 22313:2020 (20 February 2020), the guidance on using ISO 22301.

ISO 22300:2025, Security and resilience. Vocabulary (6 November 2025). The fourth edition, replacing the 2021 vocabulary that many pages still cite.

NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (May 2010, updated 11 November 2010). Free, and the only document here with a ready template. Read Section 3.2 for the three BIA steps, page 17 for MTD, RTO and RPO, and Appendix B for the template.

NIST IR 8286D-upd1, Using Business Impact Analysis to Inform Risk Prioritization and Response (February 2025). How a BIA feeds cyber risk management and how to rate the worst case. It supersedes the November 2022 edition.

NIST CSF 2.0 (February 2024). Lists BIA registers among the inputs to an Organizational Profile; ID.AM-05 prioritises assets by classification, criticality, resources and impact on the mission.

The Business Continuity Institute, Good Practice Guidelines, Edition 7.0 (31 October 2023). The practitioner's reference, with product and service, process and activity BIAs, now an "evergreen document" numbered by edition instead of year.

APRA CPS 230 and CPG 230 (July 2026). CPS 230 paragraph 37 asks for three tolerance levels per critical operation, and CPG 230 Table 4, which is guidance, maps them to maximum allowable disruption, the RTO, the RPO and the recovery level objective.

DORA, Regulation (EU) 2022/2554, Article 11(5) (applies from 17 January 2025). A business impact analysis of exposure to severe business disruptions, covering business functions, support processes, third-party dependencies, information assets and their interdependencies.

Financial Conduct Authority, "Operational resilience: insights and observations for firms" (28 May 2024). The plainest regulator's statement of why recovery time objectives sit well inside impact tolerances.

ISO sells its standards instead of publishing them, so the ISO clause content here comes from dated secondary sources, chiefly a certification body's transition guide. Check it against a licensed copy before quoting it word for word.

How Alvor helps

With Alvor, the BIA belongs to the business process it describes, and every number downstream is read from it instead of being retyped.

A process in Business Continuity records its owner and deputy, its department, its place in a parent and child hierarchy, its peak periods and its ordered steps. It declares what it depends on: assets from the asset register, vendors from Third-Party Risk Management, named people, sites and other processes, each with its own criticality.

The process owner completes the BIA in a guided wizard, in the language they already use, rating each category at each time horizon against criteria the organisation configures. As they rate, the analysis derives the tier, the MTPD and a recommended RTO: the MTPD is the first horizon at which any single category reaches the intolerable level, and the recommended RTO is the horizon before it. The RTO stays editable. The RPO and the minimum business continuity objective are entered directly, with key personnel, vital records, manual workarounds and assumptions. A BIA moves from Draft to Submitted to Approved, cannot be submitted without a score and an RPO, and on approval supersedes the previous BIA and stamps the tier onto the process. Self-approval is blocked for everyone except administrators.

A plan takes the strictest RTO, RPO and MTPD from the approved BIAs of the processes it covers, and shows beside each number the process that drove it. Each asset's Continuity tab shows the same strictest posture, read-only, from every process that depends on it and has an approved BIA, so the team that runs a system sees the recovery time and recovery point it owes the business, and which process asked for each.

Exercises record a result (Met, Partially Met or Not Met) and the recovery time and recovery point actually achieved. Lessons become tracked findings, and anyone with risk write access can escalate a finding to the Risk Management register. The process, plan and finding registers export to CSV. ISO 22301 installs in Compliance as structure, with its full text loaded from your licensed copy.

The AI Assistant is bring-your-own-model, including a self-hosted model behind any OpenAI-compatible endpoint. It answers coverage questions such as which tier 1 processes have no active plan, and drafts processes and plans as approval cards that a person approves. Activating a plan, standing down, closing an incident and approving a plan stay with people.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped, with all eight modules and the AI Assistant in each.