A BIA that produces a usable RTO, not a number everyone ignores

Business impact analysis is the foundation of the whole continuity management system. If it is wrong, everything standing on it is wrong: recovery plans, investment in redundancy, supplier contracts and priorities during an actual crisis.

And it is wrong more often than people think, almost always in the same way.

The symptom: every process is critical

When department heads are asked how long their process may be down, the answer is predictable. Nobody says "my process can wait three days". The result is a table in which twenty of twenty-two processes carry a four-hour RTO, and an organisation trying to deliver that has to double its infrastructure.

How to set the BIA up so it discriminates

Three changes in approach produce a usable result:

1. Measure impact over time, not at a single point

For each process, estimate the consequence at several time slices - say after 4 hours, 24 hours, 3 days and 7 days. The resulting curve shows where the real pain threshold sits. Most processes have a flat curve up to a point and then a sharp step; the RTO belongs before that step, not at an arbitrary four hours.

2. Use several impact categories

Financial loss, contractual obligations, regulatory consequences, safety of people and reputation. A process can be financially insignificant and regulatorily critical - incident notification is exactly that case.

3. Make total recovery capacity a constrained resource

If it is known in advance that you can fund recovery of five processes within the first four hours, department heads stop ranking their own process in isolation and start allocating a limited capacity together. The conversation changes immediately.

RPO is decided elsewhere

A common conflation: RTO and RPO get set by the same person in the same row of the table. RTO is a business decision about how long a process may be down. RPO is a decision about how much data you may lose, and it depends on how often the data changes and whether the loss can be reconstructed manually.

A process that handles one daily batch can have a two-hour RTO and a 24-hour RPO with no inconsistency at all. A process taking real-time transactions cannot.

What a BIA must produce to be usable

• A process list with owners - people, not departments.
• Dependencies. Applications, people, premises, suppliers and other processes. A process with a four-hour RTO that depends on a supplier contracted at a 48-hour SLA does not have a four-hour RTO.
• An impact curve by category and time slice.
• RTO and RPO with justification. A number without reasoning can be neither defended nor challenged.
• A minimum service level. You rarely recover to a hundred per cent - define what is enough to keep working.
• The gap between current and required capability. That is the input to the budget, and the most valuable output of the whole exercise.

The link to the Croatian Cybersecurity Regulation

Measure 12 of Annex II requires business continuity and cyber crisis management across eight sub-measures. A BIA run to ISO 22301 covers almost all of its analytical part, but two things need adding:

1. Cyber scenarios. A classical BIA assumes a systems outage. Ransomware is not an outage - the systems run, but the data is unavailable and the backups may be affected. RPO behaves differently in that scenario.
2. The link to incident management. The continuity plan and the incident response plan must share an activation criterion, or one will be triggered without the other in a crisis.