The idea that recovery objectives refer exclusively to technology and should be defined by IT is both widespread and incorrect. In fact, recovery objectives are needed for every critical business process, tech-dependent or otherwise. And defining them is the job of the business units, the business continuity office, and the senior leadership.
Related: Bridging the Gap: Aligning RTOs Between IT and the Business Units
Summary
- Recovery objectives are business requirements, not IT-owned technical targets.
- RTOs and RPOs should be defined by business units, the BC office, and senior leadership based on business impact and risk tolerance.
- IT’s role is to meet the recovery objectives for tech-dependent processes and identify gaps when current capabilities fall short.
Understand RTOs and RPOs
Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) are two of the most familiar concepts in business continuity methodology. They’re also two of the most misunderstood.
Before we discuss the details of who should define them, let’s review what they are.
An RTO is a time window within which, following an outage, a critical business process must be restored to prevent a level of damage deemed unacceptable by senior leadership.
An RPO is the maximum amount of transaction data or work product, measured in time, that an organization is willing to lose following an outage. The objective reflects both the business impact of losing that data and the organization’s ability to recreate it through manual processes or by obtaining it from other sources.
Common RTOs include: zero hours, within four hours, within 12 hours, within three days, and within one week. These are examples. A company can set and use whatever RTOs it requires.
Common RPOs are zero hours, four hours, eight hours, and 24 hours. Again, these are examples. Each company decides on a set of RPOs that make sense for it.
The most common misconception surrounding RTOs is that they refer exclusively to IT-related matters, such as computer applications. In most cases, RPOs are indeed primarily related to applications.
The second most common misconception about these two recovery objectives is that they should be set by the IT department.
Recovery Objectives Apply to Business Processes First, Then Applications
Recovery objectives should be determined based on business processes and needs, not IT considerations.
Even experienced BC practitioners sometimes think that RTOs are all about apps, specifically how quickly particular apps such as the financial system, warehouse management, order management, or other systems need to be restored.
This amounts to mixing up the ends and the means.
Applications are the means companies use, during ordinary times, to support and enhance business activities, such as running payroll or resolving customer complaints.
RTOs are about the ends, not the means. They are about how long the process, such as running payroll, can be down.
The RTO doesn’t care about the means, only the process. That’s the part that really matters to the welfare of the company.
The applications might dominate our waking hours in normal times, but BC recognizes that they are merely a means to an end. As far as resilience is concerned, it’s the end that counts.
RTOs are also needed for critical business processes in which IT plays a modest role or none at all, such as driving trucks from the distribution center to the stores or doing security screenings of visitors.
Similarly, RPOs can relate to the loss of digital transaction data, such as purchases made on a website, but they must also be set for critical non-IT activities, such as loan applications accepted over the course of the day in paper form, although this is less common.
RTOs and RPOs should apply to business processes and reflect business needs. At this stage, the objective-setting stage, IT considerations should be nowhere in sight.
Why IT Should Not Define Recovery Objectives
The other common misconception is that defining RTOs and RPOs is the job of IT.
By now, it should be obvious why this doesn’t make sense.
IT systems and apps play a primary role in business activities, during ordinary times, in certain critical business processes. Within the context of BC, that is their function.
Obviously, over the long haul, during routine periods, IT systems and apps are essential to the company’s operations.
However, in BC methodology, technology should be seen as a supporting player. In BC, the star of the show is the processes.
A few moments’ consideration will illuminate an important reality: IT is not in a position to independently know how long critical business process X can be down before it will cause a level of damage to the organization judged, by senior management, to be unacceptable. Therefore IT does not have the full insight needed to set RTOs.
Similarly, IT has no independent knowledge of how much data or work product the company is willing to lose, or can recreate, in the event of an outage to a particular application or business process. As a result, the IT department lacks the knowledge required to define RPOs.
Today, IT departments do countless important things to support their organizations, but one thing they should not be doing is setting RTOs and RPOs.
The Business Side Owns the Recovery Targets
If IT does not define recovery objectives, who does?
The answer is the business side of the organization, specifically, the business units working in collaboration with the BC office and senior leadership.
The reason is, these are the people who are in possession of the relevant information.
The business units can assess the impact of disruptions to their business processes. They are also knowledgeable about their ability to manually recover or recreate any data that is lost as a result of being outside the organization’s data protection envelope.
The senior leadership knows how much risk the organization can tolerate and what it is willing to sustain in terms of impacts.
And the BC office is familiar with the trade-offs various choices entail and knows how to work with the other parties to come up with appropriate recovery objectives.
When these groups rather than IT set the organization’s RTOs and RPOs, the result is recovery objectives that are grounded in business reality rather than ones selected without reference to the criteria that matter most.
IT’s Job Is to Meet the Objectives
The most important letter in RTO and RPO is the O, for objective. These are targets. Once they are defined, the ones for tech-dependent business processes are passed on to IT, whose skills now become relevant.
At this stage, IT’s job is to ensure that the company can hit its tech-related recovery objectives.
Sometimes this is straightforward.
Existing recovery technologies and architectures may already support the required RTOs and RPOs.
In other cases, achieving the objectives may require additional investment in infrastructure, software, cloud services, replication technologies, or other recovery capabilities.
If the desired recovery capability proves too expensive or technically impractical, the organization should not simply lower the objective. Instead, leadership should consciously decide how the gap will be addressed.
Solutions might involve any or all of the following: additional investment in technical recovery solutions, acceptance of risk, or creation of business workarounds that enable the process to continue operating until full recovery is achieved. Such workarounds are devised by the relevant business unit.
For information on the human and political side of achieving alignment between the business units and IT, see some of the blogs listed below.
In sum, with every critical business process, the discussion begins with the business side’s defining appropriate recovery objectives. This is a prerequisite to the next step: identifying and closing any gaps that exist between what the business needs and what IT can do.
Recovery Objectives Begin with the Business
Contrary to popular belief, recovery objectives are not technical specifications. They are business requirements, specifically requirements that express how long critical processes can be unavailable (RTOs) and how much data the organization is prepared to lose before unacceptable business impacts occur (RPOs).
The business units, the BC office, and senior leadership, rather than IT, need to take ownership of the recovery targets because they, and not IT, have the background knowledge needed to define them. Eventually IT will be given the objectives and work can begin on ensuring they can be met and closing any gaps that exist between IT’s capabilities and the needs of the business units.
Organizations seeking to strengthen their recovery planning do not have to navigate these decisions alone. MHA Consulting helps clients facilitate business impact analyses, establish meaningful recovery objectives, align business and IT expectations, and develop practical recovery strategies that support true operational resilience. Contact us to learn how we can help your organization build recovery objectives that reflect its real business needs.
Further Reading
- Bridging the Gap: Aligning RTOs Between IT and the Business Units
- About Time: Deciding When to Start Your RTO Countdown
- Saying No: When the IT Department Reflexively Opposes the BC Program
- RTO vs. RPO: How to Resolve Conflicts Between Business and IT
- RTO and RPO in Practice: How to Set Defensible Targets
Frequently Asked Questions
What are RTOs and RPOs?
A Recovery Time Objective (RTO) is the maximum amount of time a critical business process can be unavailable following an outage before the organization suffers an unacceptable level of harm. A Recovery Point Objective (RPO) is the maximum amount of transaction data or work product the organization is prepared to lose during an outage.
Does IT define the company’s recovery objectives?
No. RTOs and RPOs should be established by the business units, working with the business continuity office and senior leadership, because these groups understand the operational impacts of outages and the organization's tolerance for disruption and data loss. IT’s role is to design and implement recovery solutions that achieve the organization's recovery objectives.
What does “achieving alignment between BC and IT” mean?
Achieving alignment between business continuity and IT means ensuring that the organization's technical recovery capabilities support its business recovery requirements. The business side first determines how quickly critical processes must be restored and how much data loss is acceptable. IT then evaluates whether current recovery technologies can meet those objectives and, if necessary, works with the business to close any gaps through technology investments. The company might also address gaps by accepting risk or developing manual workarounds.
Why does the business side define the recovery objectives?
Recovery objectives are business decisions, not technical ones. Business units understand the importance of their processes, the operational impact of prolonged outages, and how much lost work or data can realistically be recreated. Senior leadership determines the organization’s overall tolerance for risk, while the business continuity office facilitates the process and helps participants evaluate trade-offs. Together, these groups are in the best position to establish recovery objectives that accurately reflect the organization’s business needs.
