Recovery Readiness

Recovery Readiness

Mission

Review whether a system can recover from interruption, corruption, dependency loss, or partial completion without leaving operators guessing or forcing unsafe manual reconstruction.

This is a public, software-oriented adaptation of NIST contingency and cyber-resilience guidance. It is not a control assessment or compliance checklist.

Source basis

This skill draws from:

• NIST SP 800-160 Volume 1 Rev. 1, Engineering Trustworthy Secure Systems
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems

Read references/nist-principles.md when the audit needs deeper recovery vocabulary or stronger source grounding.

When to use

Use this skill for:

• backup and restore paths
• checkpoint and resume flows
• long-running jobs that may be interrupted
• incident recovery procedures
• failover or degraded-mode workflows
• data repair, replay, or reconciliation paths
• operator runbooks that claim safe reconstitution

Recovery framing

Treat recovery as a workflow, not a promise. Establish:

1. what must be restored
2. in what order it must be restored
3. what evidence proves recovery is complete
4. what partial state must be quarantined or rolled back
5. what the operator should do if recovery itself fails

Recovery inventory

Check at least these points:

• critical artifacts and state boundaries
• checkpoint granularity
• backup or source-of-truth availability
• replay or rerun idempotency
• rollback or quarantine path
• post-restore validation
• operator instructions and escalation
• degraded operation while full recovery is pending

Recovery worksheet

Build a worksheet before findings:

Review angles

Inspect recovery from these angles:

• interruption before first side effect
• interruption after partial side effect
• restart with stale locks or temp files
• restore from incomplete or corrupt artifact
• replay after ambiguous completion
• operator choosing the wrong recovery target
• dependency unavailable during recovery itself
• claim of success without validation proof

Guard questions

Ask concrete questions like:

• What is the smallest trustworthy unit of resume?
• Which state is authoritative after partial failure?
• What proves that the recovered system is not only running, but correct enough to re-enter service?
• What should remain disabled or quarantined until validation passes?
• Can the operator distinguish reconstitution from best-effort retry?

Finding format

Use this format:

RRR-XXX: Short title

• Severity: Low / Medium / High / Critical
• Workflow: affected recovery path
• Failure or interruption point: where recovery pressure begins
• Required recovery behavior: rollback, checkpoint resume, validated restore, quarantine, hold, etc.
• Current behavior: what exists today
• Evidence: code, config, runbook, test, or observed behavior
• Impact: consequence if recovery is attempted as-is
• Recommended change: smallest credible change that improves recovery integrity
• Tests: restore, rerun, replay, validation, or operator-flow tests

Non-findings

Record explicit non-findings when the system appears to:

• preserve trustworthy checkpoints
• refuse unsafe replay
• validate restored capability before declaring success
• isolate suspect state until review or repair
• guide the operator through recovery order and next action

Output contract

Produce:

1. a short recovery posture summary
2. the recovery worksheet
3. findings
4. explicit non-findings
5. a prioritized recovery backlog
6. validation or drill recommendations
7. limits of analysis

Limits

• Do not present the review as NIST compliance.
• Do not treat backup existence as proof of recoverability.
• Do not claim restore success without a validation gate.