Getty Images/iStockphoto


Use recovery level objective to fine-tune BCDR response

Recovery level objective is not a widely used metric, but it has value to business continuity and disaster recovery teams. Learn how it fits in the BCDR timeline here.

Recovery level objective is a metric that defines the minimum resources an organization needs in the aftermath of a disruptive event. Resources required to recover and resume business operations to an acceptable level typically include people, processes, technology and facilities.

Setting goals for what constitutes a successful recovery is critical to disaster recovery planning and will vary greatly by organization. Disaster recovery teams can use recovery level objective (RLO) alongside other business continuity metrics, such as recovery point objective (RPO) and recovery time objective (RTO).

While not as frequently used as RPO and RTO, recovery level objective helps determine important information for recovery, including the following:

  • data files and databases to recover;
  • applications to restart;
  • network resources to return to service;
  • restoration of critical business processes;
  • employees who are healthy, physically able and available to work; and
  • work facilities, such as offices, factories and warehouses.

The RLO determines how much of each business element an organization needs to return the business to a minimally acceptable level of service. The recovery level objective could be business as usual before the disruption, but that may take time; during recovery and reconstruction, the organization might lose business or damage its reputation. By contrast, a more reasonable RLO could be just enough so that customers know the company is back in business.

RLO vs. RPO vs. RTO

The figure below depicts where RLO fits into a business continuity timeline. The RPO is in place to ensure that the most recent updates to data and other resources are available. The RTO indicates the amount of time needed to recover operations to an acceptable level following an incident. The RLO denotes the resources needed to be brought back into service during the RTO period that are enough for the organization to resume operations.

A chart showing where recovery level objective fits in the business continuity timeline

The RLO can extend beyond the RTO, and the additional time for an extended RLO indicates that the business wants more resources in place than simply the minimum to reopen its doors. What must be recovered during the RTO time frame, or beyond, is specified in the RLO.

How is recovery level objective determined?

Results of a business impact analysis (BIA) can provide much of the data needed to establish an RLO. The recovery level objective is not necessarily a numerical value, although one could define RLO as a 100% return to the way business operated before the incident. The desire for total recovery back to pre-event levels may be costly, challenging and time-consuming. It may also force layoffs or furloughs of employees, not to mention the competitive and reputational impacts such a decision may cause.

For example, if all servers in the data center must be operational, that's the RLO. If only two or three mission-critical systems need to be operational, that's the RLO.

BIAs are designed to identify the mission-critical processes of an organization, the technology that enables them, the people who perform them and the facilities where the work is performed. BIA results may indicate that not every system, process, employee and work location must be back in service on day one of the business restart. The table below shows how recovery level objectives may differ based on management requirements.

A table depicting different RLO management requirements

While this table is largely subjective, disaster recovery teams can develop similar tables from BIA results and discussions with senior management and business unit leaders. The challenge is then to translate management requirements into appropriate business continuity and disaster recovery plans to achieve those goals.

Dig Deeper on Disaster recovery planning and management

Data Backup