RTO and RPO are the two fundamental metrics of every business continuity and disaster recovery plan.

The Recovery Time Objective (RTO) specifies how long a system or business process may be unavailable after a failure before existential damage occurs. An RTO of 4 hours for the ERP system means: the recovery process must be completed in less than 4 hours.

The Recovery Point Objective (RPO) specifies how much data loss is maximally acceptable — expressed as a time period. An RPO of 1 hour for transaction data means: backups must be created at least hourly so that in an emergency, at most 1 hour of transaction data is lost.

The most common error: RTO and RPO are defined but never tested against the actual backup architecture. An RTO of 4 hours is worthless if the actual restore takes 48 hours. (Art. 11) and NIS2 explicitly require that RTOs and RPOs are not only defined but proven through documented tests. Typical RTOs by backup architecture: disk-based air gap (Silent Brick) 4 – 8 hours; tape-based air gap 24 – 96 hours; cloud backup 12 – 72 hours (WAN-dependent, but often compromised in a ransomware scenario).

Frequently asked questions

The starting point is a Business Impact Analysis (BIA): what financial, operational and reputational damage occurs per hour of downtime for each critical system? From this, the Maximum Tolerable Downtime (MTD) is derived, from which the RTO follows. The RPO follows from the backup frequency and the value of data generated in the last backup interval. RTO and RPO must be approved by management and technically implemented in the backup architecture.
Under NIS2 and DORA, management must approve the backup strategy — this includes RTO and RPO. IT managers and CISOs bear operational responsibility for implementation. Documentation of recovery tests protects all parties: it demonstrates that RTO targets were known and the architecture was designed accordingly.