what pg_dump proves to your soc 2 auditor — and what it does not

pg_dump is not the problem. it's a good tool. the problem is what it proves, and to whom.

a `pg_dump` on a schedule proves exactly one thing: that a logical snapshot of your database existed at a point in time. and it only proves even that if you wrote down that the job ran, when, and against what. the dump file itself is just bytes in a bucket. it doesn't carry its own history.

an auditor doesn't ask "do you have dumps." they ask a longer list, and pg_dump answers almost none of it.

what the dump doesn't prove

walk down what a type II actually probes and check each one against a file sitting in s3:

- **that it restores.** an untested dump is a backup in the same way an unopened parachute is a parachute. you find out at the worst possible moment. `pg_dump` exiting 0 tells you the read succeeded, not that `pg_restore` will land a working database on the other side. - **that you tested it in the period.** the auditor wants a successful restore *inside the observation window*, not "we did one once in 2024." a cron dump produces no restore record at all. - **that it wasn't tampered with.** a plain `.sql.gz` has no integrity story. anyone with write access to the bucket can alter it and you'd never know. "trust me, this is the file" is not an evidence posture. - **that it lives outside the thing you're hedging against.** if the dump sits in the same provider account as the primary — or worse, only in the provider's own backup dashboard — then a bad day for the provider is a bad day for your recovery too. that's not independence. - **that you have a record either way.** when the restore question comes, the honest answer for most teams is "we have backups, we've never restored one, and we have no log to show you." backups exist. proof doesn't.

what the auditor is actually asking for

the controls vary by framework but the shape is the same. for soc 2 type II, the availability criteria and the common criteria around recovery — CC7.x for incident recovery, A1.2 and A1.3 for backup and recovery testing — don't ask for the existence of backups. they ask you to demonstrate:

- a documented rto and rpo — how much downtime and how much data loss you've decided is acceptable, - a retention policy you actually follow, - and evidence of a **successful, tested restore** within the period, usually per quarter, with a record of the outcome.

vanta and drata readiness checklists land in the same place. the artifact that satisfies the control is not the dump. it's the tested-restore log plus enough integrity around it that a third party can believe it.

that's the gap. a github action that runs `pg_dump` nightly is producing the input to evidence and stopping one step short of the evidence itself. screenshots of a provider's backup tab pasted into a google doc are not an audit trail — they're a claim, in a format the auditor has to take on faith.

what closes it

the missing pieces are unglamorous and specific:

- a **signed manifest** per backup, so the file can prove what it is and that it hasn't changed, - an **append-only audit chain**, so the sequence of backups and restores can't be quietly rewritten after the fact, - a **restore you actually ran**, with the outcome recorded — the thing the control literally asks for, - an **off-provider copy in storage you own**, so the evidence and the recovery path don't depend on the provider you're being asked about, - and a **bundle your reviewer can verify offline**, without an account on your tooling, because evidence a third party can't independently check isn't worth much.

none of that replaces pg_dump. it wraps a record around it.

what we ship, and what we don't

this is the boring fix walwarden runs: scheduled logical backups of the postgres you run on supabase and neon, into object storage you own, each one signed and chained, with operator-run restores through a cli on your machine and an evidence bundle an auditor can verify offline. aws rds/aurora is on the roadmap.

what we don't do: point-in-time recovery. no wal streaming, no second-by-second rewind — not yet, and we won't put the word on your invoice before it's real. what ships today is recoverability you can prove, which — read the controls again — is the thing the audit is actually asking for.

if your type II window just opened and backups suddenly got interesting: the roadmap shows exactly what ships today, /proof is a real evidence bundle you can verify yourself, and you can start free on one database.