RTO and RPO
The Recovery Time Objective (RTO) is the maximum acceptable time to restore a process or system after an outage, while the Recovery Point Objective (RPO) is the maximum tolerable data loss, expressed as the time span back to the last usable backup.
RTO and RPO are the two core recovery metrics of business continuity and emergency management. The Recovery Time Objective defines how long a business process or IT system may remain unavailable before the damage to the organisation becomes unacceptable – it is a deadline for restoration. The Recovery Point Objective defines how much data may be lost: an RPO of four hours means that, in the worst case, the work of the last four hours cannot be reconstructed. Both are management targets rather than technical measurements – they tell the IT architecture what it has to deliver, not the other way round.
RTO and RPO are derived from the business impact analysis. For each critical process, the analysis establishes when an outage starts to cause financial, legal or reputational harm, which yields the maximum tolerable period of disruption (MTPD) that the RTO must stay within. Organisations often track supporting figures as well, such as the Recovery Time Actual (RTA) measured in real recovery tests and the Work Recovery Time (WRT) needed to catch up before normal operations resume. The link to technology is decisive: an RPO of 15 minutes cannot be met with a nightly full backup – it requires short backup intervals, transaction logs or replication – and an RTO of two hours requires standby systems prepared in advance rather than hardware procured after the incident.
Recovery objectives are firmly anchored in regulation. Article 21(2)(c) of the NIS2 Directive requires business continuity measures including backup management and disaster recovery, but prescribes no numeric targets – the measures must simply be appropriate to the risk. For financial entities, Article 12 of the DORA Regulation (EU) 2022/2554 explicitly requires recovery time and recovery point objectives to be set for each function. Methodologically, BSI Standard 200-4 as well as ISO 22301 and ISO/IEC 27031 describe how such objectives are derived and validated. For audit evidence, what matters is that the targets are not only documented but regularly proven in recovery tests, with deviations tracked and remediated.
Legal Basis
Art. 21(2)(c) NIS2 Directive (EU) 2022/2555 (business continuity, backup management, disaster recovery); Art. 12 DORA Regulation (EU) 2022/2554; BSI Standard 200-4; ISO 22301; ISO/IEC 27031; ISO/IEC 27001 Annex A 5.29/5.30
Practical Example
An energy supplier with around 400 employees qualifies as an important entity under NIS2. Its information security officer runs a business impact analysis and finds that the control system of the grid operations centre becomes critical after just 60 minutes, whereas the billing system can tolerate an outage of two working days. For the control system she sets an RTO of one hour and an RPO of five minutes, implemented through a synchronously replicated cluster in a second data centre; for billing, an RTO of 48 hours and an RPO of 24 hours based on the nightly backup are sufficient. The annual recovery test shows that restoring the control system actually takes 2.5 hours because the failover has to be approved manually. The gap is logged as a finding, automated failover is commissioned, and the issue is reported to executive management as part of the management review.