The Quandary of the Recovery Point Objective (RPO)

Michael Herrera

Recovery Point Objective (RPO) is the maximum tolerable data loss expressed in time (e.g. minutes, hours, days, weeks, etc.) that a business process can stand to lose before it is critically impacted. Establishing RPOs for the computer systems and applications used by each critical and non-critical business process is no easy undertaking. The RPO is traditionally established for each business process and their associated systems and applications during the Business Impact Analysis (BIA) study. Below are basic steps to developing your RPO:

Step 1.  Determine Your Recovery Point Actual (RPA)

Before you start on the journey of RPOs, you need to determine what your Recovery Point Actual (RPA) is today for your critical systems and applications.

A frequent mistake when setting RPA for traditional daily tape offsite backups is to assume 24 hours for the RPO. This mistake is the result of not considering that the RPA time begins with the start of the first data backup used in the synchronization point, and must also include time for boxing the tapes, the inevitable contingency time that must be allowed for “waiting for courier transport”, and loading and final escape from site (not always at exactly the same time of day); the RPA must be increased by an amount of time equivalent to any such variability. It is also risky to assume that tapes will always be physically intact – the RPA should include enough time to use a previous synchronization point too.

You must know your RPA before you continue, so you know what the baseline is on potential data loss.  Also, remember, if the data doesn’t go offsite, even through it’s backed up, your RPA is only as good as the last backup offsite.

Step 2.  Determine Your Organizational RPO Needs

To help define what level of RPO categories your organization may need to consider, it is important to consider the following:

  • Industry (e.g., financial, healthcare, retail, etc.) – Is your organization in an industry that simply cannot lose data due to its critical, complex nature and impact to its clients should it be lost?
  • Legal / Regulatory Requirements – Is the organization under strict legal and regulatory guidelines regarding the protection and availability of data?
  • Ability to Recreate Is your organization a paperless environment or uses an automated workflow system that eliminates the use of paper records making recreation a nightmare?
  • Volume – Can the business units easily recreate the data or is the sheer volume so significant that even a one-day’s loss is catastrophic?
  • Downtime Procedures – Do you have effective downtime and/or manual workarounds to reduce RPO needs?

 

If I am a hospital or bank, we know our critical RPOs will be in minutes, hours or even zero data loss for key processes.  Remember, you will need to establish various tiers of RPOs just like Recovery Time Objectives (RPOs).  Even in a bank of hospital, not all business processes may have the same RPO for the systems and applications they use.

The lower RPOs you establish (e.g., minutes, hours, zero), the more complex and expensive the solution will be.  But, the cost of data loss based on your industry, legal/regulatory requirements, ability to recreate and sheer volume could be catastrophic to your organization.  Talk to several key business units to help you develop a reasonable set of RPO tiers that make sense for your business. Here is a sample RPO tier for a hospital:

RPO Tier Description
RPO 0 – 1 hour Business   processes and associated systems and applications can tolerate no more than 1   hour of data loss.
RPO 1 – 4 Hours Business   processes and associated systems and applications can tolerate up to 4 hours   of data loss.
RPO 2 – 12 Hours Business   processes and associated systems and applications can tolerate up to 12 hours   of data loss.
RPO 3 – 24 Hours Business   processes and associated systems and applications can tolerate up to one days   data loss.
RPO 4 – > 24   Hours Business   processes and associated systems and applications can tolerate more than one day’s   data loss.

Remember, these are objectives; it may take you time to reach these timeframes. Also, a computer system and/or application may have different RPOs based on the business unit and their criticality. The lowest RPO set is the baseline for that computer system or application.

Step 3 – Determine Your RPOs

Now that you have the RPO tiers, you are ready to include it in your BIA questionnaire.  For each business process identified, you must identify what the RPO should be. Go back to the criteria in Step 2 to help the business units determine what their RPO should be today. In some cases, it’s a no-brainer, in others there will need to be a discussion of needs versus wants.

Conclusion

As you can well expect, RPO timeframes are shortening due to today’s business needs.   Gone are the days of tape backup and restore. However, surprisingly, we still have organizations backup up data nightly but leaving it onsite, organizations replicating data only locally and/or the business not knowing what is their RPA is based on what IT is doing with their data.

 

About
Michael Herrera is the Chief Executive Officer (CEO) of MHA. In his role, Michael provides global leadership to the entire set of industry practices and horizontal capabilities within MHA. Under his leadership, MHA has become a leading provider of Business Continuity and Disaster Recovery services to organizations on a global level. He is also the founder of BCMMETRICS, a leading cloud based tool designed to assess business continuity compliance and residual risk. Michael is a well-known and sought after speaker on Business Continuity issues at local and national contingency planner chapter meetings and conferences. Prior to founding MHA, he was a Regional VP for Bank of America, where he was responsible for Business Continuity across the southwest region.