SOC 2 does apply to AI systems. There's no separate "AI criterion" in the framework. Auditors instead apply the existing AICPA Trust Services Criteria to your models, prompts, and inference infrastructure, and they now expect AI-specific evidence to back it up. The first move is simple: inventory every AI system in production, decide what's in scope versus what belongs to a subservice organization, and start collecting the logs the AICPA's guidance and the NIST Generative AI Profile both point toward.
TL;DR:
- Auditors now require detailed AI-specific evidence like model lineage, drift logs, and deployment approval records, not just general monitoring statements.
- Continuous drift monitoring exports should cover at least one full quarter before the audit to avoid rejection for assembled evidence.
- AI controls are mapped to traditional SOC 2 categories such as security, availability, and processing integrity, but evidence must demonstrate ongoing operation and validation.
- A centralized telemetry system, like Quikturn's MCP server, simplifies evidence collection by consolidating agent calls, inference requests, and access logs.
- Most enterprise buyers prefer a Type II SOC 2 report for AI workloads, as it proves controls operated effectively over time rather than just on a single date.
Table of Contents
- How the Trust Services Criteria Map to AI Workloads
- Controls and Concrete Evidence Auditors Now Expect
- Scoping Decisions, Type I vs. Type II, and What They Cost You
- An Actionable SOC 2 Readiness Checklist for AI
- SOC 2, ISO 42001, and NIST: Choosing and Crosswalking Frameworks
- Common Audit Red Flags and What to Fix First
- Where a Centralized MCP Server Fits Into Evidence Collection
- Fold AI Into SOC 2, Don't Build a Parallel Attestation
- A Faster Path to Auditor-Grade AI Logs
- Sources
- FAQ
How the Trust Services Criteria Map to AI Workloads
Auditors aren't inventing new rules for AI. They're stretching five familiar categories to cover territory that didn't exist when the Trust Services Criteria were written. If you've read a SOC 2 report before, the categories will look familiar. What's changed is the evidence behind them.
Security now means access controls on model endpoints, not just servers and databases. Auditors want to see API authentication schemes, role-based access control for who can query or retrain a model, and network segmentation that keeps inference traffic away from systems that don't need it.
Availability gets tested against inference SLAs. If your product depends on a third-party model provider, auditors ask what happens when that provider has an outage. Do you have failover? A documented degraded-mode plan? Or does your service just go dark?
Processing integrity is where AI diverges most from traditional SOC 2 work. This criterion now covers drift detection, output validation, and rollback procedures. A model that quietly degrades in accuracy over three months is a processing integrity failure, even if nothing "crashed."
Confidentiality and privacy together govern training-data handling, prompt logs, and retention. Auditors ask how long you keep raw prompts, whether personally identifiable information gets redacted before it touches a log file, and who can see that data once it's stored.
The through line: every criterion still exists to answer one question. Can you prove the system behaves the way you say it does? Areebi's crosswalk between TSC controls and AI operational practices is one of the more thorough attempts to formalize this mapping, and it's worth reading before your first AI-inclusive audit.
- Security (CC6): endpoint auth, RBAC, network segmentation
- Availability (A1): inference SLAs, model-provider failover plans
- Processing integrity (PI1): drift detection, output validation, rollback logs
- Confidentiality/Privacy (P1 to P8): prompt redaction, retention limits, training-data governance
Controls and Concrete Evidence Auditors Now Expect
A control narrative that says "we monitor our models" doesn't survive contact with a competent auditor anymore. You need artifacts. Soc2auditors lists the specific evidence types now showing up in AI-inclusive audits, and they cluster into five buckets.
- Model registry entries and lineage proof. Every model in production should trace back to a specific training dataset, a version number, and a sign-off. If you can't answer "which data trained this model" in under a minute, that's a finding waiting to happen.
- Change-management tickets and CI/CD gate evidence. Deployments need an approval trail, not a Slack message that says "shipped it." Auditors will sample deployment tickets across the observation window and check for consistent gate enforcement.
- Drift-monitoring exports and rollback logs. A single screenshot from audit week doesn't cut it. You need programmatic exports covering the full window, showing the model's performance over time and proof you can roll back when it slips.
- Prompt and inference logs with redaction proof. Retention policies and DLP coverage need to show, not just claim, that sensitive inputs get scrubbed before storage.
- Access control artifacts. MFA on every privileged role touching model infrastructure, API key rotation schedules, and mTLS between services that exchange model outputs.
Pro Tip: Start your drift-monitoring exports at least one full quarter before your audit window opens. Auditors increasingly reject evidence that only covers the final two weeks before fieldwork, because it looks assembled for the test rather than produced by real operations.
Scoping Decisions, Type I vs. Type II, and What They Cost You
Whether a model vendor counts as part of your system or as a subservice organization changes your entire audit. Linford's guidance on AI and ML subservice boundaries draws the line at whether the model is core to how you deliver your service or just an internal productivity tool. A customer-facing recommendation engine built on a third-party foundation model is usually in scope. An internal chatbot that drafts marketing copy usually isn't.
Procurement teams increasingly ask for Type II reports specifically, not Type I. A Type I report proves your controls exist on a single date. A Type II report proves they worked continuously across a period, typically over a period and that's a much heavier evidence burden for anything involving drift or model behavior over time.
- Type I: point-in-time design check, faster and cheaper, weaker signal to buyers
- Type II: continuous operating evidence, what most enterprise procurement now expects
- Cost drivers: length of drift history required, number of vendor assessments, depth of continuous-monitoring tooling already in place
Schellman's recommendation to re-evaluate which Trust Services categories to include, and to consider a SOC 2+ report when AI is central to delivery, is sound advice for any team weighing these tradeoffs before signing an audit engagement letter.
An Actionable SOC 2 Readiness Checklist for AI
Most teams overbuild the parts that don't matter and underbuild the parts auditors actually test. Work through these in order.
- Inventory and classify every model and data source in production, then map each one to the relevant Trust Services Criteria.
- Implement a model registry with CI/CD gates, change approvals, and telemetry hooks baked into the deployment pipeline, not bolted on afterward.
- Set up continuous-monitoring exports into a SIEM or telemetry system, and layer DLP over prompt and input logs so redaction happens automatically.
- Run vendor risk assessments on every AI provider, get data processing agreements signed, and fold those vendors into your existing vendor-management program rather than treating them as a special case.
- Run tabletop exercises for AI-specific incidents like prompt injection or a hallucinated output reaching a customer, and keep the exercise documentation as evidence.
SureCloud's 2026 compliance guide identifies continuous monitoring exports, signed vendor DPAs, and tested incident exercises as the highest-leverage readiness items, the ones that separate a smooth audit from a scramble. Teams that build these four before their audit window opens consistently spend less time in remediation cycles once fieldwork starts.
SOC 2, ISO 42001, and NIST: Choosing and Crosswalking Frameworks
SOC 2 is fundamentally a procurement document. It answers the question a customer's security team asks before signing a contract. ISO 42001 and the NIST AI frameworks aim at something different: they govern how you manage AI risk operationally, independent of whether a customer ever asks for a report.
Most companies that need both find heavy overlap rather than duplicate work. Security researchers estimate SOC 2 and ISO 27001 share roughly 80% control overlap, and a similar pattern holds between SOC 2's AI-adjacent controls and ISO 42001's management-system requirements. The efficient move is one control program mapped to multiple standards, not three parallel compliance efforts.
- CC6 (logical access) maps to NIST AI's access-governance actions and ISO 42001's operational controls for AI system access
- CC7 (incident management) maps to NIST's incident-response guidance for AI-specific failure modes
- PI1 (processing integrity) maps to NIST's model-performance monitoring actions and ISO's continual-improvement requirements
Build the crosswalk once, in a spreadsheet or a GRC tool, and reuse the same evidence artifacts across every framework that asks for them.
Common Audit Red Flags and What to Fix First
The same handful of findings keep showing up across AI-inclusive SOC 2 engagements.
- Shadow AI. Undocumented agent integrations and ad-hoc API calls to model providers that never went through procurement or security review.
- Snapshot evidence instead of continuous evidence. A screenshot from audit week where auditors expect an export covering the full observation window.
- Consumer-tier AI vendor assurances. Relying on a provider's marketing page instead of a signed data processing agreement.
- Missing drift and incident logs. No record that anyone was watching for model degradation or responding when it happened.
SureCloud's research flags shadow AI as one of the most frequent findings in recent engagements, and the fix is usually cheaper than the discovery: an API gateway and a documented inventory of every agent endpoint in use.
Pro Tip: Rank your remediation by evidence dependency, not by ease of implementation. Fixing access controls is quick, but if your drift-monitoring pipeline isn't producing exports yet, start there first. It takes months to accumulate a usable evidence history, while access fixes can happen in a sprint.
Where a Centralized MCP Server Fits Into Evidence Collection
Auditors want consistent telemetry across the whole audit window, and that's exactly where fragmented AI tooling causes trouble. When agent calls, model queries, and inference requests scatter across a web app, a desktop add-in, and a handful of custom API integrations, stitching together a coherent log for auditors becomes its own project.
Quikturn's MCP server centralizes AI agent calls through a single integration point, whether the request originates from the web platform, the PowerPoint add-in, or the API directly. That centralization produces a consistent telemetry stream, useful raw material for drift monitoring and incident evidence, because every call passes through the same logging layer instead of three different ones.
Centralizing telemetry doesn't replace the audit itself. Scope decisions, control design, and evidence sufficiency remain the auditor's judgment call, not a platform feature.
Fold AI Into SOC 2, Don't Build a Parallel Attestation
Auditors and buyers now expect AI coverage inside your existing SOC 2 report, not a separate certificate nobody asked for. The stronger move is investing in evidence quality, continuous telemetry, drift history, redaction proof, over inventing new paperwork. When you brief non-technical stakeholders, frame it plainly: same criteria, new evidence types, same report they already trust.
— Quikturn Team
A Faster Path to Auditor-Grade AI Logs
Building the telemetry pipeline this article describes, model lineage tracking, redaction logs, centralized access records, takes real engineering time most compliance teams don't have to spare. Quikturn gives finance and compliance teams a shortcut worth considering: its MCP server routes every AI agent call, whether from the web app, the PowerPoint add-in, or direct API access, through one integration point, so the logs your auditor asks for already exist in one place instead of scattered across three systems you have to reconcile by hand.
For teams evaluating whether a centralized platform is worth the switch, Quikturn's enterprise tier includes the security controls and access governance auditors specifically test for under CC6. If you're weighing the engineering cost of building this yourself against integrating a platform that already produces the telemetry, get started with Quikturn and see what a centralized evidence trail looks like before your next audit window opens.
Sources
- SOC 2 for AI companies — what auditors look at
- SOC 2 Compliance Guide: 2026 Requirements & AI Controls
- SOC 2 + AI Workloads: How the Trust Services Criteria apply
- How to Incorporate AI Controls into Your SOC 2 Examination
FAQ
Does SOC 2 Cover AI?
Yes. SOC 2 has no separate AI criterion, but auditors apply the existing Trust Services Criteria, Security, Availability, Processing Integrity, Confidentiality, and Privacy, to AI systems and now expect AI-specific evidence like model lineage and drift logs.
What Evidence Do Auditors Want for AI Systems Specifically?
Auditors look for model registry entries, change-management tickets for deployments, continuous drift-monitoring exports, redacted prompt logs, and signed vendor data processing agreements for any third-party model API.
Should We Pursue a Type I or Type II Report for AI Systems?
Most procurement teams now expect Type II, since it proves controls operated continuously over a period rather than existing on one audit date, which matters more for AI given how model behavior can drift over time.
How Does SOC 2 Compare With ISO 42001 for AI Governance?
SOC 2 is built for procurement and answers a customer's security questions directly. ISO 42001 and NIST AI frameworks govern operational AI risk management, and most teams find enough control overlap to build one program mapped to both.
Is SOC 2 Still Relevant Now That AI Handles More of the Workload?
Yes. AI adoption has increased what auditors test for, not replaced the framework. SOC 2 remains the report buyers expect, and folding AI evidence into it is more efficient than pursuing a separate attestation.