ISO Compliance Insights & Best Practices

Business Impact Analysis Example: A Complete Worked BIA (2026)

A business impact analysis example is worth more than another definition, because the hard part of a BIA is not knowing what the fields are called. It is turning vague answers like “we can’t be down for long” into numbers an auditor can trace and an IT team can build to. This post walks through one complete BIA, start to finish, for a fictional company, with every number shown and every decision explained.

The structure follows ISO 22301:2019 clause 8.2.2, so the same steps work whether you are building toward certification or simply want a continuity plan that rests on something firmer than instinct.

The company in this business impact analysis example

Northwind Parts is a fictional distributor of industrial spare parts: 140 staff, two warehouses, a cloud ERP, a cloud warehouse management system (WMS), and an outsourced payroll bureau. Most revenue comes from next-day delivery to factories that are losing money every hour a machine is down. That detail matters, because it is what makes dispatch time-critical, not the warehouse itself.

The scope is the whole company. Six activities were put through the analysis:

Order intake and customer service
Warehouse picking and dispatch
Purchasing and stock replenishment
Payments to suppliers
Payroll
Customer invoicing and credit control

Clause 8.2.2 b) asks for the activities that support the organization’s products and services. Activities, not departments: “Finance” is not an activity, but “payroll” and “paying suppliers” are, and they turn out to have very different tolerances.

Step 1: Agree the impact types and criteria first

Clause 8.2.2 a) requires impact types and criteria to be defined before anyone scores anything. In this business impact analysis example, Northwind used four impact types and a five-point scale, and wrote down what each score means in its own terms:

Free business impact analysis

How long can each activity really be down?

Rate the impact of an outage over time, set RTOs and maximum tolerable periods of disruption, map the people, systems and suppliers behind each activity, and get a recovery sequence back, free.

Run the free business impact analysis →

Score	Financial	Customer	Legal and regulatory	Staff
1 Negligible	Under $10k lost margin	No customer notices	None	No effect
2 Minor	$10k to $50k	A few complaints	Minor internal breach	Overtime needed
3 Moderate	$50k to $250k	Key accounts escalate	Contractual penalty likely	Visible stress, some absence
4 Major	$250k to $1m	A key account moves volume elsewhere	Statutory breach	Staff not paid on time
5 Severe	Over $1m	Several key accounts lost	Regulatory action	Resignations, legal claims

The rule for “unacceptable” was agreed at the same meeting: any impact type reaching 4 (Major). Setting that rule before the scoring stops each manager from arguing their own activity into a higher priority.

Step 2: Score each activity over time

Clause 8.2.2 c) asks for impacts assessed over time, because a disruption rarely hurts the same at hour four as it does at week two. Each activity owner scored the worst impact type at six time points, which is the core table of any business impact analysis example worth copying. Payroll was scored at its worst timing, a disruption starting three days before the monthly pay date, because a BIA that assumes a convenient moment is not measuring the risk the business carries.

Activity	4 hours	1 day	3 days	1 week	2 weeks	1 month
Picking and dispatch	2	4	5	5	5	5
Order intake	2	3	4	5	5	5
Payroll (worst timing)	1	2	4	5	5	5
Purchasing	1	1	2	4	5	5
Supplier payments	1	1	2	3	4	5
Invoicing and credit control	1	1	1	2	3	4

The bold cell in each row is the first point where the impact becomes unacceptable. That is the input to the next step.

Step 3: Set MTPD, RTO, RPO and minimum capacity

Clause 8.2.2 d) asks for the time frame within which the impacts of not resuming become unacceptable, usually recorded as the maximum tolerable period of disruption (MTPD). Clause 8.2.2 e) then asks for prioritized time frames to resume each activity at a specified minimum acceptable capacity, which is the recovery time objective (RTO) and the minimum business continuity objective (MBCO). The recovery point objective (RPO) is not named in the clause, but almost every BIA records one, because acceptable data loss decides how backups and replication are designed.

Activity	MTPD	RTO	RPO	Minimum acceptable capacity
Picking and dispatch	1 day	8 hours	1 hour	Orders for the top 20 accounts, about 40% of volume
Order intake	3 days	1 day	4 hours	Phone and email orders, about 50% of volume
Payroll	3 days	2 days	24 hours	Last month’s net pay repeated, corrected next run
Purchasing	1 week	3 days	24 hours	Replenish fast-moving lines only
Supplier payments	2 weeks	1 week	24 hours	Critical suppliers only
Invoicing and credit control	1 month	2 weeks	24 hours	Invoice top 50 accounts

Every RTO sits inside its MTPD with room to spare. NIST’s contingency planning guide makes the same point about its equivalent metrics: the RTO must normally be shorter than the maximum tolerable downtime, because recovery also needs time to catch up on the backlog. An RTO equal to the MTPD leaves no margin for the recovery itself going wrong. For more on how these four numbers relate on one timeline, see RTO and RPO: the four recovery metrics.

Step 4: Identify prioritized activities, resources and dependencies

Clause 8.2.2 f) closes the analysis: identify prioritized activities, determine the resources they need, and determine dependencies, including suppliers and interdependencies. Northwind treated every activity with an MTPD of three days or less as prioritized, which gave three: dispatch, order intake and payroll.

Prioritized activity	People (minimum)	Systems	External dependencies
Picking and dispatch	12 of 30 warehouse staff	Cloud WMS, handheld scanners, label printers	One courier contract; WMS vendor
Order intake	4 of 10 customer service staff	ERP, phone system, shared mailbox	ERP vendor; telephony provider
Payroll	1 payroll administrator	HR system export	Payroll bureau; bank file upload

This is the step where a business impact analysis example usually starts paying for itself, because the dependency column is where the real findings sit.

What the findings in this business impact analysis example show

Laying the resource table next to the RTOs surfaced three problems nobody had raised before the analysis:

A dependency slower than the activity it supports. Dispatch needs to be back within 8 hours, but the WMS contract only commits the vendor to restoring service within 24 hours. The RTO cannot be met as things stand. Either the contract changes, or a manual picking fallback (printed pick lists from an ERP export) becomes part of the plan.
A single point of failure. All dispatch runs through one courier. A second carrier on a standby agreement costs little and removes the risk entirely.
A key person dependency. Only one administrator knows how to submit to the payroll bureau. With a three-day MTPD at worst timing, one absence at the wrong moment breaches it. A documented procedure and a trained deputy close the gap.

The recovery sequence follows directly from the MTPDs: dispatch first, then order intake, then payroll, then purchasing, supplier payments and invoicing. That order goes straight into the business continuity plan, and the three findings go into the ISO 22301 risk assessment as risks to be treated.

Mistakes this business impact analysis example avoids

Scoring before defining criteria. Without the table in Step 1, “Major” means something different to every manager.
Asking “how long can you be down?” Managers answer that with a wish, usually “zero.” Asking what happens at each time point produces an answer you can defend.
Assuming convenient timing. Payroll looks like a two-week activity until you score it three days before pay day.
Stopping at the RTO. The RTO is not the finding. The gap between the RTO and what your suppliers actually commit to is.
Treating it as a one-off. Clause 8.2.1 requires the analysis to be reviewed at planned intervals and when significant changes occur, such as a new warehouse, a new ERP or a new key customer.

Frequently asked questions

How long does a business impact analysis take?

For a company of Northwind’s size, typically two to four weeks of elapsed time: one workshop to agree the criteria, an interview or questionnaire per activity owner, then a consolidation and sign-off meeting. The effort is in scheduling people, not in the analysis itself.

Do I need a separate BIA for IT systems?

Not a separate one. Systems appear as resources behind the business activities, and their required recovery times are derived from the activity RTOs. An IT-only BIA that sets system RTOs without a business activity behind them tends to produce numbers nobody can justify.

What is the difference between MTPD and RTO?

The MTPD is the point where impacts become unacceptable. The RTO is your target for resuming the activity, and it has to be earlier than the MTPD so there is time to catch up before the damage is done.

Can I reuse this business impact analysis example as a template?

Reuse the structure, not the numbers. The criteria table, the time points and the unacceptable-impact rule transfer well. The scores, MTPDs and RTOs have to come from your own activity owners, or the analysis will not survive an auditor asking where a figure came from.

Is there a standard that explains how to do a BIA?

Yes. ISO 22301 sets the requirement, and ISO/TS 22317:2021 gives detailed guidance on running the business impact analysis process. NIST SP 800-34 Rev. 1 covers the same ground for information systems.

Where this leaves you

This business impact analysis example fits in a handful of tables, and that is the point: a BIA does not need to be long to be defensible, it needs criteria agreed up front, impacts scored over time, and every number traceable to a decision. For the wider method behind each step, start with our business impact analysis guide.

If you want to build your own BIA from documents rather than a blank page, the ISO 22301 Toolkit includes a Business Impact Analysis Tool, a BIA report template and an illustrative worked example alongside the rest of the documented BCMS, for $99.