What is a recovery time objective (RTO)?

A recovery time objective (RTO) is the target length of time a system or process can be down before the outage does unacceptable harm to the organization. NIST defines it as the overall length of time a system’s components can be in the recovery phase before they negatively affect the mission or business processes.

What it means in practice

RTO is a deadline for getting something working again. If the order system has an RTO of eight hours, the plan has to make it usable within eight hours of the outage, not just restored somewhere on a server. So the definition of “recovered” matters. Does it mean the server is up, or that staff can log in, take an order and ship it?

The clock matters too. Decide when it starts (the outage, the discovery, the declaration of an incident) and write that down. Otherwise two people will read the same RTO and plan for different things.

RTO is set for each system or process, based on business impact. It also has to fit inside the maximum tolerable downtime, which is the longest the business is willing to accept that function being out. The RTO has to be shorter than that limit, so there is time left to test and catch up before it is reached.

Shorter RTOs cost more. Getting back in minutes means standby systems kept running and ready, such as a hot site. Getting back in days can rely on backups and a rebuild. AWS’s disaster recovery guidance describes the same trade: faster recovery comes with higher cost and complexity.

Here is a common gap. A restore job takes six hours of copying. But the forensic team won’t clear the network for two days, and nothing can be restored until identity systems are rebuilt. The RTO on paper says eight hours. The real answer is closer to three days.

Where it shows up in an incident

Business owners set RTOs. IT carries out the recovery. The incident commander or crisis team tracks elapsed time against each RTO and, when many systems are down at once, decides the restore order. That decision is a business call, not only a technical one.

Common mistakes:

• Labelling every system critical, so nothing is prioritized.
• Ignoring dependencies. An application can’t meet its RTO if the identity service, DNS or network it needs comes back later.
• Treating a vendor’s service-level promise as your own RTO.
• Never proving it. An RTO that has not been tested with a real restore is a guess.

Insurance adds a second clock. Cyber business interruption cover commonly applies a waiting period, often counted in hours, before lost income starts to count. It’s worth knowing how your RTOs compare with that number.

In a tabletop exercise

Sample inject: “It is day two of a ransomware outage. Payroll runs Friday. The payroll server is third in the restore queue, behind email and the file share. Its documented RTO is 24 hours, and 40 hours have passed. Who decides to change the restore order, and who tells employees?”

Discussion question: “Which of our systems have a written RTO, who agreed it, and when did we last restore one within that time?”

Sources

• NIST Computer Security Resource Center glossary, “recovery time objective” (source: NIST SP 800-34 Rev. 1)
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
• AWS, Disaster Recovery of Workloads on AWS, disaster recovery options in the cloud
• Corvus Insurance, Cyber Coverage Explained: Contingent Business Interruption (waiting periods)
• Insurance Business, third-party cyber attacks and contingent business interruption (June 2025)