BIA examples – how to prioritize critical processes, RTO and RPO

By Mallbutiken · Facts verified September 30, 2026 · Approx. 8 minutes reading

A BIA only becomes useful when it leads to prioritization. The analysis should help the organization understand which processes must be restored first, how consequences grow over time, which dependencies are critical, and what recovery objectives are actually needed.

Example: a small e-commerce and service company

Assume the company sells digital and physical products online. The business depends on a web shop, payment processing, customer service, order administration, finance, and several external SaaS services. Management wants to know what must function first after a major IT outage.

For each activity, the process owner is interviewed about consequences after, for example, 2 hours, 8 hours, 24 hours, 3 days, and 1 week. Consequences are assessed in terms of finance, customers, legal/compliance, operations, reputation, and security.

Simplified BIA example

The table is just the end result of the reasoning. The important thing is why checkout was ranked higher than customer service, and the assumptions behind the RTO/RPO.

Assess how consequences change over time

A process is not automatically "critical" just because it is important in daily work. The BIA needs to ask when the consequence becomes unacceptable. A two-hour outage might be manageable, while a full day could mean major financial or legal consequences.

Therefore, document thresholds. Example: after four hours, major revenue loss begins; after eight hours, a customer promise is broken; after one day, manual queues arise that cannot be cleared. This provides a factual basis for recovery objectives.

Distinguish between maximum tolerance and recovery objectives

Organizations sometimes use terms like MTPD (Maximum Tolerable Period of Disruption) for the point where the consequence is no longer acceptable. In practice, RTO should be set with a sufficient margin before such a limit, as recovery should never be planned for the absolute last possible minute.

RTO and RPO – use them correctly

RTO (Recovery Time Objective) describes the target for how quickly the service or process needs to be restored after an outage. RPO (Recovery Point Objective) describes how far back in time the organization can accept data loss during recovery.

If checkout has an RTO of 4 hours but the technical solution takes 12 hours to restore, there is a gap. The BIA has then identified a risk that must be managed through better redundancy, faster recovery, contingency procedures, or a reconsidered business objective.

If the RPO is 15 minutes but backups are only taken once a day, the same type of gap exists. RPO is therefore not a wish that can be written into a plan without technical support.

Map people, systems, and suppliers

For each critical process, the BIA should identify dependencies. These can include:

• key personnel and minimum staffing,
• facilities and equipment,
• business systems and integrations,
• identity and login services,
• data and documentation,
• telephony and communication,
• critical suppliers and subcontractors,
• power, network, and other infrastructure services.

It is common for a "secondary" service to turn out to be a single point of failure. One example is the identity provider: the e-commerce site might be technically up, but staff cannot manage it if SSO is down.

How to transfer BIA results to the continuity plan

The BIA answers what needs to be prioritized. The continuity plan answers how the business should continue and be restored.

For the highest-priority processes, the plan should therefore specify activation criteria, responsibilities, contingency procedures, contact lists, supplier escalation, recovery order, communication, and when normal operations can resume. Read what a continuity plan should contain.

If the technical service is purchased as SaaS, recovery objectives should also be compared against the provider's SLA. See the guide on SLA, RTO, and RPO.

Common mistakes in BIA work

• All processes become critical. In that case, the analysis has not prioritized.
• RTO is set by IT alone. The target should be based on the business's consequence requirements and then tested against technical capability.
• RPO lacks a connection to data. Different data sets may require different tolerance levels.
• Dependencies are missed. Especially identity, integrations, and external suppliers.
• No one owns the result. Each critical process needs a responsible process owner.
• The BIA is never updated. New systems, products, and suppliers can change priorities.

Checklist for your own BIA

• List the business's activities and process owners.
• Assess consequences at several time intervals.
• Identify when the consequence becomes unacceptable.
• Prioritize processes in order of recovery.
• Set preliminary RTO and RPO targets.
• Map personnel, systems, data, and suppliers.
• Compare targets against actual recovery capability.
• Document gaps and actions.
• Transfer the result to the continuity plan.
• Test and reconsider after major changes.

Do you need a BIA and continuity plan in the same workflow?

Mallbutiken's Continuity Plan + BIA Template 2026 combines analysis, prioritization, and continuity planning in Word, PDF, and Excel. Price in store: 249 SEK.

View Continuity Plan + BIA

Frequently asked questions

Is RTO the same as maximum tolerable downtime?

No. RTO is a recovery objective. The maximum tolerable downtime describes an external tolerance limit. The recovery objective should normally be earlier.

Must all processes have an RPO?

RPO is primarily relevant where data recovery is a central part. For manual processes, other recovery metrics may be more useful.

How often should a BIA be updated?

There is no universal interval that fits everyone. Conduct regular reviews and re-evaluate even when critical systems, suppliers, processes, or requirements change.