Backup and recovery procedures documented

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.

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

# 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

• ID: gov-fisma-fedramp.documentation-readiness.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:

  # 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