RESTORE EVIDENCE — VERIFY IT YOURSELF

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

here's the evidence — verify it yourself. a real Evidence bundle from a demonstrated restore drill, signed with Ed25519. no signup, no sales call, no trusting us.

download the bundle verify it

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 @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: audit chain intact through seq=8 (8 audit events)
OK: 1 manifests verified, 8 audit events chain-intact

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 bundles are signed with the production key published at /.well-known/walwarden-pubkey.pem.

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.