# Backup and recovery procedures documented

- **Pattern:** `ab-001587` (`gov-fisma-fedramp.documentation-readiness.backup-recovery-documented`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001587
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001587)

## Why it matters

Systems without documented backup and recovery procedures lose data permanently when hardware fails, ransomware encrypts a database, or a destructive migration runs on production. NIST 800-53 rev5 CP-9 (System Backup) requires defined backup frequencies, storage locations, and verification procedures; CP-10 (System Recovery and Reconstitution) mandates documented recovery steps and tested restoration. CMMC 2.0 RE.L2-3.8.9 requires regular backups of CUI. FedRAMP rev5 CP-9 sets specific requirements for backup retention and off-site storage. Without a written RTO and RPO, teams discover their actual recovery time during an outage — typically far longer than stakeholders expect.

## Severity rationale

Low because inadequate backup documentation does not increase the likelihood of data loss directly, but guarantees longer downtime and greater data loss when any loss event occurs.

## Remediation

Create `docs/backup-recovery.md` with all seven required components: frequency, storage location, encryption, verification schedule, RTO, RPO, and numbered recovery steps.

```markdown
# Backup & Recovery

## Backups
- **Database:** Supabase automated daily backups, retained 7 days (Pro) / 30 days (Team)
- **Storage:** Backups encrypted at rest; point-in-time recovery available within retention window
- **Config/secrets:** Stored in Vercel env vars; mirrored to 1Password for team members

## Objectives
- **RTO:** 4 hours — service restored within 4 hours of confirmed loss event
- **RPO:** 24 hours — maximum acceptable data loss window

## Recovery Procedure
1. Identify the target restore timestamp in Supabase dashboard > Backups
2. Trigger point-in-time recovery to a new DB instance
3. Update `DATABASE_URL` in Vercel env vars to point at recovered instance
4. Run `npm run db:migrate` to verify schema matches application version
5. Smoke-test critical flows (login, submit, dashboard) before marking resolved
6. Monitor error rates for 2 hours post-recovery

## Verification
- Backup restoration tested quarterly against staging environment
```

## Detection

- **ID:** `backup-recovery-documented`
- **Severity:** `low`
- **What to look for:** Look for documentation describing backup schedules, recovery time objectives (RTO), recovery point objectives (RPO), and step-by-step recovery procedures. Count the number of required components present: backup frequency, storage location, encryption, verification schedule, RTO, RPO, and recovery steps.
- **Pass criteria:** Documentation describes at least 5 of the following components: backup frequency, storage location, encryption of backups, verification procedures, tested recovery procedures, RTO (with specific hour target), and RPO (with specific hour target). Recovery procedures include at least 3 numbered steps.
- **Fail criteria:** No backup/recovery documentation found, or documentation covers fewer than 5 components.
- **Skip (N/A) when:** The site is read-only (no data loss risk).
- **Detail on fail:** `"No backup/recovery procedures documented. Unclear whether data is backed up or how to recover from outages."`
- **Remediation:** Document backup and recovery:

  ```markdown
  # Backup & Recovery

  ## Backup Schedule
  - Database: Automated daily at 2 AM UTC
  - Configuration: Committed to git, backed up automatically
  - Storage: AWS S3 with cross-region replication

  ## Recovery Time Objective (RTO)
  - Target: 4 hours to restore service
  - Backup verification: tested monthly

  ## Recovery Point Objective (RPO)
  - Target: Maximum 1 hour of data loss
  - Incremental backups every hour

  ## Recovery Procedures
  1. Identify the backup needed (date/time)
  2. Restore database from backup
  3. Verify data integrity
  4. Failover to recovered instance
  5. Verify service connectivity
  6. Monitor for issues

  ## Testing
  - Recovery procedures tested monthly
  - Backup restoration tested quarterly
  ```

## External references

- nist CP-9
- nist CP-10
- fedramp CP-9
- cmmc RE.L2-3.8.9

Taxons: operational-readiness, regulatory-conformance

HTML version: https://auditbuffet.com/patterns/ab-001587