Skip to main content
← All controls
CP-2 / CP-4 / A.17.1.2 / CIS-11.5 NIST SP 800-34 Rev 1 NIST CSF

Are RTO and RPO defined for critical systems and validated?

Demonstrate that the organization has formally defined, documented, and validated Recovery Time Objectives and Recovery Point Objectives for all critical systems through documented testing activities.

Description

What this control does

Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are quantitative thresholds that define the maximum acceptable downtime and data loss for critical systems during disruption. Organizations must formally document these metrics for each system based on business impact analysis, then validate them through testing such as tabletop exercises, recovery simulations, or actual incident response reviews. Without validated RTOs and RPOs, disaster recovery plans become aspirational documents that may fail during actual events, leading to unacceptable business disruption and data loss.

Control objective

What auditing this proves

Demonstrate that the organization has formally defined, documented, and validated Recovery Time Objectives and Recovery Point Objectives for all critical systems through documented testing activities.

Associated risks

Risks this control addresses

  • Inability to prioritize recovery efforts during multi-system incidents due to undefined criticality thresholds, resulting in business-critical systems remaining offline while less-important systems are restored first
  • Data loss exceeding business tolerance because backup frequencies and retention policies were not aligned with actual business requirements for data currency
  • Recovery procedures consuming significantly more time than anticipated, causing extended outages that violate customer SLAs, regulatory reporting requirements, or operational dependencies
  • Insufficient resource allocation (staff, infrastructure, budget) for recovery operations because RTO/RPO requirements were never quantified or validated against actual capabilities
  • Failure to meet contractual obligations or regulatory timelines due to unrealistic recovery expectations that were never tested against operational constraints
  • Cascading failures across dependent systems because interdependencies and their recovery sequencing were not documented or validated during RTO/RPO definition
  • Legal and financial liability from data loss or extended outages when leadership was not informed of realistic recovery capabilities versus business requirements

Testing procedure

How an auditor verifies this control

  1. Obtain the current inventory of systems classified as critical or mission-essential, including business impact analysis documentation that justifies their classification.
  2. Request documented RTO and RPO definitions for each critical system, including the business rationale, approval authority, and date of last review.
  3. Review business continuity and disaster recovery plans to verify they reference specific RTO/RPO metrics and include corresponding recovery procedures designed to meet those objectives.
  4. Select a representative sample of critical systems across different business units and technology platforms (minimum 5 systems or 20% of critical inventory, whichever is greater).
  5. For each sampled system, examine validation testing evidence from the past 12 months, such as disaster recovery test reports, tabletop exercise documentation, or post-incident reviews.
  6. Verify that validation testing measured actual recovery time and recovery point achieved, compared these results against defined RTO/RPO targets, and documented any gaps or deficiencies.
  7. Interview business process owners and IT recovery personnel for sampled systems to confirm they understand the defined RTO/RPO and have reviewed them for continued relevance within the past year.
  8. Review any gap remediation plans where testing revealed RTO/RPO targets were not met, including root cause analysis, corrective actions, and re-testing evidence.
Evidence required RTO/RPO definition documents with business owner approval signatures, business impact analysis reports classifying system criticality, disaster recovery test reports showing actual versus target recovery metrics for the past 12 months, post-incident review documentation comparing actual recovery performance to defined objectives. BCP/DR plan excerpts referencing specific RTO/RPO thresholds for sampled systems, gap remediation plans with corrective action tracking for any validation failures, and interview notes or attestations from business process owners confirming annual RTO/RPO review cycles.
Pass criteria All sampled critical systems have documented RTO and RPO definitions approved by business owners within the past 24 months, with validation testing conducted within the past 12 months that demonstrates achievement of or documents justified exceptions to those objectives.