Assurance and audit: proving recoverability inside your own account

This section answers one question for an auditor or a reviewer: how do you prove a backup system is doing what it claims, when the vendor never holds your data, your keys or your Cloudflare tokens? The answer is that every assurance signal downpipes produces is computed inside your own Cloudflare account, over your own observable state, and is offered for you to verify rather than for a vendor to vouch for.

The pages here describe the surfaces that make recoverability provable, and they route you to the right one for the job in front of you. Read this page first if you are orienting; jump straight to a surface if you already know what you are checking.

One sentence frames everything below, and the rest of the section repeats it because getting it wrong is the easy mistake. Every guarantee here is tamper-evident: any alteration that is not a full re-chain is detectable. None of it is the stronger word that would imply alteration is impossible, because the engine runs inside storage a sufficiently privileged holder could rewrite.

What each surface is for

Each surface answers a different part of the prove-it question. The table maps the surface to the question it settles and to its canonical page, so you can route by what you need to evidence rather than by feature name.

The compliance and evidence page, which lines the controls up against named standards, is a mapping exercise and not a certification. No product on this list makes you compliant, and downpipes carries neither a SOC 2 report nor an ISO 27001 certificate. Both are demand-gated, and the assurance the engine produces is an OWASP ASVS 5.0 self-assessment at the Level 2 / Level 3-equivalent bar for its authentication component, evidenced against cited source, not an external attestation.

The honesty boundary, stated once

Four limits run through the whole section. Stating them here means each surface page can be read without re-deriving them, and it means none of them can quietly drift between pages.

The first limit is the meaning of tamper-evident. The audit log is a SHA-384 hash chain, and store-enforced immutability is S3 Object-Lock at the destination. Both make a partial edit, a deletion or a reorder detectable, and the audit log’s exported head hash lets an external verifier detect truncation after an export. Neither makes the underlying storage physically unwritable. A holder of the engine’s own Durable Object storage could rewrite the entire chain, recompute every hash from a forged genesis forward, and that fully re-chained log would still verify. Detection is what is claimed; prevention is not. If you need prevention rather than detection, that lives in the storage layer, which is exactly why the section pairs the chain with bucket-level Object-Lock and treats them as distinct.

The second limit is what the console can assert about a report’s signature. The console reads the signature off a report and checks that it is present and well-formed, with the expected post-quantum hybrid prefix. It does not verify the signature cryptographically, because the verifying public key is not shipped to the browser. Full verification is therefore an out-of-band step you run yourself against the published engine signer fingerprint. The signed reports page gives the exact recipe, and it is honest that an unsigned report is informational, never assured.

The third limit is what an attestation is. An attestation here is an engine-side determination over a sealed run: a valid signature, the completeness of the run’s shards, and the run log’s anti-rollback position. It is never a Cloudflare-side or an object-store-side check, and it never asks the store to vouch for anything. The immutability and attestation page sets out precisely what those facts establish and what they do not.

The fourth limit is how far the canary’s coverage reaches. One flight is capped at twelve destinations (CANARY_MAX_DESTS, engine/src/canary/types.ts), and the truncation runs over the same ordered list every time, so destinations past the twelfth are never flown on any flight. They are also absent from the canary screen: the exclusion is recorded with their labels into the fault ledger and rides in a support bundle, not in the console view. An account holding more than twelve destinations should read a healthy canary aggregate as covering twelve of them, and pin the canary to the destinations it most needs proven. The integrity canary and configure and operate the canary pages carry the detail.

What is wired in the console, and what is engine-side only

Not every surface is a finished console screen today. Being clear about that is part of the honesty boundary, because an auditor needs to know whether they are looking at the whole picture or a partial one.

The canary, the signed reports, the posture score and the audit log are first-class console screens. You can open each, read its state without a click, and act on it where an action exists.

One surface needs more care. The coverage inventory can be recorded from an access-admin or owner account using the Populate inventory action on the coverage view, which posts the reference inventory to the engine. Until an inventory is recorded the portal coverage view reads as honest-unknown rather than green: an absent inventory means the system does not know what exists, never that everything is covered. Point-in-time restore, resolving which run was current as of a chosen moment, is consumed by the restore screen’s own calendar (Browse by date, beside the plain run picker), which marks the days holding a retained run. The portal restore still picks a run by id, whether directly or via the calendar, and recovery is framed as the newest good run rather than an arbitrary moment.

Where this fits

For the standing honest phrasings that bound every claim on these pages, read precise claims and honesty. To understand why the vendor can hold nothing in the first place, read the no-custody trust model. To see how a single backup run is sealed and recorded, which is what every signal here is computed over, read the anatomy of a backup run.

When you are ready to act, the natural first stop for an auditor is signed reports, which produces the artefacts you can take away, and the posture score, which tells you what needs fixing and how.

Last updated 4 August 2026.