RTO

What is RTO?

RTO (Recovery Time Objective) is the maximum time a system, service or process may be unavailable after an incident before the consequences for the organisation become unacceptable. The RTO is a target you set in advance, not a measurement taken afterwards. It determines which recovery strategy you need: a system with an RTO of five minutes calls for a redundant set-up, while a system with an RTO of three days can manage with a good backup and a reinstallation procedure. Together with the RPO, the RTO forms the core of every disaster recovery and business continuity plan.

How quickly do you need to be operational again after a fault or cyber incident?

🧠 How exactly is the RTO defined?

The US guideline NIST SP 800-34 Rev. 1 (May 2010) on contingency planning describes the RTO as the maximum amount of time a system resource can remain unavailable before there is an unacceptable impact on other system resources, the supported business processes and the maximum tolerable downtime. The continuity standard ISO 22301 follows the same idea: the RTO is the period after an incident within which a service or activity must be resumed or resources must be recovered.

What matters is when the clock starts and stops. Common practice is that the RTO starts at the moment of failure or detection, not when someone decides to begin recovery. It ends when the process is running again at an agreed minimum level, not when the server boots. Record both moments explicitly, otherwise IT, OT and the business end up talking about different numbers.

An example: if a production system that is critical to the factory has an RTO of 2 hours, the process must be running again within 2 hours of the failure. If it takes longer, you risk production downtime, financial loss, fines or breach of contract, and reputational damage.

🔄 What is the difference between RTO, RPO, MTPD and MTTR?

RTO is often confused with related terms. Each figure answers a different question:

The order follows from NIST SP 800-34: the RTO must normally be shorter than the MTD, because technical recovery is followed by further work such as reprocessing data, starting up the plant and checking product quality. If a process must be running again after 48 hours and starting up the plant itself takes 12 hours, system recovery may take no longer than 36 hours. According to NIST, the RPO is not part of the MTD; it concerns data loss, not time without service.

🔧 How does the RTO determine your recovery strategy?

The shorter the RTO, the more expensive the solution. NIST describes this as a cost trade-off: the damage from an outage grows over time, while the cost of recovery provisions rises as the RTO gets shorter. Somewhere lies a balance point, and it differs for every system. The usual link between RTO and strategy:

An RTO is only credible if the chosen strategy actually meets it in a test. If the measured recovery time does not match the target, you either improve the provisions or consciously adjust the target. For the latter, NIST refers to a Plan of Action and Milestones: record that the target is not yet achievable and when that will change.

🏭 Why is RTO different in OT environments?

Different rules apply in OT than in office IT. Three differences stand out:

• Not every system stops the process - if the SCADA display fails, the PLCs usually keep controlling. Operators do lose visibility and control, and often have to switch to local operation or shut the process down in a controlled way. The RTO of the SCADA system therefore depends on how long a plant can run safely without central supervision.
• Recovery takes longer than a restart - after an infection, PLC firmware and programs must be verified, sensors and actuators tested and the process started up step by step. A furnace or reactor sometimes needs hours or days to get back to temperature and specification.
• Safety comes before speed - a safety function such as an SIS does not get an RTO in the usual sense. It is designed so that a failure leads to a safe state (fail-safe), and the plant may only run again once the safety function demonstrably works.

Illustrative values, which vary widely per plant: an RTO of 5 minutes for a SCADA system with redundant servers, 30 minutes for an alarm platform and 1 hour for a historian database. Each of these figures must follow from the impact of an outage, not from habit.

How large the gap between target and reality can be was shown by NotPetya in 2017: at Maersk, around 49,000 laptops and 4,000 servers became unusable, and the terminals on the Maasvlakte in Rotterdam were largely idle for more than a week. At Colonial Pipeline, the pipeline was shut down for six days in May 2021, even though only IT had been hit. Both cases show that the RTO of OT processes also depends on IT systems for planning, invoicing and logistics.

🛠️ How do you set an RTO in five steps?

1. Map systems and dependencies - use the asset inventory and record per process which servers, networks, licences and suppliers are needed.
2. Carry out a business impact analysis - determine per process how the damage grows over time and where the MTPD lies, weighing safety, environment and supply obligations alongside financial damage.
3. Derive the RTO with a margin - subtract the time for start-up, quality checks and data processing from the MTPD. Agree the outcome with production and maintenance.
4. Choose and implement the recovery strategy - redundancy, spare hardware or immutable backups of PLC programs, HMI projects and configurations.
5. Test and measure - rehearse recovery periodically, for example with a tabletop exercise and a real restore test, and compare the measured recovery time with the RTO.

🔐 Which laws and standards require recovery targets?

• NIS2, Article 21(2)(c) - requires business continuity, such as backup management and disaster recovery. Without documented recovery times you cannot demonstrate that these measures are appropriate.
• Cybersecurity Act - the Dutch transposition of NIS2 (Cyberbeveiligingswet), in force since 15 August 2026. Article 9 of the Cybersecurity Decree requires recovery procedures, periodically verified backups and a continuity, recovery and crisis plan that is tested periodically.
• ISO 22301 - the standard for business continuity management has organisations set priorities and recovery times per activity through the business impact analysis.
• ISO 27001:2022 - control A.5.30 (ICT readiness for business continuity) requires that ICT provisions can meet the continuity objectives.
• IEC 62443-3-3 - system requirements SR 7.3 (control system backup) and SR 7.4 (control system recovery and reconstitution to a known secure state) make recovery within the RTO technically possible.
• NIST CSF 2.0 - the Recover function expects rehearsed recovery procedures with achievable targets.

❓ Frequently asked questions

What is a good RTO for an OT system?

A good RTO for an OT system follows from the business impact analysis and always lies within the maximum tolerable downtime of the process. For a redundant SCADA system that may be a few minutes, for a reporting server a few days. There is no standard value: the same type of server can be critical in one factory and not in another.

Is an RTO of zero possible?

An RTO of zero means no noticeable outage is allowed, which is only achievable with full redundancy and automatic failover. Even then redundancy does not protect against everything: ransomware or a faulty configuration is often synchronised straight to the second system. An RTO of zero therefore requires separate, immutable backups in addition to high availability.

Who determines the RTO?

The RTO is determined by the owner of the business process, based on the business impact analysis, and not by the IT or OT department alone. Administrators advise on what is technically feasible and what it costs. Management accepts the final choice, including the residual risk.

How often should you review an RTO?

You should review an RTO at least annually and with every change to the plant, product or supplier. The RTO must also be reassessed after an incident or a failed recovery test. An outdated RTO gives a false sense of security.

What is the difference between RTO and availability?

The RTO states how long a single outage may last, while availability states what share of the time a system works. An availability of 99.99% allows around 53 minutes of downtime per year, but says nothing about how long one failure may last. That is why you set both for critical systems.

Does the RTO belong in an incident response plan?

The RTO belongs mainly in the disaster recovery and continuity plan, but the incident response plan should refer to it. During an incident, the RTO helps you choose between recovering quickly and investigating thoroughly first. In an OT cyber incident, certainty that systems are clean often outweighs meeting the RTO.

📌 In summary

The RTO is the maximum time a system or process may be down after an incident, a target set in advance that determines the recovery strategy and the budget.

The RTO follows from the business impact analysis, always lies within the maximum tolerable downtime and is checked against the measured MTTR. In OT, recovery is not just about restarting servers, but also about verifying PLCs, starting up the plant safely and the dependency on IT. NIS2, the Dutch Cybersecurity Act, ISO 22301 and IEC 62443 all require recovery that demonstrably stays within these targets.