Skip to content
SARC

Evidence export

The evidence export is the closing demo moment: a regulated organisation’s auditor wants a packet they can sign off on. SARC produces one — per framework, per date range — in one click.

Surface

Section titled “Surface”

Route: /t/<tenant>/compliance/evidence.

ADMIN-only. Rate-limited (5 exports per hour per tenant — in-memory; Redis-backed distributed rate limit is a roadmap item).

The form takes:

  • Framework — pick one of: SOX, PCI_DSS, PSD2, DORA, ISO27001, NIST_800_53, SOC2
  • From / To dates — typically last quarter or last 30 days

Click Generate evidence pack → JSON manifest streams + single-page summary PDF downloads.

What the pack contains

Section titled “What the pack contains”

The JSON manifest is sealed with a SHA-256 envelope + HMAC and includes:

  • The control catalogue for the chosen framework (ComplianceControl rows)
  • Every DeploymentRecord in the window
  • Every AuditLog row in the window (hash-chained, tamper-evident)
  • All vulnerabilities present at the start / end of the window
  • All Kosli attestations consumed in the window
  • All ServiceNow change requests that targeted this tenant in the window
  • All ServiceNow problem records in the window
  • The seal: SHA-256 of the manifest content + HMAC

The PDF is a single-page human-readable summary that fronts the JSON. The PDF is what your auditor opens; the JSON is what they request for digital evidence.

Tamper-evidence chain

Section titled “Tamper-evidence chain”

The portal’s AuditLog is hash-chained: each row carries entryHash = sha256(prev_entryHash || row_content). POST /api/audit/verify-chain walks the chain and reports the first row (if any) where the chain breaks. The evidence pack includes a fresh verifyAuditChain result at export time.

If your auditor wants to re-verify weeks later: they have the JSON manifest (with its seal). They can re-run verifyAuditChain on the live AuditLog and confirm the chain still passes; the JSON’s seal proves the manifest itself wasn’t tampered with after export.

Per-framework usage

Section titled “Per-framework usage”

Each framework’s evidence pack looks structurally identical but is filtered to that framework’s controls. So:

  • DORA export: all 7 DORA controls + the trail evidence supporting each
  • PSD2 export: all 7 PSD2 controls — including Article 95 incident reporting + Article 97 dynamic linking
  • SOC 2 export: 7 Trust Service Criteria controls (CC + A) — a typical vendor due-diligence packet
  • ISO 27001 export: 7 Annex A controls
  • NIST 800-53 export: 7 Rev 5 control mappings

A bank that needs to satisfy DORA + PSD2 + ISO + SOC 2 runs the export 4 times (or scripts it via API).

API form

Section titled “API form”

Same surface as the UI:

Terminal window
curl -X POST 'https://<portal>/api/compliance/evidence/generate?tenant=demo' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: next-auth.session-token=<admin-session>' \
  -d '{
    "framework": "PSD2",
    "from": "2026-01-01",
    "to":   "2026-03-31"
  }' \
  -o evidence-psd2.zip

Response is a ZIP containing both the JSON manifest and the PDF summary.

Limits + roadmap

Section titled “Limits + roadmap”
  • 5/hr/tenant rate limit, in-memory (not distributed yet) — see #310
  • 15 MB byte cap on the rendered PDF — typical output is 50–200 KB
  • Single-page summary — multi-page evidence reports are a roadmap item

See also

Section titled “See also”