Summary: There is no new AI rulebook. But there is now a higher bar for how the existing one gets applied. This article provides details on what that means for your SOC 2 compliance and your next examination
If someone has told you the American Institute of Certified Public Accountants (AICPA) released AI-specific SOC 2 criteria, start here: they have not. There is no “2026 Trust Services Criteria.” The standard governing your SOC 2 examination is the same one that has applied since 2017, with the points of focus the AICPA refreshed in 2022. The points of focus are the AICPA’s illustrations of how a criterion might be met. They are not requirements. No new control objectives, no separate AI module.
What changed is not the rulebook. It is how auditors read it, and what your customers now expect to see. Your service auditor is the CPA firm performing the examination and issuing the opinion. The Trust Services Criteria were written as principles rather than a checklist. In 2026, experienced practitioners are applying those principles to the AI already sitting in your environment, whether you built it, embedded it, or simply switched on Copilot.
The practical result is the same as if the criteria had been rewritten. If AI touches your systems, your auditor will request evidence, and “we haven’t really thought about that” is not an answer that holds up in front of an enterprise buyer. You are not chasing a moving target. You are applying a stable framework to a new technology, and here is how we help clients work through it:
- Start with your risk assessment: We help clients understand how their use of AI impacts the in-scope system and identify the related risks. From there, organizations should incorporate those risks into their risk assessment and determine whether their existing controls appropriately address them.
- Bring those considerations into scoping: We work with clients during scoping to understand relevant AI use and related risks so their impact on the examination can be appropriately considered. If significant AI use or related risks are not identified until later in the examination, both the organization and the auditor may be left addressing scope, controls, and evidence after testing is already underway.
Ask one question: what is your relationship to AI?
Before anything else, get specific about how AI shows up in your business. We find it useful to sort it into three roles, because the expectations scale sharply from one to the next. A Producer carries far heavier expectations around model governance and testing than a company whose only AI footprint is an internal chatbot. The criteria does not define these categories. We use them because they track how expectations scale in practice.
| Role | What it means | A typical example |
|---|---|---|
| User | You use AI outputs internally to get work done. | Staff using Copilot or ChatGPT to draft, summarize, or analyze. |
| Provider | You operate AI that someone else built, inside your own product or service. | Wiring a third-party model API into your SaaS platform. |
| Producer | You build or train the models yourself. | Fine-tuning a large language model (LLM) or shipping a proprietary machine learning model in your product. |
Most organizations land in more than one of these roles, and that is normal. Whatever your mix, write it down as part of your risk assessment. That single determination drives most of what follows, and it is one of the first things a good auditor will want to see reasoned through.
Where AI shows up in the SOC 2 criteria you already follow
None of the items below requires a new standard. Each one maps to criteria you are already evaluated against. We have noted the relevant common criteria (CC) so you can see the thread.
Governance and people (CC1, CC2)
Your control environment must reflect the competencies your business genuinely needs. If your team relies on AI, that now includes basic AI literacy and the habit of verifying an AI output before acting on it. Producers need deeper knowledge here: data science, model governance, and AI risk management. On the communication side, people should know the rules for acceptable use, recognize when they are looking at AI-generated content, and know how to escalate when something seems off. A one-time email does not satisfy this; auditors look for an ongoing, documented practice.
- What your auditor will ask to see: add AI-specific modules to security awareness training, publish an acceptable AI use policy and have staff acknowledge it, and put a disclosure practice in place for AI-generated content that feeds business decisions. Expect to produce the policy with its version history and approval date, an acknowledgment log covering in-scope personnel across the review period, and training completion rates rather than the curriculum itself.
Risk assessment and monitoring (CC3, CC4)
Your risk assessment should name the threats that are specific to AI rather than fold them into generic technology risk. For a User, the obvious ones are staff pasting sensitive data into public tools and over-trusting inaccurate output. For a Producer, the list grows to include data poisoning (tampering with training data so the model learns the wrong thing), adversarial inputs (prompts crafted deliberately to make the model fail), model theft, and model drift (a model losing accuracy over time as the real world moves away from its training data). This process is not a one-and-done exercise either. Auditors increasingly expect ongoing monitoring of model behavior, output quality, and whether what your models produce is still relevant to the business.
- What your auditor will ask to see: add an AI section to your enterprise risk assessment, tie it to your Producer, Provider, or User determination, and define what a misbehaving model looks like along with whoever gets alerted when it happens. Expect to show that the monitoring ran, which means logs, dashboards, or review signoffs across the full period rather than a screenshot from last week.
Access controls and shadow AI (CC6)
Logical access, meaning who can reach which systems, has always been core to a SOC 2. What is new is that AI service accounts, API keys, and automated agents deserve the same discipline as human accounts: least privilege (each account gets only the access it needs), periodic review, and prompt deprovisioning when access is no longer needed. The larger exposure for most companies is shadow AI, meaning the tools staff adopt without telling IT or security. Staff adopt new tools faster than security can vet them, and an auditor asking how you know what AI is running in your environment is testing whether you have a current list. A verbal answer is not evidence.
- What your auditor will ask to see: inventory of the AI tools and service accounts you have, add detection for unsanctioned usage at the network or endpoint layer, and fold AI accounts into your regular access reviews. Expect to produce a current list of AI tools and API keys, with named owners.
System operations and incident response (CC7)
Monitoring an AI-enabled system means more than tracking up time. If your product or operations depend on a model, you need visibility into output quality, a way to spot manipulation, and incident response that anticipates AI-specific failure modes: a model that starts producing biased or wrong answers, a data leak through prompts, or an adversary probing your system. The newest item here is prompt injection, meaning hidden instructions buried in the text you feed a model, used to make it ignore its own rules. For Producers and Providers, auditors are now asking to see evidence of adversarial testing, not just a policy stating that you care about it.
- What your auditor will ask to see: extend vulnerability management to cover prompt injection and model manipulation, set thresholds and alerts for anomalous output, and write AI scenarios into your incident response playbooks. Expect to produce adversarial test reports with dates, scope, findings, and remediation status, plus evidence that your AI incident scenarios were exercised.
Change management (CC8)
Retraining a model, swapping out training data, or adjusting parameters is a change, and it belongs in your change management process with the same rigor you apply to code: impact assessment, testing, and approval before anything reaches production. Adversarial testing fits naturally here too, as a gate before deployment, much like a penetration test for a traditional release.
- What your auditor will ask to see: bring model updates and retraining under formal change control, and keep a model registry with versions, training-data references, and deployment approvals. Expect your auditor to pick a model running in production and ask you to show the exact data set, code, and approval behind it.
Vendor oversight and privacy (CC9, P series)
If you embed someone else’s model, decide deliberately what that vendor is. If the provider performs part of the service your report covers, it may meet the definition of a subservice organization, which changes how it is presented in your report. If it does not, it is still a critical vendor under CC9.2. Make the determination deliberately and document your reasoning, because your auditor will want to understand the conclusion you reached and why.
For AI providers that receive company or customer data, understand and document how that data is used, retained, and protected, and whether appropriate contractual safeguards are in place. On the privacy side, personal information should not flow into an AI system without appropriate consent, access controls, retention limits, and a way to delete it.
- What your auditor will ask to see: add AI questions to your vendor risk questionnaire, get zero-retention and data processing terms in writing from your model providers, and review every AI workflow for personal data exposure. Expect to produce your documented subservice organization determination, the signed agreements, and a data flow map showing where personal information touches an AI system.
A practical path to SOC 2 readiness
You do not have to do all of this at once. A staged approach keeps it manageable and gives you something to show at each step. If you are not sure where you stand, a readiness assessment will tell you before the examination period begins.
- Assess. Classify your AI roles, inventory every AI tool, model, service, and service account, run an AI-focused risk assessment, and find gaps in your current description, policies, training, and monitoring.
- Design. Write or update your AI acceptable use policy, design controls for each criteria area above, refresh your incident response, change management, and vendor procedures, and set your monitoring thresholds.
- Implement. Stand up shadow AI detection, roll out AI awareness training, build adversarial testing into your development lifecycle if you are a Producer or Provider, and get AI terms into your vendor agreements. Start the clock early enough to build operating history.
- Validate. Test your AI controls internally, watch model performance and output quality, reassess risk on a regular cadence, and keep your evidence organized so testing can be completed without exceptions.
Final thoughts: the AI questions buyers are already asking
The criteria did not change, but the bar did. Enterprise buyers are already asking whether a SOC 2 report covers AI systems, and a vague answer is starting to stall deals at procurement. The companies that treat AI as in scope today, under the SOC 2 framework they already follow, will walk into their next examination prepared and will have a cleaner story for the customers asking the hard questions. The ones that wait tend to address it under deal pressure, which is the most expensive time to do it.
