The parts a security review asks about.
Permissions, audit, isolation and data protection — described plainly, because you should not have to ask.
Roles are assembled, not chosen from a list of three.
Permissions are granular and specific, and roles are built from them, so access can match what someone actually does rather than the nearest preset.
Each workspace is a separate tenant, and a user's access is scoped to the workspaces they have been invited to.
Composed per workspace
Read, create, update, delete
Access granted deliberately
A record of what happened, that cannot be quietly edited.
The audit trail is enforced by the database, not by convention.
Append-only
A trigger blocks UPDATE and DELETE on the audit table outright.
Who, what, before, after
Changes record the actor and the values on both sides.
Failed sign-ins too
Authentication attempts that did not succeed are recorded.
Marked at the row level, never mixed
Sends are mocked, nothing leaves
Try it properly before it touches anything real.
Sandbox mode gives the workspace a parallel set of data. Records created there are marked as such throughout, and never mix with production.
It runs through the same code as everything else, so what you learn in sandbox is true in live — and email sent from sandbox never leaves the building.
Where your data sits, and who is responsible for it.
The full position is in the Terms and the Privacy Policy. The short version:
You are the controller
For the client data in your workspace. We process it on your instructions and nothing else.
Sending is authenticated
Domains are verified, with SPF, DKIM and DMARC configured and a custom return-path available.
Breach notification
Within seventy-two hours of becoming aware, with what is known at the time.
Ask us the awkward questions.
The Terms and Privacy Policy set out the position in full, including our processor obligations.