What is RPO?
RPO (Recovery Point Objective) is the point in time to which data must at least be recoverable after an incident, expressed as the maximum amount of data loss, measured in time, that an organisation still considers acceptable. An RPO of 15 minutes means that after a crash, outage or cyber attack you may lose at most the data of the last 15 minutes. The RPO is a target you set in advance, and it determines how often you make a backup or replicate data. Together with the RTO, it forms the core of every disaster recovery and business continuity plan.
How much data can you afford to lose at most in a crash or cyber attack?
🧠 How exactly is the RPO defined?
The US guideline NIST SP 800-34 Rev. 1 (May 2010) on contingency planning defines the RPO briefly as the point in time to which data must be recovered after an outage. The business continuity standard ISO 22301, using the vocabulary of ISO 22300, phrases it from the perspective of the business process: the point to which the information used by an activity must be restored so that the activity can operate again on resumption.
Both definitions say the same thing with a different emphasis. NIST thinks in terms of the system, ISO in terms of the activity. In practice that difference matters: a historian can be restored perfectly from a technical point of view, while the batch report that depends on it is still unusable because there is a one-hour gap in the measurement series.
A worked example makes it concrete. If you take a backup every hour on the hour and the server crashes at 10:50, the last usable copy is the one from 10:00 and you lose 50 minutes of data. The worst case is therefore not the backup interval itself, but the interval plus the time it takes to create and write the copy. An RPO of 1 hour therefore requires an interval that is clearly shorter than 1 hour.
🔄 What is the difference between RPO, RTO and backup frequency?
The RPO is often confused with related terms. Each figure answers a different question:
| Term | Question it answers | Type of figure | Example in OT |
|---|---|---|---|
| RPO (Recovery Point Objective) | How much recent data may be lost? | Target, set in advance | At most 15 minutes of historian data lost |
| RTO (Recovery Time Objective) | How quickly must the system work again? | Target, set in advance | SCADA server showing screens again within 4 hours |
| Backup frequency | How often is a copy made? | Technical setting | An incremental backup every 10 minutes |
| MTTR (Mean Time to Repair) | How long did recovery actually take on average? | Measured afterwards | Measured recovery of an HMI: 3 hours |
The RPO looks back in time, from the incident to the last good copy. The RTO looks forward, from the incident to the moment the process runs again. According to NIST SP 800-34, the RPO is not part of the maximum tolerable downtime: it is about data loss, not about time without service. In practice they do influence each other. A smaller RPO often means more recovery points or log files to replay during a restore, which can lengthen the recovery time.
🔧 Which technology fits which RPO?
The smaller the RPO, the more expensive and complex the solution. The usual mapping:
| RPO class | Suitable technology | Example in OT |
|---|---|---|
| Zero (no loss) | Synchronous, real-time replication or mirroring: a write only completes once the second location has stored it too | Redundant DCS servers, mirrored databases for batch records |
| Seconds to minutes | Asynchronous replication, transaction logs or continuous data protection (journaling) | Historian replication to a second site |
| Minutes to hours | Frequent snapshots of virtual machines or incremental backups | Snapshots of a virtualised SCADA platform |
| Hours to a day | Daily backup to separate storage | Reporting and MES servers |
| Per change | Backup immediately after every change, with version control | PLC programs and HMI projects |
One pitfall: synchronous replication and high availability protect against hardware failure, but not against errors in the data itself. If ransomware encrypts a database or an operator saves a wrong recipe, that error reaches the second location within milliseconds. An RPO of zero is therefore only valuable when combined with separate point-in-time recovery points, preferably immutable backups that ransomware cannot delete or encrypt.
🏭 Why is the RPO different in OT environments?
In OT it is not just about databases and files. Four types of data each need a different approach:
- Process data in the historian - measured values from sensors and SCADA are often unrecoverable once lost, because you cannot measure yesterday’s temperature again. Many historians buffer data at the source (store-and-forward) on an interface node or edge device. As long as that buffer is large enough, a network outage does not cause data loss.
- Configurations and programs - for PLC code, HMI projects and network settings you do not want to lose a single approved change. Here the RPO is event-driven rather than time-based: a backup after every change, recorded through configuration management and change management.
- Batch and quality records - in pharmaceuticals and food production, batch records must be complete and reliable. A gap in the record can mean that a batch may not be released, so the RPO here is close to zero.
- Operator settings - setpoints and alarm limits changed during operation often live only in the controller. Losing them means that after recovery the installation starts up with outdated settings.
Illustrative values, which vary widely per installation: an RPO of zero for operator settings in a batch process, 5 minutes for alarm logs, 15 minutes for historian data with local buffering and 24 hours for reporting environments. Each figure should follow from the impact of loss, not from habit.
🛠️ How do you set an RPO in five steps?
- Inventory the data - use the asset inventory and record for each system which data it holds: process data, configuration, records or reporting.
- Determine the impact of loss - record in the business impact analysis what it costs if an hour, a shift or a day of data is missing, including quality, statutory record-keeping and safety.
- Agree the RPO with the process owner - the owner of the business process decides; administrators advise on feasibility and cost.
- Design the technology with a margin - choose replication, snapshots or backups whose worst case stays within the RPO, and keep at least one copy separate or behind an air gap.
- Test and verify - perform a real restore periodically and check that the restored data actually runs up to the expected point in time. Also rehearse the scenario in a tabletop exercise.
🔐 Which laws and standards require an RPO?
- NIS2, Article 21(2)(c) - requires business continuity, such as backup management and disaster recovery.
- Cybersecurity Act - the Dutch transposition of NIS2 (Cyberbeveiligingswet), in force since 15 August 2026. The Cybersecurity Decree requires in Article 9 recovery procedures, periodically verified backups and a tested continuity plan.
- ISO 22301 - has organisations derive recovery objectives, including the RPO, from the business impact analysis.
- ISO 27001:2022 - control A.8.13 (information backup) and A.5.30 (ICT readiness for business continuity).
- IEC 62443-3-3 - system requirements SR 7.3 (control system backup) and SR 7.4 (control system recovery and reconstitution to a known secure state).
❓ Frequently asked questions
What is a good RPO for an OT system?
A good RPO for an OT system follows from the impact of data loss on the process, not from a standard figure. For batch records and operator settings the RPO is often close to zero, while for reporting servers a day may be acceptable. Record the RPO per system in the business impact analysis.
Is an RPO of zero achievable?
An RPO of zero is achievable with synchronous replication, but only against the failure of hardware or a site. Logical errors and ransomware are replicated immediately. You should therefore always combine an RPO of zero with separate, immutable recovery points.
How often should I back up for an RPO of 1 hour?
For an RPO of 1 hour, the backup interval plus the time needed to create and write the copy must together be shorter than 1 hour. In practice you would choose an interval of, for example, 30 to 45 minutes. Also check that backups do not fail silently.
What is the difference between RPO and RTO?
The RPO determines how much data you may lose, the RTO how long a system may be down. The RPO looks back to the last good copy, the RTO forward to the moment of resumption. You set both targets separately for each system.
Does an RPO also apply to PLC programs?
An RPO also applies to PLC programs, but there it is event-driven rather than time-based. Every approved change should be followed by a backup with version control, so you never lose a modification. That way a PLC can be returned to the last known good version after a failure or attack.
Who determines the RPO?
The RPO is determined by the owner of the business process, based on the business impact analysis. IT and OT administrators advise on what is technically feasible and what it costs. Management accepts the choice, including the residual risk.
📌 In summary
The RPO determines the point in the past to which you must be able to recover data after an incident, and therefore how much data loss is acceptable.
The smaller the RPO, the less data you lose, but the higher the demands on your backup and replication architecture. In OT the RPO applies not only to historian data, but also to PLC programs, HMI projects, batch records and operator settings. Replication alone is no protection against ransomware; only separate, tested recovery points make an RPO real.