In today’s bulletin, Charlie discusses the debate of aspirational vs achievable RTOs (Recovery Time Objectives) and looks at the types of incidents and their impact on our organisation’s RTO.
We got all of our consultants together this week and, under the guidance of Simon Freeston, had a session to align our views, outputs, and templates on BIAs. We all adhere to the ISO 22301 and GPG principles, but we all do things in a slightly different way and we all have lots of opinions on how to conduct them. We had three and a half hours chatting on the subject, but I think we could have kept going for a day or so.
RTOs – Aspirational?
One of the big debates we had was whether RTOs should be aspirational or achievable. Are they aspirational because the RTO might not work in every circumstance, such as an aircraft crashing into your organisation’s building, killing the majority of staff, it is unlikely that any of the activity RTO would be met. On the other hand, should the RTO be achievable? If we set an activity RTO at 24 hours, we should be able to recover within that time, not just hope we can. This includes verifying it in an exercise and also documenting the MBCO (Minimum Business Continuity Objective) so we know the level and the resources needed to recover the activity at an agreed RTO.
If we document unachievable RTOs, are we giving the organisation false hope and reassurance that an RTO can be achieved? This debate went back and forth for a while, and then the debate switched to whether we should document under what circumstances or in what incidents an RTO should be able to be achieved. In some incidents, the RTO may be achievable, but in others it can’t be.
Case Studies
I have written past bulletins on trying to define RTOs. In my bulletin, ‘Defining RTOs – Help Needed’, I asked for help in defining RTOs. The example I used was a power generating company on the Island of Aruba. For their power company, should their RTO for the activity ‘generation of power’ be 0 hours, which the island would like, or 24 hours, which is the government’s requirement, which is the government’s requirement, or 2 years, which is the rough time it would take to reinstall power to the island if all generators were lost to a tsunami. Similarly, in the ‘Do Application RTOs and RPOs Work During a Cyber Incident?’ bulletin, I discuss that RTOs are very unlikely to be met during cyber incidents. I suspect that in the M&S and JLR cyber attacks, they likely breached all their RTOs.
This got me thinking about whether there should be a definition alongside each RTO that specifies the types of incidents in which the RTO is likely to be achieved, and those in which it is not. I came up with a diagram, Figure 1, to look at the relationship between the type and magnitude of the incident, and in what circumstances the RTO would be achievable.
Levels of Incidents
In Figure 1, the X axis shows the level of incident from low-level incident to catastrophic, while the Y axis shows the likelihood of an incident occurring. The four boxes can be described as follows:
1. Day-to-Day Incident
These are incidents which can be managed within the operations of the organisation and do not require business continuity or crisis plans to be activated, as the impact on the organisation is low. Examples could include machine breakdown, bad weather, or an application going offline.
2. Major Disruptions
These are incidents at the lower level that require the business continuity plan to be involved. Depending on the severity of the incident, it could be at the operational, tactical, or strategic level. This type of incident could impact the organisation’s operations, ability to deliver its products and services, or reputation, but the organisation’s viability is unlikely to be threatened. Examples could include loss of a building, data breach, loss of a key supplier, or a reputational issue.
3. Crisis
According to ISO 2236, a crisis can be defined as ‘an abnormal or extraordinary event or situation that threatens an organisation or community and requires a strategic, adaptive and timely response in order to preserve its viability and integrity’ and ‘exceed normal response capability, and it typically needs a flexible, dynamic approach beyond rehearsed plans’. For me, this is where an organisation fights for survival, and there is an existential threat to its viability or for it to remain in its present configuration. Examples could include the CBI reputational scandal, although the company survived; the failure of Lehman Brothers after the financial crash; and the collapse of the Knights of Old following a cyber incident.
4. Armageddon
This is when the impact on an organisation or population is so severe that people enter survival mode. In Maslow’s hierarchy of needs, this corresponds to level 1: physiological needs – food, water, sleep, warmth, and shelter. Examples include the 2023 Turkey–Syria earthquakes, Hurricane Katrina flooding, and the Indian Ocean tsunami.
Which Level Should the RTOs be Set At?
Looking at the four levels of incidents, an RTO can only realistically be set for day-to-day incidents or major disruptions. At these levels of incidents, we can be realistic that the impact is likely not to overwhelm the RTO, and that, with validated strategies and solutions in place, they have a reasonable chance of being achieved. At the top end of the ‘major disruption’ and into a ‘crisis’, the types of incidents are going to cause impacts, the RTOs are unlikely to be met, and so the RTOs are aspirational and very dependent on the type of incident that occurs and how it impacts the organisation. If the incident is ‘armageddon’, then recovering to an RTO is the least of our worries, and we are in survival mode. In Figure 1, I have annotated the most likely areas where the RTO will be set.
Defining RTO Recovery Circumstances
A way of addressing the aspirational vs achievable debate is to perhaps include a disclaimer in the BIA about the type or level of incident we expect the RTO to be met for. Within business continuity plans, there is often an escalation matrix that defines the types of incidents that the operational, tactical, or strategic teams would mobilise for, and perhaps we could tie the RTO to these. The disclaimer may state that we have reasonable certainty that an RTO may be met under operational or tactical conditions, but it may not be met if the incident would cause the strategic plan to be activated. It might also help with investment in and implementation of further resilience measures or recovery strategies to ensure that, in more impactful incidents, the RTOs are still met.
Call to Arms
My call to arms after this bulletin is to revisit your RTOs and objectively assess them, including what types of incidents they cover and whether they would be effective.
