Reflections on RPOs: How continuity parameters can diverge
October and November are the ideal time for reflection – memories of summer holidays are definitely gone and for now, there is still enough time to think about the Christmas holidays. This year I used my reserve in thinking capacity on the topic of Recovery Point Objective (RPO).
For what reason?
I found that although there is a precise definition of this parameter (ISO 22300), as well as a number of detailed descriptions in methodologies and guidelines (including the BCI Good Practice Guidelines or the BCI Dictionary of BCM Terms), the perception of RPO as a continuity parameter very often diverges. The main causes in my opinion are:
- From what source is the RPO requested
- How the RPO is described and explained
- For what purpose the RPO is requested
Let’s look at these in more depth.
Source of RPO request
If the RPO represents one parameter common to the entire organization, who will have a decisive influence on its determination is important. Will it be a specific user who evaluates the importance of a specific application’s availability with a current and complete data for the work, as well as for the RTO of a dependent process, activity or asset? Or will it be the business sponsor who collects user requirements for the maintenance and development of the application, coordinates the relevant steps with its supplier/admin, and is responsible for the budget for investment and operational support of the application? Or is it the application vendor/administrator who knows the technical capabilities, architecture, and links between related IT service processes?
It can be expected that each of them will have a different view on the level of RPO and their assessments will differ. The assessment of RPO then depends on many factors such as the cost of maintaining and restoring data vs. the estimate of damages and losses caused, and technical/capacity possibilities.
Description/explanation of RPO
This depends very much on the knowledge of the business continuity coordinator, who has to be able to place the RPO rate in the overall context of business continuity planning.
For a complete description of an RPO, let's recall the definition from the ISO 22300 standard: "point to which information used by an activity must be restored to enable the activity to operate on resumption. It can also be referred to as “maximum data loss.” An RPO can be decided on in many ways:
- I personally witnessed a business continuity coordinator tell a staff member, without much explanation “Just tell me or find out how often the data in the application is backed up and we will supplement the RPO accordingly. If it is once a day, then the RPO will be 24 hours."
- Or a business continuity boordinator sending out a questionnaire by bulk email with a choice of scale from 15 minutes to 72 hours.
- Or the default setting of the RPO amount depending on the RTO amount (e.g. if the RTO is ½ day, then the RPO will be 1 hour).
However, in practice, one can very often encounter several scenarios, such as the owner of the process being able to restore the process without needing data (or securing it independently of the recovery team from external sources), the process owner being able to recover the process without the data but requesting recovery in the future to work with it later, or the process owner being unable to accept the loss of data as it would seriously jeopardise the required RTO level.
Purpose of the RPO request
I think this point is the most important: why do we actually want to know the RPO rate and what do we intend to use it for? Let's go back to the definition that says that information must be restored to enable the activity to operate on resumption. This means that the goal is not to find out how long in the event of data loss in the primary storage we will be able to get to the backup data (restore), but to ensure their availability, integrity and trustworthiness in the relevant applications so that they can be used by the relevant users (recovery).
At the same time, it can often be very difficult to quantify all the data in an application with a single time figure. Therefore, I believe that an RPO parameter should also contain a comment to which specific activity within the BIA subject the data recovery requirement applies. For example: XY application – previews of supply proposals and invoice generation – data loss max. 1 hour.
The fact is that an RPO expresses the expectation or an optimal target state, not a commitment that must be currently realistic to keep.
Final thoughts on different parameters
I fully understand the key role of ICT and the influence of data (both electronic and paper) availability on ensuring the continuity of activities. However, let´s agree that the perception of RPO as a continuity parameter very often diverges.
Why don’t we pay similar attention, within the parameters of business continuity, to the ability to replace and supplement the team, including authorisation and know-how? Or to time for activation and occupation of backup jobs, time for replacement and commissioning of spare technical components, or the time required for a replacement solution to supply of goods and supplier failure services?
What are your thoughts? I will be very glad for your opinions and comments.
More on
About the author
Ondrej Bos
BCM Coordinator
Ondrej Bos has been working in security, BCM, crisis management and risk management for over 20 years. He has experience in public administration, financial and insurance sectors. Ondrej likes sharing experience and discussions on practical topics.
