VaultKeep blog

Supabase backups for SOC 2: the questions auditors actually ask

What a SOC 2 auditor wants to see about your database backups, why Supabase's built-in backups only answer half of it, and a checklist you can finish in a week.

SOC 2 doesn't prescribe a backup product or a retention number. It asks whether you have controls that match what you told customers, and whether you can prove they operated during the audit period. For backups, in practice, that boils down to six questions. Here they are with the evidence that satisfies each one, and where Supabase's own features do and don't help.

This is a practitioner's summary, not legal or compliance advice. Your auditor and your Trust Services Criteria mapping decide what applies.

1. "Are backups taken automatically, on a defined schedule?"

Evidence: the schedule itself (a policy line like "daily at 03:00 UTC, 30-day retention") and a log showing it ran on those dates.

Supabase built-in: yes on Pro (daily, 7 days). No on Free. There's no exportable log of runs; you screenshot the dashboard.

What to add: a backup system that records every run with a timestamp and outcome, and that you can export. A CSV of "backup started / succeeded" events across the audit window is the cleanest possible answer.

2. "Are backups stored separately from the production system?"

This is the one people miss. Auditors are looking for a copy that survives the failure of the primary system, which includes its account, its region and its provider.

Supabase built-in: backups live inside Supabase, under the same account. That's a rollback capability, not an off-site copy. PITR is the same.

What to add: an off-site copy in a different provider or, at minimum, a different account. Write down where it is and who can access it.

3. "Are backups encrypted at rest and in transit, and who holds the keys?"

Evidence: a description of the encryption (algorithm, where keys live, who can decrypt) and the access controls around it.

Supabase built-in: encrypted at rest by the platform; keys are Supabase's.

What to add: for the off-site copy, encryption before the data leaves your control is the strongest story: per-backup keys wrapped by a master key, with the master key in a secrets manager that only the backup job can read. Per-backup keys also make retention clean; see question 5.

4. "Are backups tested? How do you know they can be restored?"

Half of teams answer this with a shrug, and it's the question most likely to produce a finding.

Evidence: a documented restore-test procedure, plus dated records showing it ran during the audit period, with results. A single successful test from eight months ago is worth little; a weekly record is worth a lot.

Supabase built-in: no automated restore testing. You can restore manually to a new project and document it.

What to add: a scheduled test restore into an isolated environment, with checks (table counts, row counts, integrity hashes) and a stored report. Our test-restore drill describes the method; whatever you use, keep the reports.

5. "How long are backups retained, and how are they destroyed?"

Retention cuts both ways. Too short and you can't recover; too long and you're holding customer data you promised to delete.

Evidence: the retention policy, and proof that expired backups are actually removed.

What to add: a retention sweep that logs each deletion. If backups use per-backup keys, destroying the key ("crypto-shredding") makes the data unrecoverable even if an object lingers, and the log entry is the evidence.

6. "Who can access backups and restore them, and is that access logged?"

Evidence: role definitions (who can trigger a restore, who can read credentials) and an access log.

What to add: an append-only audit trail covering credential reads, backup runs, verifications and restores, ideally enforced at the database level so nobody can quietly edit history. Restores should require a deliberate confirmation and should refuse to overwrite a non-empty target; auditors like controls that make the dangerous action hard.

The one-week checklist

1. Write the backup policy: schedule, retention, location, encryption, who can restore. One page.
2. Turn on Supabase's daily backups or PITR for fast rollback (Pro).
3. Set up an off-site, encrypted copy on a different provider or account.
4. Schedule a weekly test restore with checks and keep the reports.
5. Add a retention sweep that logs deletions.
6. Make sure every backup, verification, restore and credential read lands in an audit log you can export.
7. Export the log and the verification reports once a month into your compliance folder. Future you, during the audit, will be grateful.

Items 3 to 6 are exactly what VaultKeep does, which is why we built it this way: the audit log is append-only and exportable, every weekly verification stores its checks, and retention is crypto-shredded and logged. Items 1, 2 and 7 are still yours.