How we think about SOC 2 readiness — and the five criteria we'd add to ours

SOC 2 is often described as a compliance checkbox. Get the report, send it to the vendor questionnaire portal, move on. That framing undersells what a strong SOC 2 readiness program actually requires — and, more practically, it causes regulated buyers to extract less value from vendor compliance documentation than they should.

This post describes how we approach SOC 2 readiness internally: what our program is built around, and five criteria beyond the AICPA Trust Services Criteria minimum that we believe a rigorous vendor in our position should include. We’ll also cover what buyers should actually look for when they review a SOC 2 report.

Starting with the basics: what SOC 2 actually measures

The AICPA Trust Services Criteria define five categories: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Security is always required; the others are optional. The framework evaluates whether a defined set of controls was designed effectively and, in a Type II report, whether those controls operated effectively over an observation period — typically 6 to 12 months.

This structure matters because it defines the limits of what SOC 2 attests to. It covers the controls within the defined scope, over the defined period, as evaluated by the auditor who performed the engagement. A vendor with a SOC 2 readiness program is preparing to operate within those parameters at a high standard — and is thinking hard about what “effective controls” means in practice for a vendor handling regulated data.

Our readiness program is designed against the AICPA Trust Services Criteria, with internal controls mapped to each TSC category. We treat the readiness program as the ongoing discipline of maintaining evidence — not as annual activity before a scheduled audit window.

The five criteria we’d add

The AICPA TSC framework is rigorous, but it was designed to apply broadly across software-as-a-service products. For a vendor in our position — handling regulated data on behalf of healthcare, financial services, and defense-adjacent organizations — the base TSC scope leaves meaningful gaps in categories our customers regularly ask about. Here are the five criteria we believe belong in any comprehensive readiness program for vendors in our market, and that we include in our own.

1. Software supply-chain controls.

Our readiness program includes controls covering our software build pipeline: dependency provenance tracking, SBOM generation and attestation, code-signing practices, and third-party component review cadence. These address the category of risk where a compromise of a build dependency — not our own code — introduces a vulnerability into what we ship. The base Security TSC doesn’t prescribe supply-chain software controls with this specificity.

When we think about what an auditor should examine in this area: CI/CD configuration, SBOM tooling output, and evidence of a defined dependency update process. For buyers, the question to ask a vendor is simple: can you produce a software bill of materials for your current production release, and what controls exist around your build pipeline?

2. Software bill of materials (SBOM) availability.

Connected to the supply-chain controls above, we maintain a current SBOM for every production release — in SPDX 2.3 format, updated within 48 hours of any production release — and make it available to customers on request. This is a specific, verifiable commitment: either the SBOM exists with the specified update frequency or it doesn’t.

SBOM availability is increasingly a requirement in regulated procurement, particularly in defense and federal adjacent programs under Executive Order 14028. Including it as a defined, measurable criterion in a readiness program gives buyers a concrete deliverable to ask for, rather than a policy assertion.

3. Internal AI system use disclosure.

We use AI-assisted tooling in several internal workflows: code review assistance, anomaly detection in our security monitoring pipeline, and customer support triage. A rigorous readiness program should include a criterion requiring documentation of which workflows use AI-assisted tooling, whether any AI system processes customer data, and what human oversight exists at each step.

Our commitment: no customer file content is processed by any AI system without explicit customer opt-in, which is currently disabled for all tenants by default. This is the kind of specific, auditable commitment that belongs in a compliance readiness framework — not a generic policy statement.

4. Privileged access management (PAM) coverage.

The base Security TSC includes logical access controls, but a mature readiness program should specify more granular requirements: just-in-time privileged access for production systems, session recording for all privileged access, quarterly PAM coverage audits, and break-glass procedure documentation. This is the difference between having access controls and operating them rigorously.

For buyers, the PAM criterion translates to specific evidence requests: access request workflows, session recording coverage, and evidence of periodic privileged access reviews. These should be reviewable against a defined standard, not just asserted.

5. Vendor and subprocessor security verification.

Our readiness program includes controls around our own supply-chain assessments: a documented annual review of each material subprocessor, a standardized security questionnaire process, and a requirement that critical-path subprocessors maintain their own SOC 2 or equivalent certification. This is not just a policy — it’s a tracked program with a vendor register, assessment cadence documentation, and evidence of assessments completed.

For regulated buyers, a vendor’s subprocessor security verification program is directly relevant: if you’re placing regulated data with a vendor, you’re implicitly relying on every subprocessor that vendor uses to handle that data with appropriate controls.

What buyers should look for in any vendor’s SOC 2 program

A SOC 2 readiness package — or a completed SOC 2 report — is not a pass/fail certification. It’s a description of a control environment over a period of time, accompanied by an assessment of whether the controls operated as described. Buyers who treat it as a checkbox miss most of the value.

The most important things to evaluate:

Scope. What TSC categories are covered? Security only, or all five? Are there any supplemental criteria? A Security-only SOC 2 from a vendor handling your financial data is a thin foundation.

Period of coverage. For completed Type II reports: they cover a period of time — typically 12 months. A 3-month Type II from a new vendor is much less meaningful than a 12-month report from a vendor that has operated the same control environment for consecutive years.

Exceptions and qualifications. For completed reports: read the exceptions section. An auditor opinion that says “except for the controls noted below” is substantively different from a clean opinion.

Complementary user entity controls. SOC 2 readiness documentation should be transparent about the controls the buyer must operate to make the vendor’s controls effective. A vendor who shifts significant risk to the buyer through CUECs should document that clearly.

Subprocessor coverage. If the vendor uses material subprocessors that handle your data, are those subprocessors addressed in the vendor’s supply-chain controls?

How to request our readiness documentation

Our SOC 2 readiness package — including our control framework, the five supplemental criteria above, and evidence of how each area is addressed — is available to prospective and current customers under NDA. Request it through your account contact or via the security page on our site. We also publish a summary control description that doesn’t require NDA for initial due diligence.

The SBOM for the current production release is available via authenticated API to any customer on a paid plan.