What is a recovery point objective (RPO)?

A recovery point objective (RPO) is the point in time to which data must be recovered after an outage. In plain terms, it is how much recent work, measured in minutes or hours, an organization can afford to lose.

What it means in practice

RPO looks backwards from the moment of failure. Say a system goes down at 3 p.m. and the last good copy of its data was made at 2 a.m. Everything entered in between is gone unless it can be rebuilt some other way. An RPO of 24 hours says that loss is acceptable for that system. An RPO of 15 minutes says it isn’t, and the data has to be copied far more often.

That is why RPO drives how data is protected. A nightly backup can meet an RPO of about a day. It can’t meet an RPO of an hour. Short RPOs usually mean continuous replication or frequent point-in-time copies, and those cost more. AWS’s disaster recovery guidance makes the link directly: how often you back up decides the recovery point you can actually achieve.

RPO is set for each system or business process, not once for the whole company. A document archive might tolerate a day of loss. An order or payments system might tolerate almost none. The business owner decides how much loss is tolerable, usually through a business impact analysis. IT then works out what it takes to deliver that.

RPO is not the recovery time objective. RTO is how long recovery takes. RPO is how much data you lose. A system can come back quickly and still be missing a day of records.

Where it shows up in an incident

The business owner of each system sets the tolerance, and IT or the disaster recovery lead owns meeting it. During an incident, the incident commander needs one answer fast: what is the newest copy we can trust, and what do we lose by restoring it?

Ransomware makes that harder. Replication copies damage as faithfully as it copies good data, so AWS notes that point-in-time backups are still needed alongside continuous replication. If attackers were inside for days, the newest backups may be encrypted or tampered with, and the last clean copy may be older than the RPO on paper. A ransomware recovery plan should say who decides which restore point to use.

Common mistakes:

• An RPO in a policy that nobody has compared with how often backups actually run.
• Backups that have never been test-restored. Sample underwriting questions from one US state’s cybersecurity hub ask whether backups are tested for restorability.
• No plan for the gap. Data created after the restore point has to be re-entered or rebuilt from emails, paper and vendor records, and someone has to own that work.

In a tabletop exercise

Sample inject: “The IT lead reports that the newest unencrypted backup of the order database is two days old. Sales says two days of orders now exist only in customers’ inboxes. Who decides to restore from that copy? How do you rebuild the missing orders? What RPO did leadership agree to for this system?”

Discussion question: “Pick your three most important systems. For each one, what is the written RPO, and how often is the data really copied? Do the two match?”

Sources

• NIST Computer Security Resource Center glossary, “recovery point objective” (source: NIST SP 800-34 Rev. 1)
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
• AWS, Disaster Recovery of Workloads on AWS, disaster recovery options in the cloud
• Indiana Cybersecurity Hub, underwriting security controls questions