Dejan Kosutic Updated: December 13, 2023.
When developing Business Continuity Plans (BCPS) or Disaster Recovery Plans (DRPs), two terms appear quite often: Recovery Time Objective (RTO) and Recovery Point Objective (RPO). While paramount to the definition of BCPs and DRPs, RTO and RPO aren’t easy concepts to understand, which can lead to plans that either allocate more resources than needed, or to plans that won’t achieve the expected outcomes.
In this article, you will see how ISO 22301, the leading ISO standard for business continuity management, defines these parameters, as well as examples of their application and how they can be used to build robust and reliable plans that allow the optimization of resources considering the desired outcomes.
RTO definition: The amount of time after a disaster in which business operations need to be resumed and resources need to be available for use.
RPO definition: The amount of data loss that would be acceptable for an organization as a consequence of a disaster.
What is the RTO?
The definition of RTO, Recovery Time Objective, is the amount of time after a disaster in which business operations need to be resumed and resources are again available for use. The RTO definition can be found in ISO 22300, which defines the vocabulary for ISO 22301.
For example, if the RTO is two hours, then this means you must resume delivery of products or services, or execution of activities, in two hours – therefore, your business continuity and disaster recovery plans need to consider the RTO during their development.
What is the RPO?
The definition of RPO, Recovery Point Objective, is the amount of data loss that would be acceptable for an organization as a consequence of a disaster (e.g., a catastrophic loss of software or hardware).
The meaning of RPO is also given by ISO 22301: The definition of the Recovery Point Objective, or RPO, is the amount of data a business can afford to lose in terms of time, or in terms of amount of information.
As an example, think about a database for recording all transactions in a bank (e.g., payments, transfers, scheduling, etc.). Usually, in such a case RPO is zero, because even in just a few minutes, hundreds of transactions can be made, and this information cannot be lost and cannot be easily recovered in any other way.
Now think about a source code repository where software developers keep their work. It is relatively easy to rewrite one day of lost coding for a software developer, but more than that can be difficult or impossible to recreate. In this case, the RPO would be 24 hours, which means that the backup needs to be done at least every 24 hours.
The point is, the harder it is to recover or recreate the data, the shorter the RPO needs to be.
RTO vs. RPO: What is the difference?
The main difference between RTO and RPO is in their purposes – being focused on time, RTO is focused on the downtime of services, applications, and processes, helping define resources to be allocated to business continuity; while RPO, being focused on the amount of data, has as its sole purpose to define backup frequency.
Another relevant difference is that, in relation to the moment of the disruptive incident, RTO looks forward in time (i.e., the amount of time you need to resume operations), while RPO looks back (i.e., the amount of time or data you are willing to lose).
What are RTO and RPO in disaster recovery and business continuity?
RTO is used to determine what kind of preparations are necessary for a disaster, in terms of money, facilities, telecommunications, automated systems, personnel, etc. The shorter the RTO, the greater the resources required.
RPO is used for determining the frequency of data backup to recover the needed data in case of a disaster. If your RPO is four hours, then you need to perform backup at least every four hours; every 24 hours would put you in big danger, but if you did it every hour, it might cost you too much and not bring additional value to the business.
Both Recovery Time Objective and Recovery Point Objective are related to business continuity by means of the business impact analysis (BIA), where they are determined, and the business continuity strategy, where preparations for achieving them are defined.
See these articles to learn more about RTO, RPO, and BIA: Five Tips for Successful Business Impact Analysis, and Backup policy – How to determine backup frequency.
RTO and RPO – are they related?
Although RTO and RPO are both crucial for business impact analysis and for business continuity management, they are not directly related, and neither conflict with each other (one deals with time and the other with an amount of data), so it does not make sense to talk about RPO vs. RTO.
Should RPO be less than RTO?
Since RTO and RPO are not directly related, RPO does not need to be less than RTO or vice-versa – you could have an RTO of 24 hours and an RPO of one hour, or an RTO of two hours and an RPO of 12 hours.
For example, an e-commerce site may need to be online 4 hours after a disruption, so RTO is four hours. Now, this same e-commerce site has two databases, one for its product catalog, which is updated once a week, and the second to record sales (thousands per day). The RPO for the first database can be one week, but for the second, the RPO should be near zero.
The importance of RTO and RPO in cyber security
Although RTO and RPO were initially introduced regarding disruptive events related to natural disasters and direct man-made attacks (e.g., vandalism and terrorism), the increasing dependence of businesses makes RTO and RPO also useful for cybersecurity. For example, RTO and RPO enable cybersecurity teams to plan responses to cyberattacks, like DoS and ransomware.
Continuity management is more about preparation and less about guessing
Business continuity and disaster recovery plans are things that organizations need to have and hope not to use, and in such cases, they need to find a balance between investing the minimum amount of resources possible, and having the maximum confidence that the plans will work.
To achieve this balance, RPO and RTO are paramount. Without determining them properly, you would just be guessing – and guessing is the best way to ensure recovery disaster, instead of recovery from a disaster.
You can also check out this ISO 22301 Documentation Toolkit that enables you to develop business continuity and disaster recovery plans based on RTO and RPO.
