Evidence Package
An evidence package bundles four kinds of evidence for one period — whether the controls hold, where the data physically sits, who reviewed access, and what changed — into a single signed zip file. Unlike a folder a person assembles by visiting four different screens, this zip can prove on its own that its contents are exactly what they were at the time it was built.
1. Requesting one
From a project's (or connection group's) Evidence screen, request a package by specifying:
- Period — a start and end date
- Frameworks — which framework(s) to include a control report for (at least one required)
- whether to include access reviews and audit history (both on by default)
The request doesn't complete immediately — it's registered as a run in the execution history and assembled from there. Assembly can take a few minutes, and the screen shows its progress.
If any single input can't be read during assembly — say, a control report can't be produced, or audit history can't be exported — the request ends as failed, with a reason. A package is never shipped with an empty section: an empty section could be misread by whoever receives it as "nothing happened in that period," when the truth is "we couldn't read it." If the chosen scope has no storage connected at all, the request is rejected outright.
2. What's inside the zip
| File | Contents |
|---|---|
manifest.json | The index — every file in the zip, with its name, kind, size and SHA-256 |
signature.json | A signature over the manifest's digest |
README.txt | The same verification steps as section 3 below, included as a file so the package can be checked without this product at all |
1-controls/<framework>.json/.pdf | One control report per framework — the three indicators and their denominators, every requirement, its basis, and exceptions |
2-data-location.json/.pdf | Each connection's region and storage, the data class table, and original-data availability |
3-access-reviews/<review>.json/.pdf | Every access review completed inside the period, with its per-principal decisions and its own signature |
4-change-history/audit-events.json | Every audit event for that period and scope |
executions.json | Every run recorded in that period (scans, syncs, and so on), with its transitions |
ledger-verify.json | The result of re-verifying the run ledger's hash chain, and where that chain's head stood at that moment |
3. One signature covers the whole manifest
Because every file's name, size and hash is listed in manifest.json, a single signature over that manifest's digest covers the entire package. Verification is two steps:
- Check the files — for each entry in
manifest.json, find the file at that name inside the zip, recompute its SHA-256, and confirm it matches the manifest's value (and the byte count matches too). - Check the signature — serialize
manifest.jsonin canonical form (sorted keys, no extra whitespace, UTF-8), hash it, confirm that value matches what's insignature.json, and verify the signature over that digest.
Nothing outside those two steps needs to be trusted — anyone with a hash calculator and a signature-verification library can do this without any tool from this product. README.txt carries the same steps as plain text, so an auditor whose engagement has ended, or a regulator without access to this screen, can still verify the package.
You can also re-check the run ledger's hash chain via ledger-verify.json — that file reflects the state at the moment the package was built, and since the chain keeps growing afterward, asking the platform to re-verify it later also tells you whether the chain has stayed unbroken since.
4. HMAC and KMS: two signing modes
This product supports two signing modes; which one is in effect is shown both in the package's own signature information and on the Signing key screen.
- HMAC (shared secret) — the platform signs with a secret key. There's no public half to hand out, so a package signed this way can only be verified by whoever holds that same secret — the platform itself. Independent verification means asking the platform operator to check it for you.
- KMS (asymmetric key) — the private key never leaves the platform, but the public key is published in
signature.jsonand on the Signing key screen. An auditor can verify the signature with that public key alone, without asking the platform again.
Either way, the mode is stated directly on the package and on screen, so whoever is checking it always knows up front whether verifying it requires the platform's cooperation or not.
5. Receiving, downloading and verifying
A built package appears identically in the list on the project's (or group's) Evidence screen and on the portal's Evidence menu for an auditor with access. From either place, you can:
- Download — retrieve the zip as-is. A package that isn't ready yet, or that failed, can't be downloaded.
- Verify — re-reads the stored zip and answers three questions separately: does every file in the zip match the manifest, was that manifest signed with this platform's key, and is the run ledger's hash chain from that point still intact today. These are never merged into one answer, because a changed file, a broken signature, and a broken ledger chain are three different problems that call for three different responses.
Someone signed in with auditor access sees only the packages inside their granted scope, and within that scope can list, download and verify all the same as anyone else.
6. Related pages
For what each section of the package actually means, see Controls, Data Location, and Access Reviews; for how the score inside a control report is derived, see Risk Score Explained.