How to calculate RTO and RPO in a business impact analysis (BIA): step by step, with a worked example and a template

The short answer: RTO and RPO are not chosen, they are derived from the business impact analysis. First you measure, process by process, how much damage a disruption does after 1 hour, 4, 8, 24 and 72. The maximum tolerable period of disruption (MTPD) is the first point at which that damage becomes unacceptable. The RTO is the time within which you commit to be running again, at least at a minimum level, and it sits before the MTPD, with a margin. The RPO is how much data, measured in time, you can lose and still keep the process viable, and it is set by what the business cannot rebuild, not by how often you take backups.

The rest of this article is the full method in six steps, applied to a case with numbers, the mistakes I see most often and a template to build your own.

RTO, RPO and MTPD in one table

RTO, RPO and MTPD are defined in the ISO 22300 vocabulary standard. ISO 22301, the business continuity standard, does not impose numbers: it requires you to determine, for each activity, the time frame within which the impact of not resuming it becomes unacceptable, and to set, within that time frame, prioritised times for resuming it at a minimum acceptable capacity. That is exactly the MTPD and the RTO.

The rule you cannot break: RTO < MTPD. If your RTO is equal to or longer than your maximum tolerable disruption, you do not have a continuity plan; you have the hope of recovering just in time.

Step 1. List processes, not systems

The BIA is done on what the organisation does (selling, fulfilling orders, paying salaries), not on servers. Systems come later, in step 6, and inherit the objectives of the processes they support.

For each process, record:

• a business owner, who will decide its objectives;
• which systems, people, sites and suppliers it depends on;
• its calendar peaks: month-end close, payroll day, the Christmas season. A process may survive a week down in August and not a single day on the 28th.

Step 2. Set an impact scale and time horizons

Without a scale, every owner will say their process is critical. The scale makes processes comparable. Five levels and five dimensions are enough:

Add a fifth dimension, people (health and safety), if your activity has one. The amounts are for a mid-sized company; adjust them to yours, but have management approve them before you start, not after seeing the results.

The horizons, the same for every process: 1 h, 4 h, 8 h, 24 h, 72 h and 1 week.

Step 3. Measure each process's impact at each horizon

With the process owner in the room, fill in one row per dimension: if this process stops now, at the worst reasonable moment of the year, how much damage is there after one hour? After 4? After 8?

Two rules for filling it in:

• Impact never goes down over time. If it is major at 8 hours, it cannot be moderate at 24.
• Every level with its reason. "At 8 hours, EUR 40,000 in orders lost to competitors" can be defended in front of an auditor. "A 3, because" cannot.

Step 4. The MTPD is the first unacceptable horizon

Look at each dimension's row and find the first horizon at which any of them reaches level 4. That is the process's maximum tolerable period of disruption. Dimensions are not averaged: it is enough for one to become unacceptable.

Step 5. The RTO goes before "major", and the RPO comes from what cannot be rebuilt

The RTO. My rule: the RTO is the last horizon before any dimension reaches major (level 3). That leaves a margin between the moment you commit to be back and the moment the damage is beyond repair, and reality eats that margin: detection takes time, deciding to invoke the plan takes time, and the first restore almost never works first time.

Remember that the RTO counts from the disruption, not from when someone decides to invoke the plan. If it takes you an hour to notice and another to decide, those two hours are part of your RTO.

The RPO. It is not calculated from the impact table but from a question to the process owner: if we lose the last hour of data, can we rebuild it? And the last 4 hours? From where, at what cost and how quickly? The RPO is the point at which the answer becomes "no" or "yes, but at an unacceptable cost".

Some data rebuilds itself: a web order usually leaves a trail in the payment gateway and in the confirmation email. Other data leaves none: an order taken by phone and keyed into the ERP exists only in the ERP.

Step 6. Move from processes to systems, and compare with reality

A system that supports several processes inherits the most demanding RTO and RPO of all of them. Then compare each objective with what you actually have:

• against the RPO: how often data is backed up, and whether the backup is out of reach of ransomware;
• against the RTO: how long it takes to restore that backup, measured in a test, not estimated; and, if the system belongs to a supplier, what recovery time is signed in the contract.

Every difference is a gap. Every gap is closed (more investment), accepted (signed off by management) or revisited (if the objective was wrong). What must not happen is that nobody saw it.

A full example: ACME's order management process

ACME is a distributor that sells online and by phone. Its order management process depends on the ERP, which runs on its own servers, and on the web shop, a cloud service from a supplier. It takes about EUR 5,000 in orders per business hour, and its warehouse picks everything that comes in before 18:00 so it ships the next day.

The head of operations fills in the impact table:

And the reason for each jump:

• At 4 hours, about EUR 10,000 in orders have gone to competitors (level 2), and the warehouse starts running out of work for the afternoon.
• At 8 hours, it is about EUR 40,000 (level 3), the 30 warehouse staff are idle (level 3) and nothing will ship the next day.
• At 24 hours, ACME misses the delivery deadlines of its three largest customers, a third of its revenue, and cannot serve anyone else (operational, level 4).

The MTPD is 24 hours: it is the first horizon at which a dimension, the operational one, reaches level 4.

The RTO is 4 hours: the first level 3 appears at 8 hours, and the last horizon before that is 4. That leaves 20 hours of margin between RTO and MTPD.

The RPO is 1 hour. Web orders can be rebuilt from the payment gateway, but phone orders only live in the ERP: nobody remembers what a customer ordered three hours ago. The head of operations accepts losing, at most, the last hour and calling those customers back.

Now step 6. The ERP also supports invoicing (RPO 24 hours) and payroll (RPO 24 hours), so it inherits the most demanding: RTO 4 hours and RPO 1 hour. And this is where the gaps appear:

None of the three gaps was visible looking only at the ERP or only at the shop. They come from crossing what the business needs with what the technology and the contracts deliver. And the third one is the most often forgotten: your RTO cannot be better than that of the supplier you depend on, unless you have a plan B that does not depend on them.

My rules for what the standards leave open

No standard tells you how to turn impact into an RTO. These are the rules I apply:

• The business signs the RPO, never IT. If IT decides it, the RPO ends up being the frequency of the backup that already exists, and the gap disappears by definition.
• Neither MTPD nor RTO is rounded to a nice number. If the BIA says 4 hours, the objective is 4 hours, not "same day".
• A gap that will not be closed is accepted in writing. With the risk, the cost of closing it and the signature of whoever accepts it. A supervisor or an auditor understands that not everything can be paid for; they do not understand that nobody knew.
• The BIA is redone when the business changes, not just once a year: a new supplier, a new system or a customer that grows to a third of revenue changes the numbers.

What the standards require

The most common mistakes

1. Doing the BIA by system. The result is a list of servers with an RTO each, and nobody knows why.
2. Confusing the RPO with backup frequency. The backup is reality; the RPO is the objective. If they are equal by definition, you will never see the gap.
3. Measuring the RTO without ever restoring. An hourly backup that takes 10 hours to restore does not meet a 4-hour RTO.
4. Forgetting suppliers. Your cloud provider's recovery time is your floor, unless you have a fallback plan.
5. Filling in the impact on a quiet day. The BIA is done for the worst reasonable moment: month-end, the busy season, payroll day.
6. An RTO longer than the MTPD. It happens more than you would think when each figure is set by a different person.
7. An unapproved BIA. Without management's signature, the objectives are an opinion, and the resources to meet them never arrive.

A template to build your own

One row per process and dimension, with these columns:

You can download it as CSV, with ACME's example already filled in, and open it in Excel or LibreOffice.

How to keep it solved

A BIA in a spreadsheet goes stale the day something changes, and the gap between the RPO and the ERP backup only shows up if someone cross-checks two documents by hand.

In Almenara, the Business Continuity module runs the BIA with a wizard that explains each concept, proposes MTPD, RTO and RPO from the impact you fill in, and lets you correct them with your reason. The objectives flow to the systems and suppliers in your inventory, and the gaps show up on their own. If you would rather do it with us, the business impact analysis workshop leaves you with the BIA done and approved. And the DORA guide covers the rest of the continuity obligations.

Frequently asked questions

What is the difference between RTO and RPO?

RTO is downtime: how soon you must be running again. RPO is data loss: how many hours of information you can lose. A process can have a 24-hour RTO and an RPO of zero, if it can wait a day but cannot lose a single record.

What is the difference between RTO and MTPD?

The MTPD is the limit beyond which the damage is unacceptable; the RTO is your recovery commitment, and it always comes first. The gap between them is the margin for what goes wrong during recovery.

Who should set the RTO and RPO?

The business owner of the process, with the impact in front of them, and management approves them. IT contributes what it costs to meet them and what is met today, but does not decide the objective.

Is an RPO of zero possible?

Yes, with synchronous replication to a second site, but it costs much more than periodic backups. Keep a zero RPO for data that truly cannot be rebuilt, such as settled financial transactions.

Does the RTO start from the incident or from when the plan is invoked?

From the disruption. The time it takes to detect it and decide to invoke the plan is part of the RTO, which is why you leave a margin before the MTPD.

How often should the BIA be reviewed?

At least once a year and whenever something important changes: a process, a system, a supplier or the weight of a customer. DORA requires continuity plans to be tested at least once a year, and a test with an outdated BIA tests the wrong plan.