Trumis For organisations

Trumis for organisations / Security

Security & data processing

The procurement view: what Trumis processes and stores when it runs your complaint intake, who can read what, and where the full technical detail lives. The canonical, consumer-facing security page — architecture, data flows, headers, disclosure policy — is at trumis.com.au/security; this page is the organisation-side summary your diligence needs first.

The controlled data design

  • Complete encrypted intake archive. Individual, pilot and licensed-business conversations, structured facts, approved evidence text, generated documents and routing are encrypted before database storage and retained for up to 24 months.
  • Your register holds category codes about your own intake — dispute type, legal grounds passed, circumstance keys, urgency, evidence-class counts, amount bands, risk tier, lifecycle events, and the document reference — in a schema with no free-text columns. It structurally cannot contain anyone's words, and it holds no names or contact details: identity the person chooses to include travels with the complaint to you, not into the register. Rows are readable only through the partner-scoped API, keyed to your licence.
  • Platform administration uses a separate database credential and explicit named administrator allow-list. Cross-organisation reads are attributed and appended to an audit log.
  • Trumis's own statistics plane (anonymous category trends) is a separate store; the two share nothing, and cross-sector statistics never draw on register rows.
  • The intake service record. Processing a turn writes an encrypted intake service record (AES-256-GCM, Sydney), retained for up to 24 months for audited platform administration. It sits behind a separate access role with every read logged, and it is excluded from the register and from all statistics. Raw screenshot pixels and payment secrets are never part of it.

Least privilege, verifiable

  • The intake runtime, tenant reader, platform reader and authentication service use distinct restricted database credentials.
  • The register read role can SELECT the register tables and nothing else; your key resolves your organisation from the registry server-side, and no partner identifier is ever accepted from a request.
  • Schemas, roles and retention functions are public in the repository (docs/register/, docs/complaint-signals/) — the privacy control is structural, not procedural.

Hosting and transport

Functions run in Vercel's Sydney region (syd1); register and statistics stores are Neon PostgreSQL in Sydney (ap-southeast-2). TLS everywhere, HSTS, and the security headers documented on the canonical page. Service state is public at status.

Terms that govern it

  • Privacy policy (one canonical policy for the product): trumis.com.au/privacy — including the organisation's-page section describing exactly what is recorded for your register and what your complainants are told.
  • Terms of use: trumis.com.au/terms — Starter self-serve terms included.
  • Licensed agreements add data-processing terms, support and availability commitments, and origin-locked branding — pricing.
  • Certifications: we are open about not yet holding SOC 2 / ISO 27001 / IRAP; the architecture is small enough to review directly, and we support security questionnaires under licence.

Report a vulnerability

One address for everything, acknowledged within two business days: info@trumis.com.au. Machine-readable policy at security.txt.

Last updated: 23 July 2026