Business Impact Analysis (BIA): Method, Template, and Example

A business impact analysis (BIA) is the step in business continuity planning that measures how a disruption to each business process would harm the organization over time, then turns that measurement into recovery priorities and targets. For each critical process, a BIA sets the maximum tolerable period of disruption (MTPD), the recovery time objective (RTO), the recovery point objective (RPO), and the minimum service level to keep running, and it maps the systems, people, and suppliers the process depends on. Those numbers decide what the business continuity plan protects first and what the disaster recovery design has to deliver. ISO 22301:2019 requires a BIA in clause 8.2.2, and NIST SP 800-34 Rev. 1 makes it the second of seven contingency planning steps.

What does a business impact analysis produce?

A BIA produces a ranked list of prioritized activities and, for each one, time and capacity targets that leadership approves. The definitions below follow the ISO 22300 vocabulary that ISO 22301 uses. NIST SP 800-34 calls the MTPD the maximum tolerable downtime (MTD).

The outputs depend on each other in a fixed order. The MTPD comes first because it is a business judgment about when damage becomes unacceptable. The RTO must be shorter than the MTPD, leaving time after systems return to validate data and clear backlogs. The RPO looks backward from the disruption to the last good copy of the data, and NIST SP 800-34 says plainly that "unlike RTO, RPO is not considered as part of MTD." The MBCO sets how much capacity the workaround or the recovered system must deliver by the RTO.

How to conduct a business impact analysis, step by step

ISO 22301 clause 8.2.2 lists what a BIA must do, and these seven steps are the sequence we use to get there with the fewest rework cycles.

1. Set the scope and approve the impact criteria

Fix the scope first: the products, services, sites, and legal entities covered, matched to the business continuity or ISO/IEC 27001 management system the BIA supports. Then write the impact criteria that clause 8.2.2 requires and have leadership approve them before the first interview. A five-point scale per category works for most companies, and a company with $120 million in revenue might rate financial impact 1 below $25,000, 2 up to $100,000, 3 up to $250,000, 4 up to $500,000, and 5 above that.

2. Build the process inventory

List the activities that deliver each product or service and name an owner for each. Work from the value chain (sell, deliver, bill, collect, pay, report), because order-to-cash alone crosses sales, the warehouse, and finance, and include support functions such as payroll and treasury.

3. Collect data with a questionnaire, then interview

Send each process owner a short questionnaire, then hold a 60-minute interview to test the answers. Ready.gov recommends questionnaires completed by managers who know how the business delivers its products and services, and the interview finds what the form missed, such as a supplier with no backup. Ask about peak periods, because timing changes the answer: a store damaged just before the holiday shopping season can lose much of its yearly sales.

4. Rate impacts over time in each category

Rate the impact of a total outage at fixed intervals, such as 4 hours, 1 day, 2 days, 3 days, and 5 days, in five categories: financial, regulatory, customer, safety, and reputational. Ready.gov's impact list is a good prompt for the financial category: lost and delayed sales, overtime and outsourcing costs, regulatory fines, contractual penalties, and customer defection. Rate each process as if no workaround existed, since the workaround belongs in the continuity strategy.

5. Find the MTPD, then set the RTO, RPO, and MBCO

The MTPD is the point just before any category reaches the rating leadership called unacceptable, usually a 4 on a five-point scale. Set the RTO inside it with enough buffer to recover data and clear the backlog, the RPO from how much data the business can rebuild or afford to lose, and the MBCO as the share of normal output the business must sustain.

6. Map dependencies, including third parties

List every system, data set, supplier, site, and role the process needs at its MBCO, and give each one an RTO no longer than the process RTO. A process with a 24-hour RTO that runs on a SaaS platform promising uptime but no recovery time has an unmanaged dependency. DORA Article 11(5) requires EU financial entities to cover third-party dependencies and interdependencies in their BIAs.

7. Validate the results with leadership

Take the ranked list, the proposed targets, and the cost of meeting them to the executive team for written approval. An RTO is a statement of risk appetite, so a 4-hour RTO for a system that takes 3 days to restore is a funding request: leadership funds it, accepts a longer recovery time, or changes the process.

A worked example: impact over time for one process

The example is a hypothetical distributor with $120 million in annual revenue over 250 business days, so order processing handles $480,000 of orders per business day at a 30% gross margin. The BIA team rates a total outage of the order management system with no workaround. Three assumptions drive the numbers: the share of backlogged orders that customers cancel grows from 0% at 4 hours to 30% at 5 days; overtime and rework cost $25,000 per business day of backlog; and two customers with 48-hour fulfillment commitments receive $30,000 service credits each once orders wait longer than 48 hours.

Financial impact alone would put the MTPD between day 3 and day 5, where the total crosses $250,000, the threshold for a rating of 4. The customer category gets there first. Past 48 hours, the two largest accounts are in breach of their commitments, which leadership rated a 4, so the MTPD is 48 hours. A hospital pharmacy ordering process would instead hit a 4 on safety within hours, which is why the first category to cross the line sets the MTPD.

The team set a 24-hour RTO for the order system and its database, leaving 24 hours to re-key orders, clear the backlog, and ship. The RPO is 15 minutes, because the EDI provider can resend EDI orders but customer service can rebuild only about 30 minutes of web orders from confirmation emails. The MBCO is 60% of daily order value, delivered by a manual order desk serving the 20 accounts with commitments or the most revenue. Figure 1 shows where the three targets sit.

Those targets are now IT requirements: a 15-minute RPO rules out nightly backups as the only protection for the order database, and the 24-hour RTO counts only after a restore test proves it.

Business impact analysis template: the fields to capture

A BIA template holds one record per process with the same fields every time, so results roll up. These are the fields we capture, filled in from the worked example. NIST SP 800-34 Rev. 1 also publishes a sample BIA template in Appendix B, written for a single information system.

How often should you update a business impact analysis?

Update the BIA at least once a year and whenever a change moves an impact or a dependency. ISO 22301 clause 8.2.1 requires review at planned intervals and after significant changes, and NIST SP 800-34 notes that the BIA may need to be redone as system components change. Our rule is a full refresh every 12 months and a targeted update within 30 days of an acquisition, a new product line, a new critical supplier or SaaS platform, an ERP or cloud migration, a reorganization of process ownership, or any disruption or exercise that disproved an assumption.

Which frameworks require a business impact analysis?

ISO 22301 and DORA require a BIA by name, NIST SP 800-34 builds contingency planning around one, and ISO/IEC 27001, HIPAA, SOC 2, and the FFIEC expect its outputs. The table maps each reference as of October 2026.

Three rows need context. Under HIPAA, an addressable specification must be implemented when it is reasonable and appropriate, and otherwise 45 CFR 164.306(d)(3) requires the entity to document why and adopt an equivalent alternative if one is reasonable. HHS proposed on January 6, 2025 to require an analysis of the relative criticality of relevant electronic information systems to set restoration priority, plus written procedures to restore certain systems and data within 72 hours. As of October 2026 the proposal is not final, and the HHS fact sheet states that the current Security Rule remains in effect during the rulemaking.

For SOC 2, the AICPA's 2017 Trust Services Criteria, with revised points of focus from 2022, never use the phrase, yet testing A1.3 means testing recovery against stated objectives, and the BIA records where those objectives came from. ISO/IEC 27001:2022 control 5.30 also names no BIA while its guidance starts from one. If you are building an ISMS, our ISO 27001 implementation team scopes the BIA to the ISMS boundary so the same RTOs feed control 5.30 and the risk treatment plan.

Business impact analysis vs risk assessment

A business impact analysis asks what happens if a process stops, whatever the cause, and a risk assessment asks what could make it stop and how likely that is. ISO 22301 keeps them separate, in clauses 8.2.2 and 8.2.3, and running the BIA first focuses the risk assessment on the processes that matter.

HIPAA separates them too. The required risk analysis in 45 CFR 164.308(a)(1)(ii)(A) covers risks to electronic protected health information, while the criticality analysis in 164.308(a)(7)(ii)(E) ranks what comes back first. Our HIPAA security risk assessment guide covers the first.

Common business impact analysis mistakes

Six mistakes cause most failed BIAs, and each one produces targets that look approved and cannot be met.

• Letting IT run it alone. An IT-led BIA inventories systems and skips the manual steps, suppliers, and people that recovery also needs.
• Interviewing before the criteria are approved. Without thresholds, every owner rates their process critical and asks for a four-hour RTO.
• Rating one point in time. A single "high" rating hides how fast impact grows, and the growth rate separates a 24-hour RTO from a 5-day one.
• Setting the RTO equal to the MTPD. Systems that return at the deadline leave no time for data validation and backlog.
• Copying the RPO from the backup schedule. The RPO should set the backup schedule, and writing the nightly job into the BIA as a 24-hour RPO turns a technical habit into an approved risk.
• Skipping third-party recovery commitments. Many SaaS agreements commit to uptime and say nothing about recovery time or data loss, which caps the RTO of every process that depends on them.

How the BIA feeds the continuity plan and disaster recovery design

The BIA feeds both halves of a continuity program. Its priorities, MTPDs, and MBCOs drive the continuity strategies and plans in ISO 22301 clauses 8.3 and 8.4: who staffs the manual order desk, where people work if a site is lost, and what customers hear. Its RTOs and RPOs become IT design requirements, since the RPO sets backup and replication frequency and the RTO decides between restoring from backup, a pilot light, a warm standby, and active-active. Our guide to business continuity vs disaster recovery compares those strategies and their costs.

Then close the gap between what the BIA requires and what IT can prove. Put each system's required RTO and RPO next to its last tested restore, and each gap becomes a funded project or a risk that leadership formally accepts. A tabletop exercise built on the BIA's worst-timed scenario tests the plan's sequence and decisions before a real outage does. In a cyber incident, the BIA's priority list is the restoration order an incident response retainer team needs on day one.

Frequently asked questions

What is a business impact analysis in simple terms? A business impact analysis works out how much damage the organization suffers when each business process stops and how quickly that damage grows. It rates financial, regulatory, customer, safety, and reputational impact over time, finds the point where impact becomes unacceptable, and sets the recovery targets that drive the continuity plan and the disaster recovery design.

What is the difference between MTPD and RTO? The maximum tolerable period of disruption (MTPD) is the point after which the impact of a stopped process becomes unacceptable. The recovery time objective (RTO) is the target for resuming the process or recovering a system, and it must be shorter than the MTPD so there is time to clear backlogs and validate data.

What is the difference between RTO and RPO? The RTO measures forward from the disruption: how long until the process or system must run again. The recovery point objective (RPO) measures backward: how much data, in minutes or hours before the disruption, the business can afford to lose. A 15-minute RPO means the last good copy of the data is never more than 15 minutes old.

Who should own the business impact analysis? A senior business leader, often the COO or the executive who owns operational risk, should own the BIA, with a business continuity manager or a vCISO running it and process owners supplying the data. IT supplies dependencies and tested recovery times, but the MTPD and RTO are business decisions about acceptable loss.

How long does a business impact analysis take? As a BD Emerson planning range, a first BIA for a company with one to three sites and 20 to 40 processes takes 4 to 8 weeks from kickoff to leadership approval. Process owner availability moves the number most, followed by the number of sites and legal entities and whether approved impact criteria already exist.

Does ISO 27001 require a business impact analysis? ISO/IEC 27001:2022 does not use the term in its requirements. Annex A control 5.30 requires ICT readiness to be planned, implemented, maintained, and tested against business continuity objectives, and the ISO/IEC 27002:2022 guidance for 5.30 treats ICT continuity requirements as the outcome of a business impact analysis.

Is a business impact analysis required for HIPAA? HIPAA does not use the term, but the contingency plan standard at 45 CFR 164.308(a)(7) includes an applications and data criticality analysis, an addressable specification to assess the relative criticality of specific applications and data. A BIA satisfies it and supports the required backup, disaster recovery, and emergency mode operation plans.

If you are running a first BIA or updating one for ISO 27001, SOC 2, or HIPAA, our virtual CISO team runs the interviews, builds the impact model, and takes the RTO and RPO gaps to your leadership team with the cost of closing each one.