A financial-operations platform sets one RTO and RPO for the entire business. What goes wrong, and how should they be derived instead?
Show the full answer Hide the answer
What goes wrong
Applying the strictest requirement everywhere makes disaster recovery unaffordable, and unaffordable DR is untested DR. The reporting warehouse gets the same recovery investment as the card authorisation path, budgets are exhausted, and the plan becomes a document rather than a rehearsed capability.
The reverse error is equally common: applying the loosest requirement everywhere, so the critical path discovers during an incident that its recovery point is yesterday.
How to derive them
Per business capability, from the consequence of loss:
| Capability | RPO | RTO | Reasoning |
|---|---|---|---|
| Card authorisation | Zero data loss | Minutes | Money moves; a lost authorisation is a financial and dispute problem |
| Ledger and balances | Zero | Minutes | Correctness is absolute |
| Expense workflows | Minutes | Hours | Work is deferred, not lost |
| Accounting integrations | Hours | Day | Batch by nature |
| Analytics and reporting | Day | Days | No operational consequence |
The consistency check that is frequently missed
An RPO must be achievable by the backup and replication mechanism actually configured. An RPO of five minutes with hourly snapshots is a contradiction, and it is usually written by someone other than the person who configured the schedule. Every stated RPO should be traceable to a mechanism.
An RTO must be achievable given the restore throughput. Restoring a given volume at a given rate takes a calculable number of hours, and if that exceeds the RTO the design is wrong regardless of how good the backups are. This arithmetic is available before any incident and is rarely done.
What makes the plan real
- Rehearsal at realistic scale, by people who did not write the runbook, without privileged shortcuts.
- Testing the dependencies — DNS, certificates, identity, third-party allow-lists — which is what actually breaks a failover.
- Including the decision. Who declares a disaster, on what evidence, and how to roll back if the declaration was premature. The technical recovery is usually easier than the decision to invoke it, and the deliberation is what consumes the RTO.