SOC 2 for AI Companies in 2026 — What Auditors Test That Didn't Exist Two Years Ago

Two years ago, if you asked a SOC 2 auditor what they wanted to test for an AI company, the answer looked almost identical to what they asked any SaaS vendor. Firewall rules. Access logs. Encryption at rest and in transit. Backup procedures. Incident response documentation.

That is not what the conversation looks like in 2026.

The companies coming through SOC 2 Type 2 engagements now have ML pipelines, LLM integrations, autonomous agents taking actions on behalf of users, and engineering teams using AI coding tools that the security team may not even know about. The Trust Services Criteria have not changed — the AICPA has not released a special AI edition of SOC 2. But auditors are mapping existing criteria to AI-specific risks in ways that produce entirely new evidence requests. If you are a company building with AI and planning your first or next SOC 2 audit report, the preparation looks materially different from anything your peer company went through in 2022 or 2023.

This article covers exactly what has changed — the specific things SOC 2 auditors are now testing for AI companies that were simply not on the radar before.

THE FRAMEWORK HASN'T CHANGED. THE RISK HAS.

Before getting into the specifics, the important starting point: SOC 2 compliance is still a SOC 2 compliance exercise. Your SOC 2 audit report is still issued under AICPA attestation standards by a licensed CPA firm. The five Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — still define the scope. A SOC 2 Type 2 report still covers a defined observation period, typically 6 to 12 months, during which the auditor tests whether controls are operating effectively, not just designed on paper.

None of that has changed.

What has changed is that the risk profile of a company building with AI sits in fundamentally different territory from a traditional SaaS company. When your product calls OpenAI's API, an LLM provider is processing customer data in a way your own systems never touch. When an autonomous agent takes a privileged action — writing to a database, sending an email on behalf of a user — that action needs to be attributable to someone or something accountable. When an engineer pipes a customer data export into ChatGPT to debug a problem, that is a vendor relationship your vendor management process almost certainly did not approve.

SOC 2 auditors are seeing these realities in fieldwork and adapting their testing accordingly.

1. MODEL LINEAGE — PICK A MODEL, SHOW ITS HISTORY

In a traditional SaaS SOC 2 audit, change management testing involves showing that code deployments were approved, tested, and authorised before going to production. The change management ticket, the pull request review, the deployment log.

For an AI company, the SOC 2 auditor now extends this to model deployments. Pick a model currently in production — any model. Show the dataset it was trained or fine-tuned on. Show the approval chain. Show the testing that happened before it went live. Show that there is a documented, tested rollback procedure if the model behaves unexpectedly.

This is what auditors call model lineage. It maps directly to CC8 — Change Management — in the SOC 2 Common Criteria. But the evidence looks nothing like a traditional change ticket. A company without a model registry, or one where models were updated informally between sprints without a formal approval gate, will struggle to produce this evidence during fieldwork.

The fix is not technically complex. It requires a model registry — a documented record of every model version in production, the inputs that produced it, and the approvals that authorised it. Many teams already have this informally. The SOC 2 requirement is that it is formal, maintained, and auditable.

2. LLM SUBPROCESSORS — YOUR PROVIDER IS NOT INVISIBLE

If your application calls OpenAI, Anthropic, Google Gemini, Mistral, or any hosted LLM, that provider is a subprocessor under your SOC 2 reporting framework. Customer data flows through their infrastructure as part of your service. Auditors test this.

What a SOC 2 auditor now asks for every LLM provider in scope:

• A signed Data Processing Agreement confirming the terms under which your customer data is processed. Not a reference to their Terms of Service. An actual DPA.

• Written confirmation — in the contract, not in the provider's marketing copy — that data is not used to train their models unless you have explicitly opted in. This distinction matters in SOC 2 reporting because your Confidentiality and Privacy commitments extend to the data your LLM provider handles on your behalf.

• A copy of the provider's own SOC 2 report or ISO 27001 certificate. This is your evidence that you have assessed their security posture, not just assumed it.

• Your vendor risk assessment for each provider, documenting why you chose them and what residual risk you accepted.

The LLM provider exception that auditors are flagging in 2026: API keys for these providers are credentials. They need to live in a secrets manager, rotate on a documented schedule, and be revoked on offboarding with the same rigour as database credentials. Companies that treat LLM API keys as a convenience configuration item rather than a credential management matter are getting observations in their SOC 2 audit reports.

3. SHADOW AI — THE FINDING NOBODY EXPECTS

The most common AI-related finding in SOC 2 audits in 2026 is not about the AI your company has deployed. It is about the AI your employees are using without your compliance team knowing about it.

Shadow AI — engineers and customer support staff using ChatGPT, Claude, Gemini, or AI coding assistants to process company or customer data without going through your vendor review process — creates three simultaneous SOC 2 control failures:

• A vendor management gap: the tool is not on your vendor inventory and has not been risk-assessed. Your vendor management controls, however well-designed on paper, are not working in practice for this category of tool.

• A policy gap: if no AI-specific usage policy exists, employees cannot be in violation of it, but auditors will note the absence as a control deficiency.

• An evidence gap: auditors test controls in practice, not just in documentation. If fieldwork — log review, employee interviews, incident discovery — surfaces shadow AI usage, it directly undermines the evidence that your access and data handling controls are operating effectively.

• Auditors are probing for this explicitly. The testing involves reviewing endpoint security logs, checking whether AI browser extensions are visible or blocked, and in some cases including questions about AI tool usage in employee interviews during fieldwork.

The control that addresses this is not a technical block — although browser extension controls help under CC6. It is a documented AI tool approval process: a list of approved AI tools, a process for requesting approval for new ones, and monitoring that gives you visibility into what is actually being used.

4. AGENT ACCOUNTABILITY — WHEN THE MACHINE ACTS

Autonomous AI agents — systems that take actions on behalf of users without a human approving each step — create a specific SOC 2 challenge that did not exist in meaningful scale two years ago.

SOC 2's access control criteria expect privileged actions to be attributable to an accountable person. When an agent writes to a database, sends a communication, or calls an external API without a human directly authorising that specific action, auditors have a legitimate question: who is accountable for this action in your control framework?

The evidence auditors now request for agentic systems includes: a clear definition of what actions the agent is authorised to take and what it is prohibited from taking, audit logs that attribute each agent action to the session, user, and workflow that initiated it, and evidence that the agent's permission scope is limited to what it actually needs — not the widest scope that makes development convenient.

Agent-generated code that executes at runtime without human authorisation is a specific area of auditor focus. CVE-2025-34291 in the Langflow AI platform — which allowed attackers to bypass authentication and execute arbitrary Python code — is now part of the risk context auditors use when assessing agent accountability controls. The evidence needed is a tested authorisation boundary for every agent deployment.

5. PROMPT AND INFERENCE LOGS — WITH PII HANDLED BEFORE LOGGING

Logging is a foundational SOC 2 control area. Security operations need logs to detect anomalies. Incident response needs logs to reconstruct what happened. Auditors test logging coverage and retention.

For AI companies, the logging requirement extends to prompt and inference logs — records of what went into the model and what came out. But here is the tension: if customer prompts contain personally identifiable information, logging them creates a privacy exposure. Auditors are testing how companies handle this tension.

The acceptable approach, as it has emerged in 2026 SOC 2 audits, is PII redaction applied before logging — not after. Customer data is scrubbed from the prompt before the log entry is written. The evidence required is documentation of the redaction mechanism, test results showing it works for common PII patterns, and logs that demonstrate the control is operating in production.

Companies that log everything and handle privacy questions later are producing evidence that conflicts with their own Confidentiality and Privacy commitments.

WHAT YOUR SOC 2 AUDITOR NEEDS TO UNDERSTAND

Not every SOC 2 auditor has caught up with what AI deployments actually look like. An auditor who has not tested an ML pipeline, reviewed a model registry, or assessed an LLM vendor relationship before will approach your engagement with a traditional SaaS testing programme — and will miss the AI-specific risk areas entirely.

For AI companies, the selection of a SOC 2 auditor matters more than it did two years ago. The questions to ask before engaging a CPA firm for SOC 2 reporting: Have they conducted SOC 2 audits for companies with LLM integrations in the last 12 months? What controls have they tested in that context? How do they approach agent accountability in the context of CC6 and CC7?

A SOC 2 Type 2 report that does not address these areas is not wrong — the AICPA has not codified AI-specific requirements. But it is incomplete relative to what enterprise buyers are now expecting when they review your SOC 2 audit report as part of vendor security assessments.

HOW ACCORP PARTNERS APPROACHES SOC 2 FOR AI COMPANIES

Accorp Partners is an AICPA peer-reviewed CPA firm that conducts SOC 2 Type I and Type II attestations for companies across SaaS, cloud infrastructure, and AI-native environments. Our auditors have worked with companies operating LLM integrations, agentic systems, and ML pipelines as part of their customer-facing service delivery.

For AI companies preparing for SOC 2 compliance, our readiness assessments specifically address model lineage documentation, LLM subprocessor vendor management, shadow AI governance, and agent accountability controls — so that the eventual SOC 2 audit report reflects the actual risk profile of an AI company, not a generic SaaS vendor.

Learn more about Accorp Partners' SOC 2 audit services here:
https://accorppartners.com/services/risk-assurance/soc-2

Frequently Asked Questions

Q: Does my company need a special SOC 2 framework for AI, or is the standard SOC 2 sufficient?

A: The standard SOC 2 framework applies. There is no AICPA-specific AI edition of SOC 2 as of 2026. The Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — remain the basis for every SOC 2 audit report. The AI-specific testing is auditors mapping existing criteria to the risks your AI systems introduce. Some AI companies layer ISO/IEC 42001 or the NIST AI RMF on top of SOC 2 to address AI governance specifically, but these are additions to SOC 2 compliance, not replacements.

Q: Does my LLM provider need to have a SOC 2 report for my audit to pass?

A: Your LLM provider's SOC 2 report is evidence in your vendor risk assessment, not a pass/fail condition for your own SOC 2 audit report. What auditors require is that you have assessed your LLM provider's security posture and documented why you trust them with customer data. A provider SOC 2 or ISO 27001 report is the strongest evidence for that assessment. A provider without either creates a vendor management gap that your auditor will flag.