--- title: "The Reliance Test: A Key Factor in Determining Application RTOs" description: Not every application needs the same RTO as the process it supports. Learn how reliance and workarounds can help right-size recovery targets. --- [MHA Consulting Blog | Roadmap to Resiliency](https://mha-it.com/blog) # [The Reliance Test: A Key Factor in Determining Application RTOs](https://mha-it.com/blog/application-rtos-reliance-test) Written by [Richard Long](https://mha-it.com/blog/author/richard-long) | Oct 6, 2026, 6:28:43 PM Many organizations make life unnecessarily difficult for themselves by making their software application RTOs more stringent than necessary. By looking at how critical each application is to the business process it supports, organizations can right-size their RTOs, saving time, reducing stress, and conserving resources. **Related:** [Bridging the Gap: Aligning RTOs Between IT and the Business Units](https://mha-it.com/blog/align-rtos-rpos-business-it) **Summary** - Not every application supporting a business process needs the same RTO as the process itself. - Application reliance helps distinguish systems that need rapid recovery from those that can safely wait longer. - Workable alternatives can further reduce reliance on an application and support more realistic recovery targets. ## The Problem with One-Size-Fits-All RTOs Setting appropriate recovery time objectives (RTOs)—that is, the target time within which a given application must be recovered after an outage—is probably the most important requirement in developing appropriate strategies for business continuity and IT disaster recovery (IT/DR). Best practices for setting RTOs are well-known, but many organizations struggle in this area. One problem we see frequently is that RTOs are determined by the capacity of the IT department rather than the needs of the business. This is the exact opposite of how it should be done. See [“The Role of the Business Side in Defining Recovery Objectives.”](https://mha-it.com/blog/business-continuity-recovery-objectives) Recovery objectives should be driven by business requirements, not IT capabilities. Another common problem in determining application RTOs is that organizations often decide on them as part of a perfunctory data-gathering exercise rather than through a careful assessment of the importance of each application. For example, they might just send a questionnaire to business owners asking them to identify the RTOs of their processes and applications. We often see companies, as a matter of routine, giving every application the RTO of the business process it supports, whether that’s running payroll, processing orders, manufacturing a product, or whatever it might be. This is quick and convenient but not necessarily correct. Ironically, this apparent labor-saving approach frequently makes things harder for the company in the long run. In many cases, it makes the RTOs for a whole raft of applications much shorter than they need to be, needlessly increasing the burden, stress, and expense of achieving recoverability. ## The Reliance Test The key to understanding why application RTOs don’t necessarily have to be the same as those of the business processes they support is a concept called reliance. In the normal run of business, several different software applications might be used in carrying out a given business process. Let’s take order processing as an example. In a typical, nondisrupted situation, the applications used to process orders might include, among others, an order management system, an inventory management system to reference information, a customer relationship management system, a shipping and fulfillment system, and a business intelligence dashboard. In a normal situation all of these applications might play a role in processing orders. But some are more important to the process than others. ### What Application Reliance Means Reliance is the term we use to describe the importance of a given application in carrying out a process. It can be defined as the degree to which the business process depends on an application to continue functioning. ### High, Medium, and Low Reliance With our order-processing example, all of the applications mentioned might support this process, but they do not necessarily have the same level of reliance. The order and CRM might be considered high reliance, inventory systems and shipping systems medium reliance, and the intelligence dashboard low reliance. And their RTOs should reflect these differences. The RTOs of the medium- and low-reliance applications could conceivably be longer, and therefore less stringent, than those of the high-reliance applications and the process itself. ## The Benefits of Considering Reliance Subjecting applications to the reliance test helps IT develop more appropriate recovery solutions. Identifying applications with lower reliance and giving them appropriately longer RTOs can significantly reduce the demands on IT—without compromising the organization’s ability to recover its critical business processes. Generally speaking, the longer an application’s RTO, the less the resources that are required to meet it. Short RTOs can cause IT to build recovery capabilities that aren’t actually necessary, increasing the costs associated with recovery and maintenance. By identifying low-reliance applications and giving them appropriate, longer RTOs, the organization saves time and resources that it can invest elsewhere. And right-sizing application RTOs is more than a cost-saving exercise. It also makes recovery itself more manageable. When everything is important, nothing is important. Giving lower-reliance systems longer RTOs allows the recovery team to focus on the applications that truly need to be restored quickly. The reliance test helps distinguish which applications truly need short RTOs from those that can safely wait. And it delivers its benefits without compromising the organization’s recoverability. ## Don’t Forget the Workarounds When the issue of workarounds is considered, the news about application RTOs potentially gets even better. If a solid workaround exists for an application that might be considered high reliance, that should be factored into its RTO. If employees can perform the function another way for a limited period, the organization may be able to give the application a longer RTO without compromising the business process. ### Example: Shipping and Fulfillment For example, an organization might normally rely on its shipping and fulfillment application to process customer orders. If that application goes down, employees may be able to use a manual process or an alternate system to continue fulfilling orders for a period of time, several hours or perhaps even a day or two. The application is still important, but the business may not need it back as quickly as the order-processing function itself. The key is to consider the actual capability provided by the application, rather than simply assuming that everything supporting a business process must be recovered at the same time. Understanding workarounds can therefore help organizations distinguish between applications that truly need short RTOs and those that can safely wait longer. ## Putting Reliance to Work Many organizations struggle with determining application RTOs, a critical factor in developing appropriate IT/DR strategies. One common mistake is assigning applications the RTO of the business process they support. A better approach is to consider reliance and the availability of workarounds to distinguish between applications that need rapid recovery and those that can safely wait. This approach can reduce the time, effort, and resources required for IT/DR while keeping recovery focused on what the business actually needs. MHA Consulting has extensive experience helping organizations assess application reliance and develop practical, business-driven recovery objectives. If you need help right-sizing your application RTOs, [get in touch](https://mha-it.com/contact). ## Further Reading - [The Role of the Business Side in Defining Recovery Objectives](https://mha-it.com/blog/business-continuity-recovery-objectives) - [After the BIA: Save Time and Money by Fine-Tuning Your Application RTOs](https://mha-it.com/blog/fine-tuning-your-application-rtos) - [Bridging the Gap: Aligning RTOs Between IT and the Business Units](https://mha-it.com/blog/align-rtos-rpos-business-it) - [All About RTOs: What They Are and Why You Have To Get Them Right](https://mha-it.com/blog/recovery-time-objectives) - [Take Your Pick: Which BC Consulting Approach Is Right for You?](https://mha-it.com/blog/business-continuity-consultant-engagement-model) ## Frequently Asked Questions ### What is an RTO? A recovery time objective (RTO) is the target time within which an application must be recovered after an outage. RTOs should be based on business requirements, not simply on IT capabilities. ### Should every application have the same RTO as the business process it supports? No. Different applications can play different levels of importance in a business process. Assigning every application the process's RTO can result in unnecessarily short RTOs and increased recovery demands. ### What is the reliance test? The reliance test looks at how much a business process depends on a particular application to continue functioning. Applications with lower reliance may be able to have longer RTOs than applications that are essential to the process. ### How do workarounds affect application RTOs? A workable alternative can reduce an organization’s reliance on an application. If employees can continue performing the function manually or through another system for a period of time, the application may not need to be recovered as quickly. ### What are the benefits of right-sizing application RTOs? Appropriately longer RTOs for lower-reliance applications can reduce the time, effort, and resources required for IT/DR while allowing recovery teams to focus on the applications that truly need rapid recovery. [View full post](https://mha-it.com/blog/application-rtos-reliance-test) ```json { "@context" : "http://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Richard Long" }, "dateModified" : "2026-10-06T18:28:43.088Z", "datePublished" : "2026-10-06T18:28:43Z", "headline" : "The Reliance Test: A Key Factor in Determining Application RTOs", "image" : { "@type" : "ImageObject", "height" : 941, "url" : "https://46330580.fs1.hubspotusercontent-na1.net/hubfs/46330580/The%20Reliance%20Test_%20A%20Key%20Factor%20in%20Determining%20Application%20RTOs.png", "width" : 1672 }, "mainEntityOfPage" : "https://mha-it.com/blog/application-rtos-reliance-test", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "height" : 60, "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png", "width" : 60 }, "name" : "Roadmap to Resiliency" } } ```