Business continuity plan: what it is, BIA, RTO and RPO

Monday, 9 a.m., and the ERP doesn't respond. No one knows whether last night's backup works, who authorizes working with spreadsheets in the meantime, or whom to call at the vendor. That scenario is the one a business continuity plan should have resolved before it happens.

This guide explains what a business continuity plan is, how it differs from a disaster recovery plan and a contingency plan, what the business impact analysis (BIA) is, what RTO and RPO mean, what ISO 22301 says and which decisions belong to leadership. The definitions come from two official sources: NIST SP 800-34 Rev. 1 and ISO's page on the 22301 standard.

What is a business continuity plan?

A business continuity plan (BCP) is the plan that defines how an organization keeps operating when a disruption affects its critical processes. According to NIST SP 800-34, the BCP focuses on sustaining an organization's mission/business processes during and after a disruption; it may be written for the processes of a single business unit or address the entire organization's processes, and it may be scoped to only the functions deemed priorities.

The same guide clears up a frequent confusion: continuity planning normally applies to the business itself — the ability to continue critical functions and processes during and after an emergency — while contingency planning normally applies to information systems and provides the steps to recover their operation.

What is the difference between a continuity plan, a DRP and a contingency plan?

They are three different plans that must be coordinated. NIST SP 800-34 describes them this way:

Business continuity plan (BCP): sustains business processes during and after a disruption. It is leadership's plan.

Disaster recovery plan (DRP): applies to major, usually physical, disruptions that deny access to the primary facility for an extended period. It is an information-system-focused plan designed to restore operability of the target system, application or infrastructure at an alternate site after an emergency.

Information system contingency plan (ISCP): provides established procedures for the assessment and recovery of a specific system following a disruption, with roles, inventory, recovery procedures and testing. Unlike the DRP, it can be activated at the system's current location or at an alternate site.

The BCP belongs to the business; the DRP and contingency plans belong to IT. Without the first, the other two restore systems that perhaps no one needed first.

What is the business impact analysis (BIA)?

The business impact analysis is the step that turns continuity into something measurable. According to NIST SP 800-34, the BIA's purpose is to correlate the system with the critical mission/business processes and services it provides and, based on that information, characterize the consequences of a disruption.

The guide describes three steps. First, determine the business processes the system supports and their recovery criticality, along with the outage impacts and estimated downtime, which should reflect the maximum time the organization can tolerate. Second, identify the resources required to resume those processes: facilities, personnel, equipment, software, data files, system components and vital records. Third, identify recovery priorities for system resources, to establish the order in which each one is recovered.

In practice, the BIA is a conversation with process owners and leadership, not an IT exercise: they are the ones who know what each hour without invoicing, shipping or running payroll costs.

Has your continuity plan never been tested?

We run the impact analysis, set RTO and RPO with leadership and design a continuity and recovery plan that is rehearsed before it is considered finished.

• BIA with critical processes and recovery priority
• Drill with a real scenario

Learn about business continuity consulting

What are the RTO, the RPO and the MTD?

Three measures come out of the BIA, which NIST SP 800-34 defines as follows:

Maximum Tolerable Downtime (MTD): the total amount of time the system owner or authorizing official is willing to accept for a business process outage or disruption, including all impact considerations.

Recovery Time Objective (RTO): the maximum amount of time a system resource can remain unavailable before there is an unacceptable impact on other system resources, the business processes it supports and the MTD. Because the RTO must ensure the MTD is not exceeded, it must normally be shorter than the MTD.

Recovery Point Objective (RPO): the point in time, prior to a disruption or outage, to which business process data can be recovered given the most recent backup copy. Unlike the RTO, it is not considered part of the MTD: it is a factor of how much data loss the business process can tolerate.

The guide adds a useful idea for leadership: the shorter the RTO, the more expensive the recovery solutions. A system that must be recovered immediately requires redundancy and alternate sites; a low-impact system with a long RTO can be handled with a simple backup. The balance point between the cost of disruption and the cost to recover is different for every organization and every system.

What does ISO 22301 say?

ISO 22301:2019 is the international standard for business continuity management systems (BCMS). According to ISO's official page, it provides a framework for organizations to plan, establish, implement, operate, monitor, review, maintain and continually improve a documented management system to protect against, reduce the likelihood of, and ensure recovery from disruptive incidents. Its second edition was published in October 2019 and has a 2024 amendment.

Certification is not mandatory. It makes sense when a customer, a bank or the sector requires it. What is worthwhile, in our view, is building the plan with the logic of a management system — owners, documentation, tests and periodic review — even if the company never certifies.

The plan's solutions, with no vendor commissions

If the plan requires backup, high availability or an alternate site, we select vendors with criteria defined before seeing proposals.

• Four criteria: functional, technical, economic and sustainable
• Implementation governed by the PMO

Talk to our team

How do you build a business continuity plan, step by step?

NIST SP 800-34 describes a seven-step process for information system contingency planning, which also works as a structure for the continuity plan:

1. Develop the policy: objectives, scope, roles and responsibilities, and the frequency of testing and maintenance.

2. Conduct the business impact analysis (BIA): critical processes, impacts, resources and recovery priorities.

3. Identify preventive controls: measures that reduce the effects of a disruption before it happens.

4. Create contingency strategies: backups, alternate sites, roles and cost considerations, integrated into the architecture.

5. Develop the plan: document the recovery strategy with detailed procedures.

6. Test, train and exercise: rehearse the plan, train personnel and run drills.

7. Maintain the plan: review and update it when systems, processes or the organization change.

A continuity plan that hasn't been tested isn't a plan. The drill shows in hours what the document doesn't show in months.

What must leadership decide?

There are decisions the IT department cannot make alone. Which processes are critical and in what order they are recovered. How long each one tolerates being down (MTD and RTO) and how much data it can lose (RPO). How much the company is willing to invest in redundancy versus the cost of the disruption. Who activates the plan, who communicates with customers and authorities, and who decides to return to normal. And how often it is rehearsed.

What does belong to IT is the DRP: which systems are restored, with which backups, at which site and with which procedures. The two parts must fit: the DRP recovers what the BIA said was critical, in the order and times leadership set.

How we can help

At Cyrrus we provide business continuity consulting: we identify critical processes, run the impact analysis, set RTO and RPO with leadership and design the continuity and recovery plans, which are rehearsed with a real scenario before being considered finished.

If the plan requires new backup, high-availability or alternate-site solutions, we select them with our technology infrastructure consulting, with no vendor commissions, and Project Management governs the implementation. To prepare the leadership team, Leadership Academy offers a business continuity and DRP workshop.

To go deeper into related topics: how to choose a cybersecurity consulting firm and what IT strategy is.