Security & Trust

The most important guarantee we make is that one firm can never see another firm's data, and one client can never see another client's. We enforce this at the database layer using PostgreSQL Row-Level Security, enabled and forcedon every table that holds firm data, with policies anchored to the signed-in member. Access can't leak through an application bug, because the database itself refuses to return rows outside the caller's scope.

Crucially, we don't just claim this — we test it continuously. An automated suite signs in as a real client and a real staff member and attempts cross-firm access, privilege escalation, and cross-client reads and writes, then confirms every attempt is denied. It runs on every single code change; if isolation ever regressed, the build fails and the change never ships.

Only the people you authorize. A client login sees only the specific entities it's been granted (with the ability to exclude individual clients within a family). Firm staff get least-privilege, role-based access — the capabilities to prepare, approve, publish, and manage are granted explicitly — and can be scoped to specific families of clients rather than the whole book.

Sensitive workflows support separation of duties (the person who submits a report can be required to be different from the person who approves it). Firms can enable optional single sign-on (SAML) to manage staff access through their own identity provider, and we never store client or staff passwords — authentication is handled by a dedicated identity provider.

All traffic is served exclusively over HTTPS/TLS, and data at rest — the database and all stored files — is encrypted by our infrastructure providers with industry-standard AES-256.

Reports and documents are never attached to email. Notifications are secure nudges that link back to the portal; files live in private storage and are served only after sign-in, through short-lived signed links that expire within minutes. There are no public URLs.

Reports are versioned and can be routed through an approval workflow before a client ever sees them; prior versions are retained. Every meaningful action — publishing, revising, archiving, deliveries, and each view and download of a client document — is recorded in a per-firm audit trail you can review.

No one credible claims to be unhackable, so we design for defense in depth and to contain impact. Isolation is layered behind authentication and encryption, and because scoping is enforced by the database, even a single compromised session is confined to that one account's data — there is no cross-firm view and no administrative “god mode” over all clients.

Privileged service credentials are used only by server-side code and are never exposed to browsers. If we ever detect a breach affecting your data, we will investigate, contain it, and notify affected firms promptlywith what we know and what we're doing about it.

Relayward runs on Vercel (application) and Supabase (PostgreSQL database, authentication, and file storage), hosted in the United States. Both are independently SOC 2 Type II–certified, so the underlying platform and physical security are audited by third parties. Transactional email is sent via Resend. We keep the current subprocessor list available to customers on request.

Your firm owns its data. We use it solely to operate the service for you — never to train models, sell, or share it. On request we'll provide an export or permanently delete your data.

We're glad to support your vendor review: we'll complete your security questionnaire, walk your technical team through the architecture in detail, and provide a Data Processing Agreement and subprocessor list. Formal third-party assessments (SOC 2, independent penetration testing) are on our roadmap, and we'll publish them here as they complete — we won't claim controls we haven't earned.

If you believe you've found a security issue, please contact security@relayward.com. We take every report seriously and will respond promptly.