Skip to content

Security

What we can prove, and what we are still working on

You are about to put your customer list, your pricing and your revenue into someone else's software. Here is the honest state of it — including the parts that are not finished.

Shipped and enforced

Row-level security on every table

Tenant isolation is enforced in Postgres, not in application code. Every tenant-scoped table carries RLS policies, and a runtime test suite queries as the authenticated role with forged JWT claims to prove a tenant cannot read another's rows.

Card data never touches us

Payments go through Stripe. Card numbers are entered into Stripe's own elements and we store a token, so the PCI surface stays with the processor.

Role-based access

Six roles out of the box — Owner, Admin, Dispatcher, Salesperson, Technician, Viewer — with thirteen distinct permissions, enforced server-side and again at the database.

Encrypted in transit and at rest

HSTS, a strict content-security policy, and Postgres storage managed by Supabase with encryption at rest.

Signed webhooks and scoped API keys

Outbound webhooks are HMAC-signed. Public API keys are minted per workspace, rate-limited, and revocable.

Audit log

Material changes are written to an activity log per workspace, readable from Reports.

In progress — stated plainly

A security page that only lists wins is not a security page.

SOC 2 Type II
Controls are mapped and documented. The Type II observation window is planned, not complete — we will publish the report when there is one to publish.
Multi-factor authentication
Not available yet. It is on the roadmap and we will not pretend otherwise on a security page.
Offline writes
The crew app requires a connection today and says so when it loses one. Offline write queuing is planned.

Running a security review? Email hello@serviceflowiq.com and we will answer your questionnaire directly. Live uptime is on the status page.

Questions your IT person will ask

Bring them to the call. We would rather answer them up front.