You don’t have to know everything about how your IT plan for disaster recovery works. But there are two critical metrics related to that plan that should be clearly defined before you sign-off on the budget for the next fiscal year – that is, your Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
Don’t worry I am not trying to complicate things for you with two more acronyms to remember. In fact, you might even realise that you were thinking RTO and RPO long ago; you just called them something else. However, understanding the difference between the two will help you optimise your disaster recovery plan. First off, real recovery is the when the business is back up and running again, whether on premise or in the Cloud; when all the teams are able to access their data and their applications and operate as before, then the business is said to have recovered from the disruption or disaster.
In this context, the data loss that a business is able to tolerate when a disaster or disruption occurs is the Recovery Point Objective (RPO). According to TechAdvisory.org “RPO is determined by looking at the time between data backups and the amount of data that could be lost in between backups”.
Alternately, the amount of time it will take for the business’ IT systems to be operational again – apps, data and all – after an outage is the Recovery Time Objective (RTO). This is typically defined in hours, days or weeks. But the best practice time frame is around 15 minutes. Once you identify your RTO and RPO you should then move quickly to quantify the costs associated with a downtime brought on by a disaster or unplanned disruption. And in identifying these associated costs, you will begin to see a clear picture of the impact and financial risk of a system outage, and the steps that must be taken to minimise that risk.
“…CEOs and COOs should play an active role in identifying their company’s RPOs and RTOs”
Contrary to what typically happens in many organisations, CEOs and COOs should play an active role in identifying their companies RPOs and RTOs. In fact, identifying RPOs and RTOs will minimise the risks associated with downtime, and therefore should be treated as an important performance metric. Let’s look a scenario that illustrates how RPOs and RTO impacts on your business.
Let’s say your IT teams backup at the end of the day around 7 o’ clock. What if at 4 pm the next day a major event occurs and your system goes down? In this scenario your closest point of recovery (your RPO) is the night before. Just like that, you have lost data for 8 hours of the workday, not to mention any processes that might have started after the backup from the previous evening. Armed with this metric, you can determine if your business can withstand that much data loss.
“The greater the number of business transactions the higher the risk to the organisation”
When it comes down to it, the right RPO is really about a company’s transaction rate and what management feels is an appropriate data loss that they can recover from; the size of the business doesn’t matter. The greater the number of business transactions the higher the risk to the organisation. If such a business is processing transactions every minute of the day and customer records are being updated continuously throughout the day – your RPO can’t be more than minutes.
“Aim to have an RPO of 15 minutes or less”
Companies ideally should aim to have an RPO of 15 minutes or less. If you are unable to achieve your RPO you could lose customers and damage your reputation.
So while IT Team leads offer very valuable insight to the business, a company’s RTO an RPO is really a business issue; one that needs to be defined and articulated at the C-Level, and then a technical solution deployed to accommodate it. At a minimum, one should quantify the cost to the business when your system is down. One rule of thumb is that when a business is down for 24 hours, the financial impact could be as high as $11Million, depending on the size of the business.
Such technical solutions then, should really pivot around the broader conversation of IT resilience. With today’s business being increasingly dependent on stored data, forward looking CEOs should drive their IT Teams away from the ad hoc scenario of back up and recovery toward a deliberate and methodical approach for achieving IT Resilience. Such a scenario gives businesses the ability to maintain acceptable service levels through severe disruptions to a business’s critical processes and the IT systems that support them.
In the meantime, while CEOs may not have to know every IT detail of your business continuity plan, it’s pretty important to have a handle on your RTO and RPO.
