KSI-RPL-ARP—Aligning Recovery Plan
Formerly KSI-RPL-02
>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 security program maturity through metrics dashboards — key security indicators tracked over time, program maturity assessments with year-over-year comparisons, and roadmap progress measured against prior commitments. Agencies assess maturity through measurable trends, not marketing narratives.
Security Metrics Dashboard
Dashboard expressing security program health — key metrics and trend lines showing maturity trajectory
Security Program Overview
Security program overview expressing governance, team structure, and key initiatives
Security Roadmap
Security roadmap expressing planned improvements and investment areas — with progress against prior commitments
>Programmatic Queries
CLI Commands
aws backup list-recovery-points-by-backup-vault --backup-vault-name <vault> --query "RecoveryPoints[].{ARN:RecoveryPointArn,Resource:ResourceType,Created:CreationDate,Status:Status}" --output table --max-results 20aws backup describe-recovery-point --backup-vault-name <vault> --recovery-point-arn <arn> --query "{Status:Status,Created:CreationDate,Encrypted:IsEncrypted,Lifecycle:Lifecycle}" --output json>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Do recovery plans cover all critical systems, services, and dependencies — including third-party services, DNS, identity providers, and key management systems?
- •Are recovery plans defined for multiple failure scenarios — single-service failure, availability zone loss, region loss, and provider-wide outage?
- •How do you ensure recovery plan alignment covers both RTO (service restoration) and RPO (data loss) objectives for every critical resource?
- •Are there dependencies or services where recovery plans are incomplete or untested, and how are those gaps tracked?
Automation & Validation:
- •What automated runbooks or scripts support recovery plan execution, and what percentage of recovery steps are automated versus manual?
- •How do you validate that recovery plans actually achieve defined RTOs and RPOs — through full recovery tests, not just tabletop exercises?
- •What happens if a recovery plan fails during execution — is there a fallback plan, and has the fallback been tested?
- •How do you detect when environmental changes (new services, new dependencies, architecture updates) invalidate portions of the recovery plan?
Inventory & Integration:
- •What tools support recovery plan execution (orchestration platforms, DR automation, cloud-native recovery services)?
- •How do recovery plans integrate with your asset inventory and dependency map to ensure all critical resources are covered?
- •Are recovery plans stored as executable runbooks (linked to automation), or only as narrative documents?
- •How does your recovery plan account for the recovery order of dependent services — which services must recover first for others to function?
Continuous Evidence & Schedules:
- •How frequently are recovery plans reviewed for alignment with objectives, and what evidence proves each review was completed?
- •Is recovery plan testing data (test dates, achieved RTO/RPO, issues found) available in structured format for assessor review?
- •What evidence demonstrates that recovery plans have been updated in response to environmental changes, test failures, or objective updates?
- •How do you prove that recovery plans remain viable — that they reflect the current architecture, dependencies, and staffing?
Update History
Ask AI
Configure your API key to use AI features.