Security controls

Isolated per workspace. Every record carries a workspace id and row-level security is enabled on every application table, so one customer's data is not reachable from another's session. A database event trigger enables RLS on any new table automatically.

Encrypted in transit; encrypted at rest by the provider. All traffic is served over TLS with HSTS. Our managed Postgres provider encrypts data at rest; that is a property of the platform, and we state it as such.

Integration credentials encrypted. API keys and OAuth tokens for connected platforms are encrypted with AES-256-GCM using a key held only on the server, and are never returned to the browser.

Verified webhooks. Inbound webhooks are verified by signature or shared secret before anything is written. A request that fails verification is rejected and the rejection is recorded.

Least privilege by role. Owner, admin, operator and viewer roles gate every action on the server, and the same rule is enforced again by database policy — a role that lacks a permission cannot write the row even if the interface were bypassed.

Audited. Changes to orders, connections, pricing, team access and security settings are written to an audit log with the acting user and time. No user of the application can edit or delete an entry.

No third-party scripts. The application loads no analytics, tag manager, session recording or advertising script, and the Content Security Policy permits scripts only from our own origin with a per-request nonce.

An AI off-switch that actually switches. A workspace can turn the AI features off. The setting is enforced at the single point every model call passes through, before any content leaves — not in the screen that sets it.

Password sign-in. Email and password, with email confirmation on signup and a reset link flow. Leaked-password checking against known breach lists is not yet enabled on our authentication provider.

Two-factor authentication. Available to every login, using a time-based code from an authenticator app. Each person turns it on for their own login under Settings → Two-factor; it then applies wherever that login is used. Once it is on, the code is demanded after the password at every sign-in, and both pages and server actions refuse until it has been given — a password-reset link or an old session cannot skip it. The status is written to the workspace audit log from what the server observes, never from what the browser reports.

Recovery. There are no recovery codes. A person who loses their authenticator is signed back in by a Throughline platform owner removing the factor from their login, which is recorded in the platform audit log. We state this at setup, before the code is entered.

Requiring two-factor for a whole workspace. Not yet. It is the next authentication feature, and it ships together with the recovery path above, because a mandatory factor with no recovery is a lockout waiting to happen.

Single sign-on. Not available. We do not currently offer SAML or OIDC sign-on, and we would rather say so than imply it. It is planned for when a customer needs it, and our authentication provider supports it, so the work is configuration and testing rather than new infrastructure.

SOC 2 report: no. ISO 27001 certification: no. Cyber Essentials: no. Independent penetration test: no.

None of these exists yet, and this page will say so until one does. What we offer in the meantime is evidence rather than attestation: on request we will show a reviewer the row-level security policies on the production database, the credential encryption path in the source, the audit table’s grants, the Content Security Policy as served, and the test suite that holds the public claims on this site to the code.

Email security@throughlineop.co.uk. We will acknowledge within two working days, keep you informed, and credit you if you wish. Please do not test against customer data; a trial workspace is free and is the right place.