What the auditor receives

DP dashboard · Settings → Auditor access · Audit → Auditor requests
1 · The auditor asks, in control language
1 · The auditor asks, in control language
A named, scoped, expiring link — never the operator's credentials. They pick a framework, controls and period inside their engagement and write one line. Requests outside the engagement are refused by the evidence service, not by the form.
2 · The compliance lead fulfils, with the exact filter in view
2 · The compliance lead fulfils, with the exact filter in view
One click builds the package once, pins the period, records its content digest, and stores nothing. Decline is a click too, with a reason that goes into the chain.
3 · The auditor verifies it on their own laptop
3 · The auditor verifies it on their own laptop
verify.html, from inside the zip. Every row hash, every chain link, every signature against the customer's root, and the package's own signature — recomputed with the browser's cryptography. No network. Nothing installed.
Every step of the exchange — account created, each page opened, the request, the fulfilment, the download, a revocation — is itself a row in the tenant's chain, signed by the evidence service's own identity. The record of who accessed the evidence is evidence.

Verify it yourself, right here

verify.html · the same file inside every package
5,000+ rows verify in a few seconds. Or drop any Hexr package on the page.

Or take it with you

Download the sample packageA real seven-day SOC 2 package from the healthtech tenant, signed by the evidence service. Unzip it, double-click verify.html, drop the zip on it. Hand it to your auditor before we ever talk.