The Recovery Time Objective debate continues over on a LinkedIn discussion board. Really folks, I don’t know what is so hard to comprehend here! I think some people are just trying to be difficult as a means to show they are smarter than everyone else. Me, personally, I prefer the KISS method – Keep It Simply Simple (I know it is usually said another way, but I wanted to avoid labeling people).
Simply put, the RTO measures the time objective for moving from Point A to Point B where; Point A equals the moment when a business process (or technology resource, if used for IT Disaster Recovery purposes) stops functioning and Point B equals the point when the business process (or, you know) must start functioning again to avoid jeopardizing the solvency of the organization.
It is an OBJECTIVE – that word is part of the acronym – why is it so hard to comprehend?
Yes, yes, yes, the event that interrupts the process or service will definitely influence when the recovery process starts, or what recovery tactic you decide to take – but the OBJECTIVE remains the same. Fine, fine, fine, so you have an emergency response team that is responsible for assessing the damages and determining whether or not to declare a disaster, but the OBJECTIVE remains the same and the clock is ticking.
Hopefully, your proven recovery capability is less than your recovery objective. In that case, the Recovery Time Objective minus the Proven Time to Recover equals the time your Emergency Response Team has to gather, evaluate the situation, and declare the disaster in order to ensure your RTO is met.
RTO – PTtR = Maximum Time to Declare
Your Emergency Response Team needs to be aware of all of these factors while performing their response tasks.
You do not decide the RTO or the PTtR at time of disaster – it is too late.
The RTOs are established in the BIA process. The PTtR are established through a series of tests and exercises.
I do not disagree with most of what people are arguing in the discussion thread – I just disagree with the words they are using in the argument. You are overcomplicating the point and mixing apples with oranges. Sometimes I think it would be better to just throw out the common terms in use today and come up with new terms at each company that do not have a preconceived notion of what they mean. Then define the new terms the way you want to use them so everyone in that organization has a common understanding. That may be throwing out the baby with the bath water, but it might stop me from pulling out what little hair I have remaining while reading this agonizing discussion thread.