TL;DR: SOC 2 audits in 2026 now routinely include AI-specific questions across all five trust service criteria. Availability controls cover fallback procedures when AI models are unavailable. Confidentiality controls examine whether training data or model outputs leak sensitive information. Processing integrity covers how you verify AI outputs are accurate. Privacy TSC applies to training data consent and inference-time data handling. Common gaps include undocumented model inventories, missing version control records, and no formal testing procedures. The AICPA's 2024 AI-related guidance is now referenced in audit programmes at most major accounting firms.
If you shipped an AI feature in the last two years and you are going through your next SOC 2 audit, you should expect it to come up. The days when SOC 2 auditors would treat AI as a black box inside someone else's infrastructure are over. Auditors in 2026 ask specific questions about how AI models are governed, tested, and monitored, and the companies that have not updated their control documentation to account for AI are the ones generating findings.
This guide explains how each trust service criterion applies to AI systems, what questions auditors are asking, what the common gaps are, and how to prepare documentation that holds up to scrutiny.
How SOC 2 applies to AI: the framework
SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) for auditing service organisations' controls. It is built around five trust service criteria: security (the common criteria, required for all SOC 2 reports), availability, processing integrity, confidentiality, and privacy.
AI systems are not a separate SOC 2 category. They fall within the existing trust service criteria depending on how they are used. An AI model that generates customer-facing responses is in scope for processing integrity because clients rely on those outputs. An AI that processes personal data in training or inference is in scope for privacy. An AI API that customer workflows depend on is in scope for availability.
The AICPA published AI-related supplemental guidance in 2024 that addressed how attestation engagements should consider AI systems. While this guidance is non-binding, the major accounting firms have incorporated its principles into their SOC 2 audit programmes. If your auditor is one of the top ten accounting firms, AI governance is now part of their standard inquiry list.
Availability controls for AI
The availability trust service criterion requires controls ensuring the system is available for operation and use as committed or agreed. AI introduces new availability risks that traditional IT availability controls do not address well.
Model API availability. If your product relies on a third-party AI API (OpenAI, Anthropic, Google, Cohere, or similar), that API is a single point of failure. Auditors ask: what is your fallback procedure when the AI API is unavailable? Does your service degrade gracefully, fail closed, or fail open? What is your SLA with the third-party provider, and does it meet your service commitments to customers?
Model loading and inference latency. For self-hosted models, availability includes the infrastructure that serves the model. Auditors will review your monitoring for inference failures, latency spikes, and GPU/CPU availability.
Version and rollback capability. If a model update causes a regression, can you roll back? Auditors ask whether you have model versioning controls and tested rollback procedures.
Documented fallback procedures. Every service that uses AI should have a written fallback procedure that is tested at least annually. The fallback might be a rule-based system, a human review queue, or a degraded-but-functional version of the service. The existence and testing of that procedure is what auditors check.
Confidentiality controls for AI
The confidentiality criterion covers information designated as confidential, including customer data and proprietary business information. AI creates several confidentiality risks that standard controls miss.
Training data handling. If you fine-tuned a model on customer data, or if customer data was used in model training in any way, auditors ask how that data was governed. Was it anonymised? Was consent obtained? Who had access to training datasets? Are training datasets retained beyond the model training window?
Prompt injection and data exfiltration. AI models can be manipulated through adversarial inputs into revealing information from their context or training. Auditors are beginning to ask whether companies have tested their AI systems for prompt injection vulnerabilities and what controls prevent confidential information from appearing in model outputs to unauthorised users.
Model output access controls. Who can query your AI model directly? Are model endpoints authenticated? Auditors look for access control lists on model APIs and evidence that access is reviewed periodically.
Multi-tenancy in AI contexts. For SaaS companies, the risk that one customer's data influences model outputs for another customer (through shared fine-tuning or shared context windows) is a confidentiality risk. Auditors ask how you isolate customer data in AI pipelines.
Processing integrity for AI
Processing integrity is where AI creates the most novel audit challenges. The criterion requires that system processing be complete, valid, accurate, timely, and authorised. AI outputs are probabilistic, not deterministic, which makes standard accuracy assurance approaches inadequate.
Testing procedures for AI accuracy. Auditors ask whether you have documented testing procedures that establish accuracy baselines for your AI system. This means test sets, evaluation metrics, and records of accuracy testing before each production deployment. Companies without written testing procedures consistently generate findings here.
Ongoing accuracy monitoring. Testing at deployment is not sufficient. Auditors ask whether you monitor AI output accuracy over time and what your process is for detecting performance degradation. Acceptable approaches include periodic evaluation against held-out test sets, user feedback analysis, and statistical sampling of outputs.
Anomaly detection and alerting. Do you have automated monitoring that flags unusual output patterns, error spikes, or confidence score drops? Auditors expect to see evidence of automated monitoring for production AI systems, not just manual spot checks.
Human review thresholds. For AI systems making consequential decisions (credit, hiring, medical triage, content moderation), auditors ask whether there are defined thresholds at which AI outputs are reviewed by a human before acting on them. The absence of any human review process for high-stakes AI is a common and significant finding.
Model versioning records. Auditors ask to see a record of which model version was deployed, when, and by whom. Undocumented model updates are a frequent gap: a developer updates a model version without going through a formal change management process, and the change is invisible to the audit trail.
Privacy TSC and AI
The privacy criterion covers the collection, use, retention, disclosure, and disposal of personal information. AI introduces privacy questions at multiple points.
Training data consent. If your model was trained on personal data, auditors ask what the legal basis was for using that data. Consent records, legitimate interest assessments, or data processing agreements with data subjects may be required depending on the jurisdiction and the data type.
Inference-time data flows. What personal data goes into AI model inputs at inference time? Is it minimised? Is it retained by the AI vendor? Many companies are surprised to discover that their AI provider retains prompt data by default. Auditors review your data processing agreements with AI vendors to confirm retention and use terms.
Output data handling. AI outputs that contain personal data (for example, AI-generated summaries of customer records) are subject to the same retention and access controls as any other personal data. Auditors ask whether output data is categorised and handled accordingly.
Data subject rights and AI. If personal data was used in training or is processed at inference time, data subject rights requests (access, deletion, portability) may apply. Auditors ask whether you have a process for responding to data subject rights requests that accounts for AI processing.
Common audit findings related to AI
Based on what auditors at major firms are reporting, the most frequent AI-related SOC 2 findings in 2025-2026 are:
-
No AI model inventory. Companies cannot produce a list of AI models in production, their versions, providers, and purposes. This makes scoping every other AI control impossible.
-
Undocumented model deployments. Model updates deployed outside the change management process, with no record of what changed or when.
-
No written testing or accuracy monitoring procedures. AI is deployed to production based on informal testing, with no documented methodology or acceptance criteria.
-
No access controls on AI endpoints. Model APIs accessible without authentication or without role-based access controls.
-
Third-party AI vendor not in vendor management programme. The AI provider whose model processes customer data has not been assessed for security, availability, or privacy controls.
-
No AI incident response procedure. General incident response procedures do not address AI-specific failure modes such as model degradation, adversarial attack, or discriminatory output.
See the AI tool register template for a starting point on the model inventory, which resolves the first three gaps simultaneously.
How to prepare: AI documentation for SOC 2 auditors
The documentation package for an AI-ready SOC 2 audit should include:
AI model inventory. A register of every AI model in production, including: model name and version, provider (internal or vendor), intended use case, deployment date, data inputs at inference, and the control owner responsible for testing and monitoring.
Testing and evaluation records. Documentation of pre-deployment testing for each model, including the test dataset used, metrics evaluated, acceptance criteria, and pass/fail results.
Accuracy monitoring records. Evidence of ongoing monitoring including the monitoring methodology, frequency, metrics tracked, and a log of any anomalies identified and how they were resolved.
Change management records for model updates. Evidence that model version changes go through a formal change management process including testing, approval, and rollback documentation.
Vendor assessment records. SOC 2 reports or equivalent attestations from AI vendors whose models process customer data, along with your internal assessment of how their controls address availability, confidentiality, and privacy risks.
AI-specific incident response procedure. A documented procedure for responding to AI failures, discriminatory outputs, or adversarial attacks, with evidence that it has been tested (tabletop exercise or live incident).
The AI governance checklist 2026 provides a broader governance framework that encompasses the SOC 2 documentation above alongside other regulatory requirements.
Questions to expect from a SOC 2 auditor about AI
Auditors are now asking questions like:
- How do you know which AI models are running in your production environment?
- What is your process for testing a model before it goes to production?
- How do you monitor whether model outputs are accurate after deployment?
- What happens when the AI model is unavailable? Walk me through your fallback procedure.
- Who has access to your model API endpoints? How is that access reviewed?
- Does any customer data go into model training? If so, what was the legal basis?
- Who retains your inference-time prompt data: you or your AI vendor?
- How would you detect if your AI was producing discriminatory outputs?
- When did you last update your AI model? Can you show me the change record?
Preparing written answers to these questions before your audit, backed by the documentation described above, is the single most effective way to avoid AI-related findings.
For companies also navigating EU AI Act or other AI regulatory frameworks, see ISO 42001 vs EU AI Act vs NIST AI RMF which framework applies for guidance on how SOC 2 AI governance documentation maps to other frameworks.
How to update your existing SOC 2 controls for AI
If you have an existing SOC 2 programme and you are adding AI capabilities, you do not need to start over. The most efficient approach is to extend your existing controls to cover AI, rather than creating parallel AI-specific processes.
Extend your asset inventory to include AI models. If you maintain a software asset inventory or a system inventory as part of your common criteria controls, add AI models to it. Each entry should include the model name, version, provider, intended use, and the data it processes.
Extend your change management process to cover model updates. Your existing change management controls should already require testing and approval for production changes. Add a step for AI model updates that includes accuracy testing and rollback verification. The key is that the change goes through the same approval gate as any other production change.
Extend your vendor management programme to cover AI vendors. Your third-party vendor assessment process probably already covers critical software vendors. Add your AI providers to the list and collect their SOC 2 reports (or review their security attestations if they do not have a SOC 2).
Extend your incident response process to cover AI failures. Add a section to your existing incident response runbook that covers AI-specific failure modes: model unavailability, accuracy degradation, adversarial prompt attacks, and discriminatory output events. Define who owns each type of AI incident and what the escalation path is.
Add AI-specific monitoring to your existing monitoring infrastructure. If you already run availability monitoring for production services, extend it to include your AI model APIs. Add accuracy metric dashboards alongside your existing performance dashboards.
This extension approach is faster to implement than building separate AI governance processes and is easier to demonstrate to auditors as an integrated part of your control environment.
Timing: when AI controls come into scope
For companies undergoing a Type II audit, AI controls come into scope based on when the AI system was deployed into production. If you deployed an AI feature six months before your audit period ends, auditors will expect to see evidence of controls operating for those six months.
The most common timing mistake is deploying AI features during the audit period without updating control documentation first. You end up with a finding because the AI feature was in scope but the controls were not yet in place when it was deployed.
Best practice is to update your SOC 2 control documentation before deploying AI to production. This means: updating your asset inventory, extending your change management process, adding AI to your monitoring dashboards, and documenting your accuracy testing procedures, all before the deployment date. That way, from the first day the AI feature is live, the controls are operating.
See the AI vendor evaluation checklist for a framework to assess third-party AI providers before deployment, which gives you the documentation you need to demonstrate vendor oversight controls in your SOC 2 report.
Related Reading
- AI Agent Data Controls Register: A Free Template
- AI tool register template
- AI governance checklist 2026
- High-risk AI documentation templates for August 2026
- AI vendor evaluation checklist
- AI regulatory readiness scorecard for software and biotech
- AI supply chain security checklist 2026
- ISO 42001 vs EU AI Act vs NIST AI RMF which framework applies
- AI red-teaming security testing requirements 2026
