RTO and RPO

What RTO and RPO means in practice

RTO and RPO are business decisions expressed in technical terms. RTO answers how long the organisation can operate without a system before the harm becomes unacceptable. RPO answers how much recent work it can afford to lose. Both should be set by the people who own the process, then engineered to — not inferred from whatever the current backup schedule happens to deliver.

The relationship to cost is steep and non-linear. An RPO of 24 hours is a nightly backup. An RPO of 15 minutes requires log shipping or continuous replication. An RTO of a week is a rebuild from backup. An RTO of an hour requires standby infrastructure that is already running. Moving from daily to near-continuous protection can multiply infrastructure cost several times over, which is precisely why the objective should be argued about before the architecture is chosen.

Objectives should be set per service, not for the organisation as a whole. Payroll, the finance system, email, the customer-facing platform and the file archive rarely share the same tolerance. A single blanket objective either overspends on everything or underprotects what matters.

The most common failure is untested recovery. Backups that complete successfully are not evidence of recoverability; only a restore is. Testing should include the dependencies — identity, DNS, network connectivity, licensing, the credentials needed to perform the restore — because these are what actually extend a real recovery beyond its planned window. Documented, timed restore tests are also the evidence auditors, insurers and APRA-regulated clients ask for.

For Microsoft 365 specifically, the platform's native retention is not a backup in the RTO/RPO sense. Microsoft protects the service; recovering an organisation's own data after deletion, ransomware or a malicious insider generally requires either configured retention policies or a third-party backup product, chosen against defined objectives.