Calculated RTO’s Often Miss The Mark
As it relates to the business continuity consulting services we offer, Castellan works with a lot of organizations that already have software to assist with a wide variety of tasks, including the performance of a business impact analysis (BIA). Most commercial business continuity software tools have functionality that guides an organization through the BIA process. Some of these tools with BIA functionality “calculate” recovery time objectives, or RTO’s, for business activities and resources, often using complex algorithms that are difficult to understand or explain to the business.
In addition to performing consulting work, Castellan also offers business continuity software called Castellan, which like many of our competitors, has a BIA module. Unlike some of our competitors, we chose not to offer calculated RTO’s but rather to provide a recommended RTO for consideration and then allow the person responsible for the BIA to make a choice, using his or her best judgment.
Allow me to explain why, and I’ll do so using my recollection of a recent business continuity software sales conversation. For purposes of this blog, I’ll call the person I was engaging in the sales conversation, Joe.
Joe – “Brian, I understand Catalyst doesn’t calculate RTO’s like some other software.”
Brian – “That’s correct Joe. When designing the Catalyst BIA module, we decided to recommend RTO’s.”
Joe – “Can you explain this decision to me further, because I’m struggling to understand how an organization can achieve consistency with its RTO assignment process. The way I see it, software-driven RTO calculation is essentially a form of AI that can benefit us.”
Brian – “At one point in my career, I thought the same thing. But before I explain why we made the choice, I think it would be intriguing to discuss your AI comment. As I see it, AI is essentially a computer system functionality that performs tasks that normally require human intelligence. Some examples are speech recognition, decision-making, and translation between languages. So if we use the decision-making component of this definition, you’d be right, calculated RTO’s could be considered a form of AI.”
Although we were on a conference call, I could almost hear Joe nodding. So I continued.
Brian – “But the reality is often very different. Human judgment is a key factor in making risk management-related decisions, and the assignment of RTOs is no different. This is where AI and calculated RTO’s fail to align. There is a myriad of factors that play into the RTO assignment process, and not all of them are quantifiable. Legal and regulatory requirements, customer service level agreements, management expectations, reputation impairment, and operational impacts can be qualitative and therefore RTO assignment can be subjective. Keep in mind, collecting impact information is essentially like justifying an RTO, and you’re just showing your work in case someone asks. And a narrative explanation is often sufficient. Also, the identification of necessary upstream dependencies can be less than black and white, which factors into the RTO assignment. And one more thing. Despite best attempts to qualify financial impact at an activity and resource level, this is often impossible or inaccurate – the use of financial impacts is more appropriate at a product/service level. And as it turns out, the financial impact is the major source of input into the algorithms that ‘calculate’ RTO’s.”
I paused to let Joe comment, but then I remembered one more key point.
Brian – “One more thing Joe, I have a theory as to why people – at first – want calculated RTO’s. Many business continuity professionals don’t have the time to explain how to determine RTO’s and as such, the assignment process is all over the place. And second, there is often a trust issue. A significant number of business continuity professionals – whether they want to admit it or not – don’t trust their business partners to come up with realistic RTO’s. I think training and awareness and strong dialogue can help overcome this.”
Then I paused my explanation and Joe offered a comment and question. “That makes sense Brian. It’s interesting, I was talking to a colleague in a different organization – someone I used to work with – her organization implemented business continuity software and she told me that her experience is that she often has to override the calculations. Do you see that too?”
Brian – “Exactly. Not only because of the qualitative nature of some impacts and the subjective nature of RTO assigning, but the algorithms used to assign RTO’s are also so complex that many business continuity professionals can’t explain them to their internal customers. When you factor all of these issues together, combined with management requesting changes based on their interpretation of the risk of disruption, these calculations often miss the mark and are overridden. Although it sounds easy, the override process is often very, very difficult and time-consuming. So the experience you noted with your colleague is incredibly common. And because Castellan uses other software at times with our clients, we’ve experienced this firsthand.”
Joe – “So how do you address this issue with Catalyst?”
Brian – “We’ve employed an approach that is based on the ISO 22301 concept of risk appetite or risk tolerance, and when either a qualitative or quantitative impact level is crossed based on the input of the person completing the BIA, Catalyst recommends a recovery time objective. The person completing the BIA process is then offered a recommendation, but they have to make a choice based on their professional judgment. It’s this choice – I should call it an informed choice – that makes the Catalyst experience more pragmatic, accurate and efficient.”
And that ended my recent conversation with Joe on the topic of calculated RTO’s. This discussion topic is very common when organizations evaluate software, and the reality is that the criticism of calculated RTO’s is incredible common as well. Management judgment is key, and it’s very important for a person responsible for a BIA to align their recommended activity and resource RTO’s with “how much” business continuity is needed for products and services at the strategic level, something determined in the Business Continuity Operating System (BCOS) Frame conversation.
Get resilience insights delivered to your inbox.