Evidence your auditor can check
A proof report shows, for any period, which backups ran and which restores were tested, with signatures an auditor can verify offline using open-source tooling, without access to your systems or your data.
What the report contains
In the dashboard, open Proof report, choose a period and download it. You get a readable summary and a JSON evidence pack with the material behind it:
- For each protected item: its schedule, storage, the number of backups and restore tests in the period, the last passing test and its measured restore time.
- Every signed backup and restore-test statement in the period, failures included. A failed test is recorded, never left out.
- The ledger entries for those statements, with the hash chain and the signed checkpoint that covers them, so missing or reordered entries are detectable.
- RFC 3161 timestamp tokens where a timestamp authority is configured.
- The public keys of the servers that signed, and of the dashboard.
Statements contain hashes, counts, times and check results. They never contain file contents, and the evidence pack doesn’t include storage passwords.
Control mapping
| Framework | Control | Evidence |
|---|---|---|
| SOC 2 | A1.2 Backup processes and recovery infrastructure | Signed backup statements per item, storage location and Object Lock settings, alerts for missed backups. |
| SOC 2 | A1.3 Recovery plan procedures are tested | Signed restore-test statements with each check’s result and the measured restore time. Failed tests are included. |
| ISO/IEC 27001:2022 | A.8.13 Backup copies maintained and regularly tested | Backup and restore-test statements over the period, with ledger proof that none are missing. |
| NIST CSF 2.0 | PR.DS-11, RC.RP-03 Backups protected and tested; integrity verified before use | Content-root check of every restored file, plus each database’s own integrity checks. |
| DORA | Article 12 Backup policies, restoration testing, integrity checks and reconciliation | Row counts compared with backup time, integrity checks, and restore tests on a separate server. |
| NIS2 | Article 21(2)(c) Backup management and disaster recovery | Schedules, outcomes and recovery times for the period. |
| HIPAA | 164.308(a)(7)(ii)(A) and (D) Data backup plan; testing and revision | Exact copies proven retrievable by a content-root match after restore. |
The mapping is a starting point for your auditor, not a certification. Whether evidence satisfies a control is their judgement.
Verifying a report
Download the BackupProof program for any platform from the Download page; it needs no installation or network access to verify. Then check the evidence pack against the dashboard’s public key, obtained from your client through a separate channel:
$ backupproof proof verify-pack evidence-2026-q3.json --key bpkey1:server@backup:…
evidence 2026-07-01 – 2026-09-30: 412 attestations (409 pass, 3 fail), ledger #1873–#2290
✓ all signatures valid, ledger chain unbroken, checkpoint verifiedAny altered, removed or unsigned statement makes verification fail and names the entry. A single proof can be checked the same way with backupproof proof verify; see How it works.
What you have to trust
- The keys. Signatures show which key signed. Confirm the public keys with your client out of band, not only from the report.
- The clock, unless timestamped. Without an RFC 3161 timestamp, times come from the signing server. With one, an independent authority attests the statement existed at that time.
- The code. BackupProof is open source under the MIT license; you can read and build the verifier yourself.
What it doesn’t prove
A passing restore test proves that the data in storage restores, matches what was backed up, and passes the configured checks. It doesn’t prove that the right things were chosen for backup, that the application works end to end on the restored data, or that people know the recovery procedure. Those remain part of the client’s recovery plan.