# Encrypted backups verified semi-annually

- **Pattern:** `ab-001419` (`finserv-encryption.data-at-rest.encrypted-backups-verified`)
- **Severity:** medium
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001419
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001419)

## Why it matters

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.

## Severity rationale

Medium because unencrypted or unverified backups create a secondary exposure vector that is often overlooked until a recovery scenario reveals the gap.

## Remediation

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:

```markdown
# 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.

## Detection

- **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:
    ```markdown
    # Backup Verification Schedule
    - Q1: Restore latest backup to staging, verify data integrity
    - Q3: Restore backup from 6+ months ago, verify historical data recovery
    ```

## External references

- cwe CWE-311
- nist SC-28
- pci-dss Req-3.4
- external FFIEC-IT-Handbook-IS — https://ithandbook.ffiec.gov/it-booklets/information-security.aspx

Taxons: cryptography-and-secrets, operational-readiness

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