Menu
On this page
- What is the latest AICPA guidance on AI and SOC 2?
- How do you scope SOC 2 for AI products and companies using AI?
- Which SOC 2 controls address AI risks?
- What evidence should an AI company prepare for SOC 2?
- Do you need SOC 2, SOC 2+, ISO 42001, or NIST AI RMF?
- How do you choose an auditor and plan the examination?
- Frequently asked questions
SOC 2 for AI companies uses the same Trust Services Criteria as SOC 2 for any other service organization, and as of 13 October 2026 AICPA has not issued AI-specific criteria. Your audit scope decides which AI risks, controls, and evidence matter. A company training models, an app calling a hosted LLM, and a SaaS team using an AI coding assistant each prepare differently.
The latest AICPA development is TQA Section 9561, listed on 11 September 2026, addressing how a service organization’s use of AI affects SOC 1 and SOC 2 examinations. As of 13 October 2026, AICPA still lists the 2017 Trust Services Criteria with revised 2022 points of focus. TQA 9561 is guidance on applying those criteria. AICPA TQA 9561, current Trust Services Criteria.
| Item | What it is | What it means for your SOC 2 |
|---|---|---|
| 2017 Trust Services Criteria, revised 2022 points of focus | The criteria AICPA lists for SOC 2. | Your report is measured against these, and AI risks map onto them. |
| TQA 9561, September 2026 | Nonauthoritative AICPA guidance on how a service organization's use of AI affects SOC 1 and SOC 2 examinations. | Ask your auditor how it affects your scope. |
| SOC 2 + AIUC-1, October 2026 | A joint AICPA and AIUC offering: a SOC 2 report and AIUC-1 certification of named AI agents from one CPA-led engagement, in a single report. Full launch planned for early 2027. | Optional. Your SOC 2 criteria do not change; the AIUC-1 part tests the agent itself. |
| Expected criteria revision | Restructured criteria and new or enhanced AI considerations, as KPMG describes them. No AICPA effective date is announced. | Nothing to comply with yet. Record the criteria version your engagement uses. |
| ISO/IEC 42001:2023 | Requirements for an AI management system, published December 2023. | A separate certification engagement. A SOC 2 or SOC 2+ report does not provide the certificate. |
| NIST AI 600-1, July 2024 | The Generative AI Profile, a companion to the voluntary NIST AI RMF. | Can help structure risk-management work. Not a certification scheme. |
Start by documenting what your service promises customers, where AI affects those promises, and who controls each part of the system. Use that description to agree scope and evidence requests with your CPA firm. To compare firms, see SOC 2 auditors for AI companies or browse the full directory of SOC 2 audit firms. Before the AI-specific questions, the baseline scope for any hosted product is in SOC 2 for SaaS companies.
What is the latest AICPA guidance on AI and SOC 2?
AICPA’s public description of TQA 9561 addresses how a service organization’s use of AI affects SOC examinations. That applies to any service organization that uses AI, not only companies that build or train models. The SOC 2 portion concerns examinations under AT-C Section 205; the SOC 1 portion concerns AT-C Section 320. The full questions and answers require a free AICPA account. AICPA resource listing, 11 September 2026.
Schneider Downs, a CPA firm, summarizes two distinctions in the TQA (30 September 2026). First, AI used in the services delivered to user entities is treated differently from AI used only in internal processes. Second, a third-party AI provider that performs functions within the service organization’s system is analyzed like any other subservice organization, and handled with the inclusive or carve-out method. That is the firm’s reading of the gated text, so confirm both points against the TQA with your auditor.
AICPA describes Technical Questions and Answers as nonauthoritative guidance. Publishing a TQA does not replace the Trust Services Criteria. AICPA explanation of TQAs.
KPMG’s webcast overview on AI risks and the changing Trust Services Criteria describes expected restructuring of criteria and points of focus, criteria designed specifically for SOC 2 and SOC 3, and new or enhanced AI considerations. KPMG presents these as expected changes. The overview does not establish an AICPA effective date for a replacement standard.
On 19 October 2026 the AICPA and the Artificial Intelligence Underwriting Company (AIUC) announced a joint SOC 2 + AIUC-1 offering: one engagement led by a CPA firm that ends in a single report, combining a SOC 2 report with AIUC-1 certification of named AI agents. Several CPA firms already deliver it, and a full launch is expected in early 2027. It adds testing of the agent itself; it does not change the Trust Services Criteria your report is measured against. If enterprise customers ask how your agent behaves under attack, see what AIUC-1 tests and who can audit it.
For an upcoming examination, ask your auditor which published criteria and guidance apply to your report and how TQA 9561 affects your scope. Keep the applicable version in the engagement documentation so everyone prepares against the same requirements.
How do you scope SOC 2 for AI products and companies using AI?
AI is relevant to SOC 2 when its use affects the system being examined, service commitments, system requirements, or relevant controls. Start with those connections. Using AI does not automatically bring every experiment, internal tool, or upstream model-training process into scope.
Scope follows how AI affects the examined service
Inventory the AI in your product and the AI your employees use to develop, support, or operate it. Use these examples to prepare for the scoping discussion with your auditor:
| How your company uses AI | What to assess | Evidence to prepare |
|---|---|---|
| AI produces a customer-facing answer, score, or action | Customer data flows, output commitments, permissions, and service dependencies | Architecture and data-flow diagrams, access records, change approvals, monitoring, and provider assessments |
| Developers use an AI coding assistant | Source code or secrets sent to the tool; how generated code enters production | Approved-tool settings, data-use rules, code review, security testing, and release records |
| Support staff use AI to summarize customer tickets | Customer information disclosed to the provider; access and retention | Data classification, vendor review, permitted-use rules, access restrictions, and retention settings |
| AI helps operate a control or prepare audit evidence | Whether people can verify the result and identify errors | Original records, documented review, exception handling, and approval history |
An employee pasting customer tickets into an unapproved AI tool can introduce a vendor and data-handling risk without changing your product’s features. Include this use in the risk assessment where it affects the examined system. Establish an approved-tool process, permitted data types, and a way to handle exceptions. Vendor management is addressed by CC9.2; access and information-protection controls may also apply. AICPA discussion of CC9.2 vendor management.
For an AI product, the architecture determines how much of the model lifecycle your company operates:
| Product architecture | What your company can control | Useful scope and evidence examples |
|---|---|---|
| App calling a hosted LLM | API credentials, application behavior, data sent to the provider, and available provider settings | Data flows, vendor assessment, tenant permissions, application testing, model-selection changes, and incident handling |
| Retrieval-augmented generation (RAG) or an agent with tools | Retrieved documents, indexes, retrieval permissions, tool credentials, and allowed actions | Tests of tenant isolation and retrieval permissions, index-change records, tool-access restrictions, and escalation or approval rules |
| Trained or fine-tuned model | Training inputs, model artifacts, evaluation, deployment, and monitoring, to the extent operated by your company | Dataset references, validation records, model versions, deployment approvals, access reviews, and performance checks |
Baker Tilly describes AI controls across the model lifecycle (18 December 2025), from access to training data through validation and monitoring, and says SOC 2 includes criteria for risks from third-party cloud providers, external datasets, and APIs. Applying that to your setup is our inference: training-data lineage is useful evidence when you control the training process. If you buy access to a hosted API, prepare evidence about your application and provider oversight. Reconstructing the provider’s entire training history may be outside your access and responsibilities.
If you deploy agents with tool access, or connect assistants to your systems through MCP, the controls section below maps the existing criteria to agent risks. For the agent certification question, see the AIUC-1 framework page.
Write a system description that connects the service to its infrastructure, software, people, procedures, and data. Explain which supporting processes affect it and why any exclusions are appropriate. A research sandbox may be separate from production, but shared credentials, customer data, or deployment access can make that separation incomplete. AICPA’s SOC 2 description criteria provide the benchmarks for preparing and evaluating that description.
For a hosted LLM, agree how the provider is treated in the examination. Identify the services it performs, the controls you retain, and the assurance you can obtain. Review the provider report’s scope, period, exceptions, and any responsibilities assigned to customers. A provider’s SOC 2 report supports your vendor assessment; it does not cover your application’s tenant isolation, API-key handling, or configuration choices.
Which SOC 2 controls address AI risks?
AI risks map to the current criteria. Security, using the Common Criteria, covers most of them through access, change, monitoring, and vendor controls. Availability, Processing Integrity, Confidentiality, and Privacy are additional categories selected for the examination. Handling personal or confidential data deserves attention in the risk assessment even when those additional categories are not selected. Agree the categories from your service commitments and customer requirements. See the Trust Services Criteria guide.
The table gives possible mappings under the current criteria. Your auditor still needs to assess the control’s purpose, design, and evidence in your system.
For AI agents with tool access or MCP connections, the criterion-by-criterion view of SOC 2 controls for AI agents and MCP lists the evidence an auditor asks for.
| AI risk | Relevant criteria or category | Example control and evidence |
|---|---|---|
| Unauthorized access to model artifacts or customer data | Security: CC6.3 | Role-based permissions, least privilege, access reviews, and removal of access when responsibilities change |
| Unapproved changes to models, prompts, retrieval indexes, or tools | Security: CC8.1 | Documented testing and approval, version history, deployment records, and recovery procedures |
| Unusual inference queries or suspected model extraction | Security: CC7.2 | Anomaly monitoring, investigation records, and documented responses; rate limits may support the response |
| Prompt injection triggers unauthorized retrieval or tool actions | Security: CC6.3 and CC7.2 | Retrieval and tool permissions, tests of authorization boundaries, and monitoring of suspicious actions |
| Malicious or unauthorized changes to training inputs | Security: CC7.2 and CC8.1; Processing Integrity where selected | Ingestion monitoring, dataset references, validation, and approved changes |
| Dependence on a hosted model provider | Security: CC9.2 | Vendor assessment, the provider’s assurance reports, contractual review, and follow-up on identified risks |
| Inference-service outages | Availability, where selected: A1.1–A1.3 | Capacity monitoring under A1.1, backup and recovery infrastructure under A1.2, and recovery testing under A1.3 |
| Processing fails to meet a defined commitment | Processing Integrity, where selected | Validation against specified requirements, error handling, performance thresholds, and follow-up records |
| Sensitive information retained in datasets or logs | Security controls; Confidentiality or Privacy where selected | Classification, restricted access, defined retention, and disposal evidence; C1.2 specifically concerns disposal of confidential information |
Processing Integrity examines defined processing commitments. It concerns whether processing is complete, valid, accurate, timely, and authorized relative to the service commitments and system requirements. For an AI service, discuss exactly what those commitments mean: accepting valid inputs, executing an authorized workflow, meeting a stated processing deadline, or applying a documented validation rule.
Baker Tilly describes validation, error detection, and drift monitoring as safeguards that can support Processing Integrity for AI. The limit is ours rather than Baker Tilly’s: a Processing Integrity opinion does not certify that every AI response is correct, unbiased, or free of hallucinations. Model evaluation or drift monitoring may support a scoped commitment; neither is a universal SOC 2 requirement for every AI use.
Bias, explainability, and safety may need separate governance work or additional assurance. Their relevance depends on your commitments and the engagement. SOC 2 was not designed to cover the full range of AI risks. Schellman’s discussion of AI and SOC 2, 4 November 2024.
Auditor’s view
What does an auditor test when an AI agent can act in production, calling tools or changing customer data?
Answered by Paul Wenham, Co-founder, Throughline · Sponsored
The same Trust Services Criteria apply. When agents operate in production, the same control principles apply as for human activity, but we test them and frame them in the report as agent activity. For access control, agents should run on their own uniquely identified, least-privilege credentials that are authorised, reviewed and revoked like an employee’s. Since an agent can’t (really) be accountable, it should have a named human owner responsible for monitoring it, and an audit trail capturing its activities.
For change management, the controls are shaped around three things: whether changes are reviewed, tested and approved before release, or reviewed retrospectively; the scope of changes agents can make; and whether changes and monitoring are the customer’s responsibility. Adapt this to your service commitments and enterprise expectations. When your report shows agentic scope is assessed and governed effectively, security reviewers gain greater confidence.
More from Throughline on agent identity, change control and monitoring: SOC 2 Controls and Criteria for AI Agents in Production ↗
What evidence should an AI company prepare for SOC 2?
Prepare evidence that supports the design of controls in your agreed SOC 2 scope and, for Type 2, their operation over the reporting period. For an AI product, this may include access reviews, approved changes, data-handling records, monitoring, and provider assessments. Match the evidence to what your company operates.
A policy describes what should happen. The supporting record should show what happened, when it happened, and who reviewed it. For a Type 2 examination, retain those records throughout the agreed reporting period.
| Preparation task | Example record | Who should be able to explain it |
|---|---|---|
| Production changes | A deployed version linked to its tests, approval, and release record; dataset or model references for models you train or fine-tune | Engineering or the model owner |
| Access reviews | Review results, permission changes, and joiner/leaver records | The system owner and access administrator |
| Customer information handling | Data-flow diagram, provider settings, retention rules, and disposal records | The data owner or security lead |
| Detection and handling of problems | Alert, incident record, investigation, and follow-up | Operations or security |
| Provider assessments | Vendor review, the provider’s report, identified customer responsibilities, and remediation records | The vendor owner |
| Processing commitments, if selected | Validation results, documented thresholds, exceptions, and resolution | The product or model owner |
For example, if you change the model behind a customer-facing endpoint, keep the record that connects the old and new versions to the required testing and approval. If you add an agent tool, retain the review of what it can read or change. Both are examples of existing change-management controls applied to an AI system.
For prompt and inference logging, agree which events provide evidence for your controls and how long to retain them. Model identifiers, timestamps, access decisions, error codes, and tool-action records can be useful without storing every raw prompt and completion. If logs contain customer information, apply the relevant access, retention, and data-protection rules to those logs too.
SOC 2 does not impose a universal requirement to log every inference. Collect enough evidence for the control being tested, with suitable protection for the data it contains. Review provider retention and training-use settings against your commitments, the available service configuration, and contractual terms.
If you use AI to draft policies or summarize evidence, keep the original records and have an accountable person verify the output. A generated description of an access review cannot establish that the review occurred. Ask the auditor what source records and approvals they need before relying on an automated evidence workflow.
Original records connect a control to the examination
Compare SOC 2 quotes for your AI scope
Describe your product, data flows, and AI providers once. Request 3–10 ballpark quotes from CPA firms. Free, with your company's identity kept private until you choose who to talk to.
Do you need SOC 2, SOC 2+, ISO 42001, or NIST AI RMF?
Start with what the customer asks you to demonstrate. A SOC 2 report, an ISO/IEC 42001 certificate, and an AI risk-management program answer different questions. Adding Availability or Processing Integrity to SOC 2 remains a selection of SOC 2 categories; it does not make the report SOC 2+.
| Customer requirement | Engagement or framework to discuss | What to confirm |
|---|---|---|
| A SOC 2 report on the service they buy | SOC 2 with the relevant categories and report type | The system boundary, commitments, reporting period, and tested controls |
| A SOC 2 report that also examines controls against another framework | SOC 2+ | The additional criteria, testing, and how the results appear in the report |
| Certification of an AI management system | ISO/IEC 42001 certification | The certification scope and separate certification engagement |
| A structured way to manage AI risks across development and use | NIST AI Risk Management Framework | Which risks, owners, assessments, and follow-up your program will address |
Schellman describes SOC 2+ as a way to include an additional framework, such as ISO 42001 controls, in a SOC 2 examination. That report does not confer ISO certification. Confirm that its additional testing answers the buyer’s request before expanding the engagement.
ISO/IEC 42001, published in December 2023, specifies requirements for an AI management system for organizations providing or using AI. If a certificate is required, plan that work separately; see the ISO 42001 certification cost guide.
NIST’s Generative AI Profile, AI 600-1, published on 26 July 2024, is a companion to the voluntary AI RMF. It can help structure risk-management work; it is not a certification scheme. For software selection, see SOC 2 and ISO 42001 software for AI startups.
How do you choose an auditor and plan the examination?
Choose a CPA firm that can explain how it would examine your architecture and commitments. Ask about similar engagements, the team’s technical experience, and the proposed evidence requests. Firm size alone does not establish that fit.
Useful questions for a scoping call:
- How will TQA 9561 affect your assessment of our product and internal AI use?
- What would you include for our hosted model, retrieval system, agent tools, or training pipeline?
- Which additional Trust Services categories do our commitments justify, and what would their testing cover?
- How will you assess our model provider and any controls we must operate ourselves?
- What evidence should we retain for model, prompt, data, and application changes?
- Which assumptions about scope, readiness, reporting period, and additional assurance affect your fee?
Compare proposals against the same scope. Ask whether readiness support, compliance software, penetration testing, and any ISO work are included or priced separately. Use the AI auditor directory to compare firms and available fee estimates, then confirm a quote for your system.
In Q3 2026, firms quoted AI companies a median $9,500 for a SOC 2 Type 2 audit through SOC2Auditors.org, in ballpark quotes before scoping.
Our quote data covers Type 2 audits only. A Type 1 report addresses the description and suitability of control design at a specified date. A Type 2 report also examines operating effectiveness over a specified period. Agree the report type and, for Type 2, the reporting period with the auditor before setting a delivery date. Preparing controls in a few weeks does not create months of historical operating evidence. See SOC 2 Type 1 vs. Type 2.
An early-stage AI team deciding whether to start now should read SOC 2 compliance for startups first. A practical sequence is to agree scope, identify and remediate control gaps, operate the controls while retaining evidence, and complete fieldwork and reporting. The time each step takes depends on your starting controls and the engagement. Assign owners and recurring review dates so access reviews, vendor checks, monitoring, and change approvals continue after the report is issued.
For an existing SOC 2 program, assess a new AI use before it changes customer data flows, production access, or a control. Discuss material changes with the auditor and update the description and evidence plan as needed. A completed report describes its date or period; it does not provide continuous assurance over later changes.
Frequently asked questions
Does SOC 2 cover AI?
Yes. As of 19 October 2026, SOC 2 examines the AI parts of the system in scope through the existing Trust Services Criteria. AI that affects your commitments or controls is examined under Security and any other categories you select. The next answer covers what AICPA has and has not issued.
Has the AICPA issued AI-specific SOC 2 criteria?
As of 19 October 2026, AICPA lists the 2017 Trust Services Criteria with revised 2022 points of focus. It also lists TQA Section 9561, dated 11 September 2026, on how a service organization’s use of AI affects SOC 1 and SOC 2 examinations. That guidance is distinct from a new AI-specific SOC 2 standard. The joint SOC 2 + AIUC-1 offering announced on 19 October 2026 does not change that: it adds a separate certification of named AI agents to a standard SOC 2 report.
Does a company using AI need to include it in SOC 2?
Assess whether the AI use affects the system being examined, its service commitments, system requirements, or relevant controls. An AI coding assistant, support tool, or evidence tool can matter even when the customer-facing product is not an AI product. Using AI does not automatically put every internal tool into the examination scope.
What do auditors test first when auditing an AI company for SOC 2?
There is no prescribed AI-first testing order. Agree the scope and evidence requests with the auditor. Evidence may include model-change approvals, access controls, data lineage, monitoring, and vendor risk assessments, depending on the system and categories examined.
Are OpenAI or Anthropic in scope for my SOC 2 if I use their LLM?
Describe how the LLM provider supports your service and agree its treatment in the examination with your auditor. Your controls may cover vendor risk assessment, data handling, access, retention settings, and review of the provider’s assurance reports. The provider’s report does not replace a SOC 2 examination of your own system. Reports can cover some plans and not others. Our guide to which AI tools publish SOC 2 reports, and which plans each covers lists them by plan.
Do I need ISO 42001 or NIST AI RMF as well as SOC 2?
Not automatically. Start with the assurance your customer requires. SOC 2 examines controls around a defined system. ISO/IEC 42001 covers an AI management system, while NIST AI RMF is a voluntary risk-management framework. An ISO 42001 certificate requires a separate certification engagement; a SOC 2 or SOC 2+ report does not provide that certificate.
More in Industry & Verticals