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

verify it (copy-paste, ~10 seconds)

the verifier runs offline with zero dependencies, and its full source ships inside the npm package — read it before you run it. it checks the Ed25519 signature on the Manifest, recomputes the dump's sha256, and replays the Audit-chain hashes. needs Node ≥20, nothing else.

curl -fsSO https://walwarden.com/proof/walwarden-demo-evidence-bundle.tgz
curl -fsSO https://walwarden.com/proof/walwarden-proof-pubkey.pem
npx --yes @walwarden/verifier --bundle walwarden-demo-evidence-bundle.tgz --pubkey walwarden-proof-pubkey.pem

expected output

OK: manifest signature valid for backup_job=bjob_proof_20260612
OK: manifest artifact sha256 matches for backup_job=bjob_proof_20260612 (d91ea6fdb014…)
OK: legacy audit rows internally valid through seq=8 (8 audit events); source completeness not proven
OK: 1 manifests verified, legacy audit row set valid; source completeness not proven

bundle sha256: 3bca0d291cd68383ee34b66daf61e225deca727f48effe14d150a1afac776713

what you're looking at

the bundle is three things, tarred together:

• an Ed25519-signed Manifest for the backup — what was dumped, its sha256, and the signature over the canonical JSON.
• an append-only Audit chain — every state transition of the backup and the restore drill, each row hash-linked to the previous one. edit any row and the chain breaks at that seq.
• a restore record with its outcome — the drill ran to restore.completed, and that row sits inside the same chain.

this is the auditor ask, verbatim: SOC 2 CC7.5 / A1.3 want a demonstrated restore with evidence — not a screenshot of a backups dashboard.

backup job

bjob_proof_20260612

restore drill

rjob_proof_20260612

audit events

8 (chain-intact)

generated

2026-06-12T23:32:59.528Z

how it was made

a logical dump (pg_dump) of a demo Postgres → an S3 bucket the operator owns → an operator-driven restore through the same executor walwarden-cli runs → an Evidence-bundle export. the same code paths a customer runs — only the database is a demo (synthetic rows, nothing sensitive, which is also why the dump itself ships inside the bundle so the verifier can recompute its checksum).

the signing key is a drill key generated for this bundle; its public half is the .pem you download above. customer Evidence bundles require the matching deployment public key. the production endpoint was observed publishing an Ed25519 public key on 2026-07-14 at /.well-known/walwarden-pubkey.pem, but this self-contained demo does not prove that a production bundle is signed by its matching private key or has passed the verifier.

what we do and do not claim today is tracked, with tracking issues, on the roadmap. if you want this artifact for your own Postgres, run your first drill — same pipeline, your database, your bucket.

logical recovery windows have a separate proof lane:npm run proof:logical-recovery checks the baseline snapshot plus supported transaction-tail replay, schema-change resnapshot, cursor-gap fail-closed behavior, and unsupported-source rejection. that proof does not turn managed-provider provider-native physical recovery into a walwarden claim.