Resources / Security pack
The due-diligence answers, assembled once
Isolation, encryption, access control, audit, retention, recovery and release process — written down in the form a carrier’s security review actually asks for.
Including the places our position is weaker than we would like. A questionnaire that answers everything perfectly is the one that gets trusted least.
Request the security packCan you fill in our 90-question vendor assessment?
Yes, and most of it is already written. The pack covers the standard sections directly, cites the mechanism behind each answer rather than asserting a posture, and marks the handful of items where the honest answer is “not implemented” — automated failover and multi-region redundancy among them.
Section by section
What the pack contains
- 01
Tenant isolation and access control
The dual-wall design in detail: session-resolved tenancy, application scoping, forced row-level security, and the entitlement-then-role ordering enforced server-side on every request.
- 02
Data protection
Field-level encryption, the keyed blind index, masking rules by role, write-only credential handling, and log redaction at write time.
- 03
Audit and retention
The single transition door, what is recorded on every write, sensitive-read auditing, the absence of delete paths, and per-organization retention configuration.
- 04
Resilience
Encrypted backups, the scripted restore, weekly verification with the human decryption check, the measured recovery figure, and dead-man alarms — plus the explicit absence of automated failover.
- 05
Change management
The 2,757-test gate, ordered reversible migrations, and the vocabulary checks that fail a build when invoicing and premium billing language cross.
- 06
AI governance
The three governing rules, the entitlement-gated capability list, the per-call cost ledger, and the explicit list of decisions no model is allowed to make.
Known gaps
The items we mark as not implemented
Listing these costs us some deals. It also means the rest of the pack is believable, which is worth more than the deals it costs — particularly with buyers who read carefully.
Automated failover
Not implemented. Recovery is a scripted, timed restore
Multi-region redundancy
Not implemented. Single region today
Published availability SLA
None yet — insufficient operating history to defend a figure
Third-party attestation
Ask us for the current certification position rather than inferring one
Customer offboarding experience
Mechanism documented; no full customer exit has yet been run
Billing Portal screens
In build. The rating and premium billing engines beneath them are complete
On-call depth
Small team. Not a follow-the-sun operations center
How to read a security pack
Ours included. A pack is a set of claims about a running system, and the useful ones can be checked with the engineers who built it in the room.
Claims should be testable
Every mechanism we describe can be examined in a technical session. Ask to see the row-level security policies rather than the paragraph about them.
Absent answers matter most
Read what a pack does not address. A document with no “not implemented” section has either an unusually complete platform or an unusually optimistic author.
It is a snapshot
Positions change as the platform ships. Ask for the current version and the date, and treat anything older than a quarter as history.