DocumentationEvidence & usage

Framework evidence exports

Generate scoped reports, verify their seals, and give reviewers a clear account of coverage.

Updated 2026-09-22 Read as Markdown
On this page

Choose the scope

Open Compliance in the console and select the framework, environment, and time range. The catalog maps recorded signals to framework controls and identifies unsupported or out-of-scope areas. A mapping is evidence organization, not a certification.

Evidence generation requires the relevant Team-or-higher entitlement. Browsing the framework catalog is separate from export access. Ordinary decision CSV/JSON export has its own entitlement.

Generate a report

Use the console’s export workflow. Large ranges use async evidence jobs; read completion or failure before downloading. Supported customer routes include /api/v1/compliance/evidence, /report, /composite, /evidence-jobs, and /snapshots.

The synchronous generator has a bounded date range; the async path exists for work that cannot fit the request budget. Snapshot history is a stored report, not a live view of the same period.

Verify the evidence

Keep the original downloaded bytes and seal metadata. POST /api/v1/compliance/report/verify verifies supported report seals. Decision-chain verification and report-seal verification answer different questions.

Read sealed_fields_version and the report’s chain scope. A report may disclose that earlier links were attested by a persisted verification checkpoint while a later range was walked live. Do not describe that as a fresh full-history walk.

Explain limits to reviewers

Preserve coverage, missing-data notes, shadow/billing distinctions, and out-of-scope controls. Framework exports organize product records for your control review. Kastra’s own SOC 2 assurance and GDPR documentation are reviewed separately through the Trust Center and assurance guide.

Assemble a reviewer packet

Include the review objective, workspace and environment, date range, relevant policy revisions, export and seal metadata, verification result, known gaps, and the owner of follow-up actions. Add a representative allowed, denied, and held action where those outcomes are in scope. Explain how each record supports the control under review and which evidence must come from other systems.

Store the original artifact according to your approved evidence-handling process. A successful verification checks the supported seal or chain scope; it does not replace the reviewer’s assessment of control design and operation.

Historical chain assessments

Current single-environment evidence packs use schema and sealed-fields version 4; composite packs use schema version 2. Verification dispatches by the artifact’s recorded version. Retain older artifacts unchanged rather than rewriting them to look like new reports.

POST /api/v1/compliance/report/assess-chain accepts original sealed single-environment pack bytes, within the supported 2 MiB and 93-day bounds, and creates a separate sealed assessment. It binds the original digest/seal, assessment time and chain result. A valid report seal, a content walk, a structural walk and a witnessed historical mismatch are different findings. Reserved erasure classifications do not establish a completed attested-erasure program.