Security

This page describes controls that are in place today, in plain English. We have deliberately left out anything aspirational: there are no certification claims here, because we do not hold certifications yet. If a control you need is missing, ask us and we will tell you honestly whether it exists.

• Tenant isolation enforced in the database

  Every client table carries row-level security policies keyed to your organisation membership. A client user's query for another organisation's products, volumes, fees, reports or documents returns nothing — the isolation is enforced by Postgres itself, not by the user interface.

• Multi-factor authentication (TOTP)

  Time-based one-time password MFA is available to every user through any standard authenticator app, and is required for our own staff accounts. Staff who have not enrolled are blocked from the application until they do.

• Invitation-only access

  Public self-signup is turned off. New client users are created through an explicit staff invitation tied to a specific organisation and role, and pending invitations can be revoked.

• Enforced password policy

  Passwords must be at least 12 characters and contain both letters and numbers, enforced at signup, at invitation acceptance and on password change. Changing a password requires the current password.

• Append-only audit log

  Sign-ins, organisation switches, data edits, calculations, report generation and filing, document uploads, exports and settings changes are written to an audit table that has no update or delete policy at all. Nobody — including our staff — can alter or erase an entry through the application. Your organisation's owners can read their own organisation's trail.

• Immutable calculation snapshots

  Every fee calculation is stored with its full input snapshot and line items, and a database trigger rejects any attempt to change a stored calculation. A number you saw last season can always be reproduced and explained.

• Filed reports are locked

  Once a report is marked filed, a database trigger prevents editing or deleting it. Corrections are made by generating a new, linked amendment version, so the original filing and the amendment both survive.

• Encryption in transit and at rest

  All traffic is served over TLS. Database and uploaded-file storage are encrypted at rest by the managed cloud platform we run on. Evidence and report files live in private buckets and are served only through short-lived signed URLs.

• No card data stored

  We do not collect or store payment card numbers. Online payment is not currently enabled; plans are set manually by our team.

• Session controls

  An inactivity timeout signs users out automatically, and the user menu shows the account you are signed in as together with your previous sign-in time so an unexpected session is easy to spot.

• Error visibility

  Uncaught interface errors are recorded with the route and browser type, rate-limited per user, and reviewed by our staff. Error records do not include your packaging or financial data.