How to Add AI Tools to Your SOC 2 Program

SOC 2 Type II audits increasingly include questions about AI tool usage. If your team uses ChatGPT, Claude, Copilot, or any other AI tool, and you have not explicitly scoped this into your control environment, you have a gap.

The good news: AI tools do not require a new control framework. They slot into your existing SOC 2 program, primarily through vendor risk management, data transmission controls, and your acceptable use policy. This guide covers exactly which criteria are affected, what evidence you need, and what your AI AUP must say to satisfy auditors.

TL;DR: AI tools affect SOC 2 primarily through CC6.1 (logical access), CC6.7 (data transmission), and CC9.2 (vendor monitoring). To satisfy auditors, you need: an approved AI tools list, a risk tier for each tool, signed DPAs, and an AI acceptable use policy that explicitly covers what data employees may and may not submit. Most SaaS teams can integrate AI into their existing SOC 2 program in one documentation sprint without changing their control structure.

Why SOC 2 Auditors Are Now Asking About AI

Two years ago, AI tools were a footnote in SOC 2 audits. Now they are a standard line of inquiry. The reason is straightforward: employees routinely send company data, customer information, internal documents, source code, financial data, to external AI providers. From a SOC 2 perspective, this is a third-party data transmission, and it must be controlled and evidenced like any other.

Auditors check for three things:

1. Does the organization know which AI tools employees are using?
2. Are those tools assessed for vendor risk?
3. Is there a policy preventing unauthorized data from being submitted?

If the answer to any of these is "we handle it informally," you have a finding waiting to happen.

Which Trust Service Criteria AI Affects

For most SaaS companies, CC6.7 and CC9.2 are the primary focus areas. CC6.1 matters if AI tool access is role-restricted (e.g., only engineers can use Copilot, not support staff).

The 3-Step Process: Inventory, Risk Tier, Document

Step 1: Build Your AI Tool Inventory

List every AI tool in active use across your organization. Include:

• Approved tools: those your IT or security team has reviewed
• Shadow AI: tools employees use that have not been formally approved (run a survey or check SSO logs)

For each tool, capture: tool name, vendor, plan/tier, what data is processed, and who uses it.

Step 2: Assign a Risk Tier

Not all AI tools carry the same risk. Tier them:

Tier 1 (Low risk): AI tools that process no company data, e.g., a coding autocomplete tool with telemetry disabled, an image generation tool used only with placeholder content.

Tier 2 (Medium risk): AI tools that receive internal company data but not customer personal data, e.g., an internal knowledge base AI, a meeting summarizer for internal calls only.

Tier 3 (High risk): AI tools that receive customer personal data, financial data, or regulated data, e.g., a customer support AI that sees ticket content, a sales AI with CRM access.

Tier 3 tools require a signed DPA, documented retention limits, and potentially additional contractual controls. Tier 1 tools may require only a brief risk note. Tier 2 sit in between.

Step 3: Document and Link to Controls

Create a vendor risk record for each Tier 2 and Tier 3 AI tool in your vendor management system (Vanta, Drata, Secureframe, or a spreadsheet). Include:

• Vendor name and tool
• Risk tier
• DPA signed? (Yes/No/Link)
• SOC 2 report available? (Y/N, most major AI providers publish one)
• Last review date
• Control owner

This documentation is what your auditor reads. It demonstrates CC9.2 compliance directly.

What Your AI Acceptable Use Policy Needs to Say

Your existing AUP may reference internet use, email, and software installation. AI tools need a dedicated section. At minimum, for SOC 2 purposes, your AI AUP should cover:

1. Approved tools list. Name the tools employees are authorized to use. "Any AI tool the employee finds useful" is not an answer auditors accept.

2. Data classification rules. Specify which data categories are permitted in each tool tier. Example: "Tier 2 AI tools: internal documents permitted; customer personal data prohibited. Tier 3 AI tools: permitted only with a signed DPA and security review."

3. Output review requirements. AI-generated code, customer communications, and compliance documents must be reviewed by a human before use. State this explicitly.

4. Incident reporting. If an employee accidentally submits prohibited data to an AI tool, how should they report it? Link to your incident response process.

5. Control owner. Name the role responsible for AI tool governance (typically Security, IT, or a designated AI lead).

The AI AUP does not need to be long. Two pages covering these five points is enough. What matters is that it exists, is dated, and employees have acknowledged it.

The Evidence Package for Your Auditor

When your SOC 2 audit includes AI tool questions, you should be able to produce:

Most of this evidence overlaps with documentation you already maintain. The AI-specific additions are the tools inventory, risk tiers, and the AI AUP section.

Common Mistakes That Create Findings

Not disclosing shadow AI tools. If employees use AI tools that are not in your inventory and an auditor discovers this through interviews, it is a control gap, even if the tool itself is low-risk.

Generic AUP language. "Employees should use AI tools responsibly" does not satisfy CC6.8. Auditors want specific data classification rules.

Treating AI vendors as low-risk by default. Any vendor that receives company data requires a risk assessment, regardless of how popular they are.

Relying on vendor's SOC 2 report as your entire control. Your AI vendor having SOC 2 Type II covers their environment. It does not cover your data handling decisions (what data you choose to send, who has access, your retention practices).

How to Handle AI Tools Added After Your Last Audit

SaaS teams add AI tools constantly, new Copilot integrations, AI features added to existing tools, and team-adopted assistants that expand between audit cycles. The gap most auditors now probe: tools adopted after your last audit that have not been through the risk-tier process.

The practical fix is a lightweight AI tool intake form that triggers automatically when a new SaaS tool is provisioned. The form asks three questions: Does this tool use AI features? Does it receive company data? What tier does it belong to? This takes two minutes to complete and creates the documentation trail that shows auditors your control environment catches new tools before they become finding fodder.

For teams using compliance platforms like Vanta or Drata, create a custom control linked to the AI tool intake form and set a 30-day review cycle. This turns AI tool governance from a point-in-time exercise into an ongoing monitored control, which is what SOC 2 Type II auditors are looking for.

What Auditors Are Now Asking About AI in 2026

SOC 2 audit scope for AI has expanded beyond vendor risk. In 2026, auditors at several major firms are now asking:

• Does your AI AUP address hallucination risk, specifically, does it require human review of AI output before it is used in customer-facing or financial contexts? This falls under CC6.8 (unauthorized disclosure) and CC4.2 (fraud risk).
• Do employees who use AI tools receive specific training, or is your onboarding general IT security training? Auditors are distinguishing between generic training acknowledgment and AI-specific training that covers data classification and output review.
• If your product relies on AI uptime, have you assessed the business impact of AI vendor outages? This falls under A1.1 (availability) and is increasingly standard for SaaS companies whose core features include AI components.

None of these require new controls from scratch. They require adding AI-specific language to existing controls and ensuring your training records distinguish AI tool training from general security awareness. Review your most recent SOC 2 management response letter, if AI tools appear in any auditor observation, address it before the next cycle with a specific documented control rather than a general policy update.

Ready to assess your AI tool risk? Use the AI Risk Assessment to rate each use case from Low to Critical. Then use the Policy Generator to create an AI acceptable use policy that includes the SOC 2-relevant clauses your auditors need.

What SOC 2 Auditors Actually Ask About AI Tools in 2026

Based on patterns emerging from SOC 2 Type II audits in 2025 and early 2026, auditors at firms covering SaaS companies are converging on a short set of AI-specific questions that fall outside the standard control questionnaire.

"Show me your approved AI tools list." Auditors expect a list, not a policy statement that says tools are evaluated, but an actual list with the tools, approved data classifications, and the date of last review. A spreadsheet with five rows is more credible than a three-page policy document with no list. This maps to CC6.1 (logical access) because the approved tools list is a form of access control.

"Who is responsible for reviewing AI vendor terms?" This is a vendor monitoring question (CC9.2). The acceptable answer is a named role or individual. "The team" or "IT" is not acceptable. Teams without a named AI tool owner for each critical vendor should assign one before the audit.

"Do your employees sign anything specific to AI tool use?" Acceptable acknowledgment exists in two forms: a standalone AI acceptable use policy signed separately, or AI-specific clauses added to the existing security training acknowledgment with a dated signature. The key is that employees have seen and acknowledged the specific restrictions on AI data handling, not just a general "use company resources appropriately" clause.

These three questions are not in the standard SOC 2 CCM questionnaire, they are being added informally by auditors who are ahead of the formal standard updates. Preparing documented answers to all three before fieldwork begins eliminates the most common AI-related management responses in current SOC 2 cycles.

Related Reading

• AI vendor due diligence checklist
• Privacy-first AI APIs, which don't train on your data
• AI coding tools governance policy
• AI governance guide for small teams
• Governing embedded AI in third-party tools
• AI data privacy for small teams, GDPR/CCPA