Not with dedicated criteria. The Trust Services Criteria are technology-neutral, so an AI product is examined like any other system: access to it, changes to it, monitoring, vendors and the data it handles. AI-specific questions such as model evaluation or bias are outside SOC 2 unless your commitments to customers bring them in.

Do we need ISO/IEC 42001 instead of SOC 2?

They answer different questions. SOC 2 is an attestation report on your controls, commonly requested in US enterprise sales. ISO/IEC 42001 is a management system standard for AI. Some buyers ask about one, some about both, so start with what your customers ask for in their security reviews.

What should we say about training on customer data?

Say what is true, in writing, and make sure the product matches. If you do not train on customer data, say so in the contract or terms and check that each model provider's terms for your plan are consistent. If you do, say which data, under what consent or opt-out, and how it is protected. A written commitment is easier for a reviewer, and an auditor, to check than a general statement on a website.

Is the AI acceptable use policy one of the 22 policies?

No. The Acceptable Use Policy in the set has one rule on AI tools. The separate free AI acceptable use policy template goes further: approved tools, data rules, coding assistants and AI features in your product. It helps once AI tools are in daily use or customers ask how you govern them.

Are model providers subservice organizations?

Possibly. A subservice organization is a vendor whose controls you need in order to meet your commitments. A model provider that processes customer data may qualify, and if so it is named in your system description, with its controls either carved out or included. Discuss each one with your auditor.

SOC 2 for AI and machine learning companies

Updated 23 October 2026

Enterprise buyers evaluating an AI product ask the usual SOC 2 questions and a few more: what happens to the data they send, whether it trains your models or a provider's models, and how changes to models and prompts are controlled. SOC 2 has no AI-specific criteria, so those answers come from criteria that already exist: confidentiality, vendor risk, change management and data handling. This page covers that overlap and where to start.

Why enterprise buyers of AI products ask for SOC 2

Customers send prompts, documents and data that can contain confidential business information and personal data, and their security teams want to know where it goes and who can see it.
AI products commonly depend on model providers and inference or GPU hosts, which reviewers treat as subprocessors with access to customer data.
Enterprise security questionnaires can include AI-specific sections on training with customer data, retention of prompts and outputs, and human review, and a SOC 2 report covers the baseline controls so that conversation can focus on those.
Customers that build your model or API into their own products need evidence about your controls for their own audits.

Trust Services Categories commonly requested

Security is in every SOC 2 report. The other categories are optional and are added when customers ask for them or your contracts make commitments they cover. What follows is what enterprise buyers of AI products commonly request, not a rule; agree on the scope with your auditor before the examination period starts.

Category	Why it comes up	In the generator
Security	Included in every SOC 2 examination. The common criteria cover governance, risk assessment, access, change management, monitoring, incident response and vendor risk.	Always
Confidentiality C1.1, C1.2	Commonly requested because customers share confidential documents, code and data with the product, and Confidentiality covers identifying, protecting and disposing of that information.	Yes
Privacy	Commonly requested when the product processes personal information about end users, for example in prompts, transcripts or training data.	No
Availability A1.1, A1.2, A1.3	Commonly added when customers build your API or model into their own production workflows.	Yes

The generator’s scope question offers Security, Availability and Confidentiality. If your auditor scopes Privacy, the 22 policies are still a starting point (the Privacy and Data Protection Policy covers notice, use, retention and data subject requests), but those criteria need controls and evidence beyond what the policies describe.

Other frameworks that come up, and how they relate to SOC 2

Each framework below is published by its own standards body or regulator; the links go to them. This is a general description, not legal advice: whether a law or contract applies to you is a question for counsel.

Customer data used for training

Buyers want a clear written answer to whether their data trains any model, yours or a provider's. Write down what your contracts and terms say, check what each model provider's terms say for the plan and API you actually use, and make the product behave accordingly. SOC 2 has no criterion for training data, but once you make a commitment to customers, the examination considers whether your controls support your commitments, and the Confidentiality and Privacy criteria apply to it when they are in scope.

Keep in mind: Vendor terms differ between plans and change over time. Do not repeat a provider's marketing claim; record what its current terms say for your plan, and review them when they change.

Sources: SOC suite of services (AICPA & CIMA) · Free AI acceptable use policy template

Model and data governance: NIST AI RMF and ISO/IEC 42001

The NIST AI Risk Management Framework is a voluntary framework for managing risks from AI systems. ISO/IEC 42001 is an international standard for an AI management system that organizations can be audited against. Some enterprise buyers ask which of them you follow. Practices they describe, such as an inventory of models and data sets, documented data sources, evaluation before release and human oversight, can be supported by the risk assessment, change management and data classification policies you already have.

Keep in mind: Neither framework is part of SOC 2, and a SOC 2 report says nothing about whether you follow them.

Sources: NIST AI Risk Management Framework · ISO/IEC 42001 (ISO)

LLM application security

The OWASP Top 10 for Large Language Model Applications lists risks such as prompt injection, sensitive information disclosure and excessive agency. It is a useful reference when you threat-model features that call a model, which the Secure Software Development Policy asks Engineering to do for security-relevant features.

Keep in mind: It is a community risk list, not a standard you are assessed against.

Sources: OWASP Top 10 for LLM Applications

AI-specific laws

Laws such as the EU AI Act (Regulation (EU) 2024/1689) set obligations for some AI systems and the companies that provide or use them, depending on what the system does and where it is offered.

Keep in mind: Whether any AI law applies to you is a legal question for counsel. SOC 2 does not address it.

Sources: Regulation (EU) 2024/1689, the AI Act (EUR-Lex)

The 6 policies that matter most

All 22 policies apply to every company that uses them. These are the ones enterprise buyers of AI products read most closely, so review them first and make sure every statement matches how you actually operate. The template index lists the full set.

P06 Data Classification and Handling Policy: Decides which classes of data may be sent to which model providers, and is where a decision about using customer data for training belongs.
P16 Vendor and Third-Party Risk Management Policy: Model providers, inference hosts and labeling vendors are vendors with access to customer data; this is where their terms on training, retention and access are reviewed.
P02 Acceptable Use Policy: Contains the rule that staff use only approved AI tools and keep customer data, secrets and personal data out of other ones.
P09 Change Management Policy: Model versions, prompts and configuration that change product behavior can be handled as changes, with review, testing and a way to roll back.
P10 Secure Software Development Policy: Covers threat modeling and security review, where risks such as prompt injection and one customer's data appearing in another customer's results are addressed.
P07 Data Retention and Disposal Policy: Buyers ask how long prompts, outputs, embeddings and fine-tuning data are kept and how they are deleted at the end of a contract.

What to select in the generator

These answers change the policy text for AI and ML companies. The other questions (company, product, tools, owners, review cadence) are the same for everyone.

Question	Answer	What it changes
Sensitive data handled	Personal data (PII)	Select it if prompts, documents or training data can contain personal data. It adds data processing agreement requirements for vendors, which include model providers that receive that data.
Trust services categories in scope	Confidentiality	Add it if your auditor has scoped it. The policies then add rules for information customers have shared under confidentiality terms.
Application type	API (or Multiple, if you also have a web app)	If customers call your model through an API, the policies add rules for customer API keys and per-client rate limits.
Key vendors and subprocessors	Your model providers, inference hosts and vector database	Named vendors appear in the vendor, incident response and privacy policies, which is where reviewers look for the providers that receive customer data.

Questions an auditor may ask

Walkthrough questions in a SOC 2 examination follow the criteria, but the examples an auditor picks depend on what your product does. These are the kind that come up for AI and ML companies; the auditor interview prep sheet lists the questions per criterion with the sentences in your policies that answer them.

Which model providers receive customer data, and what do their terms say about training and retention for the plan you use?
How do you keep one customer's data out of another customer's results?
How is a change to a model, prompt or configuration reviewed, tested and rolled back?
Where are prompts, outputs and embeddings stored, who can access them and how long are they kept?
Which AI tools may employees use for company work, and what data may they put into them?
How do you delete a customer's data, including derived data such as embeddings or fine-tuned models?

Free tools for this

AI acceptable use policy template: Approved tools, data rules, coding assistants and AI in your product, in Word or Markdown.
System description template: Name model providers that are subservice organizations and draw the system boundary.
Security questionnaire answers: Draft answers to a buyer's questionnaire from your policies, then add the AI-specific ones.
Vendor security questionnaire template: Review model and inference providers before customer data reaches them.
SOC 2 readiness self-assessment: A quick score and a prioritized list of gaps.
Trust page generator: Publish your answer on training and data retention where buyers can find it.

Other industries

Frequently asked questions

Does SOC 2 cover AI?: Not with dedicated criteria. The Trust Services Criteria are technology-neutral, so an AI product is examined like any other system: access to it, changes to it, monitoring, vendors and the data it handles. AI-specific questions such as model evaluation or bias are outside SOC 2 unless your commitments to customers bring them in.
Do we need ISO/IEC 42001 instead of SOC 2?: They answer different questions. SOC 2 is an attestation report on your controls, commonly requested in US enterprise sales. ISO/IEC 42001 is a management system standard for AI. Some buyers ask about one, some about both, so start with what your customers ask for in their security reviews.
What should we say about training on customer data?: Say what is true, in writing, and make sure the product matches. If you do not train on customer data, say so in the contract or terms and check that each model provider's terms for your plan are consistent. If you do, say which data, under what consent or opt-out, and how it is protected. A written commitment is easier for a reviewer, and an auditor, to check than a general statement on a website.
Is the AI acceptable use policy one of the 22 policies?: No. The Acceptable Use Policy in the set has one rule on AI tools. The separate free AI acceptable use policy template goes further: approved tools, data rules, coding assistants and AI features in your product. It helps once AI tools are in daily use or customers ask how you govern them.
Are model providers subservice organizations?: Possibly. A subservice organization is a vendor whose controls you need in order to meet your commitments. A model provider that processes customer data may qualify, and if so it is named in your system description, with its controls either carved out or included. Discuss each one with your auditor.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.