# Recovery Plan

> Design disaster recovery and system restoration procedures

- Skill: `bromso/recovery-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bromso/recovery-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bromso/recovery-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: bromso (https://skillmd.com/u/bromso)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bromso/recovery-plan

---


# Recovery Plan

Design disaster recovery and system restoration procedures for "$ARGUMENTS" with recovery priorities, restoration procedures per system type, RTO/RPO targets, and recovery verification.

## Prerequisites

Read `.metapowers/security/$ARGUMENTS/00-govern.md`. If this file does not exist, tell the user:

> Phase 0 (Govern) has not been completed for "$ARGUMENTS". Run a Govern skill first (e.g., `/security:security-policy $ARGUMENTS`), or use `--skip-checks` to bypass.

If `--skip-checks` is present in $ARGUMENTS, skip this check and log to `.metapowers/security/$ARGUMENTS/skip-log.md`.

## Process

1. **Read context files:**
   - Read `plugins/security/shared/incident-response-template.md` for recovery workflow reference
   - Read `.metapowers/security/$ARGUMENTS/00-govern.md` for organizational context and business impact analysis

2. **Define recovery priorities:**
   - Rank systems by business criticality (Tier 1: mission-critical, Tier 2: important, Tier 3: supporting)
   - **Tier 1** — systems whose failure causes immediate revenue loss or safety risk (payment processing, authentication, core API)
   - **Tier 2** — systems causing significant operational impact within hours (email, internal tools, monitoring)
   - **Tier 3** — systems with lower urgency (development environments, reporting, analytics)
   - Map dependencies between systems to determine restoration order
   - Identify critical path: which systems must be restored first to unblock others

3. **Create restoration procedures per system type:**

   **Database restoration:**
   - Point-in-time recovery from transaction logs
   - Full restore from latest backup plus replay of transaction logs
   - Failover to read replica promoted to primary
   - Data integrity verification after restoration (checksum validation, row counts, referential integrity)

   **Application restoration:**
   - Redeployment from container images or build artifacts (known-good version)
   - Configuration restoration from version-controlled config
   - Secret and credential restoration from vault/KMS
   - Health check verification before accepting traffic

   **Infrastructure restoration:**
   - Infrastructure-as-code redeployment (Terraform, CloudFormation, Pulumi)
   - DNS failover to disaster recovery site
   - Network configuration restoration (VPN, firewall rules, load balancer config)
   - Certificate and key restoration

4. **Set RTO and RPO per system:**
   - **RTO (Recovery Time Objective)** — maximum acceptable downtime
     - Tier 1: 15 minutes to 1 hour
     - Tier 2: 1–4 hours
     - Tier 3: 4–24 hours
   - **RPO (Recovery Point Objective)** — maximum acceptable data loss
     - Tier 1: zero to 5 minutes (real-time replication)
     - Tier 2: 1–4 hours (frequent backups)
     - Tier 3: 24 hours (daily backups)
   - Document justification for each target based on business impact

5. **Plan communication during recovery:**
   - Define status page updates and customer communication cadence
   - Internal communication: recovery progress updates every 30 minutes for Tier 1
   - Stakeholder notifications: who to inform at each recovery milestone
   - Define go/no-go decision points for failover and failback

6. **Define recovery verification:**
   - **Functional verification** — automated test suites against restored systems
   - **Data verification** — integrity checks, sampling, and reconciliation
   - **Performance verification** — load testing to confirm restored systems meet SLAs
   - **Security verification** — confirm patching, credential rotation, and monitoring are active
   - Define observation period before declaring recovery complete
   - Plan for failback from DR site to primary (if applicable)

7. **Write the artifact** to `.metapowers/security/$ARGUMENTS/05-recover.md` with heading:

   ## Recovery Plan

   Include sections:
   - **Recovery Priorities** — tiered system ranking with dependencies and critical path
   - **Restoration Procedures** — step-by-step per system type (database, application, infrastructure)
   - **RTO/RPO Targets** — per system with justification
   - **Communication Plan** — stakeholder updates during recovery
   - **Recovery Verification** — functional, data, performance, and security checks
   - **Failback Plan** — return to primary site procedures

## Output

The recovery plan written to `.metapowers/security/$ARGUMENTS/05-recover.md`. Present a summary to the user highlighting:
- System recovery priorities and critical path dependencies
- RTO/RPO targets per tier
- Key restoration procedures per system type
- Recovery verification checkpoints