BIA – how to conduct a Business Impact Analysis step by step

By Mallbutiken · Facts checked September 30, 2026 · Approx. 9 minutes read

A Business Impact Analysis (BIA) helps an organization determine which functions must be restored first when something goes wrong. You identify critical activities, the consequences of a disruption over time, the resources and suppliers those activities depend on, and how quickly they need to be recovered.

Short answer: A BIA is not primarily about which threats are most likely. It starts with the business operations: what happens if an activity cannot be performed for 2 hours, 1 day, or 1 week – and when do the consequences become unacceptable?

What is a Business Impact Analysis?

A BIA is used in business continuity management to understand an organization’s dependencies and recovery priorities. The Swedish Civil Contingencies Agency (MSB) uses the term impact analysis in its methodological guidance, describing it as an assessment of the business, what it consists of, and what it needs to function.

The result provides a basis for decision-making. Which activities are critical? How long can they be down? What people, systems, premises, data, suppliers, and other resources are required? Which measures need to be prioritized?

BIA and risk analysis are not the same thing

Analysis Main question Typical result
BIA / Impact analysis What is the consequence if a key activity is interrupted? Prioritized activities, dependencies, and recovery needs.
Risk analysis What could cause the disruption and how should the risk be managed? Risks, probability/consequence, and risk-mitigation measures.

The analyses complement each other. For example, a BIA might show that order processing must be back up within 24 hours. The risk analysis can then investigate which events threaten order processing and what preventive measures are needed.

How to perform a BIA in seven steps

1. Determine the scope

Choose which part of the organization to analyze. Initial work can be done per business unit or main process. Document the scope to ensure important interdepartmental dependencies are not missed.

2. List the organization's activities

Start with the work that actually creates or enables the organization's services. This may include order processing, production, customer support, payroll, operational monitoring, or regulatory reporting.

3. Assess the consequences over time

Analyze what a disruption means after various time intervals. Consequences can be financial, legal, safety-related, operational, or reputational. Avoid simply assigning a general value like "high." Describe why.

4. Determine when the disruption becomes unacceptable

For each critical activity, the organization needs to decide how long a disruption can last before the consequence passes an acceptable level. This assessment is central to later recovery prioritization.

5. Map dependencies

  • Personnel and key skills.
  • IT systems, data, and communication.
  • Premises and physical equipment.
  • Electricity, networks, and other utilities.
  • Suppliers and subcontractors.
  • Access rights, certificates, and keys.
  • Other internal processes.

6. Set recovery targets

Translate business needs into realistic goals. A goal should not be set solely because it sounds safe; it must be technically and organizationally supportable.

7. Prioritize measures

Identify the gap between the desired state and current capabilities. If the business needs an activity back within four hours but the current solution requires two days, you have identified a concrete continuity gap.

RTO, RPO, and maximum tolerable downtime

Three time-related terms are often confused:

  • Maximum Tolerable Period of Disruption (MTPD): how long the business can accept that the activity is not functioning before the consequences become unacceptable.
  • RTO (Recovery Time Objective): the target for how quickly a service, activity, or resource should be restored.
  • RPO (Recovery Point Objective): the acceptable amount of data loss in terms of time, e.g., that recovery must involve a maximum loss of the last 30 minutes of data.
Check question: If the RTO is set after the maximum tolerable downtime, the plan is logically impossible. The recovery target must provide a buffer before the consequences become unacceptable.

Hypothetical example: the webshop order flow

An e-commerce company analyzes the activity of "receiving and releasing paid orders to the warehouse." After two hours, the impact is small. After eight hours, the order backlog begins to grow and customer service comes under pressure. After 24 hours, delivery promises risk being broken and revenue is clearly impacted.

The business therefore decides that the activity should be highly prioritized. Dependencies include the e-commerce platform, payment status, integration platform, warehouse system, internet connection, and two key roles. The BIA also reveals that an external integration provider lacks a documented contingency procedure – which becomes a concrete action item.

The point is that the analysis does not stop at "Shopify is critical." It shows which business activity is affected, how quickly, and through which dependencies.

Common mistakes in a BIA

  • Starting with the threat list. This often turns the BIA into a generic risk analysis.
  • Labeling almost everything as critical. If everything has the highest priority, there is no real prioritization.
  • Only asking IT. Business owners need to define consequences and tolerance.
  • Setting RTO without a reality check. Test whether technology, personnel, and suppliers can actually meet the goal.
  • Forgetting suppliers. An internal system might be recoverable, but it could still depend on an external service that lacks corresponding capabilities.
  • Never updating the analysis. New systems, outsourcing, and process changes can quickly make the dependency map obsolete.

What happens after the BIA?

The BIA should result in action plans and business continuity plans. The Swedish Civil Contingencies Agency's (MSB) methodology describes how impact analysis and risk assessment are used as a foundation for actions and continuity planning.

The next step is therefore to describe what the business should actually do during a disruption in a continuity plan. If you are subject to the Cybersecurity Act, the supply chain and other security measures should also be part of the integrated effort; see the guide on NIS2 and supplier security.

Continuity plan and BIA template package in Word, PDF, and Excel

Do you need a practical BIA foundation?

Mallbutiken's Continuity Plan + BIA package includes editable Word/PDF templates and Excel files for, among other things, critical activities, dependencies, consequences, RTO/RPO, and actions. Price in store: 249 SEK.

See Continuity Plan + BIA

Frequently asked questions

Is a BIA the same thing as a continuity plan?

No. The BIA analyzes what is critical and what recovery needs exist. The continuity plan describes how the organization should act to maintain or restore priority activities.

Must you use RTO and RPO?

Not as universal legal labels. They are practical management concepts. Use them when they help the organization express measurable recovery needs.

How often should the BIA be updated?

Update when critical processes, systems, suppliers, or other dependencies change, and also conduct planned, recurring reviews.

Back to blog