Who would have thought when the terms RTO (Recovery Time Objective) and RPO (Recovery Point Objective) were coined, that 30+ years later, the industry as a whole would still be arguing about what they meant, the “certifying bodies” would still be debating about when their clocks start and end, and the standards organizations would still be on a mission to invent new terms to better explain the concepts, while actually exacerbating the confusion (i.e. MTPOD).
Now enter the BIA. A good BIA (once again, if there is such a thing) will attempt to define both Application RTOs and Process RTOs. A valid effort as far as it goes. However, in today’s business environment of ever-increasing competition and cost-containment; continually more demanding availability requirements; increasing natural and man-made disruptions; and never-ending automation challenges…the effort doesn’t go far enough. The traditional terms do not answer today’s questions. They do not contribute to optimal planning and prevention efforts. And they do not facilitate the critical decision making and trade-offs that must be brokered at-time-of-disaster to enable the optimal recovery effort given the specific event’s impact.
In addition to the traditional RTO, there are at least eight additional “RTO Flavors” that are a mandatory part of any worthwhile BIA…or BIA Alternative.
- Process – Application RTO
- Minimum Application RTO
- Cumulative Application Criticality
- Application Recovery Group
- Application Recovery Group RTO
- Application Recovery Sequence
- Process RPC
- Application RPC
The key is that your BIA methodology must identify and define these “RTO Flavors” without any more effort and with indisputable accuracy. Unfortunately, most BIA’s do not even acknowledge these concepts. If your BIA doesn’t provide these “flavors”, it’s probably time to conduct a new BIA.
It’s time to dump the traditional BIA!
