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.
Medium because unencrypted or unverified backups create a secondary exposure vector that is often overlooked until a recovery scenario reveals the gap.
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.
finserv-encryption.data-at-rest.encrypted-backups-verifiedmedium"0 of 2 backup configurations have encryption enabled" or "Backups encrypted but last verification 540 days ago — exceeds 180-day maximum"# Backup Verification Schedule
- Q1: Restore latest backup to staging, verify data integrity
- Q3: Restore backup from 6+ months ago, verify historical data recovery