Business impact analysis (BIA): steps, template and example
When the warehouse floods or the order system goes down, the question is not “what went wrong?” but “what do we restore first, and how long have we got?”. A business impact analysis answers that before it happens.
A business impact analysis (BIA) identifies the activities a business cannot afford to lose and measures how the impact of their disruption grows over time. For each critical activity it sets the maximum tolerable period of disruption (MTPD), a recovery time objective (RTO) inside that limit, a recovery point objective (RPO) for data, and the minimum level of service needed, and it lists the people, systems, suppliers and premises the activity depends on. The BIA is the foundation of a business continuity plan and feeds disruption risks into the risk register.
Turn BIA findings into tracked risksRisk Samurai links each critical activity’s disruption risks to owners, controls and review dates, so recovery gaps do not sit in a forgotten spreadsheet.
Get early accessWhat a business impact analysis is
A business impact analysis (BIA) is the part of business continuity management that works out what to protect and how fast to recover it. It deliberately ignores why a disruption happens — fire, ransomware, a supplier collapse, a pandemic — and asks what the consequences are if an activity stops, and how they grow hour by hour or day by day.
A BIA produces four things:
- A ranked list of prioritised activities — the products, services and processes that must continue or resume first.
- For each, time limits: how long it can be down before the damage is unacceptable, and the recovery target inside that limit.
- The resources and dependencies each activity needs: people and skills, systems and data, suppliers, premises, equipment.
- The gaps between what is needed and what current arrangements could deliver — which become risks and actions.
BIA vs risk assessment
The two are often confused because both end up in the same continuity programme.
| Business impact analysis | Risk assessment | |
|---|---|---|
| Question | If this activity stops, how bad is it and how fast must it come back? | What could cause disruption, and how likely is it? |
| Focus | Consequences over time | Causes, likelihood and existing controls |
| Unit of analysis | Activities, products and services | Threats, hazards and vulnerabilities |
| Output | Priorities, MTPD, RTO, RPO, dependencies | Scored risks and treatments in the risk register |
| Typical order | First | Second, focused on the dependencies the BIA shows are critical |
Done together, they are powerful: the BIA tells you the payments platform must be back within four hours, and the risk assessment tells you the most likely ways it could fail for longer than that. For the security side of that assessment, see our cybersecurity risk assessment guide.
Key terms: MTPD, RTO, RPO and MBCO
| Term | Meaning | Example |
|---|---|---|
| MTPD — maximum tolerable period of disruption | The point after which the impact of not resuming the activity becomes unacceptable. Also called maximum acceptable outage (MAO) or, in NIST guidance, maximum tolerable downtime (MTD) | Order dispatch: 3 days, after which customer losses and penalties become severe |
| RTO — recovery time objective | The target time to resume the activity or system. Must be shorter than the MTPD, leaving time to catch up the backlog | Order dispatch: resume within 24 hours |
| RPO — recovery point objective | The maximum age of the data you restore to; how much data you could lose | Order database: 1 hour — orders since the last backup must be recoverable |
| MBCO — minimum business continuity objective | The minimum level of service acceptable during the disruption | Dispatch 60% of normal daily orders, priority to next-day delivery |
The rule that matters: RTO < MTPD. If your realistic recovery time for a system is longer than the MTPD of the activity that depends on it, you have a gap — and a risk for the register.
How to conduct a business impact analysis in 7 steps
- Set scope and impact criteria. Decide which sites, products and functions are in scope. Agree the impact categories (financial, customer, legal and regulatory, reputational, health and safety, staff) and a scale for each — the same 1–5 scale your risk matrix uses is ideal.
- List products, services and activities. Start from what customers buy, then list the activities that deliver each. Twenty to forty activities is typical for a mid-sized business.
- Interview activity owners. A 45-minute structured interview or workshop per area works better than a questionnaire. Ask how impact grows over time if the activity stops tomorrow.
- Set MTPD, RTO, RPO and MBCO for each activity, using the impact-over-time table below.
- Map dependencies. For each prioritised activity record the people and skills, IT systems and data, suppliers, premises and equipment it needs, and their own recovery times. Your supplier list from a third-party risk assessment helps here.
- Find the gaps. Compare required recovery times with what current arrangements could really deliver: backup restore times, supplier SLAs, alternative premises, cross-trained staff.
- Validate and sign off. Leadership confirms the priorities and accepts or funds the gaps. The results go into the continuity plan and the register.
Measuring impact over time
The core of a BIA is a time-based impact table. For each activity, score each impact category at fixed intervals. The MTPD is the first interval at which any category reaches the level leadership has said is unacceptable.
| Activity: customer order dispatch | 4 hours | 1 day | 3 days | 1 week | 2 weeks |
|---|---|---|---|---|---|
| Financial (lost and delayed revenue) | 1 | 2 | 3 | 4 | 5 |
| Customer (complaints, cancellations) | 1 | 2 | 4 | 5 | 5 |
| Contractual (marketplace penalties, SLAs) | 1 | 3 | 4 | 5 | 5 |
| Reputational | 1 | 1 | 3 | 4 | 5 |
| Health and safety | 1 | 1 | 1 | 1 | 1 |
If leadership has said that a score of 4 in any category is unacceptable, the MTPD for dispatch is three days. An RTO of 24 hours leaves two days to clear the backlog.
Business impact analysis template
Use one row per activity. The columns below are the minimum a BIA needs; copy them into a spreadsheet or straight into your risk tool.
| Column | What to record |
|---|---|
| Activity | Name and short description |
| Product or service supported | What the customer gets from it |
| Owner | The manager accountable for the activity |
| Peak periods | When disruption would hurt most (month-end, seasonal peaks) |
| Impact over time | Scores per impact category at 4 hours, 1 day, 3 days, 1 week, 2 weeks |
| MTPD | Point at which impact becomes unacceptable |
| RTO | Target recovery time, shorter than MTPD |
| RPO | Maximum acceptable data loss, for each system used |
| MBCO | Minimum service level during disruption |
| People and skills | Minimum staff, key individuals, who can cover |
| Systems and data | Applications, data stores and their current recovery capability |
| Suppliers | Critical third parties and their SLAs |
| Premises and equipment | Sites, specialist equipment, workarounds |
| Upstream and downstream activities | What this activity needs from others and who needs it |
| Manual workaround | How long the activity could run without its systems |
| Gap and action | Where capability falls short of the RTO; proposed fix |
Business impact analysis example
A summary from the BIA of a 120-person online retailer with its own warehouse. Times are in hours (h) or days (d).
| Activity | MTPD | RTO | RPO | Key dependencies | Gap found |
|---|---|---|---|---|---|
| Taking online orders | 1 d | 4 h | 15 min | Ecommerce platform, payment provider, DNS | Single payment provider; no tested failover |
| Order dispatch | 3 d | 24 h | 1 h | Warehouse system, courier integration, 8 trained pickers | Warehouse system restore untested; estimated 48 h |
| Customer service | 2 d | 8 h | 4 h | Help desk software, phone line, order lookup | None material |
| Supplier payments | 5 d | 3 d | 24 h | Accounting system, banking portal, two authorisers | Only one person can approve payments over £10k |
| Payroll | Monthly cycle | 2 d before pay date | Last run | Payroll bureau, HR data | No offline copy of last payroll file |
| Marketing campaigns | 2 weeks | 1 week | 24 h | Email platform, ad accounts | None material |
The two gaps at the top are the ones that matter: a warehouse system restore estimated at 48 hours against a 24-hour RTO, and a single payment provider for an activity with a one-day MTPD. Both go into the register as risks with owners and actions — for example, “test a full warehouse system restore by end of quarter” and “contract a second payment provider”.
From BIA to business continuity plan and risk register
A BIA is only useful if something changes as a result. Its findings flow three ways:
- Continuity strategies. For each prioritised activity, choose how you will meet the RTO: alternative site or remote working, manual workaround, standby supplier, cross-training, faster backups. These become the business continuity plan.
- Incident procedures. The priorities and recovery order go into your incident plan so responders know what to restore first. For cyber incidents, see our incident response plan template.
- The risk register. Each gap becomes a risk: cause (single point of failure), event (disruption longer than MTPD), consequence (from the impact table). Track it like any other operational risk, with an owner, controls and a review date.
Test the result. A tabletop exercise that walks through a realistic scenario — ransomware over a weekend, a warehouse fire in peak season — quickly shows whether the RTOs are believable. Our ransomware risk guide covers the recovery side of that scenario.
Standards and regulations that use BIA
- ISO 22301:2019, the business continuity management system standard, requires a BIA and risk assessment (clause 8.2). ISO/TS 22317:2021 gives detailed guidance on how to perform a BIA.
- NIST SP 800-34 Rev. 1, the US contingency planning guide for information systems, includes a BIA process and template focused on systems.
- Ready.gov, the US government’s preparedness site, publishes a free BIA worksheet aimed at small businesses.
- UK operational resilience rules (FCA and PRA): regulated firms must identify important business services, set impact tolerances for them and, since 31 March 2025, be able to remain within those tolerances in severe but plausible scenarios. An impact tolerance is close to an MTPD, set from the customer’s and market’s point of view.
- APRA CPS 230 in Australia, in force since 1 July 2025: regulated entities must identify critical operations and set tolerance levels for disruption. See our CPS 230 guide.
Common BIA mistakes
- Every activity is “critical”. If owners all claim a four-hour RTO, the analysis has not challenged them. Ask what would really happen on day two.
- Starting from systems, not services. An IT-led BIA lists applications; a business-led one starts with what customers need and works back to systems.
- Ignoring peak periods. A one-day outage in February and one in the week before Christmas are different events.
- RTOs nobody has tested. A backup that has never been restored does not have a recovery time; it has a hope.
- Forgetting people. Key-person dependencies are as real as server dependencies and usually cheaper to fix.
- Filing it away. A BIA that does not produce actions, a continuity plan and register entries was a survey.
Frequently asked questions
What is a business impact analysis?
A business impact analysis is a structured way of identifying which activities matter most to a business and how quickly the damage grows if they stop. It sets recovery priorities and time limits for each critical activity and lists the resources each one depends on.
What is the difference between a BIA and a risk assessment?
A BIA looks at consequences: if this activity stops, for whatever reason, how bad is it and how fast must it come back? A risk assessment looks at causes and likelihood: what could disrupt the activity and how likely is it? Business continuity uses both, and the BIA usually comes first.
What is the difference between RTO and RPO?
The recovery time objective (RTO) is how quickly an activity or system must be running again after a disruption. The recovery point objective (RPO) is how much data, measured in time, you can afford to lose — for example, an RPO of four hours means backups or replication must be no more than four hours old.
What is the difference between a BIA and a BCP?
The BIA is the analysis: what is critical, how fast it must recover and what it depends on. The business continuity plan (BCP) is the response: the procedures, people and resources that will deliver those recovery times. You write the BCP from the BIA's results.
How often should a business impact analysis be updated?
At least annually, and whenever the business changes significantly — a new product or site, a new critical supplier, a system migration, an acquisition or a major incident that tested the assumptions.
Your continuity risks, owned and reviewed
In Risk Samurai, the dependencies and recovery gaps your BIA uncovers become risks with owners, actions and indicators — reviewed on schedule alongside everything else. AI drafts the first version of your register to get you started.
Get early access