Isolation and security
Your firm runs on its own infrastructure, not a row in a shared database
This page describes how FirmHaven is built. It states what is separate for each firm, what is shared, and what the design does and doesn't protect against.
Your firm
your-firm.firmhaven…- Database cluster
- Document bucket
- Encryption key
- Access role
- Work queue
Another firm
another-firm.firmhaven…- Database cluster
- Document bucket
- Encryption key
- Access role
- Work queue
Shared by all firms
The application servers that run the code, the network they sit on, and the control plane that holds the firm directory, sign-up and FirmHaven's own billing. The control plane stores no client data.
Separate for each firm
- Database cluster
- A PostgreSQL cluster created for your firm alone, encrypted with your firm's key. It pauses when nobody is using it.
- Document bucket
- A storage bucket for your firm's files, with public access blocked and versioning on.
- Encryption key
- A key that belongs to your firm and encrypts your database and your documents.
- Access role
- A role that can reach your firm's database, bucket, key and queue, and nothing else.
- Work queue
- Your firm's background work, such as automations and reminders, runs from its own queue.
- Address
- Your firm has its own web address, which identifies the firm on every request.
Shared by all firms
- Application servers
- The servers that run FirmHaven's code are shared. Each request takes the role of exactly one firm before it touches any data.
- Network
- The network and load balancers in front of the application are shared.
- Control plane
- A small directory of firms, used for sign-up, routing and FirmHaven's own billing. It holds firm names and addresses, never your clients' data.
What the design protects against
- A software defect that would otherwise return one firm's records to another, because each firm's data is in a different database reached with a different role.
- A leaked access credential for one firm reaching another firm's documents or database.
- Deleting or restoring one firm without touching any other firm.
What it doesn't protect against
- A compromised staff account at your firm. Use a passkey or an authenticator app, which FirmHaven requires for staff.
- A defect in the shared application servers that runs before a firm's role is chosen.
- Mistakes in what your firm chooses to share with clients or other people.
How we check it
- Every change to FirmHaven runs an automated test in which a request holding one firm's role tries to read another firm's bucket, queue and database. The change is blocked unless every attempt is refused.
- Staff sign in with a passkey or an authenticator app as a second step.
- Traffic is encrypted in transit, and every firm's data is encrypted at rest with that firm's key.
Status: FirmHaven is in development. No independent penetration test or SOC 2 report exists yet. We will publish the dates of both when they are scheduled, and this page will link to the results.