Compliance evidence

An auditor does not want a screenshot. They want a control, a time window, and a way to check the evidence themselves.

Whisper turns identity, resolution, egress, and logging into a machine-readable control grid, sampled period by period, with every cell anchored to a public transparency ledger. You read your own grid with your key. Your auditor checks the same evidence keyless, against the ledger, without an account and without trusting the console.

This is the evidence layer behind the framework mapping on the Compliance page. That page says which frameworks Whisper helps with; this one is the grid and its provenance.

The controls Whisper evidences

Ten controls across SOC 2 and ISO 27001, each backed by a capability that is either in force for a tenant or it is not, evaluated every period:

Your grid, with your key

The keyed grid returns every control across a rolling window of periods, with a status per cell and the provenance of that cell:

// GET https://whisper.online/api/compliance/evidence  (X-API-Key: your partner key)
{
  "generatedAt": "2026-07-20T08:47:08Z",
  "periods": [ { "id": "1784536800000", "from": "2026-07-20T08:40:00Z", "to": "2026-07-20T08:45:00Z" }, … 24 periods … ],
  "controls": [
    {
      "framework": "soc2",
      "controlRef": "CC6.1",
      "title": "Logical access restricted to authorized identities (DANE-pinned per-agent /128)",
      "status": "not_applicable",
      "periodId": "1784536800000",
      "provenance": {
        "leafId": null,
        "entriesReceiptUrl": "https://whisper.online/entries/8ea7cfad…78e140c",
        "inclusionProofUrl": null
      }
    }
    // … one row per control per period …
  ]
}

A cell reads in_force when the capability was demonstrably active for that period, or not_applicable when the tenant exercised nothing that the control governs. An in-force cell carries a leafId and an inclusionProofUrl pointing at the exact ledger leaf that proves it.

Your auditor, with no key

Every tenant also has a keyless evidence index: the coordinates of its anchored evidence in the public ledger. No key, no account, and no customer identity, only the opaque tenant slug also published in RDAP:

// GET https://whisper.online/compliance/tc76deaa651427ca97c760ab3302c3e9d/evidence
{
  "object": "compliance-evidence-index",
  "tenant": "tc76deaa651427ca97c760ab3302c3e9d",
  "tree_size": 4322,
  "count": 100,
  "evidence": [
    {
      "leaf_index": 462,
      "id": "3dfc61063993deb7f18d42c57a26a50d375910ebfa1e8c6596436e6c1ce796c5",
      "receipt": "/entries/3dfc61063993deb7f18d42c57a26a50d375910ebfa1e8c6596436e6c1ce796c5",
      "inclusion": "/inclusion?leaf=462"
    }
    // … 100 coordinates …
  ]
}

Each coordinate is a receipt (the signed SCITT inclusion receipt) and an inclusion link (the RFC 6962 audit path). Follow either and fold it to the signed checkpoint: the same keyless carrier-verify chain that anchors every Whisper identity and evidence receipt, applied to a single evidence statement. The console never has to be trusted, because the evidence proves itself.

Say it exactly like this

Whisper is a control and evidence layer inside your program. It provides a control, gives audit evidence toward a requirement, or complements the sector's own PKI. It never makes you or your client compliant or certified, and it never guarantees compliance. Your auditor does that. This is the evidence you and your clients hand your auditors.

Next: Transparency log the ledger every cell anchors to · SCITT receipts the signed inclusion receipt format · Compliance the full framework grid · MCP server trust the keyless verify tier for MCP hosts.