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. Each signal 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 to a surface if you already know what you are checking.

Every guarantee here is tamper-evident: any alteration that is not a full re-chain is detectable. None of it makes alteration impossible, because the engine runs inside storage that 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 the page that covers it, 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. 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. The assessment is evidenced against cited source, not an external attestation.

Four limits across the section

Four limits run through the whole section.

The first limit is the meaning of tamper-evident. The audit log is a SHA-384 hash chain, and store-enforced immutability is the destination store’s own retention lock, such as S3 Object-Lock.

Both make a partial edit, a deletion or a reorder detectable. 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. The chain detects an alteration; it does not prevent one. Prevention lives in the storage layer, so 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 recipe, and it states 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 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. From console 0.2.7, the canary screen names them below the destinations it flies to, and its destination count reads, for example, “12 of 15”. The engine also records the exclusion with their destination ids in the fault ledger, which rides in a support bundle. 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, and 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 using the Populate inventory action on the coverage view. An access-admin, an owner, or a custom role that holds access.policy sees that action. The action posts the reference inventory to the engine. Until an inventory is recorded the portal coverage view reads 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). The calendar marks the days with a successful run in the downpipe’s recent-run history. The portal restore picks a run by id, whether directly or via the calendar, so recovery is framed as the newest good run rather than an arbitrary moment.

Where this fits

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 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 25 September 2026.