Recovery Time Objective (RTO) is the longest a system, application, or process can stay down after a disruption before the damage becomes unacceptable. If email carries a four-hour RTO, the recovery plan has to restore email within four hours of an outage. The number is not guessed. It comes out of the business impact analysis and reflects how long the business can genuinely tolerate the loss.
Different systems earn different RTOs by criticality. A trading platform might need to be back in minutes, while a document archive could sit idle for days without real harm. RTO then steers concrete choices, since a tight target rules out slow recovery options. Promising a one-hour RTO while relying on a cold site is a contradiction the exam loves to test, because that gap between the stated objective and the chosen strategy is exactly where plans fail. Recovery targets should also be revisited as the business changes, not set once and then forgotten.
How is RTO tested on the CISSP?
RTO appears in Domain 7: Security Operations recovery planning. Know how the BIA sets it, how it shapes site selection and technology, and the cost relationship: shorter objectives demand more expensive solutions.