Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) answer different business continuity questions. RTO concerns the acceptable duration of a disruption before important operations must be restored. RPO concerns the recovery point in the data timeline and therefore the amount of recent information that could be lost. Both should be tied to operational impact rather than chosen as attractive round numbers.

Suppose a service company relies on online bookings. An RTO of four hours may call for a recovery process that restores booking capability within that target. An RPO of thirty minutes calls for data recovery near enough to the incident that no more than roughly thirty minutes of recent bookings are lost under the planning assumptions. Backups alone do not establish that either goal is achievable: restoration tests, dependencies, access credentials, and vendors matter.

NIST defines the objectives separately in its contingency-planning terminology. Actual incident recovery can miss a target, and an RPO is not a promise that all corrupted data will be reconstructed. Prioritize systems by business impact and test the chosen plan. Because RTO and RPO are distinct concepts, a combined entry should clearly explain each and may later be split if the existing glossary already treats one separately. They are not synonymous with mean time to repair or a general uptime percentage.