Secure Report is built around one idea: a whistleblowing platform must protect the whistleblower first. The design keeps the reporter’s submission inside a hardened, isolated intake system, and gives your team everything it needs to investigate without ever copying that content out.

​
Design principles

Separation of content and process

The report itself — answers, attachments, the conversation with the reporter — lives only in your organisation’s dedicated intake system. Secure Report holds the case shell: status, severity, classification, activity.

One organisation, one vault

Every organisation gets its own isolated intake instance with its own database and storage. There is no shared pool of reporter data.

Append-only accountability

The audit log is append-only and hash-chained — every entry is linked to the one before it, so any tampering is detectable.

Access is deliberate

Roles are granted by your admin, and each role’s access to screens, actions and case categories is mapped explicitly.

​
What your team sees

Case metadata — reference, status, severity, classification, assignees, timeline.
Live reads of the report — the submission and conversation are displayed on demand, fetched directly from the intake system for authorised roles.
Evidence records — a chain-of-custody register holding file identifiers and cryptographic fingerprints (SHA-256), not the files themselves.

​
What Secure Report never stores

The reporter’s words are never persisted in Secure Report. Report answers, attachments, filenames (which can themselves reveal identity), and reporter messages stay in your organisation’s intake system. Exported PDF reports contain case activity only.

​
Anonymity, honestly

Reporters can submit without any account, email address, or identifying details. Whether a report is truly anonymous ultimately also depends on what the reporter chooses to write — your intake questionnaire and internal handling policies matter. Secure Report’s role is to make sure the platform itself never becomes the leak.