Security Overview

• Per-firm tenancy. Every customer firm is its own workspace. All data is scoped by workspace_id at the database level.
• Postgres row-level security (RLS). Every table has RLS enabled, and the policies are tested by signing in as an ordinary user, not through the SQL editor. The server's own data layer also scopes every query to the signed-in firm.
• Server / client separation. The Postgres service-role key is server-only. A secret scan checks the code that ships to the browser for it on every commit and in continuous integration.

• In transit. All traffic to the application and APIs uses TLS 1.2+. HTTP requests are 301-redirected to HTTPS by the edge.
• At rest. Postgres data and Storage objects are encrypted at rest by our hosting provider.
• OAuth refresh tokens. Gmail and other integration refresh tokens are encrypted before they are written to Postgres using authenticated AES-256-GCM (12-byte IV, 16-byte tag), with a key held in our server environment, never in the database. Short-lived access tokens are stored server-side only. Plaintext tokens never appear in logs and never cross a function boundary that returns to a client.
• Backups. Daily automatic database backups, encrypted at rest.

• Operator authentication. Email and password, or a one-time sign-in link or code sent by email. Sessions use secure HttpOnly cookies.
• OAuth integrations. Gmail and Outlook connect through Google's and Microsoft's OAuth 2.0 authorization-code flows, with a one-time state value checked when the user comes back. We never request a mailbox password and never store one.
• Role hierarchy. Within a firm: owner > workspace_admin > licensed_pa > adjuster_in_training. Role gates are enforced both in the database (RLS) and in the application's data-access layer.
• Contractor access. Contractors (roofers, restoration vendors) get per-claim grants, never workspace-wide access. They never see fee math. What else they see is set per firm: the settlement total shows once a claim is settled unless a firm admin turns it off, and correspondence, inventory and deadlines stay hidden unless a firm admin turns them on.

• Privileged content never enters the AI scanner. Before the AI classifier sees a message, a filter checks the sender against the firm's privilege list, which every firm starts with. This covers new mail and the history import, for Gmail and Outlook. Mail from a listed attorney domain is recorded by sender and subject only; its body is not kept and never reaches the AI. Mail from a listed custody app is discarded. Mail from an address not on the list is treated as ordinary mail.
• AI providers. Email classification, drafting, extraction and the phone line run on Google's Gemini API under ClaimStation's paid account. Roof image analysis runs on Gemini too, and also uses Anthropic's Claude API when that is turned on.
• A person sends. Nothing goes to a carrier without a person: carrier email is drafted into the adjuster's own mailbox and sent from there. Every e-signature request and every phase change needs an explicit click. Once a person has sent an e-signature request, the system emails the signer reminders on days 3, 7 and 13 until it is signed, and scheduled meetings get a reminder an hour before. A firm can also turn on its phone intake line, which emails and texts a new claim's agreement to the caller who asked for it. The AI drafts; the operator commits.

Every claim mutation, every privileged action, every contractor data event, and every admin action writes an append-only audit row recording who did what and when. No user can edit or delete an audit row: the database grants no update or delete on the table. Operators and firm admins can review the relevant audit history in-product.

When a document signed through E-Send is completed, ClaimStation records a SHA-256 fingerprint of the final PDF. Anyone can upload a copy at claim-station.com/verify to confirm it has not changed since it was signed.

• ClaimStation employees access production data only with named-user, MFA-protected credentials and only when necessary to support a customer ticket, investigate an incident, or comply with legal process. Each access is recorded.
• We do not have a "view-as-user" backdoor that bypasses RLS without writing an audit row.

Suspected security events are triaged within one business day. Confirmed incidents affecting customer data are notified to affected operators within 72 hours, including what occurred, what data was affected, and what we are doing about it. Notification of government regulators is provided where required by law.

To report a suspected vulnerability or incident, email security@claim-station.com. We will respond within one business day.

See our Privacy Policy for the current list of sub-processors, what each one receives, and why.

There is no self-serve account deletion or export. Operators may ask us to delete their account, or for a copy of their data, by emailing support@claim-station.com. ClaimStation staff handle each request by hand within 30 days of a verified written request. Claims are never permanently erased: a deleted claim is hidden and kept with its audit trail. Details are at /data-deletion.