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, Recovery Point Objective and Recovery Time Objective 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 learn about the RPO and RTO meaning. You will also 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.
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.
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.). In a case like this, the RPO is usually zero, because even in just a few minutes, hundreds of transactions can be made, and this information cannot be lost and cannot be recovered easily.
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.
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 between RPO and RTO 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).
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.
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 versus RTO.
Since RPO and RTO 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 four 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.
Although Recovery Point Objective and Recovery Time Objective 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, RPO and RTO enable cybersecurity teams to plan responses to cyberattacks, like DoS and ransomware.
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, RTO and RPO 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.
ISO 22301 Documentation Toolkit
Step-by-step implementation for smaller companies.
ISO 22301 Documentation Toolkit
Step-by-step implementation for smaller companies.
ISO 22301 Documentation Toolkit
Step-by-step implementation for smaller companies.
Leading expert on cybersecurity & information security and the author of several books, articles, webinars, and courses. As a premier expert, Dejan founded Advisera to help small and medium businesses obtain the resources they need to become compliant with EU regulations and ISO standards. He believes that making complex frameworks easy to understand and simple to use creates a competitive advantage for Advisera's clients, and that AI technology is crucial for achieving this.
As an ISO 27001, NIS 2, and DORA expert, Dejan helps companies find the best path to compliance by eliminating overhead and adapting the implementation to their size and industry specifics.
Connect with Dejan: ContributorRhand Leal has more than 15 years of experience in information security, and for six years he continuously maintained а certified Information Security Management System based on ISO 27001.
Rhand holds an MBA in Business Management from Fundação Getúlio Vargas. Among his certifications are ISO 27001 Lead Auditor, ISO 9001 Lead Auditor, Certified Information Security Manager (CISM), Certified Information Systems Security Professional (CISSP), and others. He is a member of the ISACA Brasília Chapter.
