SOC 2 is the de-facto security attestation for B2B SaaS companies, and in 2026 nearly every enterprise software procurement involves a SOC 2 Type II report. What very few of those reports address is the explosion of generative AI use inside the audited organization. Engineers paste proprietary code into GitHub Copilot. Customer success managers summarize support tickets in ChatGPT. Finance teams draft board materials in Claude. Each of these interactions may affect the organization's SOC 2 posture — specifically the Confidentiality and Security criteria — yet most SOC 2 programs have not caught up.

This guide explains how AI tool usage intersects with the AICPA Trust Service Criteria (TSC), what evidence auditors are starting to request, and the controls that satisfy SOC 2 requirements without blocking the productivity gains that made AI tools worth adopting.

SOC 2 fundamentals and the Trust Service Criteria

SOC 2 is not a standard with pass/fail rules — it is an audit framework in which a CPA firm tests whether an organization's controls are suitably designed and operating effectively to meet one or more Trust Service Criteria. The five criteria are:

Security (CC) — the required baseline; covers logical and physical access, change management, risk mitigation.
Availability (A) — system uptime and performance commitments.
Processing Integrity (PI) — complete, accurate, timely processing.
Confidentiality (C) — protection of information designated as confidential.
Privacy (P) — collection, use, retention, disclosure, and disposal of personal information.

For AI tool usage, Security and Confidentiality are the most directly implicated. Privacy is secondarily relevant if customer personally identifiable information (PII) reaches AI tools.

How AI tools affect the Confidentiality criterion

The AICPA defines confidential information as "information designated as confidential" and requires controls that:

Identify and maintain information designated as confidential (CC6.1 / C1.1).
Restrict access to confidential information to authorized personnel (CC6.3).
Ensure confidential information is protected during transmission (CC6.7).
Dispose of confidential information according to stated policy (C1.2).

The AI tool problem. When an employee pastes customer data, source code, board presentations, or M&A due diligence into ChatGPT, they are transmitting confidential information to a third party outside the organization's access controls. Whether that constitutes a confidentiality breach under SOC 2 depends on:

How the organization defines "confidential information" in its information security policy.
Whether the AI vendor has contractual obligations not to use or disclose that information.
Whether the transmission was authorized under acceptable-use policies.
Whether the auditor characterizes the AI tool as a sub-processor subject to vendor management controls.

Most organizations' SOC 2 programs classify customer data, source code, financial projections, and personnel records as confidential. Pasting any of those into a consumer AI tool is almost certainly unauthorized under those policies — even if no policy explicitly names AI tools.

How AI tools affect the Security criterion

Several Security common criteria are relevant:

CC6.6 — Logical access to system components. The organization prevents unauthorized access through system boundaries. AI tool usage creates a new outbound data pathway. If employees can freely transmit production data to AI tools, the organization's logical access controls are partially bypassed.

CC6.7 — Transmission of information. Controls must protect transmission of confidential information. Unencrypted, unmonitored transmissions to consumer AI tools via the browser may not satisfy this criterion depending on how the auditor interprets "protection."

CC9.2 — Vendor and business partner risk. AI vendors are third parties. The Vendor and Business Partner criterion requires that vendor risks be identified, assessed, and managed. An AI tool receiving confidential information that is not on the vendor inventory, not assessed, and not subject to a contractual agreement represents a gap in CC9.2.

CC2.2 — Communication of information security policies. Employees must be informed of their responsibilities. A SOC 2 program that does not include AI-specific policies is increasingly a gap that auditors will flag.

What auditors are asking in 2026

SOC 2 auditors (and the enterprises reviewing reports) are starting to include AI-specific inquiries. Common questions:

Does the organization have a policy addressing employee use of generative AI tools?
What AI tools are approved for use, and under what conditions?
Are AI vendors included in the vendor risk management program?
What contractual commitments do AI vendors provide for confidential information protection?
Are there technical controls (DLP, CASB, browser controls) that prevent unauthorized transmission of confidential data to AI tools?
Has the organization had any incidents involving AI tools and confidential data in the audit period?

Organizations that cannot answer these questions with documented evidence are likely to receive observations, management letter comments, or qualified opinions in jurisdictions where auditors are more conservative.

The shadow AI problem and SOC 2

The most common AI-related finding in SOC 2 audits is not that the organization approved AI tools without proper controls — it is that employees are using AI tools that the organization has not reviewed or approved at all. This is the shadow AI problem: the gap between sanctioned tools and actual usage.

Shadow AI creates multiple SOC 2 risks:

Vendor management gap: Unapproved vendors are not on the vendor inventory and have not been risk-assessed.
Policy gap: Employees using unapproved tools cannot be complying with AI-specific policies if no such policies exist.
Evidence gap: Auditors test controls in practice; shadow AI usage that surfaces during fieldwork (through log review, employee interviews, or incident discovery) undermines the evidence that policies are effective.

The antidote is a two-part approach: an AI inventory process that captures what employees actually use (not just what is approved), paired with technical controls that provide evidence of policy enforcement regardless of which tools are used.

The controls that satisfy SOC 2 requirements for AI

1. Acceptable-use policy with AI-specific language

Your information security policy must explicitly address AI tools. At minimum:

Define which AI tools are approved and for which use cases.
Prohibit transmission of defined confidential information categories to non-approved AI tools.
Require that AI vendors be added to the vendor inventory before use.
Specify incident-response steps for accidental transmission.

This feeds CC2.2 (communication of policies) and provides the documentary baseline for auditor review. See the AI Acceptable Use Policy template for annotated model language covering all seven sections an effective AI AUP needs.

2. Vendor inventory and risk assessments

Add all AI tools — approved and discovered — to your vendor inventory. For each:

Obtain the vendor's SOC 2 report (most major AI providers have Type II reports).
Review data retention, training, and confidentiality commitments.
Document the risk assessment and any residual risk accepted by management.

This feeds CC9.2 and provides evidence that vendor risks are managed.

3. Contractual protections

For AI tools that touch confidential information or customer data, obtain a DPA or contractual commitment with the following minimums:

Restriction of vendor's use of your data to service delivery.
Prohibition on training models on your data without consent.
Retention limitations and deletion obligations.
Breach notification obligations.

Enterprise tiers of ChatGPT, Claude, Gemini, and Microsoft Copilot provide these terms; consumer tiers do not.

4. Technical controls for data classification

Data loss prevention (DLP) tools and AI-aware CASB products can inspect traffic to AI tools and block or log transmissions of classified data. For organizations with mature DLP programs, extending policies to cover AI endpoints is a natural extension.

For organizations without DLP, a local-first browser extension that detects and masks confidential data patterns — PII, financial identifiers, proprietary keywords — before AI submission provides a lightweight but effective control that generates no logs of the unredacted data itself (important for privacy of the privacy tool). See Sonomos vs. cloud DLP for a side-by-side of the two approaches.

5. Evidence of operating effectiveness

SOC 2 Type II audits test whether controls operated effectively over the period, not just whether they exist. Evidence to maintain:

Screenshots or logs showing AI tools configured per policy (training disabled, data sharing disabled).
Vendor risk assessment records updated annually.
Employee acknowledgment of AI acceptable-use policy.
Incident logs (including near-misses) for the period.
DLP / CASB alert logs for AI tool traffic.

Frequently asked questions

Does having a SOC 2 report mean an AI vendor is safe to use?

A SOC 2 Type II report from an AI vendor attests that the vendor's own internal controls were suitably designed and operating effectively. It is necessary but not sufficient for procurement: you still need to review their data use terms (whether they train on your data), their data retention commitments, and whether their DPA/BAA covers your regulatory obligations. A SOC 2 report answers "is this vendor well-run?"; it does not answer "will this vendor protect my confidential information in the way I need?"

Should AI tools appear in our SOC 2 system description?

If an AI tool is part of a service commitment or system boundary (e.g., an AI feature built into your product, or an AI tool that processes customer data as part of service delivery), it should be described in the System and Organization Controls description. If employees use AI tools internally for productivity without customer data touching those tools, it typically does not need to be in the system description, but it should be covered by your vendor management and acceptable-use programs.

Can we use AI to help draft our SOC 2 documentation?

Yes, with appropriate judgment. Using ChatGPT or Claude to draft policy language, risk assessment prose, or control descriptions is common and generally low-risk, as long as you are not pasting customer data or proprietary trade secrets into the prompt. The final documentation should be reviewed and approved by qualified personnel — AI output is a starting draft, not a compliance deliverable on its own.

What if our employees are using consumer ChatGPT despite a prohibition?

This is the shadow AI enforcement challenge. Technical controls (DLP, network monitoring, browser policies) are more reliable than policy alone. If you detect violation through log review or an incident, document it, respond per your incident procedures, and update your controls to prevent recurrence. Auditors expect that policies will occasionally be violated; they want to see that violations are detected and addressed, not that violations never happen.

How do AI coding assistants affect SOC 2 change management?

SOC 2's CC8 (Change Management) requires that changes to the system be authorized, tested, and approved. AI-generated code is not exempt. If a developer uses GitHub Copilot or Cursor to write code that is deployed to production, that code must go through the same review and approval workflow as manually written code. The AI tool is a code generation aid; the change management controls apply to the output, not the generation method.

Does our AI vendor need their own SOC 2 to satisfy CC9.2?

CC9.2 requires that vendor risks are assessed, but it does not mandate SOC 2 specifically. A SOC 2 Type II report is the most convenient evidence, but other acceptable approaches include ISO 27001 certification, independent pen test results, or an annual questionnaire with management's review of the responses. Most enterprise AI vendors have SOC 2 Type II reports; if a vendor cannot provide one or equivalent documentation, that is itself a risk factor to document.

A practical SOC 2 AI readiness checklist

Inventory all AI tools currently used by employees — approved and unapproved.
Update the acceptable-use policy to explicitly cover AI tools with prohibited data types and approved configurations.
Add AI vendors to the vendor inventory; complete risk assessments; obtain SOC 2 reports.
For tools processing customer data, execute a DPA or equivalent contractual commitment.
Configure approved AI tools per policy (training disabled, data sharing disabled where available).
Deploy technical controls (DLP, CASB, or local-first browser extension) to prevent unauthorized transmission.
Collect evidence of control operation for the next audit period: logs, screenshots, acknowledgment records.
Brief your auditor on your AI governance program before fieldwork starts — surprises during testing are harder to address than proactive disclosure.

The bottom line

SOC 2 and AI are not inherently in conflict. The conflict arises when organizations adopt AI tools faster than their governance programs can adapt — leaving vendor management gaps, policy gaps, and evidence gaps that auditors will find. The organizations that handle this best in 2026 are those that treat AI tools like any other technology: inventory them, assess the risk, put contractual protections in place, deploy technical controls, and collect evidence that the controls work. That posture satisfies SOC 2's Confidentiality and Security criteria without requiring organizations to ban AI or limit its use to only the most conservative configurations.

SOC 2 and AI: What Auditors Look For When Your Team Uses ChatGPT and Claude