Backup and restore posture for persistent data is evidenced in the repo

This is an evidence-pointer check: it verifies committed evidence of the backup and restore control, which is exactly what an auditor will ask for. It evidences SOC 2 A1.2 (backup and recovery infrastructure) and supports A1.3 and CC7.5 (recovery testing and incident recovery). Auditors do not accept "Supabase probably handles it": they want to see where backups are configured and, crucially, how a restore would actually be executed and by whom. AI-generated and vibe-coded apps typically fail both halves. The scaffolded stack leans on platform defaults nobody has confirmed (Supabase free tier has no PITR; daily backups are not restore rehearsals), and no human ever writes the restore runbook because "how do I restore prod" is not a prompt anyone types until the day the table is already dropped. The GitLab 2017 database incident is the canonical case: five backup mechanisms existed on paper, none restorable when needed, roughly six hours of production data lost. A committed IaC flag or ops doc plus a restore procedure is cheap insurance and the minimum artifact a SOC 2 readiness assessment expects.

Commit both legs of the evidence. Backup leg: either an IaC setting (backup_retention_period = 7 on an aws_db_instance, point_in_time_recovery on DynamoDB, backup_configuration { enabled = true } on a GCP google_sql_database_instance), a scheduled dump job (a pg_dump step in .github/workflows/backup.yml or a Vercel/Supabase cron), or an ops doc such as docs/ops/backup-restore.md stating the platform-managed arrangement ("Supabase Pro, PITR enabled, 7-day window"). Restore leg: in the same doc or a scripts/restore-db.sh, write the concrete restore procedure — the exact commands or the dashboard path plus who is authorized to run it. Platform-managed backups documented in a committed ops doc are acceptable auditor evidence; undocumented platform defaults are not.