No. Kommit is not SOC 2 certified, and we will not describe Kommit itself as "SOC 2 ready" or "SOC 2 certified" anywhere — that would be misleading.
What Kommit does ship is the control library and evidence-collection plumbing that helps you pass your SOC 2 audit with Kommit-governed AI agents as part of the audit scope.
The honest distinction
SOC 2 audits are conducted against the customer's operation, not the platform's. A vendor saying "we're SOC 2 certified" usually means one of:
- —The vendor has a SOC 2 Type 1 or Type 2 report from a CPA firm covering the vendor's own internal controls.
- —The vendor's product is built in a way that doesn't break the customer's SOC 2 controls.
Kommit is in category 2 today, not category 1. Specifically:
- —We don't yet have a SOC 2 Type 2 report against Kommit's own internal operations. We may in 2026 — see "What's next" below.
- —We have built the product to support a customer's SOC 2 scope for AI agents: tamper-evident audit logs, change-management workflows for policy edits, separation of duties between authoring and approving, evidence packs you can attach to audit responses.
What we provide for your SOC 2 audit
If you are pursuing SOC 2 (Type 1 or Type 2) and Kommit-governed agents are in scope, you typically need to satisfy controls under CC6 (Logical Access), CC7 (System Operations), and CC8 (Change Management). Kommit produces evidence for each of these:
| Control area | What Kommit produces |
|---|---|
| CC6.1 — logical access | Live /access matrix snapshots, role-change events in the audit log. See [#access-control-matrix]. |
| CC6.6 — encryption | Deploy-topology page showing TLS termination, at-rest encryption (Hetzner-managed). See [#where-does-my-data-live]. |
| CC7.2 — monitoring | Audit log exports for the audit period. See [#exporting-audit-logs]. |
| CC8.1 — change management | Policy-edit workflow with author / approver separation, audit trail of every policy change. See [#policy-library]. |
We do not generate the customer-side controls themselves — Kommit won't write your incident-response procedure or your training-and- awareness program. We give you the evidence trail for the controls that Kommit-governed agents touch.
A "shared responsibility" diagram
Your SOC 2 scope
┌────────────────────────────────────────────┐
│ Your policies, procedures, training, IR │
│ Your other vendors' SOC 2 reports │
│ Your own infrastructure │
│ ┌────────────────────────────────────────┐ │
│ │ AI-agent surface (governed by Kommit) │ │
│ │ ──────────────────────────────────────│ │
│ │ Kommit controls: │ │
│ │ - access matrix + role change log │ │
│ │ - policy library + change management │ │
│ │ - tamper-evident audit log + exports │ │
│ │ - deploy topology + encryption posture│ │
│ └────────────────────────────────────────┘ │
└────────────────────────────────────────────┘
What's next
We're targeting a SOC 2 Type 1 report on Kommit's own operations
once we hit the engineering team size and the customer concentration
that justifies the audit cost. We will update this article and
publish the report at /trust when it lands. Until then: see above.
If your procurement process requires a vendor SOC 2 report before you can buy, tell us — there are pre-engagement workarounds (NDA'd control questionnaire, security review on top of the Trust Center) that have unblocked customers in similar situations.
See also [#gdpr-support] and [#eu-ai-act-support] for the same "what we ship vs. what you do" breakdown against other frameworks.