Compliance and evidence: framework mapping, not certification
This page sets out how downpipes relates to the compliance frameworks an assessor checks, what the product holds by way of certification, 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.
The position is deliberately narrow and honest. downpipes maps its assurance evidence to the backup and recovery controls of several frameworks. That mapping is exactly that, a mapping, 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 today 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. Adding those regimes adds mappings, it does not change the underlying evidence.
One honest qualification matters when you read a mapping. Some framework articles ask for properties the platform genuinely 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 what the platform verifies and what an operator attests runs through the whole assurance surface, and it is set out for each piece of evidence below.
The certification posture, plainly
The product’s certification posture is short, and stating it plainly avoids any inference that more is held than is.
| Item | Posture |
|---|---|
| OWASP ASVS 5.0 | A self-assessment to the Level 2 / Level 3-equivalent bar for an authentication component, evidenced against source. 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 was carried out as an adversarial code review of the engine’s identity and authentication component, with each control judged against cited source rather than asserted, and no source modified during the assessment. It is a credible Level 2 / Level 3-equivalent self-assessment for that component, and it should be described as exactly that: self-assessed, evidenced, and not certified by a third party.
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, not an oversight, and it is the honest answer to give an assessor who asks.
What downpipes will never claim
It will never claim to be Essential Eight certified, because no such certification exists and ASD says so. It will never claim to be IRAP certified, because IRAP assessors assess systems rather than products. And it will never claim to 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
This is the line worth stating once and clearly. 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. That is the version that survives an audit, and it is the only version downpipes claims.
If a vendor tells you their product is “compliant” or “certified” in a way that removes the obligation from you, that tells you something about the vendor. The obligation does not transfer.
How a reviewer uses each piece of evidence
The assurance surface produces several distinct artefacts. Each answers a different audit question, and each has an honest limit. The table maps the evidence to the question it answers and the caveat to keep in mind.
| Evidence | The question it answers | The honest 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 immutable, 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 is honest-unknown from the portal, 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; control rows claim no more than the compliance pages state, 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 honest limit is the one that matters most to a reviewer. 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 immutable, attributable record. It is hash-chained and signed, so it is tamper-evident, and you export it with its chain head so a reviewer can confirm the export is the whole chain and has not been altered. 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. For that reason it is correct to describe the audit log as tamper-evident and as carrying personal data, and incorrect to describe it as carrying none. 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, each mapped to a named control standard, computed purely over your own observable state. 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 folding them into the genuine 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. Its defining honesty property is that it is unknown by default. When the portal has no inventory it says so, and it never paints an untested or uninventoried resource green to imply coverage it cannot confirm. That honest-unknown stance is what makes coverage usable as an audit scope statement rather than a flattering dashboard. It is described on coverage.
The compliance evidence pack
The newest artefact is 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 exact 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 evidence on this page rests on two foundations worth reading directly. The standing honest phrasings, including why an attested control is never a verified one and why tamper-evident is the correct word, are on precise claims and honesty. The reason the vendor reads nothing, which is what 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 .