Understanding Recovery Point Objective (RPO) for Effective Data Protection

RPO – Recovery Point Objective

So, what is RPO? Recovery Point Objective (RPO) specifies how much time you have during a data ‘disaster’ before the amount of data you lose goes beyond what’s considered acceptable as defined in your Business Continuity Plan.

In other words, it defines how much data you can realistically afford to lose before it affects normal business operations or constitutes a serious data-loss problem. The ‘point’ at which things become serious will differ according to the type of business you operate – and the nature of the data you create, hold and take ultimate responsibility for. Critically, it also differs according to when your last data backup took place. For example, an hour of data loss for a financial or legal business will be far more damaging than, say, for a recruitment agency – so your RPO should reflect this, and so should the intervals between backups of data. It should answer the question, ‘how long until data loss affects business as usual?’

RPO (Recovery Point Objective) looks at what just happened, while RTO (Recovery Time Objective) focuses on how long it takes to fix.

To calculate Recovery Point Objectives, consider these factors:

• The maximum amount of data loss your business could tolerate
• Industry-specific factors – those who hold sensitive information will need to update more frequently
• Cost of lost data to your operations
• Data storage space and options
• Cost of implementing disaster recovery solutions
• Relationship between management and IT – management should decide on acceptable RPO and a budget for recovery measures, and communicate this to IT staff

RTO – Recovery Time Objective

What is RTO? As the name suggests, this is your disaster recovery time: how long it should take to recover fully from data loss, or a system or application problem that exposes or restricts access to data. Your RTO depends on the nature of your business and the sensitivity of data it generates and/or stores – so the more business-critical and/or private the data that’s potentially compromised, the faster you need to have it fully recovered and secured. You should state your RTO clearly in your Business Continuity and Disaster Recovery Plan, and ensure you have the means to meet it should anything go wrong.

To calculate Recovery Time Objectives, consider these factors:

• Outage costs per hour
• System importance and priority
• Available budget and resources for restoring applications and systems
• Recovery procedure complexities
• Again, the relationship between management and IT – IT staff may need to educate management teams on what is viable within a given budget

What is the difference between RPO and RTO?

While RTO and RPO are both business metrics that can help you calculate how often to perform data backups, it’s important to reiterate the difference between the two:

• RPO is the maximum amount of time between the last data backup and the ‘disaster’ that affects it. The more frequent the backups, the less data you lose.
• RTO is the maximum amount of time that can pass between data loss and complete recovery of systems. Depending on the data type, this can be an hour, or 15 minutes – for banks or legal firms, for example, RTO is ‘immediately’!

Your Disaster Recovery and Business Continuity Plans aren’t complete without a clearly defined RPO and RTO.

How to define RPO and RTO for your business

Your Recovery Point Objective and Recovery Time Objective – you do need both – will reflect the nature of your business and the data it generates and stores.

Websites or web-connected internal systems that create, use and depend on continuously updated and/or personal and private data will aim for an RPO defined in minutes or seconds – or even zero – to maintain data integrity and seamless operations. The associated RTO will reflect this, with an emphasis on returning all business-critical systems to normal ‘as before’ functionality as soon as possible. Conversely, non-revenue-generating marketing platforms, or purely information-sharing or entertainment websites may define an RPO and RTO in hours, days or even weeks.

Once defined, both need to feature prominently in your Disaster Recovery Plan – and anyone tasked with protecting data needs to know exactly how to ensure these objectives are reached.

Your step-by-step guide to defining RPO and RTO:

Step 1: Take an inventory of your IT assets, applications and data to get a clear picture of what you have, where it’s stored/located, and how it’s used. Ask as many of your staff as possible for their input, as data and applications may be in use without your IT team’s knowledge. Identify any dependencies between apps and systems.

Step 2: Conduct a business impact analysis to ascertain the operational, financial and reputational effects of your applications and data becoming unavailable. Remember you’ll need to consider compliance requirements too.

Step 3: Conduct a risk assessment to determine the vulnerability of your IT assets. Consider all possible disaster scenarios that could result in downtime and data loss.

Step 4: Review your current business continuity/disaster recovery (BC/DR) plan. If you don’t have a formal plan in place, make sure you know how your organisation handles backups and other elements of BC/DR plans.

Step 5: Consider enlisting the help of a third-party specialist in BC/DR. They can help with the steps listed here, as well as evaluate strategies for achieving your company’s RPO and RTO requirements.

You need to be able to answer the following questions:

• Which of your IT assets, applications and data are most critical to ensure your business can keep running?
• Which applications and data would you need to access first in the event of a data loss event?
• Which applications and data are less critical and would not have to be available immediately – and for how long could you operate without them?

Why your business needs a Disaster Recovery Plan

RPO and RTO planning is just one aspect of your Disaster Recovery Plan – a fully documented process that will define the recovery period for returning your organisation’s IT infrastructure to ‘business as usual’ following an incident.
Remember that the causes of these ‘disasters’ can be internal, such as human error or system failure – or external, such as malware or power cuts.

One way of looking at it is to plan for the worst-case scenario and ask, ‘what do we stand to lose?’ This isn’t scaremongering – it’s the best way to ensure you cover every aspect of what needs protecting, including customer data, day-to-day business functionality, and reputation. Let’s say you sell financial or legal services, or even handbags or car parts, online. You hold personal and possibly confidential data as part of what you do.

What would the knock-on effects be if one of your servers or hard drives failed and your backup wasn’t as frequent as it should be? What if a flood takes out your minute-by-minute physical backup, and your cloud solution only backs up every hour? What would the repercussions be?

By understanding and defining your business’s RPO and RTO requirements, you can identify and implement the resources needed to protect your data and effectively.

Editor’s Note: This post was originally published in November 2018 and has been updated for accuracy and comprehensiveness.