Reports and assurance limits

Review target, dates, performed checks, findings, exclusions and incomplete tasks. Share only evidence appropriate to the recipient.

Framework mappings organise evidence for assurance work. They do not independently establish SOC 2 or ISO 27001 compliance or replace an audit.

Each issued report states what was actually exercised, what was blocked or unavailable and why. Planned checks that did not run are listed as limitations.

A positive assurance is reported only when an explicit control check passed, with a named validator and supporting evidence; for example, a restrictive Content Security Policy, a hard-fail SPF record or a modern TLS configuration. A module that ran and found nothing is listed separately as a no-issue observation. It is not a verified control.

Every assessment run produces a deliverable pack: each promised document, its SHA-256 hash, a manifest and a single pack root. The pack root is signed with your organisation’s Ed25519 key and stored write-once. Each read recomputes integrity, and a document that no longer matches its manifest is flagged and not served as genuine.

Anyone holding the pack can check it without an account through POST /api/assessment-pack/verify. See the proof and retest guide for the request format and offline verification.

The platform includes report and certification verification routes and an offline MCP certificate verifier. A valid signature establishes integrity relative to the associated key; it does not repeat the assessment.

Check issuer, scope and date. A signed static result is not a blanket claim about runtime behaviour, future versions or connected services.

Ask whether the document was altered, what the assessment tested and whether the risk is acceptable. Signatures address integrity; evidence supports coverage; the accountable owner accepts risk.

Collect fresh evidence after material changes. Preserve prior reports for history and make the new scope explicit.