Why SOC 2 is not AI assurance

SOC 2 attestation is based on the AICPA's Trust Services Criteria, covering five categories: Security (common criteria), Availability, Processing Integrity, Confidentiality, and Privacy. The Security category is required; the others are optional inclusions depending on the vendor's scope.

Within those categories, SOC 2 covers:

• Logical and physical access controls — who can access systems and data, how access is provisioned and revoked.
• System operations — how the vendor monitors and maintains its infrastructure.
• Change management — how software changes are tested and deployed.
• Risk management — how the vendor identifies and manages operational risks.
• Vendor management — how the vendor manages its own third-party relationships.
• Data handling for Privacy criteria — if included, how personal data is collected, used, retained, and disposed of.

These controls are relevant and important. For any software vendor, they represent a meaningful baseline. The issue is not what SOC 2 covers — it is what it does not.

SOC 2 was designed around a model of software behaviour that does not apply to AI systems. It assumes that software, given the same input, produces the same output — or at least predictable output within defined parameters. It assumes that the risk profile of the system is stable between assessments. It assumes that the “system” being attested is the vendor's software, not a model that a third party controls.

The risks SOC 2 does not cover for AI vendors:

• Model behaviour: How the model behaves in production — including its failure modes, its responses to edge cases, and its behaviour under adversarial inputs. SOC 2 does not assess whether a model produces accurate, safe, or appropriate outputs.
• Training data: What data the model was trained on, whether that data was collected with appropriate consent, and whether the training data introduces bias, harmful capabilities, or privacy risks.
• Capability boundaries: What the model can and cannot do — its capability profile and the excess capability risks that come from capabilities beyond what the intended use case requires.
• Alignment properties: The rules and values the model has been trained to respect — and how robust those properties are under adversarial pressure or in edge cases.
• Model governance: Who can change the model, how changes are reviewed, and what happens to customers when the model changes.

The AI gap in attestation is the absence of any widely adopted third-party verification mechanism for model-level properties. There is no equivalent of SOC 2 for model behaviour, alignment, or governance. The closest available options are:

• Model cards — voluntary disclosures by model providers about training data, capabilities, limitations, and evaluation results.
• Red-team summaries — vendor-disclosed summaries of adversarial testing conducted before deployment.
• Capability evaluations — formal evaluations of model capabilities against defined benchmarks.
• AI incident reports — disclosures of known model failures, misalignment incidents, or safety issues.

None of these is independently verified in the way SOC 2 is. They are vendor-produced documents, and their quality varies significantly. But they are the best available evidence for model-level assurance — and they are what AI assurance requires in the absence of formal attestation frameworks.

AI assurance for a vendor requires evidence across three areas that SOC 2 does not address: model provenance, behaviour documentation, and governance.

AI assurance is not a replacement for SOC 2 — it is a complement. SOC 2 covers the infrastructure layer. AI assurance covers the model layer. An AI vendor review needs both.

Model provenance evidence: The model card or equivalent documentation describing what the model was trained on, what data governance practices were applied, and what the intended use cases are. For foundation model products, this evidence comes from the model provider. For fine-tuned or custom models, it must come from the vendor.

Behaviour documentation:Red-team results showing what adversarial testing found and what the vendor's response was. Capability evaluations showing what the model can and cannot do. Limitation documentation describing where the model is known to perform poorly or produce unreliable outputs.

Governance evidence:Documentation of who controls the model, how changes are managed, what notification obligations exist to customers, and what the vendor's AI incident classification and response process covers.

Several emerging frameworks are attempting to fill the AI assurance gap that SOC 2 leaves:

• NIST AI RMF: A voluntary framework for AI risk management that covers Govern, Map, Measure, and Manage functions. Not an attestation standard, but a structured approach that organisations can use to assess vendor AI governance.
• ISO 42001: An international standard for AI management systems that can be used as the basis for third-party certification. Still early in adoption but establishing itself as the AI governance standard analogue to ISO 27001.
• EU AI Act technical documentation: For vendors placing high-risk AI systems on the EU market, the EU AI Act requires technical documentation that goes significantly beyond SOC 2. This documentation, when available, provides the model-level evidence that SOC 2 does not.

Until these frameworks achieve the adoption level of SOC 2, organisations conducting AI vendor assessments must supplement SOC 2 with direct questionnaire and documentation review. The frameworks above provide a structure for that supplementation.

The practical approach to supplementing SOC 2 for AI vendor assessments is a structured evidence request covering the areas SOC 2 does not address:

• Model card or equivalent documentation for the model(s) powering the product.
• Summary of red-team or adversarial testing conducted on the model or the product.
• Capability evaluation results or limitation documentation.
• AI incident history — any known model behaviour incidents in the past 24 months.
• Model governance documentation — change process, customer notification procedure, governance roles.
• Training data description — what the model was trained on and whether customer data is used for training.

The quality and completeness of vendor responses to this evidence request is itself a signal about the vendor's AI governance maturity. A vendor with no model card, no red-team documentation, and no defined model governance process is a vendor whose AI governance is immature — regardless of their SOC 2 status.

For the full set of additions to a standard vendor questionnaire, see The AI section your vendor security questionnaire is missing.