Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are terms used during the implementation of a business continuity management system. As of 2020, there is about 2,200 valid ISO 22301 business continuity management system (BCMS) certificates.
Organisations that provide products and services that require minimal or no disruptions are often mandated by regulatory authorities and interested parties to implement a business continuity management system. It ensures that organisations can reduce the cost of disruption and help them recover within the shortest period possible. Examples of the cost of disruptions are lost revenue and lost customer trust.
Most often, the finance and software as a service (SaaS) industry that handles customers’ data or assets are required to have a business continuity management system in place.
At the end of this article, you will learn:
- What is Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
- What is the difference between RTO and RPO
- How to define RTO and RPO
- Examples of RTO and RPO
At Stendard, we believe that quality is everyone’s business because it takes a team to consistently deliver and uphold excellent standards that build confidence with customers, partners and the community.
We are a regulatory consultancy and technology company that helps businesses implement international standards, streamline business processes across the organisation, and accelerate global growth.
With our vast range of consulting services, feel free to contact us, and we at Stendard will be glad to assist.
What is RTO and RPO?
Recovery Time Objective (RTO)
Recovery time objective is defined as the time frame set within the time frame of the determined maximum tolerable period of disruption for resuming disrupted activities at a specified minimum acceptable capacity. This will be based on the acceptable amount of downtime and level of performance.
RTO is also known as the target time frame an organisation aims to resume normal business operations in the event of a disaster. In short, it is the amount of downtime a business can tolerate before its system recover.
Recovery Point Objective (RPO)
Recovery point objective is defined as an objective point to restore data or information after a disruption based on the acceptable amount of information or data loss. RPO is also known as the data backup period. An organisation considers how much data loss is acceptable before a disaster occurs.
In short, it refers to the frequency of backup of your system and how much data loss will occur during a disruption.
What is the difference between RPO and RTO?
The main difference between Recovery Point Objective (RPO) and Recovery Time Objective (RTO) is the type of tolerance before and after an event or disaster occurs. Illustrated in the image below, RPO is the data loss tolerance before a disaster or event occurs. On the other hand, RTO is the disruption tolerance after a disaster or event that disrupts normal business operations.
How to define RTO and RPO?
To define RTO and RPO time frames, it is crucial to conduct a business impact analysis as part of your organisation’s business continuity or disaster recovery plan. Following this is the assessment of your organisation’s resources and the regulatory requirements of each country. This ensures that your organisation’s business continuity plan priorities and requirements are met.
RTO
RTO is often defined as part of your organisation’s disaster recovery strategy or plan and may be categorised based on the level of impact that your organisation determines. For example, a disruption to your organisation’s business operations due to a worldwide disaster that affects cloud services, causing system downtime to all of your customers, will naturally lead to a quicker RTO being defined.
This is due to the need to resume normal business operations as soon as possible.
RPO
Similarly, RPO is defined as part of your organisation’s risk appetite on how much data loss is acceptable before a disaster or event occurs. RPO is usually the scheduled backup or backup frequency of the critical data in your organisation’s database. Since having too frequent backups may cost a lot. A reasonable or practical backup period should be determined because they may take up too much of your organisation’s resources.
RPO is also usually mentioned in the Service Level Agreement between your organisation and the clients to indicate the service uptime, downtime tolerance and backup frequency of critical data to account for when a disaster occurs.
Examples of RTO and RPO
Example 1:
Your organisation provides Software as a Service to manage and store patients’ data where data protection and availability are crucial in everyday business operations. In this case, RTO can be determined based on the severity of the incidents. The following tiering system may be used to illustrate different categories of RTO.
- Tier 1 – One hour (Disaster)
- Tier 2 – Two hours (High Severity Incidents)
- Tier 3 -Four hours (Medium Severity Incidents)
- Tier 4 – One Day (Low Severity Incidents)
RPO, in this example, is critical if data is being stored frequently. Therefore, depending on how often data is being stored, the RPO should be determined and its risk assessed in the event where the patient’s data is stored, but a disaster occurs before the data is backed up (worst case scenario).
If your organisation can accept an hour’s worth of data loss, an RPO of one hour is possible to determine. This means that no more than one hour’s worth of patient data will be lost.
Example 2:
Your organisation provides Software as a Service for customers to make payments or financial transactions. Uptime and availability of the service are critical. Similar to the previous example, RTO can be determined based on the severity of the incident. For instance, if the incident is minor that does not cause disruptions to the service, the RTO may be set to have a longer time frame.
To determine the RPO, your organisation needs to determine again the amount of lost data that can be accepted in the event of a disaster. Since financial transactions or payment information are critical, the RPO may even be set to as low as 15 minutes, where a backup of the data is done every 15 minutes.
Conclusion
RTO and RPO are frequently used during disaster recovery planning as part of the business continuity plan or management system.
Data protection and availability of systems have been the town’s talk when it comes to these services. As long as your organisation handles customers’ critical data, it is crucial to have a disaster recovery plan or process.
Stendard can help your organisation by providing business continuity management system consulting services with experienced ISO 22301 consultants. This includes the guidance on determining RTO and RPO for your products and services as part of the disaster recovery and business continuity plan.
If you have any questions regarding business continuity, please feel free to drop us an inquiry.
