BIA and RTO/RPO: the numbers IT cannot set alone

A disaster recovery plan says the payroll system comes back in four hours. Ask where the four hours came from and the answer is usually the infrastructure team: it is how long a restore took in the last test. That is a useful fact about the technology. It is not a decision about the business, and an auditor reading a continuity plan for ISO 22301 will ask who made that decision.

This article explains the three numbers at the centre of a business continuity plan, who should set them, and how to carry one number from the business impact analysis through to the exercise report.

The three numbers

Maximum tolerable period of disruption (MTPD). How long an activity can stop before the damage to the organisation becomes unacceptable: money lost, customers gone, a regulatory deadline missed, or harm to people. It is a business limit, and only the people who own the activity can set it.

Recovery time objective (RTO). When the activity, or a minimum version of it, must be running again. It sits below the MTPD, with a margin for the things that always take longer than planned: deciding to invoke the plan, reaching people, finding the right access.

Recovery point objective (RPO). How much data the activity can afford to lose, counted back from the moment of the outage. An RPO of four hours means the restored system may be missing the last four hours of transactions, and someone has to re-enter them or accept the loss.

ISO 22301:2019 asks the business impact analysis to set prioritised timeframes for resuming activities. The names MTPD, RTO and RPO come from the wider ISO 22300 family of vocabulary and guidance, and they are the names most continuity teams use.

Why IT cannot set them alone

An IT team knows how long a restore takes, how often data is replicated and what a second data centre costs. It does not know how long the finance team can miss a payment run before suppliers stop delivering, or how many hours of orders the sales desk can re-key by hand. Those facts sit with the people who run the activity.

When IT sets the numbers, two things go wrong. The targets describe current capability, so the gap the analysis should reveal never appears. And every system gets a similar target, because without a business view there is no reason to rank them: money goes to systems that could wait a week, while the activity that cannot wait a day has the same backup schedule as the rest.

The order that holds up

Run the business impact analysis first. List the activities that deliver your products and services, then score the impact of stopping each one over time: an hour, four hours, a day, three days, a week, two weeks. Score financial, operational, regulatory and reputational impact separately, and note where the impact jumps.

Set the MTPD where the impact becomes unacceptable. The point where the scores cross your organisation's tolerance is the MTPD. The activity owner signs it, not the person running the analysis.

Set the RTO below the MTPD, and the RPO from the data. Leave a margin between the two for invocation and staffing. Ask the activity owner how much lost data the team could rebuild, and from what; that answer is the RPO.

List the minimum resources and dependencies. People, systems, suppliers, sites and information needed to run the activity at its minimum level. This is where IT's view comes in: each system inherits the shortest RTO and RPO of the activities that depend on it.

Check every strategy against both numbers. For each prioritised activity, record the recovery strategy and whether it meets the RTO and RPO. Where it does not, say so. A flagged gap with an owner and a decision is evidence of a working system; a plan that quietly assumes the gap away is not.

Quote the same numbers in the plans. The continuity plan and the IT disaster recovery runbook cite the analysis's figures. If a plan contains a recovery time that does not appear in the business impact analysis, one of them is wrong.

Exercise against the RTO, and record what broke. A tabletop or a technical recovery test is timed against the RTO. The report notes where it ran over and what changes as a result, and the management review sees it.

A test for your own plan

Pick one critical activity and trace its recovery time objective. It should appear in the signed business impact analysis, in the strategy register with a yes or a flagged gap, in the continuity plan, in the disaster recovery runbook for each system it depends on, and in the last exercise report with an actual time beside it. If the number changes along the way, or disappears, that is where the work is.

Run the same test for the RPO. It is often missing from the exercise report altogether, because restore tests record how long recovery took and not how much data came back.

One set of numbers for every system

Availability risks in an information security management system for ISO/IEC 27001 and the service continuity requirements in ISO/IEC 20000-1 depend on the same figures. Agree one set of numbers and one owner for each, and let the other systems refer to them rather than set their own.

A note on using AI

An AI assistant can draft the activity list and suggest impact categories. It should never score an impact or set an MTPD, an RTO or an RPO: those are decisions about your organisation, and a named owner signs them. Record what the assistant drafted and who reviewed it.

The free resources

The free BCMS Starter Kit for ISO 22301 follows this order. Its business impact analysis workbook scores impact over time and works out the MTPD, RTO and RPO with the rule built in, the strategy register flags any strategy that cannot meet them, and the plan, the disaster recovery runbook and the exercise pack quote the same figures, with a worked example throughout. Fourteen files, no sign-up. The ISMS Starter Kit for ISO/IEC 27001:2022 uses the same risk scales, so the two systems speak the same language.