The short answer
Auditors reviewing AI tools in a SOC 2 Type II assessment focus on vendor risk management, data confidentiality, change management, and access control across Trust Services Criteria (TSC) Security, Confidentiality, and Availability.
To satisfy SOC 2 auditors, you must provide concrete evidence: an inventory of approved AI tools, vendor SOC 2 reports or security assessments, formal acceptable use policies, repository ignore configurations, and evidence of human code review for AI-generated changes.
SOC 2 Trust Services Criteria Impacted by AI
AI tools directly touch four core Trust Services Criteria:
1. Vendor Risk Management (CC9.2)
SOC 2 Common Criteria 9.2 requires organizations to assess and manage risks associated with third-party vendors.
- Auditor Evidence Required: Signed vendor agreements, the AI vendor’s SOC 2 Type II report (or ISO 27001 certificate), completed security questionnaires, and documented annual vendor reviews.
- Audit Trap: Using individual paid accounts on personal credit cards without central vendor evaluation. See our breakdown of free vs paid AI tools terms.
2. Confidentiality (CC6.1, CC6.3)
Confidentiality criteria demand that confidential information is protected during collection, processing, transmission, and storage.
- Auditor Evidence Required: Evidence that model training is disabled for your workspace, retention policies for prompt logs, repository ignore configs (e.g.,
.envexclusions), and secret scanning logs. Read our guide on how to stop secrets leaking into an AI assistant.
3. Change Management (CC8.1)
CC8.1 requires that code changes are authorized, tested, and reviewed prior to production deployment.
- Auditor Evidence Required: Pull request logs showing peer code review approval for AI-generated code snippets. AI cannot act as a peer reviewer to satisfy CC8.1—human approval is mandatory.
4. Logical Access Controls (CC6.1, CC6.2)
Access controls dictate who can access AI tools and what data those tools can reach.
- Auditor Evidence Required: Single Sign-On (SSO) integration logs, Centralized User Provisioning (SCIM), role-based access configurations, and deprovisioning evidence for departed employees.
Evidence Collection Checklist for Auditors
When preparing for your SOC 2 audit window, compile the following evidence artifact package:
Artifact 1: Approved Vendor Inventory
A documented register of all authorized AI tools, specifying approved tiers, department access, data classification limits, and business owner.
Artifact 2: Vendor SOC 2 / Trust Package
The AI vendor’s current SOC 2 Type II report covering the audit period. If the vendor relies on sub-processors for model inference, include the sub-processor SOC 2 reports or bridge letters.
Artifact 3: Acceptable Use Policy & Training Records
An Acceptable Use Policy explicitly detailing permitted and prohibited AI tool usage, along with signed employee acknowledgment logs or security training completion records.
Artifact 4: Technical Configuration Evidence
Screenshots or export logs showing:
- Workspace admin settings with “Model Training” explicitly toggled off.
- SSO / MFA enforcement for the AI workspace.
- Committed ignore files in source control repository roots.
Artifact 5: Code Review Sample Evidence
PR sampling showing that code generated or assisted by AI underwent standard peer review, automated linting, and CI/CD security scanning prior to merge.
Summary Auditor Evidence Mapping Table
| SOC 2 Criterion | AI Risk Area | Required Audit Artifact |
|---|---|---|
| CC6.1 Access | Unauthorized tool access | SSO / SCIM provisioning & MFA enforcement logs |
| CC6.3 Confidentiality | Secret/data leakage | Repository ignore files, secret scanner logs, DPA |
| CC8.1 Change Mgmt | Unreviewed AI code | Peer review approvals on PRs containing AI code |
| CC9.2 Vendor Risk | Unvetted AI SaaS | Vendor SOC 2 report, annual vendor risk assessment |
Why Type II changes what counts as evidence
This is the distinction that catches teams out, and it is worth being exact about.
A Type I report tests whether controls are suitably designed at a single point in time. A Type II report tests whether they operated effectively throughout a period — typically six to twelve months.
The consequence is that a screenshot taken the week before fieldwork proves almost nothing for Type II. If your workspace training toggle was switched off in March and the audit period began in January, you have two months where the control did not operate, and the auditor will say so. Configuration screenshots are point-in-time artefacts being used to evidence a continuous state.
What actually satisfies a Type II test is evidence with dates spread across the window: change logs showing when a setting was applied and that it was not altered, periodic access reviews performed on a schedule you can demonstrate, tickets or approvals recorded when each tool was onboarded, and samples drawn from across the period rather than the end of it.
The practical implication is that the time to instrument this is before the audit window opens, not before fieldwork. Once the period has started, gaps in it cannot be filled retroactively without the auditor noticing — and attempting to is a far worse finding than the original gap.
Scope: which AI tools are actually in the audit
Not every AI tool your organisation uses falls inside the audit boundary, and conflating the two produces either wasted effort or a nasty surprise.
The question the auditor asks is whether the tool touches the systems and data in scope for the services covered by your report. A coding assistant used by engineers on the in-scope production codebase is squarely in. A marketing team’s copywriting tool that never touches customer data or production systems generally is not — though it may raise separate GDPR questions.
Three cases sit awkwardly and are worth resolving early with your auditor rather than during fieldwork:
AI features inside existing in-scope vendors. Your ticketing system, code host or observability platform adding an AI summarisation feature does not create a new vendor, but it may materially change the data flow of one already in scope. Auditors increasingly ask whether these features were assessed when enabled.
Agents with tool access. A system that can read repositories, call internal APIs or execute actions is not a chat interface; it is a non-human identity with permissions, and it belongs in access control testing. Its credentials need scoping, rotation and review like any service account. Securing an AI agent that has tool access covers the control set.
Shadow usage. If unapproved tools are processing in-scope data, the control gap exists whether or not anyone documented it. Shadow AI: finding unapproved tools covers discovery, and doing that sweep before the audit is considerably more comfortable than during it.
The four findings that come up most
No evidence the vendor was assessed before adoption. The assessment exists, performed a fortnight before fieldwork, dated accordingly. CC9.2 expects vendor risk management to be a process, and a process has a record at the point of onboarding.
Deprovisioning gaps on AI tooling. Departed employees retain access because the tool was bought on a corporate card and never connected to SSO or SCIM. This is the single most common AI-related access finding, and it is also the easiest to prevent — routing every tool through SSO makes the offboarding evidence a by-product of a process you already run.
Personal accounts on consumer tiers. Individual subscriptions expensed by staff operate under consumer terms, typically without a DPA, frequently with different retention and training defaults. From an audit perspective there is no contract to evidence and no vendor to assess. Free vs paid AI tools: what actually changes in the terms covers what differs.
Policy without acknowledgement. An acceptable use policy exists; nobody can show that staff read it. Signed acknowledgements or training completion records are what convert a document into a control. Writing an AI acceptable use policy that people follow covers drafting one worth acknowledging.
Reading a vendor’s own report properly
Collecting the vendor’s SOC 2 is a checklist item. Reading it is where the value is, and three parts matter more than the opinion on the first page.
The scope section tells you which systems and services the report covers. A report covering the vendor’s enterprise platform may not cover the consumer product your staff are actually using, and they are frequently different systems.
The exceptions. Any test with an exception noted is a control that failed during the period. A clean report with no exceptions across hundreds of tests is unusual enough to be worth a second look at the scope.
The complementary user entity controls. This section lists what the vendor assumes you are doing — enforcing SSO, configuring retention, managing your own users. These are your obligations, they are frequently ignored, and your auditor will check whether you perform them. It is the most-skipped and most useful page in the document.
Where the period covered by the vendor’s report does not span your own audit window, ask for a bridge letter covering the gap.
To systematically assess vendors before your audit window, use our framework on how to judge an AI provider, and the AI vendor security questionnaire for the assessment record CC9.2 expects you to have made at onboarding.