The Recovery Time You Promised vs the One You Have Tested

Every resilience plan has a page of recovery time objectives. Each row is a promise: this system will be back within this many hours. Boards approve those promises. Customers and insurers rely on them. Almost nobody asks when the promise was last tested.

A recovery time objective is not a fact about your systems. NIST defines it as the target time within which a function must be restored after a disruption. It is a target someone set, often years ago, against an architecture that has since changed. The number in the plan stays still while the business moves.

The gap that matters is not between your RTO and some industry benchmark. It is between the RTO you promised and the restore time you have actually evidenced. Closing that gap starts with one table.

TLDR

• An untested RTO is an assumption with a date on it.

• Track three numbers per critical system: promised, last tested, and actually observed.

• Dependencies, data growth and staff turnover push real restore times above planned ones.

• Retest any system whose tested time misses its promise, and re-promise honestly.

• Give the board the gap, the decision it forces and the retest date, twice a year.

The number in the plan is a promise

Read your contingency plan the way a customer would. Each recovery objective says: if this system fails, you will have it back within the stated window. NIST's contingency planning guide treats those objectives as the foundation the whole plan is built on, and it treats testing as the only way to know whether the plan works.

When the board approves the plan, it approves the promise. When a customer signs a contract that references your resilience, they rely on it. A promise nobody has tested recently is a liability wearing a control's clothing.

Why tested times drift from promised times

Four forces push real restore times above planned ones:

• Dependencies. The plan restores the application. The application needs identity, DNS, a database and a network path, and each has its own restore order. The tested time for the whole chain is longer than the sum on paper.
• Data growth. A restore that took six hours over last year's data volume takes longer over this year's. The plan rarely gets re-timed as volumes grow.
• People. The runbook assumes the engineer who wrote it. If that person left, the first real restore includes learning time.
• Partial tests. Many tests restore one server to an isolated network and call it done. That proves a copy exists. It does not prove the service comes back.

Build the RTO evidence table

One page, one row per critical system, three numbers: what you promised, what your last test produced, and what you last observed in a real event or full exercise. The example below is fictional and illustrative; yours should carry real dates.

Critical system	Promised RTO	Last tested restore	Last observed	Gap decision
Customer portal	4 hours	9 hours	Not measured	Retest with full dependency chain in Q1
Payment processing	2 hours	2.5 hours	3 hours	Tolerate with monitoring; retest in 6 months
ERP	24 hours	31 hours	Not measured	Re-promise at 36 hours or fund the fix
Email and collaboration	8 hours	6 hours	5 hours	Meets promise; retest annually

The last column is the point. Every gap ends in a decision: retest properly, tolerate with your eyes open, re-promise at the honest number, or spend to close it. A gap without a decision is just bad news filed neatly.

What the board should ask twice a year

Directors do not need the restore runbook. They need three answers on a fixed cadence:

1. Which critical systems have a tested restore time that misses the promised one, and by how much?
2. What decision was made about each gap, who owns it and when does it close?
3. When did the last test include the full dependency chain, not just the application?

Recovery testing that includes customers, not just servers, is the natural next step once the core numbers hold. That is covered in the recovery test that includes customers.

Frequently asked questions

How often should recovery time objectives be tested?

At least annually for critical systems, and again after material changes to the architecture, data volumes or the team that would run the restore. A test older than the current architecture is weak evidence.

What is the difference between an RTO and a tested restore time?

The RTO is the target the business committed to. The tested restore time is what actually happened when someone ran the recovery. Only the second is evidence; the first is intent.

Who should own the gap between promised and tested recovery times?

The business owner of the system owns the risk, with IT or security supplying the tested evidence. The board's role is to see the gap and confirm a decision was made, not to run the test.

What should we do when a tested restore time misses the RTO?

Decide explicitly: retest with the full dependency chain, invest to close the gap, or re-set the promise at the honest number. The worst outcome is leaving the miss unrecorded.

A Defensible Next Step

Pick your five most critical systems and put their three numbers side by side this month. If the promised and tested columns disagree, that is not a failure. It is the first honest picture of your resilience you have had. Book a Decision-Clarity Call if you want help building the evidence table and the board cadence around it.