Security, data protection and hosting

The page a procurement team opens before a call. Written to answer their questions, including the ones where the answer is 'not yet'.

Keeping customers apart

Every row in the database carries the id of the company it belongs to, and that filter is applied in one central data-access layer rather than being remembered separately by each screen. Site ids that arrive from a browser are proved against the database before they reach a write, not merely checked against what the session claims.

This is the risk we take most seriously, because it is the one that would end the business. It has its own automated test suite, and those tests run against a real database rather than mocks.

Credentials

  • Passwords hashed with Argon2id. We cannot see them and neither can an attacker with a copy of the database.
  • Session tokens, trusted-device tokens, terminal tokens and invitation links are stored as hashes. Stealing the database does not yield a usable token.
  • Sign-in throttles and locks after eight failed attempts.
  • Employee PINs at a terminal lock the badge after five wrong tries, so a four-digit PIN cannot be exhausted by someone left alone with the tablet.
  • Terminal pairing codes are generated with a cryptographic random source and expire after seven days.
  • Signing out also stops that browser being a trusted computer — on a shared office PC, an admin clicking sign out must actually be signed out.

The audit trail

Movements are append-only. Nothing edits or deletes a ledger entry, including us — a correction is a new, opposite entry, so the history of a mistake survives alongside its fix. Balances are a derived cache written in the same transaction as the ledger row, and a nightly job recomputes every balance from the ledger and reports any disagreement.

That is what makes the record worth having in a dispute: it is not simply a number someone could have changed.

Infrastructure

  • Hosted on Railway, UK and EU regions. PostgreSQL, encrypted at rest.
  • TLS everywhere. Cookies are httpOnly, SameSite, and Secure in production.
  • Card details go straight to Stripe and never reach our servers.
  • Payment webhooks are signature-verified against the raw request and rejected if replayed.

What we have not done yet

A security page that lists only strengths is not much use to someone doing diligence. As of August 2026:

  • No SOC 2 or ISO 27001. SOC 2 Type II readiness is on the roadmap. If you need a certificate today, we are not the right supplier yet and we would rather say so now than at the end of a procurement cycle.
  • No SSO / SAML yet. Planned for Enterprise. Today it is email and password with roles.
  • No two-factor authentication yet for back-office accounts. It is on the roadmap and the user model is built for it.
  • No third-party penetration test yet. When one is done we will publish the summary here.

Reporting a vulnerability

Email [email protected]. We will acknowledge within two working days and keep you updated until it is fixed. We will not take legal action against anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before publishing.

Please do not test against other customers' data. Ask us and we will set you up an account to test against.

Data protection

See the privacy policy for what we hold and why, and contact us for a data processing agreement.