Identity resilience glossary
Recovery time objective (RTO)
A recovery time objective, or RTO, is the target maximum time for restoring a defined service after a disruption. It expresses how much downtime the organization is prepared to tolerate for that service. Business needs set the objective; the recovery approach must then be tested against it. NIST RTO definition, Google Cloud disaster recovery planning
Why it matters
For identity-dependent operations, restoring directory records is only part of the work. The team needs a clear definition of restored service: which users, which applications and which access checks must succeed. Otherwise, a fast restore job can be reported as a successful recovery while people still cannot do their jobs.
Illustrative identity example
A company sets a one-hour RTO for staff access to its support application through Okta. Access is disrupted at 09:00. Its plan therefore targets validated service restoration by 10:00. Investigation, recovery decisions, configuration repair and application testing all consume that window. Finishing a configuration restore at 09:20 does not establish success if staff cannot access the application until 10:15. This is a planning example, not a Backupta recovery promise.
Common confusion
RTO is an objective, not a measured result or a guarantee. Record actual exercise and incident timings separately, including the conditions under which they were achieved. RPO addresses a different issue: how much data loss, measured in time, is acceptable. A current backup can coexist with a lengthy service outage.