KSI-RPL-RRO—Reviewing Recovery Objectives
Formerly KSI-RPL-01
>Control Description
>NIST 800-53 Controls
>Trust Center Components3
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express governance through defined accountability — named roles with qualification requirements, board-level security briefing cadence, and training completion tracked automatically. Governance structures show agencies that security leadership is defined and accountable at every organizational level.
Governance and Oversight Structure
Organizational structure expressing security governance — board/executive oversight, named leadership roles, and reporting lines
Security Awareness Program
How security awareness training is delivered and measured — completion tracked via LMS integration
Security Team Qualifications
Security team structure, certifications, and expertise areas
>Programmatic Queries
CLI Commands
aws backup list-recovery-points-by-backup-vault --backup-vault-name <vault> --query "RecoveryPoints[].{Resource:ResourceType,Created:CreationDate,Completion:CompletionDate,Status:Status}" --output table --max-results 10>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Are RTOs and RPOs defined for all critical services and data stores, or are there components without formally defined recovery objectives?
- •Do recovery objectives account for all failure scenarios — not just service outages but also data corruption, ransomware, insider threats, and provider failures?
- •How do you ensure recovery objectives reflect agency requirements and SLA commitments, not just internal preferences?
- •Are recovery objectives defined at a granular level (per service, per data tier) rather than a single blanket RTO/RPO for the entire CSO?
Automation & Validation:
- •What automated monitoring confirms that current technical capabilities (backup frequency, replication lag, failover speed) can actually meet defined RTOs and RPOs?
- •How do you detect when infrastructure changes make a defined RTO or RPO unachievable — for example, when data volume growth outpaces backup throughput?
- •What happens when a recovery test fails to meet the defined RTO or RPO — is the objective updated, or is the capability improved?
- •How do you validate that RPO-aligned backup frequencies are maintained during peak load periods and not just under normal conditions?
Inventory & Integration:
- •Where are RTOs and RPOs documented and maintained — in a GRC tool, a configuration management database, or alongside service definitions?
- •How do recovery objectives integrate with your backup configuration, replication settings, and failover policies to ensure technical alignment?
- •Are recovery objectives linked to agency SLAs and customer agreements in a traceable manner?
- •How do recovery objective definitions integrate with your recovery plan documentation to ensure plans are designed to meet them?
Continuous Evidence & Schedules:
- •How frequently are recovery objectives reviewed and validated, and what evidence demonstrates each review occurred?
- •Is recovery objective compliance data (current capability vs. defined objective for each service) available via API or dashboard?
- •What evidence shows recovery objectives have been updated in response to changes in agency requirements, architecture, or test results?
- •How do you demonstrate that actual recovery performance in tests or incidents met defined RTOs and RPOs?
Update History
Ask AI
Configure your API key to use AI features.