Do AI tools like ChatGPT count as vendors under SOC 2?

Yes. Any AI tool that receives company or customer data is a third-party vendor under SOC 2 CC9.1. OpenAI, Anthropic, GitHub, Microsoft, and Google all qualify if your team sends data to their AI products. Each should be in your vendor inventory with a risk tier, DPA reference, and current SOC 2 or ISO 27001 report on file.

Does using GitHub Copilot or ChatGPT expand my SOC 2 audit scope?

Yes. AI tools create new data flows to external systems that auditors will trace. Your audit scope now includes the vendor relationship, the data classification of what is sent, your acceptable use policy, and access controls over who can use the tools. Auditors are asking these questions as standard fieldwork in 2026.

What SOC 2 policy do I need for AI tools?

You need a written AI acceptable use policy covering which tools are approved, which data classifications each tool may receive, the approval process for new AI tools, and consequences for violation. This satisfies the CC1 documentation requirement. Auditors will ask to see it, so it needs to exist before fieldwork begins.

Can employees use ChatGPT free for work under SOC 2?

No. The free ChatGPT tier does not provide a Data Processing Agreement and may use prompts for model training. Under SOC 2, sending company or customer data to a tool without a DPA and appropriate data handling terms is a vendor management gap. Employees should be on ChatGPT Teams or the OpenAI API with a signed DPA.

What happens if an employee pastes customer data into an AI tool?

From a SOC 2 perspective, this is a data handling incident. The data has been sent to an external system, potentially without a DPA or appropriate controls. It should be documented in your incident log, the vendor relationship assessed, and your acceptable use policy reviewed. Recurring violations suggest a training or enforcement gap.

AI tools and SOC 2: what changes when your team uses ChatGPT and Copilot

Almost every SaaS team now uses AI tools. Engineers paste code into ChatGPT to debug it. Sales reps draft outreach with Claude. GitHub Copilot writes a meaningful percentage of production code. Customer support feeds tickets into a model to summarize them. Each of these tools is, from a SOC 2 perspective, a third-party data processor. That changes your audit scope, your vendor inventory, and the policies you need to have in writing. Auditors are noticing, and the questions are becoming standard.

12+ AI tools are now in a typical SOC 2 scope

Why AI tools matter for SOC 2

The Trust Services Criteria were not written with large language models in mind, but they apply cleanly. When your team sends data to OpenAI, Anthropic, or any other model provider, you have created a data flow to an external system. CC9.1 requires you to assess and manage that vendor relationship. CC6 requires logical access controls on the data being sent. CC1 requires acceptable use policies that govern employee behavior with company systems and data.

The auditor's question is straightforward. What customer data, source code, or sensitive internal information leaves your environment to reach an AI provider? Once it leaves, who controls it, how long do they keep it, and what happens to it? You need defensible answers to all of these.

Vendor inventory implications

AI providers are vendors. They belong in your CC9.1 vendor inventory the same way AWS or GitHub does, scoped according to what data they actually receive.

OpenAI is in scope if any team member uses ChatGPT or the OpenAI API for work tasks involving company or customer data. Anthropic is in scope if Claude is used for any of the same. GitHub is already in your inventory, but if you use Copilot, the scope of your GitHub relationship has expanded to include code that flows to a model and back. Microsoft is in scope if anyone uses Copilot in Word or the broader 365 suite on company documents. Google is in scope if Gemini is enabled inside Workspace.

Treat each as a critical-tier vendor unless you can clearly demonstrate that the data sent is non-sensitive. Critical tier means you collect their SOC 2 or ISO 27001 attestation, you confirm zero data retention or training opt-out terms in your contract, and you reassess annually.

The good news is that the major model providers know this conversation is coming. OpenAI publishes a SOC 2 Type II report. Anthropic publishes a SOC 2 Type II report. Both offer enterprise terms that include zero data retention and explicit no-training commitments. If your contract still defaults to consumer terms, that is a finding waiting to happen.

Data classification before AI use

Before authorizing AI tools, classify your data. A simple three-tier model works for most companies. Public or non-sensitive information can be sent to any approved AI tool. Internal but non-customer data can be sent only to AI tools under enterprise contracts with no-training and short-retention terms. Customer data, regulated data, source code containing secrets, and credentials must never be sent to general-purpose AI tools.

The third tier is where most violations happen. Engineers paste a stack trace that includes a customer email address. A sales rep uploads a contract draft that contains pricing terms. A support agent feeds a ticket containing personally identifiable information into a public chat interface. Each of these is a data exfiltration event from a control standpoint, even though the intent was harmless.

Make the rules explicit and concrete. Vague guidance produces vague compliance. Specific rules with examples produce behavior change.

Acceptable use policy

Tip

You need a documented AI acceptable use policy. The auditor will ask for it. The policy should define which AI tools are approved for which data classifications, name the approval owner for new AI tools, prohibit putting credentials or customer data into unapproved tools, require employees to acknowledge the policy at hire and annually, and describe the consequences of violation.

If you do not have this policy in writing today, write it before your next audit window opens. A short, clear, two-page policy is better than no policy at all. You can refine it later as your AI usage matures.

CC9.1 assessment for AI vendors

Run the same vendor assessment you run on any critical vendor. Request the SOC 2 report. Confirm the audit period is current. Read the exceptions. Verify the scope covers the API or product you actually use. Save the evidence in your vendor folder. Set the next reassessment date.

For OpenAI and Anthropic, the reports are publicly accessible through their trust portals. For GitHub Copilot, the relevant attestations roll up under GitHub's broader SOC reporting. For Google and Microsoft, enterprise customers can request the relevant SOC and ISO reports through standard channels.

What you should be looking for is not just the existence of a report but the contractual data handling terms. Many incidents start when a free or trial tier of an AI tool defaults to using prompts for training, while the enterprise tier opts out. Verify the tier you are actually on matches the controls you assume.

If you use AI in your product

Consuming AI tools internally is one thing. Building AI into your product creates a different and larger scope expansion. Now the controls apply to you, not just to your provider.

You will need access controls on which users and services can call the model. You will need rate limits and per-tenant cost caps to prevent runaway behavior. You will need audit logging of every AI call, capturing at minimum the tenant, the timestamp, the model used, the token count, and the result. You will not log raw prompts or responses if they contain sensitive data, but you will log enough metadata to investigate any incident.

Prompt injection becomes a security risk worth modeling. If your product accepts user input and feeds it to a model, an attacker may attempt to manipulate the model into ignoring its instructions, leaking system prompts, or producing harmful output. Document how you mitigate this. The auditor will not necessarily test the mitigations, but they will expect to see that you considered the risk.

If your product makes decisions affecting customer data based on AI output, you will also need a defined process for human review or override. Fully autonomous AI decisions on sensitive data are a hard sell to auditors and to customers.

Questions auditors are starting to ask

The standardization of AI questions in audit fieldwork is already underway. Expect to be asked:

Which AI tools your team uses
Whether you have a written AI acceptable use policy
Whether AI tools are in your vendor inventory
What data classification rules govern AI use
Whether your product incorporates AI-generated content or decisions
How you handle AI provider security incidents

If you can answer all of these in five minutes with documentation in hand, you are ahead of the curve. If any of these takes a meeting to figure out, fix the gap before fieldwork starts.

Next steps

Per-tenant data isolation, PII stripping, and audit logging for AI calls in production are the kind of controls a security leader designs before they become an audit finding. Read the continuous compliance glossary entry to understand how ongoing monitoring fits with AI vendor management, and if your company is building AI features or wants a certifiable AI governance framework, see the ISO 42001 guide for SaaS companies.

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.