Two years ago, “AI policy” was a nice-to-have on a security questionnaire. Today it is a standard request. Enterprise customers ask whether staff can paste customer data into public chatbots, whether prompts are used to train third-party models, and who approves new AI tools. Auditors who read your system description increasingly ask the same things.
This guide explains how AI use fits within SOC 2, what an AI acceptable use policy (AUP) should contain, which evidence supports it, and where teams commonly go wrong. It is practical guidance, not legal advice.
Does SOC 2 have AI-specific criteria?
As of our research for this article, the AICPA has not published AI-specific Trust Services Criteria. The criteria were last substantively revised in 2017 with updated points of focus in 2022, and AI use is evaluated within the existing categories. Secondary sources report that an AICPA technical Q&A issued in September 2026 (TQA Section 9561) takes the same position: AI does not create a separate SOC examination model, and its effect depends on how the organization uses it and whether that use touches in-scope services, systems, risks and controls. We recommend confirming the latest on the AICPA SOC suite page, since guidance in this area is moving quickly.
In practical terms, that means your AUP is evidence for controls you already have, not a new mandated artifact. For a broader view of the topic, see our guides on SOC 2 for AI and what changes for AI companies.
Two different AI scenarios
| Scenario | Example | SOC 2 impact |
|---|---|---|
| AI used internally by staff | Engineers use a coding assistant; support drafts replies with a chatbot | Mostly a confidentiality, access and vendor-management question. May have little effect on the report if no in-scope data is exposed, but customers will ask. |
| AI embedded in your service | Your product uses a model to generate outputs or make decisions for customers | Affects the system description, risk assessment, processing integrity, change management and subservice organization treatment. |
An acceptable use policy primarily addresses the first scenario. The second needs product-level governance, such as model change control, output testing and disclosure in the system description, which goes beyond a staff policy.
How AI risks map to existing criteria
| AI risk | Relevant criteria | Control example |
|---|---|---|
| Staff paste customer data into an unapproved tool | C1.1 (confidential information), CC6.1, CC6.7 | Data classification rules and approved tool list |
| Vendor retains or trains on your prompts | CC9.2 (vendor risk), C1.1 | Vendor review of terms, enterprise plans with training disabled |
| No inventory of AI tools in use | CC3.2, CC2.1 | AI tool register maintained and reviewed |
| AI-generated code introduced without review | CC8.1 | Peer review and testing apply to all code regardless of origin |
| Incorrect AI output affects customers | PI1.1 and PI1.2 if Processing Integrity is in scope | Output validation and human review |
| Prompt injection or data leakage through AI features | CC6.6, CC7.2 | Security testing and monitoring of AI integrations |
| Personal data entered into AI tools | P-series criteria if Privacy is in scope | Rules on personal data and lawful use |
What an AI acceptable use policy should contain
1. Purpose and scope
State who the policy covers (employees, contractors, interns) and which tools it applies to: generative chat tools, coding assistants, meeting transcription bots, browser extensions and AI features inside existing SaaS products.
2. Approved and prohibited tools
Maintain a list of approved tools with the data types permitted in each. Specify that unapproved tools may not be used with company or customer data. Include a simple request process for new tools so staff are not forced into shadow IT.
3. Data handling rules
Tie the policy to your data classification scheme. A clear table works well: public data allowed in approved tools, internal data allowed only in enterprise-licensed tools with no training on inputs, and customer data, credentials, secrets, health or payment data prohibited unless a specific approved use case exists.
4. Human oversight and accuracy
Require that people review AI output before relying on it, especially for code, customer communications, legal or contractual content, and security decisions. Responsibility remains with the human who uses the output.
5. Intellectual property and licensing
Address ownership of generated content, open-source license risk in generated code, and restrictions on submitting third-party confidential material to a model.
6. Vendor and contract requirements
Specify minimum vendor terms: no training on your data by default, defined retention, encryption, subprocessors disclosed and security assurance such as a SOC 2 report. Route AI vendors through your third-party risk management process. If a model provider supports a service you deliver, evaluate whether it becomes a subservice organization, as described in our article on subservice providers.
7. Incident reporting
Tell staff to report accidental disclosure of sensitive data to an AI tool immediately, and connect this to your incident response plan.
8. Monitoring, enforcement and exceptions
Explain how compliance is monitored (for example, SaaS discovery, DLP or browser controls), consequences of violations and how exceptions are approved and recorded.
9. Ownership and review
Name a policy owner, require annual review and capture approval. This version history is itself audit evidence.
Evidence to keep for the audit
- The approved AI AUP with version history and management sign-off.
- Employee acknowledgements and training records covering AI use.
- The AI tool inventory, with owners, data permitted and approval dates.
- Vendor review records and contract terms for approved AI vendors.
- Technical enforcement evidence, such as blocked domains, SSO enforcement or DLP rules.
- Records of approved exceptions and any related incidents.
- Risk assessment entries showing AI risks were considered, per your risk assessment process.
Common mistakes
- A ban nobody follows. A blanket prohibition drives usage underground. Offer approved options instead.
- Policy without enforcement. If you can’t show any technical or procedural check, auditors will see a policy that exists only on paper.
- Ignoring AI features inside existing tools. Meeting recorders, CRM assistants and ticketing summaries may process customer data without anyone formally approving them.
- Treating AI code as exempt from change management. Your secure SDLC review and testing steps apply to generated code too.
- Overstating compliance. Do not claim in sales material that your AI use is “SOC 2 compliant” unless the examined scope actually covers it. SOC 2 is an attestation report on a defined system, not a badge on every tool.
What this means for your business
If your company sells to enterprises, an AI AUP shortens security reviews because it answers a question that now appears in nearly every questionnaire. If your product itself uses AI, the stakes are higher: your system description and risk assessment should reflect it, and you should discuss scope with your auditor early.
Our SOC 2 readiness service can review your AI policy and tool inventory alongside the rest of your control set, and our 24×7 GRC chat and Slack support helps keep approvals and evidence current as new tools appear. This article is general guidance and not legal advice; consult counsel on privacy and IP obligations.
Rolling out the policy in four weeks
Policies fail when they are published and forgotten. A short rollout plan turns the document into practice.
- Week 1: discover. Survey teams about the AI tools they already use, including features inside existing SaaS products. Use SSO logs or browser reports to catch what surveys miss.
- Week 2: decide. Review each tool against your vendor criteria, approve a short list and record the permitted data types for each.
- Week 3: publish and train. Release the policy with a one-page summary, short examples of allowed and prohibited use and a clear request path for new tools. Collect acknowledgements.
- Week 4: enforce and measure. Block or monitor unapproved tools where feasible, set up a quarterly review of the inventory and record the first review.
Concrete examples help more than abstract rules. “Do not paste customer names, tickets or contract text into unapproved tools” is easier to follow than “protect confidential information.” Keep the policy and training aligned with your security culture efforts, and revisit it whenever a new class of tool becomes common.
Frequently asked questions
Is an AI policy required for SOC 2?
Not by name. SOC 2 evaluates risk and controls, and AI use that touches in-scope data or services falls under existing criteria. A written policy is the standard way to demonstrate those controls.
Can employees use ChatGPT or similar tools under SOC 2?
Yes, if your policy allows it and the risks are controlled. Define which tools and plans are approved, what data may be entered and how vendors handle that data.
Does using a third-party AI model make it a subservice organization?
It can, when the model provider performs a function that is part of the system you describe and is relevant to your service commitments. Discuss the carve-out or inclusive method with your auditor.
Do we need to disclose AI use in our SOC 2 system description?
If AI is part of the in-scope system or materially affects how services are delivered, it should be described appropriately. Internal-only productivity use usually does not need to be, but your auditor will advise.
How do auditors test an AI policy?
They typically inspect the policy and approval, check employee acknowledgement, review the tool inventory and vendor assessments, and look for evidence of enforcement, such as technical controls or exception records.
Should the AI policy be separate from the general acceptable use policy?
Either works. Many companies add an AI section to the existing acceptable use policy, while others create a standalone document for clarity. What matters is that it is approved, communicated and enforced.
Conclusion
An AI acceptable use policy turns a vague worry into a set of controls an auditor can test: approved tools, data rules, vendor review, human oversight and incident reporting. It is not a SOC 2 mandate, but it is quickly becoming the evidence customers expect. Write it plainly, enforce it with real controls and review it as often as the tools change.
