Encrypted backups verified semi-annually

An encrypted backup that has never been successfully restored is operationally equivalent to no backup. CWE-311 applies equally to backup files: if the backup encryption key is lost, rotated without updating the backup policy, or the encryption configuration is misconfigured, the backup is unrecoverable — which is a data loss event, not a security win. PCI-DSS 4.0 Req-3.4 and NIST SC-28 require that encrypted backups remain recoverable, not just encrypted. FFIEC IT Handbook (Information Security) mandates periodic backup testing. A 180-day verification cadence ensures that rotation events and configuration drift haven't silently broken your recovery path before an incident forces you to find out.

Enable backup encryption in your database provider console, then schedule and document semi-annual restore tests. Store test results in a docs/backup-verification.md file that your deployment checklist references:

# Backup Verification Log

## 2026-01-15 — Q1 Test
- Provider: AWS RDS automated backup
- Backup date tested: 2025-12-01
- Restore target: staging-restore cluster
- Encryption: AES-256 (confirmed via RDS console)
- Data integrity: Verified — row counts matched, 0 decryption errors
- Signed off by: [name]

## Next test due: 2026-07-15

If using Supabase, enable Point-in-Time Recovery (PITR) in Project Settings > Database > Backups, then restore to a shadow project to verify. The test must confirm both that decryption succeeds and that the restored data is coherent.

• ID: encrypted-backups-verified
• Severity: medium
• What to look for: Count all backup configurations and enumerate which are encrypted. Quote the actual encryption setting found. Look for evidence of restore testing — count all verification records and check if the most recent is within 180 days. A backup without encryption enabled does not count as pass.
• Pass criteria: At least 1 backup configuration has encryption enabled, AND at least 1 verification record exists within the past 180 days (semi-annual). Report the count even on pass (e.g., "2 backup configs encrypted, last restore test 2026-01-15").
• Fail criteria: Backups are unencrypted (0 encrypted backup configs), or no verification within 180 days (0 recent test records).
• Skip (N/A) when: Project is stateless with no persistent data, or uses a provider that handles backups — cite the actual provider found.
• Detail on fail: "0 of 2 backup configurations have encryption enabled" or "Backups encrypted but last verification 540 days ago — exceeds 180-day maximum"
• Remediation:
  • Enable encrypted backups via your database provider (AWS RDS backup encryption, Supabase automated backups with encryption, etc.).
  • Document and perform semi-annual restore tests:

    # Backup Verification Schedule
    - Q1: Restore latest backup to staging, verify data integrity
    - Q3: Restore backup from 6+ months ago, verify historical data recovery