Does SOC 2 Cover AI Risk? What Auditors Are Starting to Ask
Your compliance lead is three weeks from a SOC 2 Type II renewal when the auditor asks a question nobody prepped for. Last quarter, the product team quietly wired a large language model into the support workflow: it drafts responses, pulls account context from a RAG pipeline, and occasionally files a ticket update on its own. The auditor wants to see the model registry entry, the prompt and inference logs, and the vendor risk assessment for the LLM API sitting behind it. None of that exists, because nobody thought an SEO-friendly chatbot upgrade was an audit event.
This is playing out at a lot of companies right now, and it raises a fair question: does SOC 2 cover AI risk, or is this scope creep from an auditor who's read too many AI headlines? The honest answer is that SOC 2 itself hasn't changed. What's changed is how auditors interpret the Trust Services Criteria you already report against, and if your AI features aren't accounted for in that interpretation, your next renewal is going to surface gaps you didn't know you had.
SOC 2 Doesn't Have an "AI Module." Auditors Built One Anyway
The AICPA has not published a dedicated AI supplement to SOC 2. The five Trust Services Criteria, Security, Availability, Processing Integrity, Confidentiality, and Privacy, still anchor every engagement, and the underlying 2017 framework hasn't been rewritten. What changed is interpretation. AICPA-aligned practice guidance issued in late 2025 sharpened how member firms should evaluate AI-related controls under criteria that already existed, and most audit firms updated their playbooks to match by early 2026.
In practice, that means auditors aren't inventing new checkboxes. They're asking you to demonstrate that criteria you've reported against for years, CC1.4 (commitment to competence), CC3.1 (risk identification), CC6.1 (logical access), CC7.2 (system monitoring), and CC9.2 (vendor risk mitigation), hold up when the system in question is a model instead of a database. If your last SOC 2 report was finalized before your AI features shipped, this is the gap that's about to surface.
This is also where AI compliance audit work starts to overlap with security testing rather than paperwork. An auditor can confirm a control exists on paper. A penetration test confirms whether it actually holds under adversarial pressure, which is a distinction worth understanding before your next audit window opens.
Where AI Risk Actually Lands in the Trust Services Criteria
There's no separate "AI Trust Services Criteria." AI risk gets mapped into the same five categories your SOC 2 report already covers. The table below shows how auditors are making that translation in 2026 engagements.
| Trust Services Criterion | Traditional Focus | AI-Era Interpretation |
|---|---|---|
| Security (CC1.4, CC3.1) | Role definitions, risk register, security awareness training | Named owners for who can deploy or fine-tune production models; AI risks explicitly listed in the risk register (prompt injection, training data exposure, hallucination-driven customer harm) |
| Security (CC6.1) | Access control on databases, servers, applications | Access control on model APIs, fine-tuning endpoints, and embedding/vector stores, governed the same way as production data access |
| Security (CC7.2) | Log review, anomaly detection, incident response | Logged model inputs and outputs, a documented process for investigating anomalous model behavior, and accountability for actions an agent takes without a direct human request |
| Availability (A1.2) | Uptime commitments, failover planning | Contingency planning for third-party LLM API outages or provider policy changes that could disrupt the service |
| Confidentiality / Privacy | Encryption, data classification, retention policy | PII redaction before prompt and inference logging, retention limits on conversational data, and controls preventing training data leakage through outputs |
| Vendor Risk (CC9.2) | Vendor questionnaires, subservice organization review | Treating the LLM provider as a subservice organization where appropriate, not a generic SaaS vendor, with its own risk assessment |
None of this requires the AICPA to publish new criteria. It requires your control narratives to actually reference the AI systems in scope instead of describing infrastructure that predates them.
What Auditors Are Actually Asking For in 2026
If your SOC 2 scope touches a customer-facing or data-processing LLM feature, expect requests for evidence that traditional SaaS audits never generated:
- A model registry. Every model promoted to production, tagged with version, training data snapshot reference, evaluation metrics, and the named approver who signed off on deployment.
- Prompt and inference logs with PII redaction applied before logging, not after, so sensitive data never lands in a log store in the first place.
- A documented rollback procedure with a tested example, not a runbook nobody has run. Auditors want the same change-management evidence for a model update that they'd want for a database schema change.
- A vendor risk assessment for every third-party LLM you call, distinct from your standard SaaS vendor review, because a foundation model provider can qualify as a subservice organization whose controls become part of your audit story.
- Drift monitoring output showing that model performance is tracked against a baseline, with alert thresholds and evidence that a human reviewed the deviation.
- Accountability for autonomous actions. If an agent takes a privileged action, sends an email, updates a record, calls an API, auditors increasingly treat "no human request" as an accountability gap on its own, separate from whether the action itself was correct.
Generic language like "we evaluate vendor risk" or "we use OpenAI" doesn't satisfy this bar anymore. Auditors want named individuals, dated approvals, and evidence the control operated, not just that it exists in a policy document.
The OWASP Angle: Why LLM02 and LLM06 Show Up in Audit Conversations
The OWASP Top 10 for LLM Applications (2025) isn't a compliance framework, but it's become the shared vocabulary auditors and security teams use to talk about the same risks from different angles. Two categories map directly onto the SOC 2 evidence auditors are now requesting.
LLM02:2025, Sensitive Information Disclosure, covers exposure of PII, credentials, or proprietary data through model outputs, logs, or training data. This is the same failure mode SOC 2's Confidentiality and Privacy criteria are meant to catch, and it's why auditors are asking specifically about redaction timing in your logging pipeline rather than just whether logging exists.
LLM06:2025, Excessive Agency, covers models or agents holding more capability, autonomy, or permission than their task requires. OWASP breaks this into excessive functionality, excessive permissions, and excessive autonomy, and all three map onto the accountability gap auditors flag under CC6.1 and CC7.2 when a privileged action traces back to a generic system account instead of a person.
Framing SOC 2 evidence in OWASP terms gives your compliance team and your engineering team a shared reference point, which matters more than it sounds like it should. A control narrative that says "we mitigate LLM06 excessive agency through tool-scoping and human-in-the-loop approval for high-impact actions" reads as considerably more credible to an AI-literate auditor than a paragraph about "responsible AI principles." If you're building out this mapping in more depth, our breakdown of how AI pentest evidence maps to the NIST AI RMF functions covers the same translation problem from the governance-framework side.
A Sanitized Look at How This Plays Out
To make this concrete without turning it into a how-to: picture a SaaS company running a support chatbot with RAG access to a customer knowledge base. The chatbot is scoped to answer questions about the product tied to the current ticket. During a pentest engagement, testers found that a cleverly worded support ticket, containing text formatted to look like an internal instruction, could get the model to pull and summarize account details from a different customer's record that happened to sit near the retrieved content in the vector store.
No credentials were bypassed and no exploit code was involved. The model simply did what a permissive retrieval scope and an under-specified system prompt allowed it to do. That's LLM02 and LLM06 showing up in the same incident: sensitive information disclosure enabled by a model that had more retrieval agency than its task justified. The fix wasn't a patch. It was tightening retrieval scoping, adding output filtering before customer-facing responses, and logging the retrieval boundary as a testable control, exactly the kind of evidence a 2026 SOC 2 auditor would now ask to see.
Shadow AI and the Subprocessor Problem
A quieter risk auditors are probing for is shadow AI: engineers piping company or customer data into unapproved AI tools that never went through vendor review or change management. It bypasses the exact controls your SOC 2 report claims are in place, and it's hard to catch because it doesn't show up in a firewall log the way an unapproved SaaS signup would.
The related question auditors are asking more often is whether your LLM provider should be listed as a subservice organization rather than folded into a generic "vendors" line item. If a foundation model API is core to how you deliver your service, its outages, policy changes, or security incidents affect your customers directly, which is the same test SOC 2 already applies to your cloud host or payment processor. Treating a frontier LLM provider like any other SaaS tool in your vendor register is one of the more common gaps we see when we bring an AI penetration test lens to a compliance-driven engagement.
What Waiting Actually Costs You
Remediating an AI evidence gap before your audit fieldwork starts is a fundamentally different conversation than remediating one after an auditor has already flagged it. A first-year SOC 2 Type II engagement for a company with meaningful AI in scope commonly runs well into six figures once you add auditor fees, a compliance automation platform, readiness consulting, and the engineering time to close gaps, and that number climbs when findings surface mid-audit and force a scramble rather than a planned build-out.
The other timing issue is specific to Type II reports. A Type I report tells an auditor your controls exist on a given date. A Type II report has to show those controls operating effectively over a review period, typically six to twelve months. If you stand up a model registry or prompt-logging pipeline the week before fieldwork, there's no operating history for the auditor to test against, which means the control effectively doesn't count for that cycle. AI controls need lead time in a way that a firewall rule change doesn't, which is the practical argument for running a gap assessment now rather than during renewal season.
Traditional Pentest Evidence vs. AI Pentest Evidence
A standard web or API pentest and an AI-focused pentest produce different evidence, and SOC 2 auditors are starting to expect both when an LLM sits in scope.
| Evidence Category | Traditional Pentest | AI-Focused Pentest |
|---|---|---|
| Access control testing | Authentication bypass, privilege escalation on app/API endpoints | Access control on model APIs, fine-tuning endpoints, and vector stores; agent permission scoping |
| Input handling | Injection (SQLi, XSS), input validation on forms and APIs | Prompt injection resilience (direct and indirect), RAG retrieval scope testing |
| Data exposure | Database misconfiguration, unauthorized data access | Sensitive information disclosure through model outputs, logs, or training data (LLM02) |
| Business logic abuse | Workflow bypass, race conditions | Excessive agency: tool-scoping gaps, autonomous actions without human approval (LLM06) |
| Deliverable mapped to compliance | Findings mapped to OWASP Top 10, remediation timeline | Findings mapped to OWASP LLM Top 10 and NIST AI RMF functions, structured for SOC 2 CC6/CC7 evidence |
If your SOC 2 scope includes a model, a RAG pipeline, or an agent with tool access, a traditional pentest alone won't generate the evidence your auditor is going to ask for. That's the gap our AI penetration testing service is built to close, with findings structured so they drop directly into your control narratives instead of sitting in a PDF nobody translates.
Planning an AI security assessment also requires a realistic understanding of delivery time. Our guide, How Long Does an AI Penetration Test Actually Take?, explains typical timelines for targeted AI feature reviews, full AI application penetration tests, and complex agentic or multi-integration assessments. It also covers the scope, access, integration, reporting, validation, and retesting factors that can affect the final schedule.
Closing the Evidence Gap Before Your Next Audit Window
None of this means SOC 2 has become an AI certification, and it doesn't mean every chatbot integration needs a six-figure compliance program. It means the evidence bar moved, quietly, through interpretation rather than a new framework, and the companies getting surprised in 2026 audits are mostly the ones who scoped their AI features out of the compliance conversation entirely.
The practical starting point is a gap assessment: pull your current SOC 2 scope, list every LLM-touching feature that shipped since your last report, and check each one against the criteria in the table above. Where you find gaps, an AI-focused pentest gives you the kind of tested, dated evidence auditors are asking for, rather than a policy document describing controls nobody has verified under pressure.
Pentest Testing Corp has run thousands of penetration tests for organizations across financial services, healthtech, and SaaS, and our AI security assessments are led by CEO Md. Shofiur, a Freelancer.com-recognized cybersecurity expert holding certifications spanning ethical hacking, digital forensics, API security for PCI compliance, and ISO/IEC 27001. If your next SOC 2 renewal includes AI in scope, a short scoping conversation now is considerably cheaper than a qualified opinion later.
Book a free 30-minute scoping call to walk through what your auditor is likely to ask and where your current evidence stands.
Frequently asked questions
Does SOC 2 have a specific AI or LLM control set?
No. The AICPA has not published a dedicated AI module for SOC 2. The five Trust Services Criteria remain unchanged, but auditors are interpreting existing criteria, particularly CC1.4, CC3.1, CC6.1, CC7.2, and CC9.2, against AI-specific risks like model versioning, prompt logging, and vendor LLM dependencies.
Which Trust Services Criteria apply most to AI systems in a SOC 2 audit?
Security is the mandatory baseline for every engagement and covers most AI-specific evidence: access control on model APIs (CC6.1), monitoring of model inputs and outputs (CC7.2), and vendor risk assessment for LLM providers (CC9.2). Confidentiality and Privacy apply directly when prompts, logs, or training data could expose PII.
What evidence do SOC 2 auditors request for AI features in 2026?
Common requests include a model registry with version and approval history, prompt and inference logs with PII redaction applied before logging, a tested rollback procedure, a vendor risk assessment specific to each LLM provider, drift-monitoring output, and clear accountability for any privileged action an autonomous agent takes.
How does OWASP's LLM Top 10 relate to SOC 2 compliance?
OWASP's Top 10 for LLM Applications isn't a compliance framework, but it gives auditors and engineering teams shared vocabulary. LLM02 (Sensitive Information Disclosure) maps to SOC 2's Confidentiality and Privacy criteria, and LLM06 (Excessive Agency) maps to the access control and monitoring criteria auditors use to test agent accountability.
Do third-party LLM providers count as subservice organizations under SOC 2?
They can, and increasingly should, if the provider is core to service delivery rather than a peripheral tool. That distinction matters because subservice organizations' controls become part of your SOC 2 story, the same treatment already applied to cloud hosts and payment processors.
Can a penetration test help satisfy SOC 2 AI evidence requirements?
Yes. An AI-focused penetration test generates the kind of tested, dated evidence auditors are asking for, prompt injection resilience, retrieval scope boundaries, agent permission testing, structured to map directly onto CC6, CC7, and the OWASP LLM Top 10 categories your control narratives should already reference.
