Skip to main content
ioInsureOS
Sign inBook a demo
InsureOS

Security

InsureOS handles policyholder personal data and broker records. This page describes the controls that are implemented in the product today. It is maintained by FOUR GEARS LTD and is a description of our own practices, not an independent audit, certification or assurance report.

Tenant isolation

Every domain table (leads, interactions, policies, commissions, audit logs, billing) carries a tenant_id column, and Postgres row-level security is enabled on those tables with policies that check the caller's membership in user_roles before returning rows. Isolation is enforced in the database rather than only in application code. We test this with an automated cross-tenant suite, but no control is a guarantee — please report anything you find (see below).

Encryption

  • Traffic to the application is served over HTTPS/TLS by our hosting provider.
  • Database storage is encrypted at rest by the underlying managed platform. Key management is performed by that platform, not by us.
  • Per-workspace integration credentials (Twilio, SendGrid, Meta, OAuth tokens) are encrypted with a server-side INTEGRATION_ENC_KEY before being written, and only a masked last_four is returned to the UI.

Authentication

Sign-in supports email/password and Google OAuth. Session and refresh handling is provided by the managed auth service; session lifetimes follow that service's configuration rather than a fixed duration we advertise here. The _authenticated layout gates protected routes in the browser, and every protected server function independently re-validates the bearer token via requireSupabaseAuth, so an expired token cannot read data even if the UI has mounted.

Authorization

Roles live in a dedicated user_roles table — never on the profile row — and are checked via a security-definer has_role() function inside policies. Server functions that perform privileged work (role grants, retention sweep, admin reads) explicitly verify tenant_admin or super_admin before loading the service-role client.

Audit logging

Inserts, updates and deletes on audited domain tables write to audit_logs with the actor, before-state, after-state and lead correlation id. The application exposes no route to edit or delete those rows and they are visible to managers under Audit log. We do not claim write-once or tamper-proof storage: the records live in the same managed Postgres database as the rest of the application.

Secrets handling

The Stripe secret key, SendGrid global secret, and Supabase service role key are stored as server-only environment variables. Browser bundles cannot reference them; static analysis blocks VITE_-prefixed leaks. Provider credentials are written from the UI through a server function that encrypts before insert.

Data location

The application, database and file storage run on our managed cloud provider's EU region. We do not currently operate UK-only hosting, and we do not claim it. Where data is transferred outside the UK/EEA, the transfer terms in our DPA apply.

Backups and continuity

Database backups are taken and retained by the managed platform on its standard schedule. We have not published a tested recovery-time or recovery-point objective and do not offer one contractually.

Compliance posture

We hold no security certifications today — there is no SOC 2 report, ISO 27001 certificate or completed independent penetration test to share, and we will say so plainly rather than imply otherwise. The features below are implemented in the product to help you meet your own obligations; the regulatory obligations remain yours.

  • UK GDPR — right to erasure, self-serve data export (Article 15), consent capture, and an automated retention sweep configurable per workspace.
  • PECR — opt-in is checked before SMS and email send; STOP / unsubscribe handling is processed inbound.
  • FCA conduct — advised interactions are logged with timestamp, channel and actor. Four Gears Ltd is a software provider, not an FCA-authorised intermediary. Customers remain responsible for their own regulated activities.

Incident response

Security-relevant events land in error_events with severity and surface, visible to super-admins. Reportable incidents are triaged within 24 hours and notified to affected tenant admins within 72 hours, in line with UK GDPR Article 33.

Reporting a vulnerability

Please email security disclosures to info@fourgears.com. We aim to acknowledge within two business days. Please do not test against other customers' workspaces.