Security

Every firm's data is isolated at the database layer using PostgreSQL Row-Level Security (RLS) with FORCE ROW LEVEL SECURITY on every business table. A query can only ever see rows belonging to the firm whose tenant context is set for that transaction — the isolation is enforced by PostgreSQL itself, not only by application code. The tenant context is set per-transaction (SET LOCAL), so it cannot leak across requests sharing a connection.

• In transit: all traffic is served over HTTPS. We send an HTTP Strict Transport Security (HSTS) header with a two-year max-age and preload, so browsers refuse to connect over plain HTTP.
• At rest: the PostgreSQL database and the object storage that holds generated evidence-pack PDFs are encrypted at rest by our infrastructure providers (Railway and Cloudflare R2).

• Sign-in is provided by Better Auth and supports two modes: an email magic-link (the link itself authenticates — no password is sent or stored for users who choose this mode) and an email and password mode. Passwords used with the second mode are stored only as a one-way hash; the plaintext is never written to the database, logged, or transmitted to any third party.
• Email verification is required on every new sign-up before the dashboard becomes accessible.
• Session cookies are HTTP-only and secure, and authentication endpoints are rate-limited to slow credential-stuffing and email-bombing.
• Declaration and counterparty recipients complete their forms through single-use, expiring tokens — no account is created and tokens cannot be replayed.

Every server action resolves the caller's authenticated session to exactly one firm before touching data, and all queries run inside that firm's tenant context. There is no client-trusted authorisation: the server decides what a request may see on every call, backed by the database-level RLS described above.

Security- and compliance-relevant events are written to an append-only audit log. Each entry is chained to the previous one with a SHA-256 hash, so any tampering breaks the chain and is detectable. The database revokes UPDATE and DELETE on this table — there is no code path, for anyone, that can modify or remove an audit record. These properties are what make the trail suitable for legal and regulatory proceedings.

• A strict Content-Security-Policy plus X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy headers on every response.
• All database access goes through a typed query builder (Drizzle ORM) with parameterised queries — no string-concatenated SQL.
• Request input is validated against strict schemas (Zod) at the boundary.
• Sliding-window rate limiting on authentication, declaration, and action endpoints.

We welcome reports from security researchers. See our responsible-disclosure policy for scope and a safe-harbour commitment, or read our security.txt. Report issues to security@coverproof.co.uk.

We believe a compliance vendor should be candid about what it has and has not yet done. As of the date above, CoverProof does not hold SOC 2, ISO 27001, or any third-party security certification, and has not yet commissioned an independent penetration test. We will not imply otherwise.

Our planned roadmap — clearly labelled as a roadmap, not a current state — is set out in the Trust Centre.