SOC 2 and AI Tools: What Auditors Are Now Asking

SOC 2 and AI tool use are now impossible to keep apart on an audit call. The framework was built for cloud software vendors years before generative AI was mainstream, but its Trust Services Criteria are written broadly enough that auditors have simply started applying them to AI. Do you know which AI tools your team uses? Is there a policy? Have you vetted AI vendors the way you vet any other subprocessor? For most small SaaS companies, AI is inside the scope of a SOC 2 audit whether anyone planned for it or not, and the paper trail either exists or it doesn't.

The AI questions appearing in SOC 2 engagements

Current auditors are asking variants of the same handful of questions: what AI tools are in use in your environment, do you have an AI usage policy, have employees been trained on it, how do you evaluate AI tools before approval (especially ones that touch customer data), do your AI vendors hold their own SOC 2 reports, and is there a process for retiring tools that stop meeting your bar? None of these have a convincing answer if you're improvising them in the room.

Does SOC 2 actually require an AI policy?

Not by name - there's no clause reading "thou shalt have an AI policy". What SOC 2 requires is evidence that you control access to systems, manage vendors, and handle confidential and personal data responsibly. An AI policy is simply the most direct way to produce that evidence once AI tools are part of how your team works. Auditors ask for it because, without one, you're relying on informal habits to satisfy a formal control. Complementary frameworks such as the NIST AI RMF cover similar ground from a risk-management angle, but for a SOC 2 engagement specifically, the policy and its evidence trail are what get checked.

Vendor management controls and AI

SOC 2's vendor management requirements apply to AI vendors exactly as they apply to your cloud hosting provider or payment processor. If an AI tool processes data in scope for your engagement, you need to have evaluated that vendor: confirmed their SOC 2 status, reviewed their data-handling terms against the AICPA's Trust Services Criteria, and, where personal data is involved, secured a Data Processing Agreement. Keep records of those evaluations the same way you would for a hosting provider or payroll vendor - a one-line note that says "trusted, we checked" isn't evidence, a dated review with the vendor's SOC 2 status attached is. Your AI tool register doubles as the vendor management documentation this criterion is checking for.

What happens if auditors find an unapproved AI tool mid-engagement?

It happens more often than teams expect. A 30-person fintech startup preparing for its first SOC 2 Type II audit found, partway through the observation window, that four different AI tools were in active use across support and engineering - none of them formally approved, none covered by the vendor questionnaire the team had prepared. The finding wasn't fatal, but it meant a scramble: retroactive vendor checks, a fast-tracked policy, and an uncomfortable conversation about why shadow use hadn't been caught earlier. Auditors don't expect zero surprises; they expect a documented plan for handling them, which is exactly what a live AI usage policy and tool register provide. The team's auditor treated the retroactive fix as a minor exception rather than a qualified opinion, largely because the remediation was fast and well documented - the kind of outcome a pre-existing policy would have avoided entirely.

AI policy as SOC 2 evidence

The Common Criteria around logical access and change management both touch AI indirectly. An AI usage policy that specifies who's authorised to use which tools, what data is permitted, and who signs off on new tools maps onto the access-control and change-management criteria auditors already check. Write the policy with those criteria in mind and it does double duty - governance document and audit evidence in the same file.

Type I versus Type II: what changes for AI vendor risk

A Type I report confirms controls were designed properly at a single point in time. A Type II report tests whether those controls actually operated effectively over a window, usually six to twelve months. For AI vendor risk, that distinction matters: a tool that had no policy coverage for three of those months is a genuine gap, not something a same-day fix can paper over. If you're heading into a Type II window, get the AI policy and tool register in place before the observation period starts, not during it. Retrofitting a policy the week before fieldwork begins doesn't cover the months the auditor is actually sampling.

The fastest path to audit-readiness

Get the policy in writing, get the tool list documented with each vendor's SOC 2 status noted, and get staff to acknowledge the policy on record. Those three steps produce the documentation that satisfies most AI-related audit questions without bespoke controls or a months-long project. ModelCharter generates the policy and the attestation trail; checking a vendor's SOC 2 status takes about ten minutes per tool using our AI Tool Risk Directory - most major vendors publish their own privacy and security documentation directly, the way Microsoft does for 365 Copilot - far less than building a vendor questionnaire from scratch.

Where to start this week

If your next SOC 2 engagement is on the calendar, start with the SOC 2 framework hub to see how the criteria map onto AI-specific controls, then run your current AI tools through the directory to flag any without a SOC 2 report or DPA on file. A policy and a signed-off tool register, built before the auditor asks, turns a soc 2 ai question from a scramble into a five-minute answer.