SOC 2 Type II for AI Vendors: What Buyers Should Demand to See

SOC 2 Type II for AI Vendors: What Buyers Should Demand to See

You are evaluating an AI vendor. They hand you a SOC 2 Type II report and smile like they just passed the bar exam. You flip through it, see the clean opinion letter, and feel a brief wave of comfort. Then you start reading the description of the system, and you realize the report covers their customer support ticketing platform. Not the AI inference pipeline. Not the model training environment. Not the data lake where your sensitive inputs get processed.

This happens constantly. A SOC 2 report is only as useful as its scope, and AI vendors have gotten very good at scoping their audits to avoid the hard questions. If you are a buyer in a regulated industry, you need to know exactly what to look for, what to push back on, and where the typical gaps hide.

Trust Services Criteria and AI Processing: Where the Mapping Gets Interesting

SOC 2 is built around five Trust Services Criteria (TSC) defined by the AICPA: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most SOC 2 reports only cover Security. Some add Availability. Very few AI vendors include Processing Integrity, which is arguably the most relevant criterion when you are buying a system that transforms inputs into outputs using probabilistic models.

Security (CC Series)

The baseline. Covers logical access controls, network security, change management, risk assessment. For AI vendors, you should expect to see controls around access to training data, model weights, and inference endpoints. If the report describes access controls for a web application but never mentions the ML infrastructure, the scope is too narrow.

Processing Integrity (PI Series)

This is where things get genuinely important for AI. PI1.1 requires that the entity's processing objectives are defined and documented. For an AI system, that means the vendor should be articulating what the model is supposed to do, how accuracy is measured, and what constitutes an error. PI1.2 through PI1.5 address completeness, accuracy, timeliness, and authorization of system processing. Applied to AI, these criteria should cover model validation, drift monitoring, input/output logging, and controls that prevent unauthorized modification of model behavior.

Most AI vendor SOC 2 reports skip Processing Integrity entirely. When you ask why, the usual answer is that it was "not in scope." That answer should concern you.

Confidentiality and Privacy (C Series, P Series)

If your data is being used for fine-tuning, prompt engineering, or retrieval-augmented generation, you need the Confidentiality criteria in scope. The C1.1 and C1.2 controls should describe how confidential information is identified, protected during processing, and disposed of. The Privacy criteria matter if any personal data flows through the system, which in healthcare and financial services is almost always the case.

The Scope Question: Read the System Description First

Section III of a SOC 2 report contains the system description. This is the single most important section for buyers, and it is the one most people skim. The system description defines the boundaries of the audit. Everything outside those boundaries is unexamined territory.

Here is what to look for specifically with AI vendors:

• Infrastructure boundaries. Does the system description include the model training environment, or only the production API? Many vendors train models in one cloud account and serve them from another. If the training environment is out of scope, you have no assurance about data handling during the most sensitive phase of the AI lifecycle.
• Subservice organizations. AI vendors frequently rely on foundation model providers (OpenAI, Anthropic, Google) as subservice organizations. The SOC 2 report should explicitly identify these dependencies and state whether they are using the "inclusive method" or the "carve-out method." Under the carve-out method, the subservice organization's controls are excluded from testing. That means the auditor never looked at them. If your vendor is wrapping GPT-4 and carving out OpenAI, a significant portion of your risk surface is unaudited.
• Data residency and flow. The system description should map where data goes. If you are in financial services subject to OCC guidance on third-party risk management (OCC Bulletin 2013-29, updated 2023), or in healthcare under HIPAA, you need to know whether customer data crosses geographic or organizational boundaries during processing.
• Complementary User Entity Controls (CUECs). These are controls the vendor expects you to implement. Some vendors bury significant security responsibilities here. If a CUEC says "the user entity is responsible for ensuring that only authorized data is submitted to the system," the vendor is telling you they have no input validation controls. Read every CUEC carefully.

Typical Gaps in AI Vendor SOC 2 Reports

After reviewing dozens of these reports across regulated industries, certain patterns emerge repeatedly.

No controls around model updates

Change management controls (CC8.1) in most AI vendor reports cover application code deployments. They rarely cover model retraining or weight updates. A model update can fundamentally change system behavior, but it often bypasses the same change advisory board processes that govern a CSS change. Ask whether model deployments go through the same change management controls described in the report.

Logging gaps in inference pipelines

CC7.1 through CC7.4 cover monitoring and detection. Many reports describe log aggregation for infrastructure events but say nothing about logging prompts, completions, or intermediate reasoning steps. If you are in a regulated industry where you need to demonstrate supervisory oversight of automated decisions (think SR 11-7 for banking, or the EU AI Act's Article 14 human oversight requirements effective August 2025), you need inference-level logging. If the vendor's SOC 2 does not mention it, it probably does not exist.

Vague risk assessments that ignore AI-specific threats

CC3.1 requires a risk assessment process. In many AI vendor reports, the risk assessment covers standard IT risks: unauthorized access, data loss, system downtime. It rarely addresses prompt injection, training data poisoning, model inversion attacks, or hallucination risk. These are not theoretical concerns. NIST's AI Risk Management Framework (AI RMF 1.0, released January 2023) identifies these as core risk categories. If the vendor's risk assessment does not reflect AI-specific threats, the entire control environment may be misaligned with actual risk.

No mention of data retention for training

This is a big one for confidentiality. CC6.5 covers data disposal. But many AI vendors have ambiguous policies about whether customer data used during inference is retained, aggregated, or used for model improvement. The SOC 2 report should describe the data lifecycle explicitly, including whether inference data feeds back into training pipelines. If it does not address this, you should assume the worst and ask directly.

What to Actually Demand

When you receive a SOC 2 Type II report from an AI vendor, push for the following before you sign off on procurement:

• Confirm that the system description covers the AI inference and (if applicable) training infrastructure, not just the surrounding web application.
• Require Processing Integrity criteria in scope, with specific controls mapped to model validation and output accuracy.
• Ask for a bridge letter if the observation period ended more than six months ago. SOC 2 reports cover a specific window (typically 12 months), and a lot can change in an AI system between audits.
• Request the detailed control descriptions and test results in Section IV, not just the executive summary. Some vendors share only the opinion letter. That tells you almost nothing.
• Identify every carve-out subservice organization and assess whether you need to obtain their SOC 2 reports independently.

How FirmAdapt Addresses This

FirmAdapt was built with the assumption that regulated buyers will scrutinize the AI processing environment, not just the application layer. The platform's architecture keeps data processing within defined boundaries, maintains inference-level logging by default, and enforces access controls across the full model lifecycle. These controls are designed to align with all five Trust Services Criteria, including Processing Integrity and Confidentiality, so that audit scope does not have to be artificially narrowed to achieve a clean report.

FirmAdapt also avoids the subservice carve-out problem by design. Rather than wrapping third-party foundation models and hoping buyers do not notice the gap, the platform's compliance-first approach means that data flows, retention policies, and processing boundaries are documented and auditable from the start. If your procurement team is tired of reading SOC 2 reports that carefully avoid saying anything about the AI, FirmAdapt is built to withstand exactly the level of scrutiny described above.