Recovery Time Objectives and Recovery Point Objectives

Richard Long

Sometimes it is a good exercise to step back and review some basics. I was at a high school basketball game recently and the teams were running a pro-style offense. The difference, however, was one team was fundamentally sound – on target passing, effective ball movement and basic concepts – while the other team was not. You can guess the outcome of the game.

Similarly, we should be looking at the basics in our business continuity programs to ensure we are fundamentally sound. Today’s blog is related to the very basic and fundamental concept and requirements of Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Before you close this window or go somewhere else, take  two minutes to finish this short blog, then take another two minutes to consider the state of the RTOs and RPOs in your business continuity program. These provide the basic, and arguably most important, requirements in developing technical and business recovery strategies.

What is a Recovery Time Objective?

Your recovery time objective is the time when a system, application or process must be functional again. This means ready for production use, not just “up.”

What is a Recovery Point Objective?

A recovery point objective is the data state where the system, application or process must be restored and functional. This is the amount of data lost.

These are very different. Often organizations assume that a short RTO implies a small RPO. This can be the case, but is often not. In order to demonstrate the difference, I like to use the following application examples:

  • Accounting application: This is typically a system with a slow recovery.
    • RTO = 1 – 3 days.
    • RPO = 0 – 8 hours (very little data loss acceptable).
  • Public-facing website: This is typically a very fast recovery.
    • RTO = 0 – 2 hours.
    • RPO = 48 hours or more. Because the data is static and easily recreated, more data loss is acceptable.
  • Online shopping application: This may be a highly available application.
    • RTO = 0 hours.
    • RPO = 0 hours (no data loss acceptable).
  • Reporting application: Longer recovery.
    • RTO = 5 days.
    • RPO = 48 hours or more. Because the data can be recreated from the transactional systems, a larger data loss is acceptable.

Our Experiences with RTOs and RPOs

In the hundreds of Business Impact Analyses (BIA), MHA has performed over the years, a majority of applications tend to have similar RPOs with very different RTOs. We are finding the data loss tends to be in the <24 hour timeframe, but that recovery needs vary based on the business process criticality.

The question we are asked is: how do we get the appropriate RTO and RPO? Where an application or process RTO/RPO seem out of line with actual risk or impact, it is because the determination has been made without collaboration. Either the technical team or business owner thinks they know the answer without discussion. IT can underestimate impact and business owners overestimate. In order to get appropriate values and information, collaboration between the teams is critical.

A formal BIA with business units, using objective criteria including both financial and non-financial impacts is ideal. It should be performed as a baseline and then on a regular basis (every 2 years). Performing modified or even “back of the envelope” BIAs can still provide functional information. It is important that the RTO and RPO levels are well defined and communicated. Use times along with descriptions like Tier 1 (0 – 8 hours), Tier 2 (9 – 24 hours), etc.

Modified BIAs could be short questionnaires that include basic financial and non-financial impacts such as loss of revenue, customer service impacts, etc. IT can provide input on costs, complexity and implementation times for strategies that meet the RTO/RPOs. At a minimum, a 15 to 30-minute conversation with a process owner and IT will get you 80% of the way there. The benefits of gathering dependencies (technical, business and workarounds) will not occur, but an understanding of the actual criticality can be achieved.

Understanding the RTO Process

Understanding the RTO at the process level makes technical recovery and strategies easier. When new applications are implemented for an already defined process, the RTO is known and all that needs to occur is the verification of the RTO and RPO. No formal BIA is needed.

It might be a good time to review your recovery time objectives and recovery point objectives for the processes in your organization. You might also consider a review of the applications associated with the processes. What has changed or been added? Have the priorities of the organization changed, impacting the criticality of processes and applications? This is basic and fundamental, but without it you may not be as prepared for a recovery as you think.

Richard Long is one of MHA’s practice team leaders for Technology and Disaster Recovery related engagements. He has been responsible for the successful execution of MHA business continuity and disaster recovery engagements in industries such as Energy & Utilities, Government Services, Healthcare, Insurance, Risk Management, Travel & Entertainment, Consumer Products, and Education. Prior to joining MHA, Richard held Senior IT Director positions at PetSmart (NASDAQ: PETM) and Avnet, Inc. (NYSE: AVT) and has been a senior leader across all disciplines of IT. He has successfully led international and domestic disaster recovery, technology assessment, crisis management and risk mitigation engagements.
business continuity planning resourcesdisaster recovery strategy