why walwarden exists

soc 2 doesn't care that you have backups. it cares that you can prove a restore.

that distinction sounds pedantic until an auditor asks. CC7.5 and A1.3 — the controls every type II hits — don't ask whether dumps exist somewhere. they ask whether you recovered from one, and whether you can hand over evidence that it worked.

here's how it usually goes. an engineer gets handed "make us soc 2 ready." they google it, buy a compliance platform, wire up the easy checks. then the auditor asks the restore question, and the honest answer is: we have backups, we've never restored one, and we have no record either way. backups exist. proof doesn't. that gap stalls audits every week.

the provider tools don't close it. supabase and neon each keep backups inside their own dashboards, in their own formats, recoverable only through them. that's a couple of screenshots pretending to be an evidence trail — and if the provider is the thing you're worried about, it isn't independence at all.

walwarden is the boring fix: scheduled logical dumps of the postgres you run on supabase and neon — with aws rds/aurora on the roadmap — to object storage you own. every backup gets an ed25519-signed manifest and an append-only audit chain. restores run through the cli on your machine, and the whole thing exports as an evidence bundle an auditor can verify offline.

no continuous-replication theater. we don't do point-in-time recovery yet and we won't claim it. what we ship is recoverability you can prove — which is the thing the audit actually asks for.

if your type II window just started and backups suddenly got interesting, the roadmap shows exactly what ships today — and what we don't claim.