Compliance and evidence: framework mapping, not certification
This page sets out how downpipes relates to the compliance frameworks an assessor checks, what certification the product holds, and what it does not. It is written for an auditor or a risk owner deciding what weight to put on the evidence downpipes produces.
downpipes maps its assurance evidence to the backup and recovery controls of several frameworks. The mapping is not a certification. No product makes you compliant. Your organisation owns the control and the attestation; downpipes produces the evidence and shows where it lines up with the obligation you are being assessed against.
Mapping, not certification
The compliance material quotes each framework from its primary source and lines up a requirement against a verifiable product capability. Read it as a map, not a stamp. A map tells you where the evidence sits relative to the obligation; it does not assess your implementation, which is the assessor’s job and yours.
The deepest mappings are the Australian frameworks: the Essential Eight backup control, the Information Security Manual backup and post-quantum cryptography controls, APRA CPS 234 and CPS 230, the SOCI Act and its CIRMP risk-management obligations, and the Privacy Act with APP 11. The same evidence a downpipes run produces is framework-neutral, so it also maps to the backup and resilience controls of the major international and general regimes: ISO/IEC 27001, SOC 2, EU DORA, EU and UK GDPR, EU NIS2, US SEC Rule 17a-4 and the NIST and FedRAMP backup and contingency controls. Each of those regimes reads the same underlying evidence through its own mapping.
Some framework articles ask for properties the platform verifies, and some ask for properties an operator attests. A clean-looking mapping, for example to a recovery-testing article, rests on evidence that is part verified and part attested, so do not read the map as a claim that every clause is independently proven by the product. The distinction between platform-verified and operator-attested runs through the whole assurance surface, and is set out for each piece of evidence below.
Certification status
The product’s certification posture is short.
| Item | Posture |
|---|---|
| OWASP ASVS 5.0 | A self-assessment of the platform: Level 1 met, Level 2 met across the security-critical core, and Level 3 met in substance. Not a third-party certification |
| SOC 2 | Not held. Demand-gated: pursued only if a named deal is blocked on it |
| ISO 27001 | Not held. Demand-gated on the same basis |
| Essential Eight, IRAP | No certification exists to hold. ASD assesses systems, not products, and is explicit that it certifies nothing |
The ASVS work is a self-assessment, not an external audit. It covers the engine, the console, the control plane and the downpipe reader. Each verdict is judged against the literal requirement text and named source evidence, and each met verdict was challenged adversarially. Fourteen requirements depend on runtime behaviour, so they were measured on the running platform. One Level 3 control is accepted rather than met, because Cloudflare Workers offers no trusted-execution environment.
There is no SOC 2 and no ISO 27001. Both are demand-gated, which means downpipes does not hold either and does not pursue one speculatively; it would only be pursued when a specific, named deal is blocked on it. This is a deliberate position for a no-custody, self-hosted product, where the vendor holds no customer system to attest.
Certifications that do not apply
downpipes is not Essential Eight certified, because no such certification exists and ASD says so. It is not IRAP assessed as a product, because IRAP assessors assess systems rather than products. It does not make you compliant: the CPS 234 obligation sits with the regulated entity, the Privacy Act obligation with the APP entity, and the SOCI obligation with the responsible entity. A product can supply evidence toward a control; it cannot deliver the control on your behalf.
No product makes you compliant
No product makes you compliant. downpipes produces evidence and maps it to obligations; your organisation owns the control and signs the attestation. What the product delivers is the evidence that proves the backup and recovery control the way an assessor wants to see it: verified on every run, dated, and exportable.
A product cannot take the obligation from you; it stays with your organisation.
How a reviewer uses each piece of evidence
The assurance surface produces several distinct artefacts. Each answers a different audit question, and each has a limit. The table maps the evidence to the question it answers and the caveat to keep in mind.
| Evidence | The question it answers | Limit |
|---|---|---|
| A signed report | An attestation of behaviour, in one of six kinds | The console does not verify the signature; full verification is an out-of-band step you run yourself |
| The audit log export, with its chain head | An append-only, attributable record of who did what and when | It is tamper-evident (alteration is detectable), and it carries operator identity by design |
| The posture score and its checks | A control-by-control view of the security posture at a moment | Some checks are operator-attested rather than platform-verified; a customer grading (attested pass, compensating control, N/A, accepted risk) is listed distinctly, with the reason, and never presented as a platform verification |
| Coverage | The scope: which resources are protected and tested | It reads unknown until an inventory is recorded, and never shows green for an unknown |
| A compliance evidence pack | A control-by-control view for one named framework: per control the obligation, the supporting capability and the live posture-check result | It supports the obligation and does not certify you, and an unsigned pack is the fail-open fallback |
The signed reports
The engine generates six report kinds over your own account state, in your own Cloudflare account, with the vendor reading nothing. Time-bounded, over a 90-day window by default, are a restore-tests report, an SLA-compliance report and a change records report (the change-controlled action ledger, shown only when the owner has turned on Require Change Number). Point-in-time are an immutability attestation, a posture report and a compliance evidence pack that re-projects the live posture report through a chosen framework’s control mapping. When a signer is configured, each is sealed with the engine’s post-quantum hybrid signer, so the artefact is tamper-evident and an auditor can confirm it came from your engine.
The limit that matters most to a reviewer is signature verification. The console reads a report’s signature and asserts only that it is present and well-formed; it does not cryptographically verify it, because the verifying key is not shipped to the browser. So a report’s figures are not verified in the browser. Full verification is a step you run out of band against your published engine signer fingerprint. An unsigned report, which is the fail-open fallback when no signer is configured, is informational only and is not tamper-evident. The detail of the kinds, the scheme and the verification recipe is on signed reports.
The audit log
The audit log is the append-only, attributable record. It is hash-chained, so it is tamper-evident, and you export it with its chain head hash so a reviewer can detect an edit or a truncation after export. The live chain keeps the newest ten thousand entries and rolls over the oldest, so export before the rollover to keep the full history. It carries operator identity by design: actor emails, source addresses, roles and approver emails are part of the record, because an attributable trail is the point. The audit log is therefore tamper-evident, and it carries personal data. How the chain works and how to export it is on the audit log.
The posture score
The posture score is the control-by-control view. It is a weighted pass fraction over a fixed set of severity-ranked checks, computed purely over your own observable state. Each check maps to a named control standard. The reviewer’s caveat is that not every check is platform-verified: some, such as media diversity, are operator-attested, and the security centre lists accepted and attested checks distinctly rather than counting them with the platform-verified passes. The score, the checks and the attestation flow are on the posture score and risk acceptance and posture regression.
Coverage
Coverage is the scope view: which resources the account holds, which are protected by a downpipe, and which have been tested. It is unknown by default. When the portal has no inventory it says so, and it never shows an untested or uninventoried resource as green. That is what lets coverage serve as an audit scope statement. It is described on coverage.
The compliance evidence pack
In the compliance evidence pack, the engine re-projects your live posture report through a chosen framework’s control mapping, so an auditor reads, for each control, the obligation, the downpipes capability that supports it, and the live result of the posture checks that evidence it. It is point-in-time and signed like the posture and immutability reports, and it carries the standing scope statement that downpipes supports these obligations and does not certify you. Thirteen frameworks are mapped, including the Australian regimes above plus ISO 27001, SOC 2, DORA, EU and UK GDPR, NIS2, SEC 17a-4 and the NIST and FedRAMP controls. The website also publishes a generic, product-to-framework pack for each so a prospect can read the mapping before deploying. The API route, the thirteen-framework id table and how a customer pack differs from the website’s generic packs are on compliance evidence packs.
Where this fits
The reason the vendor reads nothing, which lets every artefact above be your own evidence rather than a third party’s, is the no-custody trust model. For the artefacts themselves, see signed reports, the audit log, the posture score and coverage.
Last updated .