Legal · Security

Security

Draft · current state, reviewed November 2026

The security model starts from one assumption: some of what arrives through these forms is the most sensitive thing a person will ever write down. Everything below exists to keep that content from spreading, and to prove what happened to it afterwards.

01Where data lives

• Hosted on Cloudflare Workers; the tenant database and raw-payload storage are created in a chosen jurisdiction (EU today) and pinned at the infrastructure level.
• Attachments and evidence live in object storage with server-side encryption and bucket locks where retention requires immutability.
• Data residency is selected per organisation; moving a region is a migration, not a toggle, and is documented before it happens.

02Sensitive cases: sealed at intake

• Classification precedes persistence. A submission is evaluated against the sensitivity rules before it is written as a case, so a sensitive report never exists in a half-readable state.
• Sealing moves the content under the named recipient's envelope key, re-encrypts the raw payload, purges watchers, and revokes submitter sessions server-side before anything else in the request runs.
• No reference is returned to a shared device for a sealed submission. In-flight edits are refused and recorded.
• Named recipients, with a backup. Access is bound to a person and a designated alternate, not to a role that an administrator can quietly grant themselves. Reassignments are logged and notified.

03The accountability trace

• Append-only events, hash-chained, with field-level before-and-after values and an actor attribution — person, workflow, or system.
• Verified nightly: every hash recomputed, the chain head anchored to write-once storage, rollback against the newest anchor detected.
• No role can edit or delete an event. Export produces the whole chain plus a verification report.

04Access control

• Role-based permissions with a separate sensitivity layer: holding an admin role never grants access to sensitive content.
• Mandatory multi-factor authentication for staff; forced password change on first sign-in; no shared credentials; session revocation.
• Cross-tenant operations use signed, short-lived assertions with replay protection — not impersonation — and the platform control plane holds no case-content tables.

05Intake protection

• Rate limits and an optional bot challenge on public forms, applied to the standard track only so a challenge can never block a sensitive disclosure.
• The raw payload is stored encrypted before processing, so an accepted submission is never lost to a pipeline failure.
• Failures land in a review queue; they are never silently dropped.

06What we do not claim

We would rather state the boundary than oversell it:

• Platform operators hold infrastructure access. A small number of named engineers can, technically, reach tenant infrastructure. That access requires MFA, is limited in scope, is logged, and is exercised only for support or incident response. We do not claim that case content is unreadable by the operator.
• Deployments are currently performed manually. Automated, CI-only deploys and split-key custody are on the roadmap; until they ship, the person who deploys holds the keys that decrypt sensitive content.
• Independent certification is a goal, not a fact. ISO 27001 and a trusted-execution-environment option are planned; neither is claimed today.

07Reporting a vulnerability

Write to [SECURITY EMAIL] with steps to reproduce. We acknowledge within one business day, keep you updated, and will not pursue legal action for good-faith research that respects privacy, avoids data destruction, and gives us reasonable time to fix before disclosure. We credit researchers who want to be credited.

Please do not test against real submissions or real people's cases. A test organisation can be provisioned on request.