SOC 2 Type II
SOC 2 Type II is an attestation report produced by an independent CPA firm under AICPA's SSAE 18 standard, covering a service organization's controls against the five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. The Type II distinction is the audit window: Type I reports on the design of the controls at a point in time, Type II reports on the operating effectiveness of those controls across a period (typically six to twelve months). Enterprise procurement teams treat the Type II report as the threshold artifact for SaaS vendor security review.
How AI traffic shows up in a SOC 2 Type II audit
The Trust Services Criteria do not name AI directly, but the security and confidentiality criteria cover access control, change management, monitoring, and incident response on any system that handles customer data. An AI-handling service that routes prompts containing customer data through a vendor LLM expands the audit scope to include the AI traffic boundary. The auditor reads the policy that governs which prompts route to which model, the evidence that the policy ran on each request, and the audit log that proves the evidence is reproducible across the audit period.
Why SOC 2 Type II evidence is harder for AI without an enforcement layer
A control listed as "AI usage is governed by policy" passes a Type I review on the policy document alone. A Type II review asks for evidence the policy was applied on every relevant request across the period. An application that logs its own AI usage answers the question with self-attestation that the auditor either accepts on faith or rejects. An external enforcement layer that produces per-decision audit records with tamper-evident properties answers the question with reproducible evidence, which is the form the Type II auditor's working papers can rest on.
Related reading
- SOC 2 AI Controls: Mapping the Trust Services Criteria to AI Deployments
SOC 2 reports cover five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. AI deployments touch all five. The audit evidence that AICPA expects has to be operational, not architectural. Application logs and policy documents fail. The records that pass are per request.
- Tamper-Evident Audit Logs for AI: What Cryptographic Integrity Brings to Compliance Records
Tamper-evident audit logs make any post-hoc modification of a record detectable through cryptographic integrity. For AI compliance records, the property closes the self-attestation gap that application-controlled logs cannot. The technique combines per-record signing, hash chaining, and external anchoring. EU AI Act Article 12, Fannie Mae LL-2026-04, HIPAA, DORA, and NIST AI RMF all expect records that an auditor can rely on as evidence. Application logs that the application can modify do not meet that standard. This piece walks through the cryptographic mechanisms, the operational characteristics, and the architectural placement.
- ISO 27001 AI Compliance: How ISO 42001 Sits On Top of the ISMS
ISO 27001 is the information security management system standard. ISO 42001 is the AI management system standard published December 2023. The two standards integrate at the controls layer. Annex A controls in ISO 27001:2022 cover the same evidence ISO 42001 expects for AI-specific risk treatment.