What SOC 2 Auditors Actually Test on an AI Vendor Now (Not What Your Security Questionnaire Asks)

SOC 2 is the default trust signal buyers request from an AI SaaS vendor, and the underlying Trust Services Criteria framework itself hasn't been rewritten for AI. What's changed materially in 2026 is what auditors actually probe underneath that framework, and it's a meaningfully deeper check than most standard vendor security questionnaires ask for.

What auditors actually do now

Auditors typically start by asking a vendor to select a deployed model version and produce its full lineage: the exact dataset, code, parameters, and the approval trail that put it into production. They test prompt and inference logging specifically, including whether personal or health information is redacted before logs are written, not after. They review drift-monitoring outputs and the change-management tickets tied to model deployments. And they now expect vendor-risk assessment for every LLM subprocessor a vendor uses, meaning the underlying model API itself gets treated with the same rigor as any other third-party data processor, not waved through as an implementation detail.

Access controls have tightened too. Model APIs, fine-tuning endpoints, and embedding stores are now expected to be controlled the way production database access is controlled: service accounts inventoried, reviewed on a quarterly cadence, not granted once and forgotten.

Why a clean report can still hide a real gap

A vendor can hold a passing SOC 2 report and still have weak practices in exactly these areas, if the audit scope didn't specifically probe them. The report tells you the vendor passed whatever was actually tested, not that every AI-specific risk was tested. A standard security questionnaire, the kind most procurement teams send, rarely asks about model lineage, subprocessor risk assessment for the LLM API itself, or drift monitoring specifically.

What to actually ask for

Don't stop at "do you have a SOC 2 report." Ask whether the audit scope specifically covered model lineage tracking, PII/PHI redaction in inference logs, and vendor-risk assessment of the underlying model provider. If the vendor can't answer specifically, the badge is real but the coverage may be narrower than you're assuming.