RTO vs RPO vs MTD: what each recovery term means

RTO, the recovery time objective, is how long a system can stay unavailable before the impact becomes unacceptable. RPO, the recovery point objective, is the point in time to which data must be recovered. MTD, maximum tolerable downtime, is the longest the business can accept, and RTO must fit inside it.

The three terms, as NIST defines them

NIST SP 800-34 Rev. 1, the contingency planning guide for federal information systems, gives these definitions in its business impact analysis chapter.

NIST notes that RTO must normally be shorter than MTD, because reprocessing time after recovery has to be added to the RTO to stay inside the limit. It also notes that, unlike RTO, RPO is not part of MTD. It reflects how much data loss the process can tolerate.

A worked example

This example is hypothetical. A team backs up a database nightly at 02:00. The database fails at 16:00. The latest backup is 14 hours old, so recovering from it means up to 14 hours of lost changes. That 14 hours is the effective recovery point. If the team decided that losing more than one hour of data is unacceptable, the nightly schedule does not meet the objective, and the fix is more frequent backups or continuous log shipping.

Now consider time. Suppose restoring that database, validating it and reconnecting the application takes some number of hours. That total is the real recovery time. If it exceeds the RTO the business set, the gap needs a decision: faster recovery, a looser objective, or a documented exception.

How to set them without guessing

1. List your services and rank them by how soon users or customers notice a failure.
2. For each top service, ask the owner the two plain questions: how long can this be down, and how much recent data can we afford to redo or lose?
3. Write the answers as RTO and RPO. Record who agreed to them.
4. Compare to what you can actually do today by running a restore and timing it. A target that has never been tested is a hope.
5. Where today's capability misses the target, record the gap and a plan. NIST suggests documenting a plan of action when an RTO cannot yet be met and the MTD is inflexible.

Common mix-ups

• Backup frequency sets RPO. Restore speed and rebuild steps set RTO.
• Replication can reduce RPO but a replica copies mistakes too, so it is not a substitute for backups.
• Different parts of one product can have different objectives. A payment service and a marketing page rarely share them.

A worked table for three services

This table is hypothetical. It shows how objectives differ by service and how to compare them with what you can do today.

Read it from left to right. The business accepts at most four hours without login, so the login system's RTO of one hour leaves room for validation and reconnecting. The order database misses its RTO. The restore took four hours against a target of three. The team now has three honest options: speed up the restore, loosen the target with the owner's agreement, or document the gap and a plan. All three beat discovering the gap during a real event.

The wiki shows the opposite. A day of data loss is acceptable and the restore is fast. Spending more on that service would be waste, so leave it alone.

Step by step: running an objectives workshop

1. Invite the owner of each business process, not just engineers. They know the cost of downtime and data loss.
2. Start with MTD. Ask: at what point does an outage become serious for customers, contracts or safety? Record the number and who said it.
3. Work down to RTO. Subtract time for reprocessing, validation and reconnecting. NIST notes that reprocessing time must be added to the RTO, so the RTO has to be shorter than the MTD.
4. Ask the RPO question separately: how much recent data could be lost or redone without serious harm? Remember that it is a point in time, not a duration of downtime.
5. Compare each target with a measured restore, as described in our post on how long a restore really takes.
6. Record gaps and owners, and set a date to re-check.

Where the terms show up outside engineering

Customers and auditors often ask for these numbers in security questionnaires. Answer with the targets you have set and the date of your last test, and describe them as internal objectives, not guarantees. Avoid promising a number you have not measured. Our post on answering backup and continuity questions gives wording.

Common traps

• One number for the whole company. Different services need different objectives, and a single number is either too costly or too loose.
• Confusing the objective with the capability. A target is what you aim for. A measured restore is what you can do.
• Forgetting dependencies. A service can recover in an hour but depend on one that takes six.
• Counting just restore time. Detection and the decision to act often take longer than the copy.

Try it yourself

Open the vulnerability management demo and look at how items carry a status and a due time. Treat it as an analogy: a target means little without a record of where each item stands against it.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
• NIST Glossary: recovery time objective
• NIST Glossary: recovery point objective

Last reviewed: 19 October 2026.