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 August 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, external monitoring, and a completed recovery drill are all in place; a repeating drill cadence is not yet on the record. |
| Privacy | Partial | Strong mechanics and a binding data-processing agreement; a formal privacy program mapped to the criteria 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, external uptime probes, 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 six-job CI pipeline covering every deployable. |
| CC9 Risk mitigation | Partial | Backups, rollback, and a tiered dependency risk assessment; data-processing agreements are in force with every sub-processor but one, and a recertification cadence is still missing. |
| A1 Availability | Partial | Rate limits, timeouts, backups, a health endpoint, external uptime monitoring, and one completed restore drill; a sustained drill cadence is not yet demonstrated. |
| 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 and a binding Article 28 agreement with a published sub-processor list; a privacy program mapped to the criteria 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 CI run covering all six deployables, including dependency scanning.
- Incident response, monitoring, and backups. A severity-tiered runbook with playbooks, two independent external uptime probes with a public status page, point-in-time database restore, and a separate offline encrypted backup that has been restored end-to-end in a drill.
- Validated, integrity-checked processing. Input is allowlist-validated, queries are parameterised, and AI output is clamped and schema-checked before anything touches the data.
Contracts, sub-processors, and AI data terms
Vendor paperwork is the one part of the governance layer we have actually done, so it is worth separating from the gaps below.
- A data-processing agreement that already binds. Our GDPR Article 28 DPA is incorporated into the Terms by reference, so it is in force for every customer from the moment they accept, signature or not. Ask and we will send a countersigned counterpart for your compliance file.
- A published sub-processor list. Every sub-processor, what it is engaged for, and where it processes, published with the Privacy Policy and in the DPA's annex, with advance notice of changes and a right to object.
- Data terms with the AI providers. Anthropic and Mistral both run under a data-processing agreement and a zero-data-retention agreement: nothing retained beyond generating the response, no training on your data. OpenAI runs under a DPA with no training, but without zero retention, so a limited abuse-monitoring window applies. Mistral is the EU-residency option.
Our payment merchant-of-record moved from Paddle to Stripe in July 2026, which retired the old Paddle agreement. Re-confirming Stripe's processor terms is an open item, and it is listed as one here rather than quietly left out.
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 recertification. The agreements and the sub-processor list are in place; what is missing is the recurring discipline around them, pulling each sub-processor's own SOC 2 report on a cadence and scheduling recertification.
- A privacy program. Our privacy notice is published, but it is not mapped to the privacy criteria, and there are no data-protection impact assessments and no named privacy owner. The technical controls and the contract 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 recovery drill on a repeating schedule rather than the single completed run we can show today.
- Change-management hardening. Our CI gate is configured but not yet binding, because enforcing branch protection on a private repository needs a paid plan. Turning it on, and documenting separation of duties for merges, is the remaining work.
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, and re-checked against it at the date above rather than carried forward on trust.
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.