The term “recovery time objective” has been around for so long now that you’d think that there would be a pretty-much universal understanding of what it means. This isn’t always the case, however. There’s one area in particular where there’s often a huge gulf in that understanding, and that’s the issue of recovery time objectives for IT systems.

“The business” will typically, and quite reasonably, assume that the recovery time objective for an IT system starts at the point of disruption, as does the recovery time objective for a business activity.

IT people, on the other hand, will usually, and just as reasonably, assume that the recovery time objective starts at the point when the decision to invoke the IT recovery plan is made. 

This difference in understanding is actually quite common, and can cause significant frustration on both sides of the divide. 

Because how can the business possibly develop meaningful continuity plans based on recovery time objectives that aren’t actually what they purport to be? And how can the IT folks possibly commit to meeting a recovery time objective that includes an unknown, and possibly lengthy, decision-making process that’s often completely out of their control? Clearly they can’t. But this is precisely the situation that many organisations find themselves in. 

The answer is actually quite straightforward. It boils down to communication and awareness. All of the interested parties need to understand what’s involved in meeting a recovery time objective – the whole process, not just the technical recovery part – and the timescales involved in each part of that process, including the decision-making element. 

This understanding may even help to reduce the recovery time, as the decision-makers might be motivated to make the invocation decision a bit quicker if they fully understand the consequences of delay. If not, at least the IT people shouldn’t have to unfairly take the flak when a recovery time objective is exceeded through no fault of their own.