We don't pursue a SOC 2 report. We'd rather spend the effort on the product than on a binder of policies. But “we don't have one” is not the same as “we can't answer for it,” so we had an AI model run the gap analysis honestly: every Trust Services Criterion, what the code already does, and what a real attestation would still need. The technical controls are strong. The governance paperwork is a deliberate gap.
This report was generated by Opus 4.8 (1M context) reading our codebase against SOC 2 Trust Services Criteria. It records a pass or fail for each requirement and the plain-English reason behind it.
It is honest by construction. We asked the model to grade the code against the standard, not to make us look good. This is the same internal assessment we run for ourselves, and we publish the gaps and failures exactly as it found them. Curating it for the public meant removing implementation detail that would help an attacker. It did not mean changing a single verdict or its reasoning.
A human reviewed it before publishing. It is a point-in-time snapshot, last assessed July 2026, not a live mirror of the code.
What this is, and what it isn't
SOC 2 measures two different things: whether your product has security controls, and whether your company has the governance process around them, the policies, the oversight, the dated evidence that each control ran every day for a year. We have invested heavily in the first and deliberately lightly in the second.
So this is not a SOC 2 report and not a claim of certification. It is an honest internal read: if we ever did pursue one, where would we stand, and what is missing. The answer is that the product would do well and the company process is where the work would be.
Strong product, deliberate governance gap
| Area | Readiness | In short |
|---|---|---|
| Access control, encryption, change management | Ready | Implemented and evidenced to a level above a typical baseline. |
| Confidentiality & processing integrity | Ready | Per-org encryption, search over ciphertext, validated and parameterised processing. |
| Availability | Partial | Controls are present; external monitoring and a recovery drill are not yet in place. |
| Privacy | Partial | Strong mechanics; the formal privacy program around them is the gap. |
| Governance & control environment | Gap | The honest blocker: policies, oversight, and HR controls live in company process we have not yet built out. |
A point-in-time SOC 2 (controls suitably designed) would be achievable with focused effort. A Type II (controls operating effectively over a year) would additionally need a year of dated evidence. The product is not the blocker; the process scaffolding is.
The Trust Services Criteria
The Common Criteria cover security; the rest cover availability, confidentiality, processing integrity, and privacy. “Process” marks a real control that lives in company governance rather than in code, so it can't be graded from the codebase.
| Criterion | Readiness | Anchor |
|---|---|---|
| CC1 Control environment | Process | Engineering standards are codified and enforced; board oversight, HR controls, and an authority structure live in company process, not the code. |
| CC2 Communication & information | Partial | Strong internal docs and public commitments like this page; no formal versioned policy set. |
| CC3 Risk assessment | Partial | A disciplined security-finding lifecycle and recurring assessments; no enterprise risk register or fraud analysis. |
| CC4 Monitoring | Ready | Recurring external-standard assessments plus an audit log and per-route metrics. |
| CC5 Control activities | Ready | Automated, enforced controls: lint rules, pre-push gates, CI, documented error-handling patterns. |
| CC6 Logical access | Ready | Mandatory MFA, compile-time tenant isolation, per-org encryption, fail-closed session revocation, admin gated behind the platform access layer. |
| CC7 System operations | Ready | Dependency scanning in CI, a health endpoint and metrics, an incident-response runbook, point-in-time and offline backups. |
| CC8 Change management | Ready | Branch-and-PR flow with required local lint, test, and build gates plus a four-app CI pipeline. |
| CC9 Risk mitigation | Partial | Backups, rollback, and a tiered dependency risk assessment; no signed vendor data-processing agreements on file. |
| A1 Availability | Partial | Rate limits, timeouts, backups, and a health endpoint; external uptime monitoring and a recovery drill not yet in place. |
| C1 Confidentiality | Ready | Per-org authenticated encryption, search over ciphertext, retention sweeps, and self-service deletion. |
| PI1 Processing integrity | Ready | Allowlist validation, parameterised queries, AI-output clamping, and atomic-write patterns. |
| P Privacy | Partial | Strong mechanics (per-org encryption, EU residency, a data-export tool, self-service deletion); the formal privacy program around them is the gap. |
What the code already does
- Per-organisation encryption. A master key wraps a separate key for each organisation; every sensitive field and file is encrypted under its org's key with integrity protection.
- Compile-time tenant isolation. Identifier types make a cross-tenant call a compile error, so isolation is guaranteed before code ships, not left to whoever scopes the query.
- Mandatory MFA, server-side revocation. Every account requires a second factor; sessions are bounded and revoked server-side on password change or sign-out, failing closed if the store is unreachable.
- A real change pipeline. Changes go through pull requests with required local checks and a four-app CI run that includes dependency scanning.
- Incident response and backups. A severity-tiered runbook with playbooks, point-in-time database restore, and a separate offline encrypted backup.
- Validated, integrity-checked processing. Input is allowlist-validated, queries are parameterised, and AI output is clamped and schema-checked before anything touches the data.
What a real attestation would still need
These are the delta between strong technical controls and an attestable program. Most are documents and process, not code.
- A governance and policy set. Formal information-security, access-control, and acceptable-use policies, an enterprise risk register, and a defined oversight structure. Mostly new document authoring, and the real blocker for any attestation.
- Personnel controls. Background-check policy, confidentiality agreements, security-awareness training records, and onboarding and offboarding checklists.
- Vendor management. Signed data-processing agreements, a published sub-processor list, and a recertification cadence for the third parties we rely on.
- A privacy program. A formal privacy notice mapped to the criteria, data-protection impact assessments, and a named owner. The technical privacy controls already exist; this is the program around them.
- Operating-effectiveness evidence. Dated proof that controls ran across an audit window: key-rotation logs, access reviews, recorded incident post-mortems, and a periodic recovery drill.
- Change-management hardening. Enforce the CI check on the production branch and document separation of duties for merges.
A readiness assessment that hid its gaps would be worthless. The point of doing this honestly is that you can trust the parts marked ready, because we didn't hide the parts that aren't.
How it was assessed
An AI model mapped every Trust Services Criterion to the controls in the codebase, then separated what the code does from what company governance would need to add. Where a criterion lives in process rather than code, it is marked as such rather than guessed at. Every claim was checked against the source.
Curated from our internal report for public release. We removed implementation detail that would help an attacker, generalised file references to the controls they point at, and dropped internal tracking IDs. We did not change a single verdict or its reasoning. When we re-run the internal assessment, we refresh this page by hand.
This is the product the report graded.
A purpose-built security register with per-org encryption, mandatory MFA, and EU data residency. Free tier, no card.