Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
Two continuity targets: RTO caps how long a system can stay down, and RPO caps how much recent data can be lost, measured in time.
These two numbers turn business impact into technical requirements and budget: a 15-minute RPO for an order system needs continuous replication, while a 24-hour RPO for an intranet allows nightly backups.
A business impact analysis sets the CRM at an RTO of 4 hours and an RPO of 1 hour. Backups run hourly, and a quarterly restore test that takes 3 hours 10 minutes and loses 40 minutes of data shows both targets are met.
Targets set without restore testing are guesses, and backups that ransomware can reach may fail when needed. RTO is set per system, so shared dependencies such as identity or DNS can extend the real recovery time.
NIST SP 800-34 defines RTO as the overall time a system's components can be in the recovery phase before negatively affecting the mission or business processes, and RPO as the point in time to which data must be recovered after an outage. Both come from a business impact analysis and the maximum tolerable downtime. They shape Incident Response plans and Service-Level Agreement (SLA) commitments, and set backup frequency, replication and failover choices.
Systems Architecture
NIST CSRC Glossary — Recovery Time Objective (RTO) — https://csrc.nist.gov/glossary/term/recovery_time_objective; NIST CSRC Glossary — Recovery Point Objective (RPO) — https://csrc.nist.gov/glossary/term/recovery_point_objective