Compliance evidence packs
A compliance evidence pack is one of the six report kinds. It takes the same live posture report the engine already computes from your own account state and re-projects it through one framework’s control mapping, so an auditor reads your backup posture in the language of the obligation they are assessing against. It is point-in-time and signed in the same way as the posture and immutability reports.
Every pack states its scope: an evidence pack supports the obligation and does not certify you. It maps what downpipes does to the controls a regime expects, with the live result of each underlying check, so you can show an assessor the evidence. It is not an attestation that you meet the regime, and downpipes is not an auditor.
The thirteen frameworks
The mapping covers thirteen regimes. The ids below are the ones the engine and console use, defined in engine/src/admin/frameworks.ts:
| Id | Regime |
|---|---|
apra-cps-230-234 | APRA CPS 230 and CPS 234 (Australia) |
iso-27001 | ISO/IEC 27001 |
essential-eight | ACSC Essential Eight (Australia) |
dora | EU Digital Operational Resilience Act |
nis2 | EU NIS2 Directive |
eu-gdpr | EU GDPR |
nist-fedramp | NIST 800-53 and FedRAMP backup and contingency controls |
sec-17a-4 | US SEC Rule 17a-4 |
soci-cirmp | Australian SOCI Act and the CIRMP rules |
ism | Australian Government ISM |
privacy-act | Australian Privacy Act |
uk-gdpr-caf | UK GDPR and the NCSC Cyber Assessment Framework |
soc-2 | SOC 2 |
A request for all returns one combined pack covering every framework above.
How a pack is built
The generator (buildEvidencePackReport) is a pure re-projection. It reads the live posture report, then for each control in a framework’s mapping it records three things: the obligation the control states, the downpipes capability that supports it, and the live result of the posture check behind that capability. A control whose check id is not present resolves to not-evaluated. The pack never records a pass for a control it cannot evidence.
A check the Owner has graded carries the grading into the pack, attributed and dated: an attested pass reads “pass (customer attested)”, a compensating control “pass (compensating control)”, a scoping decision “not applicable (N/A)”, and an accepted risk stays “risk accepted”, each with the Owner’s recorded reason as a note on the bound check (for example, “MFA is enforced for all staff at our IdP, recorded by an Owner on a date”). A check the platform cannot verify and the Owner has not yet graded reads “needs attestation”. The per-framework summary tallies these distinctly: passing, failing, customer-graded, not applicable and awaiting attestation, so an assessor sees at a glance how much of the pack is platform-verified versus customer-attested.
From engine 0.3.6 two more statuses appear, and neither counts as passing. “Not met” marks a row that needs a retention lock that is not in force on every destination. A row that binds an administrator is “not met” when the lock is not in compliance mode. “Stated, cannot fail” marks a check that cannot fail. No control the Owner has graded ever prints a bare “fail”; it prints the customer’s determination, labelled as the customer’s.
Because the pack is a projection of the posture report, it inherits the posture report’s freshness: it is a snapshot of the moment it was generated, not a running guarantee.
Getting a pack
The engine serves packs from one route:
GET /admin/reports/evidence-pack?framework=<id|all>[&format=pdf]The framework parameter defaults to all. An unknown framework or report kind returns 404. Without format=pdf the response is the JSON projection; with it, a rendered PDF named downpipe-evidence-pack-<framework>.pdf. A pack is signed when a signer is reachable and is emitted unsigned when one is not, the same fail-open rule the other reports follow, so a missing signer never blocks the evidence.
The customer pack and the website packs are different artefacts
The console downloads a customer-specific, signed pack: it is bound to your deployment’s live posture, and the console offers one pack per framework plus a download-all. The downpipes website carries generic per-framework PDFs for evaluators who want to see the shape of a pack before deploying. The website packs are not bound to any account’s posture, and their download slugs differ from the engine ids for a few regimes (the website uses apra, eu-data-protection, soci and uk where the engine uses apra-cps-230-234, eu-gdpr, soci-cirmp and uk-gdpr-caf). The engine and console ids match exactly; only the website’s public download paths differ.
Where this ships
The evidence-pack report kind ships in the self-hosted engine. Treat it as a property of the engine you deploy rather than as a hosted service the vendor runs on your behalf.
Where this fits
- Compliance and evidence is the narrative home: what evidence downpipes produces and how a reviewer uses each piece.
- Posture score is the report an evidence pack re-projects, and the source of every per-control live result.
- Reports lists all six report kinds and how each is generated and downloaded.
- Coverage and gaps is the inventory-versus-captured view an evidence pack’s coverage control draws on.
Last updated .