Trust Center / SOC 2 Type II
SOC 2 Type II
CMDash does not yet hold a SOC 2 Type II attestation, and no audit period has started. This page documents where we are: our own readiness self-assessment against the AICPA Trust Services Criteria, and the auditor-engagement status. We publish this honestly so prospects can evaluate whether our current state fits their procurement bar.
Current status
- Attestation
- Not yet issued. No audit period has started, and no start date is set.
- Trust-services principles in scope
- Security (CC1–CC9) and Availability (A1). Confidentiality (C1) and Processing Integrity (PI1) addressed at summary level; Privacy (P1–P8) expanded on customer demand.
- Auditor engagement
- Auditor shortlist narrowed to three firms with deep SaaS / security-product experience. No engagement letter is signed yet. (status confirmed 2026-09-10)
- Internal controls mapping
- Complete. Every Trust Services Criterion is mapped to the file, module, or runbook implementing it, with gap items tracked in the engineering improvement catalog.
Per-criterion readiness
Readiness below reflects the state of technical and procedural controls relative to the AICPA Trust Services Criteria, as CMDash assesses them itself. A "Ready" rating means the control is implemented and evidence is readily collectible; "In progress" means implemented with known gaps tracked in the improvement catalog; "Gap" would mean not implemented — none of the in-scope criteria currently sit in that category. It is a readiness summary, not an audit opinion.
| Criterion | Title | Status | Notes |
|---|---|---|---|
| CC1 | Control Environment | In progress | Code ownership is declared in CODEOWNERS, but no second reviewer is required on changes: CMDash has one maintainer. A formal org chart and information-security responsibility statement are open management items. |
| CC2 | Communication and Information | Ready | Structured logging (pino) with request, tenant and user context; architecture docs, runbooks, a sales changelog and the product datasheet are maintained in the repository. |
| CC3 | Risk Assessment | In progress | Risk-treatment decisions are recorded in the engineering improvement catalog. Running CMDash’s own risk register in its own tenant is not set up yet. Two-person approval for dangerous operations is an open hardening item. |
| CC4 | Monitoring Activities | In progress | Alarm definitions for the production stack are written but not yet applied, so there is no automated alerting yet. Draft SLO definitions and an improvement-catalog workflow for deficiency remediation exist. |
| CC5 | Control Activities | Ready | Authentication, RBAC, per-tenant row-level security and encryption of stored integration credentials. A CI gate runs lint, typecheck, tests and secret scanning. |
| CC6 | Logical and Physical Access | Ready | JWT with refresh rotation, MFA/TOTP with recovery codes, SAML SSO, SCIM v2 provisioning, LDAP sync, RBAC, per-tenant row-level security. New evidence objects are sealed under per-tenant data keys, and tenant offboarding destroys those keys before deleting data (crypto-erasure, CC6.5). |
| CC7 | System Operations | In progress | Secret-leak response runbook, graceful shutdown and automated dependency-update pull requests. Monthly documented restore drill is an open item (CC7.5). |
| CC8 | Change Management | In progress | Every change is committed to git with a conventional-commit message and runs through the CI gate; schema migrations are checked in. main blocks force-pushes, but does not require a second reviewer (one maintainer). |
| CC9 | Risk Mitigation | In progress | Published subprocessor list (see /trust/subprocessors) and DPA (see /trust/dpa); a dedicated vendor-risk module is on the roadmap. |
| A1 | Availability | In progress | Two application instances behind a load balancer, and a managed PostgreSQL database snapshotted before every deploy; k6 load-test scripts. There is no cross-region replication, and the alarm definitions are not yet applied. Monthly restore-drill documentation is an open item. |
Readiness summary above is derived from the internal controls mapping at docs/compliance/soc2-type-ii-controls-mapping.md. The internal document is the source of truth for per-criterion evidence anchors.
How evidence is collected
Every control maps to one of the following evidence classes:
- Code anchor. A specific module, test, or configuration file that implements the control. Reviewable directly in the source tree.
- Automated artifact. CI run output: test results, secret-scan reports, SBOM attestation, container signature.
- Runbook. A documented procedure with named owners, last-reviewed date, and a post-incident update requirement.
- Audit log. Log entries corresponding to the control event (login, role change, deletion, policy change). The signed, tamper-evident audit chain is built but not switched on in production.
- Management sign-off. A documented management review of the control.
Receiving the report when it’s issued
Customers and qualified prospects under NDA will be able to request the SOC 2 report through their account team or by emailing security@cmdash.com. To be notified when the first report is issued, email the same address with the subject line "SOC 2 notify". In the meantime, you can review our published Security overview and subprocessor list, which together cover most SOC 2 questionnaires.