Recovery Time Objective (RTO)
The maximum time within which a process or system must be restored to operation after a disruption.
RTO defines how long the organisation can tolerate a disruption to a given process before the losses become unacceptable. It is set per process on the basis of a Business Impact Analysis (BIA) and then validated against reality.
The most common pitfall is an RTO mismatch: the plan states four hours, but the cloud provider contract allows eight. On paper it looks fine; in a real outage you will not recover in time. This is precisely the risk that DORA requires organisations to detect between their contracts and their BIA.
RTO works alongside RPO (Recovery Point Objective). Together they define what backup and recovery architecture you actually need, rather than leaving it to guesswork.
In practice: see the relevant RealSec module.
The maximum amount of data that can be lost after a disruption, expressed as a time interval (e.g., the last hour of data).
Business Impact Analysis: an assessment of which processes are critical and how quickly they must be restored after a disruption.
Regulation 2022/2554 on digital operational resilience for the financial sector. Applicable from 17 January 2025.
Compliance that connects.
Terms are the map. RealSec ties them to processes, systems and vendors in one engine.