What is RPO? Recovery point objective within ISO 22301
The RPO (recovery point objective) is the maximum amount of data a process may lose when it fails, expressed in time. An RPO of one hour means you may lose at most the last hour of data. You set the RPO in the business impact analysis, and then choose the backup or replication frequency that fits it. It is one of the three key figures alongside the RTO and the MTPD, and it belongs to the requirements of ISO 22301.
RPO is about data loss, RTO is about recovery time. A system can be back within one hour (RTO) but still have lost a full day of data (RPO).
RPO in plain language
The explanation below is our own wording. The official definition is in ISO 22300, which is not freely available. In practice, you express the RPO in time, as above.
Suppose you make a backup at 10:00 and the system fails at 10:45. The backup then contains everything up to 10:00. The 45 minutes after that are gone, unless you can recover them another way. Those 45 minutes are your actual data loss.
The RPO describes what you find acceptable. If management says that a maximum of one hour of orders may be lost, your backup or replication must run at least every hour. If management does not accept that, you must increase the frequency or choose a different technique.
Why the RPO is a management decision
The RPO determines what it costs to protect data. Backing up more often costs more storage, more network capacity and more time. An RPO of five minutes is technically possible, but it costs much more than an RPO of one day.
That is why the RPO is not the decision of one technician, but of management. Management weighs data loss against costs. You record that decision in the BIA.
How to set the RPO per system
Work per system, not per company. An accounting system and an internal wiki rarely have the same RPO.
- Ask for each process: how much work do we lose if the latest data disappears? Think of orders, payments and case files.
- Translate that into time: how many hours of work are there in an average hour? That gives you a first estimate.
- Present the estimate to the process owner and management, and let them choose a figure.
- Check whether your current backup or replication meets that figure.
Worked example: four systems, four RPOs
A care organisation with a small practice has four systems. The BIA produces this table:
| System | What is lost | RPO | Current backup | Meets it? |
|---|---|---|---|---|
| Patient scheduling | Appointments from the past hour | 1 hour | Every hour, automated | Yes |
| Billing | Billing entries from the day | 1 day | Every night | Yes |
| Mail archive | Emails from the past day | 1 day | Every night | Yes |
| Internal wiki | Changes from the past week | 1 week | Every week | Yes |
In this example, every backup meets its RPO. Pay attention to the last column. You must check it again every year, because systems change and backups can quietly stop.
The figure “1 hour” for patient scheduling is fictional. You set your own figures with your own BIA.
Link with backups and replication
The RPO determines the technique, not the other way round. A few common choices:
| RPO you need | Suitable technique | Watch out for |
|---|---|---|
| Days to a week | Nightly or weekly backup | You must also test restoring the backup |
| Hours | Backup several times a day | The backup must also be stored outside the system |
| Minutes | Replication to a second location | Errors are replicated too, so you still need a backup |
A backup that you never restore does not count as evidence. This applies to every RPO. Read exercising and testing to see how you test this.
Common mistakes
| Mistake | Why it goes wrong | Better approach |
|---|---|---|
| RPO set to “as low as possible” | No measurable target, so it cannot be tested | Choose a figure in hours or minutes |
| RPO set without knowing the backup frequency | The target is technically not achievable | Align the RPO with the existing backup |
| One RPO for all systems | Too expensive for unimportant data, too weak for critical data | Set it per system |
| Forgetting that errors are replicated | A deleted file is gone everywhere | Combine replication with a backup |
Checking the RPO after a restore test
An RPO is only proven once you achieve it in practice. After every restore test, do the following:
- Note the time of the last usable backup before the test.
- Note the moment you defined the test as an outage.
- Calculate the difference. That is the measured data loss.
- Compare the measured data loss with the agreed RPO.
- If the system does not meet the RPO, create an action with an owner and a date.
For example: the RPO is one hour, the last backup was at 09:00 and the test took place at 10:30. The measured data loss is one and a half hours. That does not meet the RPO, so the backup frequency must go up or the backup must run more often.
What auditors want to see
An auditor asks for the RPO values per critical system, the decision of management, and evidence that the backup meets that value. That evidence is usually a log file with backup times plus a restore report. See the audit process for what else you need to prepare.
Frequently asked questions about RPO
Is RPO the same as RTO? No. RPO is about how much data you lose, RTO is about how long it takes to be back up.
Can the RPO be zero? In theory yes, but it requires synchronous replication and costs a lot. For most businesses, a small, deliberate RPO is more realistic.
What is the link with the MTPD? The MTPD (maximum tolerable period of disruption) is the maximum downtime before things really go wrong. The RTO always falls within it. The RPO is separate from time: it is about data, not downtime. See the BIA explained.
You can find more about the whole process in the step-by-step guide.