Your expert in backup and data protection!The solution tailored to your needs
DRP and BCP
What is an RTO?
The RTO (Recovery Time Objective) is the maximum length of time a service can remain unavailable. It is measured from the incident, or from the decision to fail over, until a user can once again carry out a normal business task. Not until a machine is switched on whose application has not yet been checked.
Key points
- The RTO adds up six delays: detection, decision, locating access credentials, technical time, business verification, users getting back online.
- NIST, the US standards body, distinguishes it from the maximum tolerable downtime (MTD): the RTO should normally be shorter than the MTD.
- An RTO is set per service: the phone system and the archives do not have the same one.
- Only a timed test tells you whether the written RTO is being met.
- Support hours and the absence of an on-call rota are part of the actual RTO.
Official definition
NIST defines the RTO as the maximum amount of time that an information system resource can remain unavailable before there is an unacceptable impact on the activities it supports. It distinguishes it from the maximum tolerable downtime (MTD), which is the total downtime management accepts for an activity. The RTO must ensure that the MTD is not exceeded: it is therefore normally shorter.
ANSSI, France’s national cybersecurity agency, uses the term maximum tolerable interruption duration (DMIA). It requires a backup strategy to take this into account for each business asset, and a restoration order to be defined in advance, based on dependencies (DNS, directory, etc.) and the criticality of the applications.
What the RTO is made up of
For a conventional restore:
- the time it takes to notice the failure;
- the time it takes to decide and reach the person who knows what to do;
- the time it takes to find keys, passwords and the procedure;
- the technical time for copying or starting up;
- the time for verification by someone from the business side;
- the time for workstations or remote customers to regain access to the service (DNS, VPN, IP).
A “two-hour” RTO advertised by a software vendor often counts only step 4, in laboratory conditions. The actual RTO adds up all six. At night and at weekends, step 2 alone can take more than two hours if nobody is on call.
For a BCP, steps 4 and 6 are prepared in advance. What remains is detection and the risk of a failover that nobody dares to approve.
RTO and RPO are not traded off against each other
You can have a short RPO (frequent copies) and a long RTO (slow restore of a large volume). You can have a short RTO (standby already running) and a poor RPO if the standby is two hours behind. Both figures must be written down.
RPOMaximum acceptable data loss
RTOMaximum acceptable downtime
measured backwards
measured forwards
Data before the incident
!Incident
Services restarting
| RPO | RTO | |
|---|---|---|
| Question asked | How much work can we lose? | How long can we remain at a standstill? |
| Measured | Backwards, from the incident | Forwards, from the incident |
| Set by | The frequency of copies | The preparation of the standby |
| Verified by | The date of the last successful copy | A timed test |
One RTO per service
The phone system and the archive document management system do not have the same RTO. Writing “RTO 4 hours” for the whole company means either overpaying for the document management system or misrepresenting the phone system. One line per service is enough.
How to tell whether the RTO is being met
Only with a stopwatch during a test. If the test took six hours and the written RTO is two hours, it is the written RTO that is wrong, until the architecture changes. You do not “aim for” an RTO that the last measurement has disproved. ANSSI stresses this point: a restoration procedure must be written and regularly carried out. How often to test is discussed in How often should you test your DRP?.
At WeDoBack
No single RTO figure is published on the site, and it would be misleading to invent one: it depends on the volume, the connection, the instance size and the availability of people on the customer’s side. What the architecture changes is the nature of the delay. With a simple restore, the data has to be brought back and possibly reinstalled. With the DRP, servers restart on standby instances from the chosen version: the technical delay is that of this restart, not that of buying a server. A boot test takes place every month, without touching production. With the BCP, cloud instances run permanently and are relayed by an agent on the customer’s network, with no change of IP address: the remaining RTO is mainly that of detection and decision. Replication or synchronisation of data between the BCP instance and the original server is not built in: it relies on a specific process, tailored to the need, which WeDoBack can set up on the basis of a quote. In all three cases, business verification remains part of the clock. Human support is available from 9 am to 1 pm and from 2 pm to 5:30 pm (Paris time).
Frequently asked questions
What is the difference between RTO and MTD?
The MTD (Maximum Tolerable Downtime) is the total downtime that management accepts for an activity, including all impacts. The RTO is the time needed to bring an IT resource back into service. NIST, the US standards body, specifies that the RTO should normally be shorter than the MTD, to leave room for the other recovery steps.
A software vendor advertises an RTO of a few minutes. Is that realistic?
That figure generally only counts the technical start-up time, in laboratory conditions. It includes neither detection, nor the time taken to reach the authorised person, nor verification by a user. Your actual RTO is the one you measured during your last test, from the declaration of the incident to the first successful business task.
Is the RTO a legal requirement?
No text imposes a specific duration on an SME. However, the GDPR (Article 32) requires the ability to restore the availability of and access to personal data ‘in a timely manner’ in the event of an incident. The RTO is the practical way to define what timely means.
Further reading
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 (French agency)
- Regulation (EU) 2016/679 (GDPR), Article 32 — EUR-Lex
- 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.