Hosting and security answers, up front.
Everything below is published because a security review shouldn't require a sales conversation. If your review needs something that isn't here, tell us and we'll publish that too.
No form. No email required.
Hosted in the region your data belongs to
Tenant data — database and documents — is bound to the region the tenancy is created in and does not leave it in normal operation. Dedicated environments are stood up in the region you name. These are the regions we operate in or are prepared to stand up for a design or implementation partner; each has every managed service the platform depends on.
- Sydney, Australia ap-southeast-2 · live today
- Singapore, Singapore ap-southeast-1
- Tokyo, Japan ap-northeast-1
- Mumbai, India ap-south-1
- Frankfurt, Germany eu-central-1
- Dublin, Ireland eu-west-1
- London, United Kingdom eu-west-2
- Paris, France eu-west-3
- Montréal, Canada ca-central-1
- N. Virginia, United States us-east-1
- Oregon, United States us-west-2
- São Paulo, Brazil sa-east-1
Shared (per-user plan) infrastructure runs in Sydney today. A dedicated environment elsewhere on this list is provisioned for the partner that needs it, as a controlled build with the same gates as our own — not a switch. Residency for a group spanning more than one region is designed into the model and is on the roadmap, stated as roadmap.
Tenant isolation
Every tenant's data lives in its own database — not in shared tables separated by a tenant column. Isolation is structural, enforced by the database boundary, and the same primitive applies on both plans.
On the per-user plan, tenant databases share a managed cluster. On a dedicated infrastructure plan, the cluster itself is yours: your own database cluster and your own application compute, provisioned for your tenancy alone, in your region.
Documents are stored in a bucket per tenant, in the tenant's region. Object keys carry no customer data.
How access is decided
Every read and write — in every app, shipped or built — passes the same evaluation, in the same order:
- Sensitivity first. Records carry a sensitivity level — Unrestricted, Internal, Restricted or Confidential. If your role doesn't clear the level, nothing further is evaluated.
- Then scope. Access is trimmed to your place in the organisation structure — a division sees its own records, the group sees the aggregate. Scoping applies at every sensitivity level, and a query returns exactly the set you're permitted, with no counts leaking from outside it.
- Then the record itself. Role-based grants on the individual record are checked last. Writes always require an explicit privilege — there is no implied write access anywhere.
Permissions are additive only — there are no deny rules to reason about, so what you can access is the union of what your roles grant, and nothing else. If any part of this evaluation fails or errors, access is denied. The system fails closed. That the list you are shown and the set you may act on come from one decision is a property we test automatically, not a sentence we wrote.
What is recorded
Every change is attributable — who, what, when, effective from when. Reads of sensitive records are logged synchronously: the data is not returned unless the read has been recorded first. That is an unusual guarantee, and it is the one an investigator actually needs.
Changes to the system itself — a new field, a new app, a rule — are governed the same way: drafted, reviewed, published, attributed. The AI builder's drafts are no exception; it cannot publish.
Your identity provider, your rules
Sign-in is through your identity provider over OpenID Connect; users are provisioned and deprovisioned through SCIM. Multi-factor authentication and conditional access are enforced where you already enforce them — at the identity provider — rather than re-implemented inside the product.
If you work with an implementation partner, their access to your tenancy is granted by you, scoped like any other user's — the same sensitivity levels and organisation scoping apply, with nothing special-cased — and revocable by you at any time. Only you can change your partner of record.
Who touches the data
| Sub-processor | Purpose | Location of processing |
|---|---|---|
| Amazon Web Services | Application hosting, document storage and email delivery | The tenancy's region (Sydney, ap-southeast-2, today) |
| MongoDB Atlas | Managed database | The tenancy's region, on AWS (Sydney today) |
| Amazon Cognito (AWS) | Sign-in and identity federation — credentials and session tokens only, no tenant records | Ireland (eu-west-1) |
That is the whole list. This website itself sets no cookies and makes no third-party requests — check the network tab; we did. The list is maintained at /legal/sub-processors and dated when it changes.
What we have, and what we don't. Honestly.
What we don't have yet: ISO 27001 or SOC 2 certification, and no audit in progress. We are early; certification is sequenced spend with a defined trigger, and pretending otherwise on this page would tell you something worse about us than the absence does.
What we are doing: the scope for an independent penetration test is written, aimed squarely at cross-tenant isolation — the property this architecture stakes everything on. It is not yet complete; the report will be available to evaluating organisations on request once it is. The ISO 27001 programme follows; dates are published here as they are committed, not before. Our security overview names the mechanism behind every claim it makes, so an engineer can check it.
What we'll never do: claim a certification we don't hold, show a badge we haven't earned, or gate this page behind a form once the certificates arrive.
You can leave
Full export of your tenancy — records, documents, configuration and audit trail — in open formats (JSON and CSV for data, original formats for documents), on request, at any time, with no exit fee. The export exists so that choosing to stay is a decision, not a trap.