Trumis for organisations / Security

Security & data processing

This page is written to answer a vendor security questionnaire before you have to send one. It is specific, and it is honest about what Trumis does not have. Trumis is a small company; our view is that a small vendor who answers precisely — including on its gaps — is easier to assess than a large one who answers in boilerplate. If a question here is not answered well enough to satisfy your process, tell us and we will answer it directly.

Where your data lives · Encryption · Subprocessors · Retention & deletion · Getting your data back · Access control · Certifications · Availability & incidents · Vulnerability disclosure · The two-sided question

1. Where your data lives

Application compute runs on Vercel, with functions pinned to the Sydney region (syd1). All persistent storage is Neon PostgreSQL in Sydney (ap-southeast-2). Your complaint records, your register, the administrator authentication store and the webhook delivery queue are all in that one Australian database, separated into schemas with distinct least-privilege roles.

One flow leaves Australia, and we would rather you heard it from us. The conversational layer — the part that phrases replies while a person is telling their story — sends the turn text to Anthropic or OpenAI, which process in the United States. Voice input, when a person uses it, is sent to OpenAI for transcription and discarded after processing. Nothing else about your intake leaves the country. If a US processing flow is disqualifying for your sector, say so early: the deterministic rules engine can serve every turn without any AI provider configured, and we would rather scope that with you than discover it at contract stage.

2. Encryption

• In transit. HTTPS everywhere with HSTS (two-year max-age, subdomains included); plain HTTP redirects permanently. Database connections are made with sslmode=verify-full, so the certificate chain and hostname are both verified rather than merely encrypted.
• At rest. Every server-processed intake request and response is encrypted with AES-256-GCM in the application before it reaches the database — so the ciphertext is what the database holds, not merely an encrypted volume underneath it. Administrator TOTP seeds are encrypted the same way. Passwords are stored with scrypt (N=2¹⁷, r=8, p=1).
• Who holds the keys. Trumis does. The intake encryption key is a server-side secret held in our deployment environment, never in the database beside the data it protects and never in any client. We do not offer customer-managed keys today. If your procurement requires them, that is a real gap and we would rather discuss it than let you assume otherwise.

3. Subprocessors

The complete list, with what each one touches. We will notify licensed partners before adding a subprocessor that touches complaint data.

The two AI providers are the only subprocessors that receive the text of a complaint. Everything else on this list touches infrastructure, our own mail, or aggregate counts. Trumis's own outbound business correspondence is carried by a third-party mail provider that likewise never receives complaint content; it is named in the data processing agreement rather than here, because it processes nothing belonging to your organisation.

4. Retention and deletion

• Your schedule, not ours. Records created through your intake are retained to your organisation's regulatory schedule. The default for regulated sectors is seven years, which meets the NDIS complaint-record expectation and the equivalent aged-care and financial-services positions. It is a per-licence setting; tell us your obligation and we configure it.
• Legal hold. A record under hold is never deleted by the expiry process, whatever the schedule says. Hold can be applied across your whole account or to an individual matter. The mechanism is structural — the deletion query cannot select a held record — rather than a procedure someone has to remember.
• Deletion is evidenced. When a record reaches the end of its schedule it is deleted, and the deletion is written to a log in the same database transaction: your organisation, the record reference, the date it was created, the date it expired, and the policy applied. We can produce a certificate of deletion from that log on request.
• Consumer records are separate and unchanged. A person using Trumis for themselves is governed by the consumer policy — up to 24 months — described at trumis.com.au/privacy.
• Statistics. The anonymous category-profile store keeps raw rows for no longer than 24 months and then reduces them to monthly aggregates. That store has no free-text column, so it structurally cannot hold anyone's words.

5. Getting your data back

Everything that enters Trumis can leave it, machine-readably, from the moment it is finalised — and you can take all of it with you if you leave. This is deliberately not a support request:

• Any single complaint as structured JSON — the claims the person confirmed, the facts established, the grounds that passed, the urgency assessment, an evidence manifest with a content hash per item, and the complete document — or as a PDF of the formal document.
• Your whole register as a CSV with the column names a regulator uses, not database names.
• A complete archive — every record, every document, the register and your deletion log — from one authenticated request.
• Pushed to you as it happens, if you prefer: one signed webhook fires when a complaint is finalised, HMAC-SHA256 over the timestamp and raw body, with replay protection, automatic retries and a delivery log you can read.

The interfaces are documented at developers → exports. There is no offboarding fee and no professional-services engagement required to leave.

6. Access control

Who at Trumis can read your records, and under what conditions. Only named individuals on an explicit allow-list. An address must appear in both the administrator account store and the configured allow-list; removing it from either fails closed on the next request. Trumis is a small team, so the honest answer is that this list is short — we would rather tell you that than describe an access governance committee that does not exist.

• Authentication. Three methods, all with a second factor: password plus TOTP, one-time email link plus TOTP, or a WebAuthn passkey with user verification required. New administrator accounts start in forced enrolment — no session is issued until TOTP is verified and the temporary password replaced. There is no public account registration.
• Sessions. An opaque eight-hour cookie, HttpOnly, Secure, host-only, SameSite=Strict. Credentials are never written to local or session storage.
• What is logged. Every administrator read of intake data and every cross-organisation register read is appended to an audit table with the actor, the action, the number of records returned and a request id. Authentication events are logged separately. Log entries cannot be edited by the roles that write them.
• Your own access is isolated by the database. Your API key resolves your organisation server-side; a partner identifier is never accepted from a request. PostgreSQL row-level security then enforces the boundary a second time and fails closed if the tenant context is absent.

7. Certifications

Trumis does not hold SOC 2, ISO 27001 or IRAP. We are not going to imply otherwise. Independent assurance is on the roadmap and we will discuss timing under NDA; we would rather commit to a date with you than publish one we might miss.

What we offer instead, now:

• Completed security questionnaires returned within five business days.
• A data processing agreement on request. We hold a standing template rather than drafting one per engagement, so it can be with you the same day. It covers the Privacy Act processor obligations, subprocessors, cross-border disclosure, notifiable data breaches, retention and deletion, and — for APRA-regulated counterparties — the matters CPS 230 expects to see in an agreement with a service provider.
• A walkthrough of the actual data paths with whoever is assessing us. The architecture is small enough to review directly, which is a real advantage of assessing a vendor this size.
• Support for your own penetration testing of a pilot deployment, scoped in writing beforehand.

8. Availability and incidents

• Posture. Serverless functions behind Vercel's edge network, with the database on Neon's managed PostgreSQL. Live service state is published at trumis.com.au/status, backed by a health endpoint you can poll yourself.
• Backups and recovery. Neon's managed PostgreSQL provides point-in-time restore, with the history window set per project. We give the exact window, and the recovery point and recovery time objectives that follow from it, in our security questionnaire response and in the data processing agreement — where we can state a number for your deployment rather than a general one. We would rather answer that precisely to you than publish a figure here that drifts.
• Incident notification. If we become aware of a security incident affecting your data, we will notify you within 72 hours of becoming aware, with what we know at that point rather than waiting for a complete picture. Australian notifiable data breach obligations apply to us and we will meet them.
• No formal uptime SLA today. Licensed agreements carry availability commitments; ask for the current wording rather than assuming a number.

9. Reporting a vulnerability

Email info@trumis.com.au with enough detail to reproduce. We acknowledge within two business days, keep you informed while we fix confirmed issues, and credit reporters who want credit. We will not pursue good-faith researchers. Please do not access other people's data, do not degrade the service, and give us reasonable time to fix before disclosing. Machine-readable policy at security.txt. There is no paid bounty programme at this time.

10. The two-sided question

You will find it yourself, so here it is first: Trumis also runs a free complaint service for individuals at trumis.com.au. Some of those complaints are about organisations. It is fair to ask what that means for you.

The records are segregated. Every record carries the scope it was created under. Your API key can only ever reach records created through your own intake — the database enforces that with row-level security, not just application logic — and a consumer's own record is not reachable by any organisation. Your register is built from your intake alone.

And the shared part is the part that helps you. The same engine that helps a person write a clear, specific, evidenced complaint is what makes complaints arriving at your team cheap to resolve. A complaint that says what happened, when, with what evidence, and what outcome is sought does not need three rounds of clarification. The reason Trumis is worth having on your complaints page is precisely that it was built to serve the person writing the complaint — a vendor that only optimised for the organisation would produce complaints your team cannot action.

Every factual claim on this page is verifiable against the code and infrastructure. If you want to check one, ask — info@trumis.com.au — and we will show you where it lives.

Last updated: 28 July 2026