DRP and BCP
How do you determine your RTO?
You determine an RTO with two numbers. The first is economic: after how many hours of downtime the cost exceeds what you are prepared to pay to avoid it. The second is technical: how long the last real restore took. The written RTO must be at least as long as the second and short enough for the first to remain bearable; if they contradict each other, you change the architecture, not the stopwatch.
Updated October 20263 min read4 sources cited
Key points
- Economic number: people unable to work × hourly cost, lost sales, penalties. Calculated service by service.
- Technical number: timed from “we are declaring an incident” to the first successful business task.
- Without a test, you do not have a technical RTO, you have a hope.
- If the two do not meet: reduce the volume, prepare images, move to a DRP or BCP, or accept a written degraded mode.
- An RTO is written within the support hours you actually have access to.
The economic number
NIST, the US standards body, calls this step determining the maximum tolerable downtime (MTD): what the activity can withstand overall, all impacts combined. The IT RTO must stay below it. For a given service, estimate:
- the people unable to work × fully loaded hourly cost;
- the sales or services that cannot be recovered (a customer who has left, a cancelled care appointment);
- contractual penalties, if any;
- the point at which the company’s reputation is affected, even if it is subjective: write it down anyway.
Example. Eight people unable to work, €35 per fully loaded hour, no penalty. Each hour costs €280, plus the revenue not generated. If management accepts €1,000 of disruption, the economic RTO is about three to four hours. If it accepts a day because the order book simply shifts, the RTO can be 8 to 24 hours.
Do this calculation for each service. The phone system may have an RTO of one hour and document archiving an RTO of one week.
The technical number
Take the last test, or run one now on a test copy. Start the stopwatch at “we are declaring an incident”, not at “the software has finished copying”. Stop it when a user has successfully completed a normal task.
If you have never tested, you do not have a technical RTO. You have a hope. In that case, the immediate task is the test, not the choice between a DRP and a BCP. ANSSI, France’s national cybersecurity agency, points out that a restoration procedure must be written and regularly carried out, and the restoration order defined in advance according to dependencies (DNS, directory) and the criticality of the applications. A business server that waits for the directory inherits the directory’s RTO.
Calculation sheet
| Service | Cost of one hour of downtime | Economic RTO | Duration of the last test | Gap | Decision |
|---|---|---|---|---|---|
| Quoting software | €280 + sales | 4 h | 9 h | 5 h | DRP or degraded mode |
| Low if the phone works | 24 h | 6 h | None | Backup is sufficient | |
| Archives | Negligible | 1 week | 2 days | None | Backup is sufficient |
The figures above are examples. Replace them with your own measurements.
When the two numbers do not meet
The restore took nine hours; the business only accepts two hours.
- Reduce the volume to be restored (separate archives from live data).
- Have images ready to boot rather than a reinstallation.
- Move this service to a DRP (prepared standby) or a BCP (standby already running). See DRP or BCP: which should you choose?.
- Or accept, in writing, that the actual RTO is nine hours and organise a paper-based degraded mode for those nine hours. This is a legitimate choice if it is made knowingly.
In its cyber crisis management guide, ANSSI stresses this last point: the organisation must be able to maintain its most critical activities, possibly in degraded mode, or even without digital services. After an attack, recovery can stretch over several weeks: the RTO for a hardware failure does not apply to ransomware.
Do not forget support hours
A four-hour RTO that assumes a technician is available does not hold on a Sunday if support is open on weekdays from 9 am to 5:30 pm. Write the RTO in the business hours of the support you actually have, or pay for on-call cover. Otherwise, the RTO for Friday at 6 pm is in reality “Monday morning plus four hours”.
At WeDoBack
Human support is available from 9 am to 1 pm and from 2 pm to 5:30 pm (Paris time), on +33 9 72 50 78 28 and at [email protected]. Backup monitoring, for its part, runs 24/7: this shortens the time to discover a failed copy, not the time to restore on a Sunday. The DRP shortens the technical delay by restarting servers on standby instances, without waiting for a replacement server; a boot test takes place every month, and a test under real conditions, of up to 10 hours, is available on the basis of a quote to measure your RTO. The BCP shortens it further by having the instance already running. Neither removes the decision time or the business verification time, which remain part of your RTO.
Frequently asked questions
How do you put a figure on the cost of an hour of downtime?
Add up the fully loaded hourly cost of the people who cannot work, the revenue that cannot be recovered and any contractual penalties. For example, eight people at €35 per fully loaded hour cost €280 per hour, before lost sales. This figure is used for comparison with the annual cost of a DRP or a BCP.
Are the RTO and the maximum tolerable downtime the same thing?
Not quite. The maximum tolerable downtime (MTD for NIST, the US standards body; DMIA for ANSSI, France’s national cybersecurity agency) is what the activity can withstand overall. The RTO is the time needed to bring IT back into service. NIST recommends that the RTO be shorter than the MTD, to keep a margin.
What should you do if the calculated RTO cannot be met?
Either you change the architecture (images ready to boot, DRP, BCP), or you write down the actual RTO and organise a degraded mode for its entire duration. Both are legitimate. What is not legitimate is keeping a figure that the last test has disproved.
Sources
Documents consulted in October 2026.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Backing up information systems – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025) — ANSSI
- Cyber crisis: keys to operational and strategic management (December 2021) — ANSSI
- DRP offer: recovering operations after a disaster — WeDoBack
Planning a backup, DRP or BCP project?
More than 20 years of experience protecting business data.
Request a quote+33 9 72 50 78 28Protect your data with WeDoBack
Encrypted offsite backup, immutable storage, DRP and BCP: tell us about your servers and we will recommend the right combination.
