Skip to main content
ioInsureOS
Sign inStart your trial
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 at the platform edge.
  • Core application data is stored on encrypted Google Cloud infrastructure in a dedicated InsureOS project. Google Cloud manages the underlying disk-encryption keys.
  • Per-workspace integration credentials (Twilio, Resend, 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 currently uses email/password. Google OAuth support is implemented but remains disabled until its production client, callback and token-lifecycle tests are commissioned. Session and refresh handling is provided by our self-hosted authentication service in the dedicated Google Cloud project; session lifetimes follow its deployment 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 before accessing tenant data, 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 self-hosted Postgres database as the rest of the application.

Secrets handling

Platform Stripe, transactional-email and database service credentials are stored in Google Secret Manager and injected only into the server runtime. Browser bundles cannot reference them. Per-workspace provider credentials are written from the UI through a server function that encrypts before insert. Provider callbacks are authenticated according to the enabled provider's documented verification scheme.

Data location

Core application, database and file-storage workloads run in Google Cloud's London region. Supporting providers such as DNS/CDN, email, payments and customer-configured integrations may process data elsewhere. Where data is transferred outside the UK/EEA, the transfer terms in our DPA apply.

Backups and continuity

The production data disk has an automated daily snapshot schedule with 14-day retention in Google Cloud's London region. A disk snapshot is not the same as continuous point-in-time database recovery. 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. We assess suspected incidents and notify affected tenant controllers without undue delay when required, so they can meet their own investigation and regulatory-notification duties. We do not present the UK GDPR controller's 72-hour reporting period as a blanket customer-notification promise.

Reporting a vulnerability

Please email security disclosures to hello@insure-os.co.uk. We aim to acknowledge within two business days. Please do not test against other customers' workspaces.