RTO vs. RPO in a Tabletop Exercise

RTO and RPO are often placed on a slide at the beginning of a disaster recovery exercise and then forgotten. A stronger tabletop uses them as constraints that shape the team’s decisions throughout the scenario.

RTO: how long can the service be unavailable?

Recovery Time Objective (RTO) is the maximum acceptable delay between a service interruption and restoration. In a tabletop, RTO creates a clock. If the target is four hours, the team should see how much simulated time remains as decisions, failed attempts and recovery work consume that window.

RPO: how much data loss can the business accept?

Recovery Point Objective (RPO) represents the maximum acceptable time since the last recoverable data point. It is about acceptable data loss, not how long restoration takes. AWS describes RTO and RPO as business-defined objectives used by technical teams to select and implement the recovery strategy.

Why they should not be treated as the same thing

A service can recover quickly and still violate its RPO if the available recovery point is too old. It can also meet the RPO but miss the RTO because restoring and validating that recovery point takes too long. A useful exercise keeps both questions visible.

Use RTO as a decision constraint

Ask participants to estimate how long each recovery action takes. Advance simulated time as decisions are executed. Independent tasks can run in parallel, while dependent tasks must wait. If an attempted recovery path fails, the lost time remains lost. This exposes plans that look plausible on paper but depend on unrealistic timing assumptions.

Use RPO to challenge recovery-point assumptions

Present the age of the available backup, replica or recovery point and ask whether it satisfies the business target. If it does not, the team must explicitly discuss the trade-off: accept additional data loss, search for another recovery source, reconstruct data, delay recovery, or escalate the decision to the appropriate business owner.

Example

Assume a customer-ordering service has an RTO of 120 minutes and an RPO of 15 minutes. The team discovers that the latest known-good recovery point is 40 minutes old. Restoring it is estimated to take 55 minutes, application validation another 25, and DNS or traffic cutover 10.

The timing may fit inside the RTO, but the recovery point violates the RPO. The important tabletop discussion is therefore not simply “Can we restore?” It is “Who can accept the additional data loss, what alternatives exist, and what must happen before we declare the business service recovered?”

Questions facilitators should ask

• Who owns the RTO and RPO from a business perspective?
• Are the targets documented for this specific service?
• Do recovery dependencies have compatible objectives?
• What happens when the only available recovery point violates RPO?
• Which activities are truly parallel, and which are dependent?
• What evidence is required before the service is declared recovered?
• Which assumptions need a technical test after the tabletop?

What to record in the after-action report

Capture the target RTO/RPO, simulated recovery time, recovery-point age, assumptions, decisions made when targets were threatened or breached, and corrective actions. Avoid turning estimated tabletop timing into a claim that the organization has technically demonstrated those objectives.

References

Further reading: AWS Well-Architected Framework REL13-BP01, Define recovery objectives for downtime and data loss, and REL13-BP03, test disaster recovery implementation to validate the implementation.