Recovery time objectives documented

Without documented RTO (Recovery Time Objective) and RPO (Recovery Point Objective), teams have no shared definition of what a successful recovery looks like, no way to tell when an incident is resolved, and no accountability for response speed. NIST SP 800-53 CP-2 (contingency planning) requires organizations to define recovery targets. ISO 25010 reliability.recoverability requires measurable recovery capability — which cannot exist without first measuring what recovery means. In vibe-coded projects, the absence of RTOs is common because AI coding tools do not prompt for operational documentation; it must be written explicitly.

Document RTO and RPO for at least your three most critical system components. Store the document in docs/disaster-recovery.md and reference it from your incident runbook.

<!-- docs/disaster-recovery.md -->
## Recovery Objectives

| Component          | RTO       | RPO        | Strategy                          |
|--------------------|-----------|------------|-----------------------------------|
| API server         | 5 min     | 0          | Auto-restart via Railway/Fly.io   |
| Database           | 15 min    | 1 hour     | Restore from daily snapshot       |
| Payment processing | 30 min    | 0          | Queue + replay via webhook retry  |

## Review cadence
Update after any incident that breached the RTO or RPO above.
Last reviewed: 2026-04-18

Tie RTO targets to your alert thresholds (see alert-thresholds) — if detection takes 15 minutes and RTO is 5 minutes, the targets are mathematically impossible.