Security

What is in place, in specifics, and what is not yet. The same control map our SOC 2 readiness check runs against.

Tenant isolation is enforced in the database

Every table that holds customer data carries row-level security policies, and every request runs under a database role that cannot see another account’s rows even if the application asked. An isolation test suite runs on every change and fails if any table lets a cross-tenant read through.

What we collect, and what we refuse to

Only what is needed to decide which obligations apply. Employee legal names are sealed with a key held by the application, not the database, and read back as a name, an absence, or unreadable, never as plain text at rest.

  • Never collected: Social Security numbers, dates of birth, home addresses, bank details, pay rates.
  • Payroll access tokens are encrypted with a key that only the background worker holds; the web application cannot decrypt one.
  • Reports drop any field that looks like restricted data before they are assembled.

In transit and at rest

TLS on every hop with HSTS on the site, encryption at rest by the database provider, and evidence files in a private bucket that policies scope to the account that uploaded them.

Access

Sign-in is by emailed link; there are no passwords to leak. Roles are one permission matrix checked before every write and enforced again by the database. Our own staff reach your data only through a time-boxed grant you approve, or a flagged emergency access you are told about at once; either is read-only and every step appears in your audit trail.

Evidence and audit

Every change to an obligation, membership or setting writes an append-only audit event that the database refuses to update or delete. Account administrators can export an evidence pack for any period.

Subprocessors

The service runs on Vercel (web hosting), Supabase (database, sign-in and file storage), Inngest (background jobs), Resend (email), Stripe (billing) and, when a company connects payroll, Finch (the payroll connection). Anthropic’s API reads public legal sources for our staff and never receives customer data. Customer data is stored in the United States.

AI, bounded

A model reads public sources such as the Federal Register and drafts for our staff. It never sees customer data, and nothing it drafts reaches a customer until a person has reviewed and approved it.

Where we are honest about gaps

The product is not yet SOC 2 audited, and the rules library is in legal review: every rule shows its review status where you read it. The control map, policies, incident runbook and readiness assessment are kept in the product’s repository and checked mechanically on every change; the assessment lists what remains owner-side, including managed backups with a tested restore and an external penetration test, until each is done.

Reporting a concern

Write to support@usechurro.com with “security” in the subject. A person reads it, and a real finding is acknowledged within two business days.