Disaster Recovery (DR) has many different aspects to it. From Recovery Time Objectives (RTO) to Recovery Point Objectives (RPO), individuals in both IT and the business seem to think that what you accomplish during one exercise defines how you will perform during the next exercise. Unfortunately, many factors influence preparedness and outcomes.
The business seems to look at Recovery Time Actual (RTA), or how quickly you were able to recover an application during an exercise, as their new starting point for what they expect going forward. If your performance one year beats the RTO by 50%, can we safely assume that it will be recovered in the same timeframe during the next exercise?
My response to the business would be that they should not have those expectations. While I, as a DR Manager, may have those expectations, the business should look at the required recovery time of their applications and base the RTO on when the application must be back, not on past performances.
Things change. If your infrastructure changes year over year, the number of Critical applications rises or falls, the technology in the colocation becomes older and in need of upgrading, or replication methodologies change, these types of changes can all impact how quickly the team is able to recover applications during a DR exercise. Having the business say “You were able to recover it in X hours last year” does not automatically make it so during the next exercise.
It is imperative for the DR Manager and team to define the process for defining Criticality and follow that no matter the performance during the previous exercise. Inform the business on what RTO really means and make sure there is little variance from year to year unless the application somehow takes on more significance in the organization over that timeframe. Make sure that you adequately explain what it means to recover applications within the RTO window and set expectations for future exercises.
The main purpose of an RTO is to ensure that the business has their applications restored within the timeframe they define as needing the application to be up and running. Having the business always looking at past performance and expecting equal or better performance going forward will only hurt the overall DR process and could potentially look bad for the DR Manager and team. Making sure that the business understands the true meaning of RTO versus RTA could greatly improve your rapport with the business as well as your ability to continue making improvements in the DR space to ensure that RTAs continue to drop.
