Short answer
AICPA TQA Section 9561, released September 2026, is the first authoritative AICPA guidance on how a service organization's use of AI affects SOC 1 and SOC 2 examinations. The existing Trust Services Criteria still apply. If AI materially affects the in-scope service, it is in scope. LLM providers can be treated as subservice organizations with carve-out or inclusive methods, and auditors will test controls around model access, change management, logging and vendor oversight.
Every AI startup eventually asks the same question when a prospect requests a SOC 2 report: does our use of GPT, Claude or an open-weights model break something in the audit? Until September 2026 there was no authoritative answer. Audit firms applied the existing Trust Services Criteria by analogy and the AICPA stayed quiet. That changed when the AICPA published Technical Question and Answer Section 9561, which addresses the effect of a service organization's use of AI on SOC 1 and SOC 2 examinations.
TQA 9561 is non-authoritative, but in practice every SOC 2 auditor will now reference it. This post walks through what the TQA actually says, when your AI usage falls in scope, how to treat your model provider in the system description, and the controls your auditor will ask about. If you are earlier in your journey, see SOC 2 for AI startups for the end-to-end overview and SOC 2 evidence for AI features for sample artefacts.
What TQA 9561 actually says
TQA 9561 does three things:
- Confirms the existing criteria apply. The Trust Services Criteria — security, availability, processing integrity, confidentiality and privacy — already cover AI the moment it affects the in-scope service. No new criterion was added.
- Clarifies scope. AI is in scope when it is a part of how the service organization delivers the service that is in the SOC examination. If you use ChatGPT internally for marketing copy, that is not in scope. If your product calls an LLM to generate the response the customer sees, that is in scope.
- Addresses subservice organizations. When a third-party AI service (an LLM provider, a vector-database SaaS, a GPU host) performs part of the in-scope service, it meets the definition of a subservice organization. The auditor and the service organization choose between the carve-out method (list the subservice organization's controls as complementary and exclude them from the examination) and the inclusive method (test the subservice organization's controls as part of your examination).
The TQA does not prescribe specific AI controls. It leaves the what to the service organization and the how to the auditor's professional judgement — just applied to a new technology.
When is your AI in scope?
Apply this three-step test:
- Does the AI touch an in-scope service? If your SOC 2 scope is “the X platform offered to customers” and the AI is in the X platform, it's in. If the AI is only in a sales enablement tool that doesn't touch the customer-facing service, it's out.
- Does it affect any Trust Services Criterion? Security (how is the model accessed, how are prompts/outputs protected)? Availability (does an LLM outage take your service down)? Processing integrity (are outputs reliable enough for the service the customer bought)? Confidentiality (does the model see customer data)? Privacy (does it process PII)? If yes to any, in.
- Is the AI material to the service? A spell-check model that fixes typos probably isn't material. A model that is the service — a summariser, a search ranker, a code generator — is material by definition.
In-scope AI appears in the system description. The description must explain what the AI does, what data flows into it, what flows out, and the controls over it. The clearer that paragraph is, the fewer auditor questions you'll get later.
Carve-out or inclusive: how to treat your LLM provider
If you use OpenAI, Anthropic, Google, Mistral, Cohere or any hosted inference provider, that provider is almost certainly a subservice organization under TQA 9561. You have two options.
| Method | What you do | When to use |
|---|---|---|
| Carve-out | List the subservice organization and the Complementary Subservice Organization Controls (CSOCs) you rely on. The auditor does not test them — you rely on the subservice organization's own SOC 2. | Default for LLM providers with their own SOC 2. Fast, cheap, standard. |
| Inclusive | Include the subservice organization's controls in the scope of your examination. The auditor tests them. | Rarely used for LLM providers. Required if the subservice organization has no SOC 2 and you cannot carve them out credibly. |
Under the carve-out method you must still perform vendor due diligence on the subservice organization — obtain their SOC 2 or ISO 27001 report, review it, document gaps, re-review annually. Auditors ask to see the review file. If a model provider cannot produce a current SOC 2 or ISO 27001 report, that is a signal to switch providers or move to inclusive — both expensive.
The AI controls your auditor will test
Every control below maps to an existing Trust Services Criterion. Think of this as the pattern that TQA 9561 formalises.
| Area | Control the auditor will test | TSC |
|---|---|---|
| Model access | API keys stored in a secret manager, rotated on cadence, scoped per environment, no shared keys | CC6.1 |
| Prompt and output logging | Logs of model calls that identify user, model version, prompt hash and output hash, with retention aligned to your log policy | CC7.2 |
| Model change management | System prompts, prompt templates and model versions tracked in source control with a reviewed-and-approved change for every production update | CC8.1 |
| Vendor due diligence | LLM provider's SOC 2 or ISO 27001 report, DPA with no-training clause, annual re-review | CC9.2 |
| Data governance | Documented policy on what customer data can be sent to a model, PII minimisation in prompts, no-training opt-out confirmed in writing | C1.1, P4.1 |
| Human oversight | For high-stakes outputs (financial, medical, legal), evidence of a human review step or a documented acceptable error rate | CC5.3 |
| Incident response | Runbooks for AI-specific incidents: prompt injection, output harm, data leakage, model-provider outage | CC7.3, CC7.4 |
| Availability | Fallback behaviour when the model provider is degraded; SLA/SLO monitoring on model latency and error rate | A1.2 |
System description: what to write about AI
The description of your system in a SOC 2 report must now explicitly address AI. A workable template:
“The Service uses large language models to generate [response type]. User prompts and the resulting outputs are sent to [provider] via API. The Service does not train models on customer data; this is contractually confirmed in the Data Processing Addendum with [provider]. System prompts, prompt templates and model versions are managed in source control and change-controlled via [process]. Access to the inference API is restricted to the Service's production environment via [secret manager]. Prompts and outputs are logged with user, model version, and content hashes, retained for [N] days.”
If you use the carve-out method, add a one-paragraph description of the subservice organization and a list of CSOCs you rely on.
What's coming: Trust Services Criteria revision in 2027
The AICPA has publicly signalled that the Trust Services Criteria will be revised to incorporate AI-specific points of focus — the sub-bullets under each criterion that illustrate how to meet it — with an expected effective date in 2027. New criteria are unlikely; new points of focus around model governance, training data, output quality and transparency are expected. A startup that implements the controls in the table above today will be aligned with the revision before it drops.
The adjacent standard to watch is ISO 42001, which is purpose-built for AI management systems. If you're pursuing SOC 2 for the first time and already have AI in the product, consider stapling ISO 42001 on from the start — see ISO 42001 vs SOC 2 for the sequencing question.
Frequently asked questions
What is AICPA TQA Section 9561?
TQA Section 9561, issued in September 2026, is the AICPA's non-authoritative Technical Question and Answer that clarifies how a service organization's use of artificial intelligence affects SOC 1 and SOC 2 examinations. It confirms that the existing Trust Services Criteria still apply and explains when AI used by the service organization is in scope.
Does SOC 2 cover AI now?
SOC 2 has always covered AI the moment it affects the in-scope service. TQA 9561 makes the implicit explicit: if AI is part of how you deliver the service that is in your SOC 2 scope, the controls over that AI must meet the Trust Services Criteria. There is no new AI-specific criterion yet, though the AICPA has signalled a Trust Services Criteria revision is likely in 2027.
Are LLM providers like OpenAI and Anthropic subservice organizations?
They can be. Under the TQA, if an LLM provider performs part of the in-scope service in a way that affects a Trust Services Criterion, the auditor treats them as a subservice organization. You then decide between the carve-out method (list their controls as complementary subservice organization controls) and the inclusive method (test their controls as part of your examination). Most AI startups use the carve-out method.
What AI controls will my SOC 2 auditor ask about?
Access control over who can call the model, logging of prompts and outputs where feasible, change control for prompts, system prompts and model versions, vendor due diligence and DPAs with the model provider, incident response for AI-specific issues like prompt injection and data leakage, and human oversight for high-stakes outputs. All of these map to existing CC6, CC7 and CC8 criteria.
Will there be a new AI-specific SOC 2?
The AICPA has indicated that a revision to the Trust Services Criteria to incorporate AI-specific points of focus is likely, with an expected effective date in 2027. Until then, TQA 9561 is the governing guidance and auditors apply the existing criteria to AI-affected systems.
Does TQA 9561 apply to SOC 1 as well?
Yes. TQA 9561 explicitly covers both SOC 1 and SOC 2 examinations. For SOC 1, the question is whether the AI is relevant to internal control over financial reporting at user entities; for SOC 2, whether it affects any of the five Trust Services Criteria.
Get SOC 2 ready with AI already baked in
LowerPlane runs SOC 2 and ISO 42001 on one evidence base so your model inventory, vendor reviews and logging answer both audits. See SOC 2 for AI startups for the walkthrough.