A client showed me his business continuity plan. On page 4, a table said “RTO: 4 hours” for his ERP.
At the first test, the server came back in 9 hours. Orders started leaving the warehouse again at noon the next day, 28 hours after the exercise began. The “4 h” written on the whiteboard that morning stayed there all day. Nobody dared to erase it.
Nobody had lied. The figure came from the backup software data sheet, not from a measurement. An RTO that was never timed is a promise, not a figure. And the RTO is only one of the figures that matter when you talk about business continuity.
For context, I already introduced RTO and RPO in my article on ISO 27031:2025. Here I go further: where these figures come from, how to measure them, and what to track once they exist.
Fifteen days without services: the CCQ case
On August 24, 2026, the Commission de la construction du Québec (CCQ) shut down its systems after a cyberattack. Its services were restored on September 8, about fifteen days later. During that time, the CCQ extended to September 30 the validity of certain competency certificates that were about to expire. It also postponed the monthly report deadline, without penalty.
I do not know the CCQ’s internal recovery targets, and I will not invent them. This case does illustrate a notion that few SMBs know.
An organization that sets its own rules can push its own deadlines to buy time. Your SMB cannot extend the delivery deadline of its largest customer. The moment when you can no longer buy time has a name: the MTPD.
The acronyms, in the order you should define them
Most plans I read start with the RTO. That order is backwards. Here is the logical order.
BIA: where every other figure comes from
The BIA (Business Impact Analysis) is the exercise that produces every other figure. ISO 22301, the reference standard for business continuity, requires it at clause 8.2.2. Without a BIA, your RTOs are guesses.
MTPD: the limit management sets
The MTPD (Maximum Tolerable Period of Disruption) is the time after which the consequences become unacceptable. A lost customer, a contractual penalty, a missed legal obligation, payroll that does not go out. You will also see the acronym MAO (Maximum Acceptable Outage) for the same notion.
This figure belongs to management. Not to the MSP. Not to the technician.
RTO: the time to get running again
The RTO (Recovery Time Objective) is the target time for the activity to resume after the disruption starts. It must always be shorter than the MTPD, with a margin.
WRT: the time everyone forgets
The WRT (Work Recovery Time) covers the period between the system coming back and the return to normal work. Checking that the data is intact, re-entering lost transactions, catching up on late orders.
At my client’s, the server took 9 hours. The next 19 hours were WRT. The rule is simple: RTO + WRT must stay under the MTPD.
RPO: the work you accept to redo
The RPO (Recovery Point Objective) indicates how far back you accept to go. An RPO of 24 hours means you accept re-entering a full day of work.
Watch out for ransomware. If the attacker had been in your network for ten days, your last reliable copy can be much older than last night’s. Your real RPO becomes that of the last clean copy, not the last copy.
MBCO: the acceptable degraded mode
The MBCO (Minimum Business Continuity Objective) describes what the company must at least be able to do during the outage. Taking orders by phone, shipping what is already packed, running payroll. In the first days, the MBCO is often what saves an SMB, well before the systems come back.
In summary
| Acronym | Full name | The question | Who answers |
|---|---|---|---|
| BIA | Business Impact Analysis | Which activities are critical, and what does stopping them cost? | Management, with one person per function |
| MTPD (or MAO) | Maximum Tolerable Period of Disruption, or Maximum Acceptable Outage | After how long does the stoppage become unacceptable? | Management |
| MBCO | Minimum Business Continuity Objective | What must we at least keep doing during the outage? | Management and operations |
| WRT | Work Recovery Time | How long to resume work once the system is back? | Operations |
| RTO | Recovery Time Objective | How quickly must the system come back? | Calculated from the MTPD and the WRT, then approved by management |
| RPO | Recovery Point Objective | How much work are we willing to redo? | Operations, then management |
| RTA | Recovery Time Actual | How long did recovery take during the test? | Measured during a test |
How to measure these figures
The MTPD is measured in questions, not in technology
Bring together one person per function: sales, operations, finance, human resources. For each activity, ask the same question at four moments. After 4 hours, 1 day, 3 days and 1 week of stoppage, what happens? Note the consequences in dollars, in customers and in legal obligations.
The first moment when someone says “that is when we lose the customer” or “that is when we are in default” is your MTPD for that activity. In these meetings, the controller often gives the most precise answer. They know exactly which day payroll has to go out.
The RTO is calculated backwards
Take a distributor’s shipping activity. Its MTPD is 72 hours. The WRT measured in an exercise is 16 hours. That leaves 56 hours. With a margin, the target RTO becomes 48 hours.
Then you ask your managed service provider (MSP) whether the current infrastructure can deliver 48 hours. If the answer is no, this is no longer a technical question. It is a budget decision that comes back to management: pay for a faster recovery, or accept the risk in writing.
The RTA: the only figure that counts
The RTA (Recovery Time Actual) is a less official term, and a widely used one. It is what you measure during a test.
The stopwatch starts when the incident is declared. It stops when a user confirms they are working normally. The technician seeing the server restart does not stop the clock. That is exactly where my client’s gap hid.
Same logic for the RPO. After the restore, look at the last transaction present in the system. The gap with the time of the simulated incident is your real RPO.
What to track once the figures are in place
Figures defined once and filed in a binder age badly. Here are the indicators I recommend tracking:
- The gap between the RTA and the RTO for each critical system, at each test. A positive gap means a plan to correct, or an RTO to renegotiate with management.
- The date of the last full restore test for each critical system. At least once a year.
- The age of the last restorable copy, checked every month. That is your real RPO from one day to the next.
- The share of critical activities that have an MTPD, an RTO and an RPO approved by management.
- The recovery time guaranteed by your providers (MSP, cloud, online software), compared with yours.
This last point is often forgotten. On October 20, 2025, an Amazon Web Services outage in its us-east-1 region took down services such as Signal, Canva and Snapchat for several hours. If your online ERP depends on a single provider, the recovery time guaranteed in its contract becomes the floor of your own RTO. You cannot promise better than that provider can deliver.
Also review your BIA once a year, and at every major change. A new ERP, a cloud migration, or a new customer that represents 30% of your sales changes your MTPDs.
For an organization certified to ISO 27001, this is what the auditor will look for under control A.5.30 (ICT readiness for business continuity). Approved targets, dated tests, and gaps that were addressed.
A few traps
I see them come back from one engagement to the next:
- A single RTO for the whole company. Payroll and the intranet do not share the same urgency.
- An RTO longer than the MTPD. It happens more often than you would think, simply because nobody put the two figures side by side.
- An RTO copied from a product data sheet.
- A restore test done on one file, rather than on a complete system.
- Figures set by the MSP alone, without management approval.
Where to start, in practice
- List your 5 to 10 critical activities. Activities (ship, invoice, pay), not servers.
- Have management set the MTPD of each one.
- Define the MBCO: what you must keep doing, even by hand.
- Measure the WRT during a tabletop exercise with the people who do the work.
- Calculate the RTO and the RPO backwards, then have them approved.
- Test a full restore and record the RTA and the real RPO.
- Enter the gaps in your risk register and review them every year.
In short, the RTO is not a figure your provider hands you. It is a figure your management sets from the MTPD, and that your tests confirm or contradict.
Your plan shows an RTO for your most important system. Has that figure ever been timed, from the start of the incident until the first employee starts working again?
Want to know where you stand on this? Let’s talk.