RTO vs RPO
RTO — recovery time objective — is how quickly a system must be restored after failure: the maximum tolerable downtime. RPO — recovery point objective — is how much data you can afford to lose: the maximum tolerable gap between the last recoverable state and the failure. A 4-hour RTO with a 15-minute RPO means “back within four hours, having lost at most fifteen minutes of data.”
Why the pair matters
They price your architecture. Tight RPO demands frequent replication or continuous backup; tight RTO demands warm standbys or automated failover. Every improvement costs real money, which is why the numbers should come from the business — what a customer contract promises, what an hour of downtime costs — rather than from what the current setup happens to deliver.
What auditors and regulators check
That the numbers exist per critical system, that they trace to business requirements, and — the part most programs miss — that a test achieved them. A stated 4-hour RTO with a restoration test that took nine hours is a finding with your own signature on it. MAS-regulated firms face the strictest version: recovery expectations for critical systems measured in hours, tested realistically, reported honestly.
The honest workflow
Set targets per system tier from business impact; verify with a real restoration or failover test; record the achieved times; and either fix the architecture or revise the target when they disagree. Numbers that match reality beat numbers that impress — the BCP entry covers where these live in the wider plan.
Business Continuity Plan (BCP) — A business continuity plan keeps the business running through disruption; disaster recovery restores the systems. Auditors expect both — and a test record.
Tabletop Exercise — A tabletop exercise is a discussion-based rehearsal of your incident response plan — the cheapest strong evidence that the plan actually works.