After the BIA: Save Time and Money by Fine-Tuning Your Application RTOs 

The business impact analysis (BIA) is a great tool, but after it is complete, organizations have an opportunity to potentially save time and resources by conducting a tightly focused, second-level review of the applications RTOs. Identifying applications that have been given unnecessarily short recovery time objectives (RTOs) can enable a company to avoid overarchitecting application recovery solutions.   

Related on MHA Consulting: RTO and RPO: Making It Simple

After the BIA 

The BIA is the cornerstone of a sound business continuity program. By collecting input from across the organization and ranking the business processes in terms of time sensitivity, the BIA tells the organization the priority for process recovery, in the event of an outage, in order to avoid suffering unacceptable levels of impact. 

However, constraints on the BIA process—coupled with the complexity of modern organizational and IT systems—have created an opportunity after the BIA is complete for diligent BC offices to potentially save their companies time and money related to the IT recovery solutions.  

By going back and reviewing the application RTO and RPO information in the BIA and discussing it with the relevant department, the BC office might be able to identify applications for which the initial RTOs should be adjusted to a longer recovery time. 

The High Cost of Short RTOs  

As a reminder, an RTO establishes how quickly an app needs to be recovered to avoid an unacceptably serious impact to the organization due to a technology outage. A highly critical process might have an RTO of four hours with the associated applications having the same RTO, while the RTO of a noncritical process and associated applications might be measured in days.  

Being able to successfully meet short RTOs imposes higher costs on the organization in both capital and time due to maintenance requirements.  

The vast majority of RTOs are accurate following the BIA. However, it sometimes happens that processes and, therefore, applications determined to have short RTOs should be reassessed. 

This happens because BIAs necessarily look at things at a relatively high level; they have to since the average company has dozens of departments and hundreds or thousands of business tasks which are consolidated to a higher level process for the BIA.  

Some Application RTOs Need Reevaluation 

Savvy BC professionals understand that the above process sometimes results in the overclassification of applications. On occasion, applications associated with a process with a short RTO may not actually be required in that timeframe.  

This can be due to several reasons: 

  1. The RTO impacting tasks within the process may not require all applications.  
  1. Processes have a lower reliance on some applications.  
  1. There are effective workarounds if an application is unavailable. (These have become less frequent, but in a previous blog, MHA discussed the need for manual workaround due to extended cyber events.)  

The BC office can help the organization save time and resources by fine-tuning the RTOs, that is, identifying apps that have been given unnecessarily short RTOs by coordinating a review with the IT team and process department and adjusting the RTO into a less urgent (and less expensive) category. 

How to Fine-Tune Your RTOs 

In doing a post-BIA review to fine-tune the RTOs, the BC office should consider the following: 

  • IT should review the list of applications by RTO and identify gaps between the BIA-defined RTO and current recovery capability. For those with a gap, review the requirements initially identified for recovery and compare those results with the BIA impact results.  
  • In the BIA, processes, and applications are typically ranked low, medium, and high in terms of reliance (how dependent the larger business process is on that process or app). Applications whose reliance is medium or low are good candidates for having their RTOs relaxed. 
  • Address the manual workarounds in place. While most processes or functions do not have defined manual workarounds and even those that exist may not be viable for a significant time, those that do exist provide an opportunity for an adjusted RTO.  
  • For processes that are not obviously at the appropriate RTO, review the reasons for the impact score. There may be specific actions or tasks which drive the impact score. Ensure the high reliance applications are those tied to the impacting tasks of the process.  

The Benefits of Fine-Tuning Your RTOs 

For one thing, it can save the organization money. For example, it might cost an organization $3 million to ensure that apps have an RTO of four hours. Following the review and adjustment, the costs may reduce significantly.  

There are many potential benefits to fine-tuning your application RTOs in the manner we have been describing.  

The dollar amounts saved vary widely by organization and application set. Given the higher costs related to redundant servers, storage, licensing, and other technical costs, the benefits of conducting a second-level review become obvious. 

Other benefits of avoiding overarchitecting the recovery program include reducing the amount of time employees must spend on maintenance (since faster recovery pieces tend to require more maintenance) and enhancing execution capability (since the simpler a recovery program is, the more likely it is to succeed). In addition, it allows for more applications to be in an appropriate recovery position rather than fewer “critical” apps.  

Applications as well as processes exist for a reason and must have a level of need and will have to be recovered. A business can only run on the “critical” apps for a short period before all the others will be needed.  

Saving Money and Enhancing Resilience 

BIAs necessarily look at an organization’s business processes at a relatively high level. As a result, after the BIA is complete, a diligent BC office has the chance to further benefit the organization by conducting a tightly focused second-level review. This review, conducted in cooperation with the other departments, should look for cases where applications have been assigned unnecessarily short RTOs.  

By giving these applications appropriate RTOs, the BC office, collaborating with IT, can prevent the organization from overarchitecting its technical recovery solutions, saving it time and money and possibly enhancing its resilience.  

Further Reading 

For more information on RTOs and other hot topics in BC and IT/disaster recovery, check out these recent posts from MHA Consulting and BCMMETRICS: 

 

About
Richard Long
Richard Long is one of MHA’s practice team leaders for Technology and Disaster Recovery related engagements. He has been responsible for the successful execution of MHA business continuity and disaster recovery engagements in industries such as Energy & Utilities, Government Services, Healthcare, Insurance, Risk Management, Travel & Entertainment, Consumer Products, and Education. Prior to joining MHA, Richard held Senior IT Director positions at PetSmart (NASDAQ: PETM) and Avnet, Inc. (NYSE: AVT) and has been a senior leader across all disciplines of IT. He has successfully led international and domestic disaster recovery, technology assessment, crisis management and risk mitigation engagements.
Most Important Part of Every Risk Mitigation PlanWhen to Start Your RTO Countdown