Quick Summary
AICPA TQA Section 9561 confirms that AI does not create a separate SOC examination model or new criteria. Whether AI belongs in a SOC 1 or SOC 2 report depends on how the service organization uses it and whether that use affects the services, system, risks and controls already in scope.
How does the use of AI affect the scope, system description, controls and examination procedures of an existing SOC program?
The AICPA released technical questions and answers (TQA) in Q&A section 9561 on September 11, 2026, titled, “SOC Examinations: Effect of the Service Organization’s Use of Artificial Intelligence on SOC 1 and SOC 2 Examinations.” The TQA addresses a practical question that is becoming more common as organizations deploy Artificial Intelligence: how does AI affect the scope, description, controls and examination procedures in an existing SOC program?
The central takeaway is one that may surprise some folks: AI does not create a separate SOC examination model, and the AICPA did not invent new criteria to evaluate it (well, for now at least!). Rather, relevance depends entirely on how the service organization uses AI and whether that use affects the services, systems, risks and controls already addressed by the applicable SOC framework. That distinction matters because the knee-jerk reaction of adding an “AI section” to every SOC report is not the point of the guidance and may create scope that is broader and more costly than the underlying risk warrants.
Start With How AI Is Used, Not With the Technology Label
TQA Section 9561 describes AI broadly, encompassing Machine Learning (ML), Large Language Models (LLMs) and generative AI. More importantly, it draws a distinction that drives the entire SOC scoping analysis: whether AI is used in the services delivered to user entities, or only within internal processes.
These are materially different use cases. A service organization that embeds an AI model into the product it delivers to customers has a different set of scoping questions than one using an internal AI tool to help draft policy evidence or summarize audit logs. The former may indeed require changes to system descriptions, risk assessments, and control narratives. The latter may have no SOC implications at all.
Management’s first task is conducting a full inventory: where is AI used, what does it do and does that use collide with the system boundary covered by the examination? An AI tool used entirely outside the relevant system does not get pulled into scope simply because it is AI. That boundary discipline is where many organizations are likely to struggle in the near term, as AI adoption often moves faster than governance.
SOC 1: The Question Is Effect on Internal Controls over Financial Reporting (ICFR)
For SOC 1 examinations, the established scope does not change: controls at the service organization that are likely to be relevant to user entities’ Internal Controls over Financial Reporting (ICFR). AI does not create a new lens; it is evaluated through the existing one.
Management and the service auditor evaluate whether AI is part of the system that processes transactions or information relevant to user entities’ financial reporting, or whether AI affects controls intended to address related risks. The TQA is clear that when AI is part of the services provided to user entities and is relevant to their financial reporting controls, the system description must disclose its nature. The description must give user entities and their auditors enough information to understand the nature of the AI use and its effect on the system.
Bottom line: if you have introduced an AI-enabled process that touches transaction processing, reconciliation, exception handling or any other area a user entity’s financial auditor would care about, that process belongs in the description and likely requires control coverage. If the AI use is internal and does not affect those processes, it stays out.
SOC 2: AI Fits Within the Existing Trust Services Criteria
Same recipe on the SOC 2 side. The Trust Services Criteria has not been rewritten for AI. The question is whether AI use introduces or changes risks within the categories already in scope.
When AI is incorporated into the services the organization provides, management evaluates whether the system description remains accurate and complete under the applicable description criteria. This can require revisiting how principal services are described, which system components are identified, and what characteristics are necessary for intended users to understand the system.
On the control side, the analysis maps directly to whichever trust services categories are in scope. An AI-enabled function that makes decisions about access, processes data, generates outputs that users rely on or operates at scale can affect risks tied to the applicable trust services categories (security, availability, processing integrity, confidentiality or privacy). The organization does not need new criteria. It needs an honest assessment of where AI has changed the risk profile and whether existing controls adequately address those changes.
One category worth calling out specifically is processing integrity. AI models can produce inconsistent or incorrect outputs, and in some cases organizations have limited ability to explain why. Where those outputs are part of a service commitment, the control environment around model validation, output review and error correction becomes directly relevant to processing integrity commitments.
Third-Party AI Providers: Apply the Subservice Organization Framework
Most service organizations do not build their AI capabilities from the ground up. They consume foundation models from hyperscalers, API-based AI services or integrate AI-enabled software from third parties. TQA Section 9561 addresses this squarely through the existing subservice organization concept.
If a third-party AI provider performs functions that are part of the service organization’s system, the analysis is the same as for any other subservice organization: does this provider meet the definition under the applicable SOC guidance, and if so, is it addressed using the inclusive or carve-out method? AI does not create a separate third-party reporting model.
What AI does do is make this analysis more urgent. Many organizations that have been careful about subservice organization identification have introduced AI providers quickly and informally, often without the same third party governance rigor applied to traditional infrastructure. The practical question is whether current provider inventories, system boundary documentation and Complementary Subservice Organization Controls (CSOCs) are accurate given recent AI deployments. In many cases, it’s likely that they need to be updated.
When the Auditor Uses AI: Responsibility Does Not Transfer
Same rules, new tools. When auditors use AI to assist with examination procedures, they remain on the hook for the work, the design of procedures, the evaluation of evidence and the opinion of the report. A fancier testing tool does not diminish the auditor’s accountability for evaluating the sufficiency and appropriateness of evidence.
Service organizations should care about this too. As AI-assisted audit tools become more common, organizations should expect that some examination procedures will be performed differently than they were in prior years. That’s not necessarily a cause for concern, but it does serve as a reminder to keep documentation clear and tight. AI-assisted testing is getting better at finding the things you’d rather not explain.
Five Things Service Organizations Should Do Now
The release of TQA Section 9561 should not be seen as an automatic expansion of scope, rather as a catalyst to consider the following five things before your next examination:
- Conduct an AI use inventory against your current SOC system boundary. Identify every AI-enabled tool or service in use, and explicitly determine whether each one falls inside or outside the examination scope. Document the rationale either way.
- Evaluate whether the system description remains accurate. If AI has changed how principal services are delivered, what components are involved or what risks the system must address, the description needs to reflect that before the next examination period begins.
- Review the subservice organization roster for AI providers. Third-party AI providers introduced informally, without standard third-party onboarding, may need to be added to the subservice organization analysis and due diligence. Confirm that CSOCs are identified and documented when the carve-out method is used.
- Reassess risks and controls for AI-affected processes. Where AI is in scope, evaluate whether the existing control environment addresses the specific risks AI introduces; e.g., model drift, output accuracy, data quality, access to training data and the ability to explain or audit AI-generated decisions.
- Avoid scope inflation. Experimental tools, sandboxes and employee productivity uses of AI that do not affect the SOC system should stay out of scope. Including them creates testing burden without adding meaningful assurance for user entities. The analysis should remain anchored in materiality and relevance to the applicable framework objective.
Conclusion
The AICPA isn’t asking us to reinvent the wheel. TQA Section 9561 is essentially saying: figure out where AI actually lives in your system, apply the same SOC principles you already know and make sure your report reflects the reality of your environment.
For organizations with mature SOC programs, that means bringing AI governance into the same scoping, risk assessment and control-design disciplines already in place, rather than treating AI as a special category requiring separate treatment. The objective is accurate representation of the system and appropriate control coverage for risks that are material to the examination. Scope creep is not the compliance strategy. Organizations that approach TQA Section 9561 with that framing will be best positioned for success.
How Schneider Downs Can Help
Schneider Downs IT Risk Advisory Services helps service organizations evaluate how AI adoption affects existing SOC programs, without defaulting to scope expansion as the answer. Our professionals work with management to conduct AI use inventories against the current system boundary, evaluate whether system descriptions remain complete and accurate, identify changes to relevant risks and controls and determine how third-party AI providers fit within the subservice organization framework.
For organizations developing broader AI governance programs, we help align those efforts with existing risk and control environments so that SOC reporting, information security and AI governance work together rather than in parallel. The goal is defensible, accurate reporting that reflects the system as it actually operates, not a report that looks good on paper but creates more questions than it answers.
To discuss how TQA Section 9561 applies to your SOC program, contact the Schneider Downs IT Risk Advisory Services team.
About Schneider Downs IT Risk Advisory Services
The Schneider Downs IT Risk Advisory Services team helps organizations navigate evolving compliance, security and third-party risk demands. Our professionals work with clients to design, assess and report on controls through SOC 1, SOC 2, SOX ITGC, CMMC, HITRUST, ISO 27001, NIST, CSA STAR and HIPAA engagements, as well as Third Party Risk Management programs. Through attestation, advisory and readiness services, we help organizations build resilient, risk-based control environments aligned with their operating requirements and client expectations. To learn more, please visit our IT Risk Advisory Services page.
