SOC 2 for AI Companies (2026): What Auditors Test First

A SOC 2 report for an AI company is the same AICPA attestation as for any SaaS vendor, with one difference that changes the whole engagement: the audit scope follows your machine learning lifecycle, and auditors test evidence that traditional SaaS never produces. In 2026, the first things an AI-aware auditor asks for are model lineage (pick a deployed model, show the exact dataset, code, and approval behind it), prompt and inference logs with PII redaction applied before logging, drift-monitoring output, and a vendor risk assessment for every third-party LLM you call. Firewall rules and access logs get tested too — second.

There is no separate “SOC 2 for AI.” You report against the existing five Trust Services Criteria (TSC) set by the AICPA — Security (the Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy — but mapped to machine learning failure modes: training-data poisoning, model theft, performance drift, prompt-injected data leakage, and subprocessor risk from LLM vendors.

What auditors test first for AI companies

From firms in our network auditing AI startups, the opening procedures cluster around four things, in roughly this order:

1. Model lineage on demand. The auditor names a model version running in production and asks you to reproduce its training history — dataset snapshot, code commit, hyperparameters, and the approval that promoted it. If you cannot link a deployed artifact back to its inputs, that is a Processing Integrity (PI1.2) finding before the audit even reaches your firewalls.
2. Prompt and inference logging — with redaction. Auditors expect every inference logged with model version, a prompt hash or redacted prompt, tool calls, and outcome. The common gap: startups log raw prompts and completions, which now contain customer PII or PHI, with no redaction policy applied before the log is written. That converts your audit-trail control into a data-leakage finding.
3. LLM subprocessor evidence. If you call OpenAI, Anthropic, or any hosted model, that provider is a subprocessor. Auditors want your vendor risk assessment, proof you configured data-retention and training opt-out, and a copy of the provider’s own SOC 2 or ISO 27001 report.
4. Drift and change management. Drift-monitoring dashboards with alerting, plus change-management tickets showing every model deployment was approved, tested, and reversible.

The risks that derail these audits are newer than the framework. Shadow AI — engineers piping company data into unapproved AI tools — introduces unvetted subprocessors that bypass your change-management and vendor-review controls, and auditors increasingly probe for it (Linford & Co., 2026). Agent accountability is the other one: when an autonomous agent takes a privileged action with “no human request,” auditors treat that as an accountability gap, because SOC 2 expects privileged actions to be attributable to an accountable person, not a generic system account.

Defining SOC 2 in the world of AI

A SOC 2 report verifies that an AI company has implemented effective internal controls, measured against the TSCs. For an AI company that means an auditor examines how you manage the risks of building and deploying models — the machine learning operations (MLOps) underneath your service — on top of standard IT general controls.

The goal is not to prove your AI is “good.” It is to show that the systems and processes around your AI are controlled, as defined by the AICPA’s criteria. That distinction drives how you scope the audit and what evidence you prepare.

Why this gets complicated for AI

An auditor won’t just look at your servers and firewalls. They map the established TSCs directly to the failure modes of an AI product — risks a standard SaaS platform never has to prove against.

• Model Integrity: How do you prove your models haven’t been tampered with or unintentionally degraded? This ties directly to the Processing Integrity criterion, specifically PI1.2, which requires that “The entity implements policies and procedures over system processing to ensure that system processing is complete, valid, accurate, timely, and authorized.”
• Data Poisoning: What controls prevent a malicious actor from feeding your model poisoned training data, causing it to produce biased or incorrect outputs? This is a fundamental security threat that falls squarely under the Security criterion, particularly CC7.1 (related to detecting and mitigating malicious software and unauthorized changes).
• Algorithmic Bias: You need controls to identify, measure, and mitigate unintended bias in your model’s predictions. From a SOC 2 perspective, significant bias can lead to inaccurate outputs, which has direct implications for Processing Integrity (PI1.2) and can also violate Privacy commitments if it leads to discriminatory outcomes based on personal information.
• Training Data Security: If your models train on sensitive customer data, you need controls to protect it. This spans the Confidentiality and Security criteria. CC6.1 requires controls restricting access to logical and physical assets, which here includes your training datasets.

These AI risks have to be translated into the language of SOC 2 controls. Map a risk like data poisoning to a specific control auditable under the Security TSC, or you carry a gap into the audit. The SOC 2 security controls that cover access, change management, and monitoring are the base layer you then extend for AI.

A SOC 2 audit for an AI company tests evidence that you control the entire machine learning lifecycle — data ingestion, training, model deployment, and monitoring — well beyond server security.

This comes down to a governance framework an auditor can verify. Show controls for model versioning, data lineage, and access management, and the report becomes proof of a mature posture that helps you close enterprise deals faster.

This is also where adjacent frameworks come in. ISO/IEC 42001 — the AI management system standard published in December 2023 — and the NIST AI RMF Generative AI Profile (NIST-AI-600-1, July 2024) cover model governance, bias, and explainability that SOC 2 does not certify. They share controls with SOC 2, so most AI companies audit them together. They also feed straight into EU AI Act readiness: the Act’s high-risk obligations (risk management, data governance, logging, human oversight) apply from August 2, 2026 (European Commission), the same evidence categories auditors now ask AI companies to produce.

How Do You Scope a SOC 2 Audit for AI Systems?

Correctly scoping a SOC 2 audit is the most critical decision an AI company will make in the compliance process. The scope defines the boundary around the systems, people, data, and processes that your auditor will test. For an AI service, this boundary must encompass the entire machine learning lifecycle, from the raw data you ingest to the predictions your model generates.

Identifying Your Core Service and Boundaries

Before listing systems, you must answer the auditor’s first question: “What specific service are you providing that requires this attestation?” This answer defines the “system” for the SOC 2 report and anchors the entire audit.

For example, if you sell a fraud detection API, your service boundary is the production environment that accepts customer data, processes it through your model, and returns a risk score. The people who manage that API, the infrastructure it runs on, and the processes for updating the model are all in scope. Everything else is out of scope.

Actionable Guidance: Your SOC 2 report’s system description must clearly define the AI service you deliver. Write it from the customer’s perspective first. Then, work backward to identify every technical component and human process required to operate that service reliably and securely.

Mapping the AI Lifecycle to the Audit Scope

Once your service is defined, you must map your entire AI lifecycle to the audit scope. AI systems have unique components not found in traditional SaaS, and your auditor will expect to see controls for each one.

Your scoping exercise should produce a complete inventory of these components:

• Data Ingestion Pipelines: The systems that acquire data for training and inference, including raw data sources, ETL/ELT jobs, and the data lakes or warehouses where data is stored.
• Model Training Environments: The infrastructure where models are built. This includes cloud environments, container registries, and source code repositories for model development, training, and validation.
• Model Deployment and Inference: The production systems, including the CI/CD pipeline that promotes models to production and the infrastructure that serves predictions via your API.
• Data Storage: All databases and storage buckets containing customer data, training data, model artifacts, and system logs.
• Supporting Technologies: Critical third-party tools like authentication services, monitoring and logging platforms (Datadog, Sentry), and any sub-service organizations like a data labeling service. If it is essential for your service delivery, it’s in scope.
• People and Processes: The ML engineers, DevOps teams, and data scientists who access this infrastructure, along with the formal procedures they follow for change management, incident response, and access reviews.

Making Key Scoping Decisions

Scoping requires making judgment calls. For example, should you include the specific open-source libraries used to build a model? The answer is generally no. The audit focuses on your controls over your environment, not the internal security of a third-party component.

However, you must demonstrate a process to manage vulnerabilities within those libraries (e.g., software composition analysis). That process, which supports CC7.1, is absolutely in scope.

Why does this matter for someone pursuing SOC 2? Every component listed in your system description must have corresponding controls that an auditor can test. This direct line connecting your service, your infrastructure, and your controls is what gives a SOC 2 report its credibility. Getting the scope right ensures the audit provides meaningful assurance to your customers and is a foundational step for a successful outcome.

How Do You Map AI Risks to the Trust Services Criteria?

A SOC 2 auditor does not evaluate the quality of your AI algorithm. They evaluate your internal controls against the language of the Trust Services Criteria (TSC)—Security, Availability, Processing Integrity, Confidentiality, and Privacy. Your responsibility is to translate your unique AI risks into this framework of controls.

Security: More Than Just Firewalls

The Security criterion (Common Criteria) is the mandatory foundation for every SOC 2 audit. For an AI company, it extends beyond network security to protect the intellectual property of your models and the data that trains them.

Your auditor will look for evidence of controls against AI-specific threats:

• Model Theft: To prevent reverse-engineering of your model via API abuse, you need controls like rate-limiting on inference endpoints and monitoring for anomalous query patterns. This directly maps to CC6.8 (The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalous items are analyzed to determine whether they represent security events).
• Training Data Exposure: Your training data is a critical asset. Auditors will test your role-based access controls (RBAC) to ensure only authorized personnel can access it. This is a primary test for CC6.3 (The entity implements logical access security measures to protect its information assets against security events to meet its objectives).
• Data Poisoning: To prevent malicious data from corrupting your model, you need strong input validation on data ingestion pipelines and immutable storage for clean datasets. This helps satisfy CC7.2 (The entity implements controls to prevent or detect and eradicate malicious software).

Availability: Keeping Your AI Online

The Availability criterion assesses whether your customers can rely on your service to be accessible as promised. For an AI company, this centers on the uptime and resilience of your inference APIs and ML infrastructure.

Why does this matter for someone pursuing SOC 2? To satisfy the Availability criterion, you must provide evidence that you have planned for and can mitigate disruptions.

• High-Uptime APIs: Auditors will require evidence of load balancers, auto-scaling groups for model-serving endpoints, and tested failover environments. This directly supports A1.2, which states the entity obtains or develops, and implements, and maintains, and monitors procedures to protect against and mitigate the impact of identified site-level environmental and physical threats.
• Model Disaster Recovery: You need a documented and tested disaster recovery plan. This must include procedures for restoring model artifacts, configurations, and the entire serving infrastructure from a backup.

Processing Integrity: Proving Your Model Does What You Say It Does

Processing Integrity is arguably the most critical and complex TSC for an AI company. It addresses the auditor’s core question: “Is your system’s output complete, valid, accurate, timely, and authorized?”

An auditor will never accept your claim that your model “works.” They demand objective evidence that you have controls to ensure its outputs are consistently reliable and that you can detect and correct issues like performance drift.

Key controls are non-negotiable:

• Model Versioning: You must maintain a clear, auditable history of every deployed model version. Using tools like Git-LFS or DVC for tracking model artifacts provides auditors with concrete evidence for PI1.2 (System Processing Integrity).
• Drift Monitoring: Models degrade over time. You need automated monitoring that tracks key performance metrics (e.g., accuracy, precision) against a baseline and generates alerts when performance deviates. This is critical evidence for PI1.4.
• Output Validation: Implementing sanity checks to ensure model outputs are within expected ranges or formats provides another layer of assurance that the system is processing data correctly under PI1.2.

The table below breaks down how these AI-specific risks map to the SOC 2 framework.

AI Risk Mapping to SOC 2 Trust Services Criteria

AI Risk	Relevant Trust Service Criterion	Example Control for SOC 2 Evidence
Model Theft/Extraction	Security (CC6.8)	Screenshots of rate-limiting configurations on inference API gateways; anomaly detection alert logs.
Training Data Poisoning	Security (CC7.2)	Code reviews of data ingestion scripts showing input validation; change logs from an immutable data store.
Inference API Downtime	Availability (A1.2)	Cloud configuration records showing load balancers and auto-scaling rules; disaster recovery test results.
Model Performance Drift	Processing Integrity (PI1.2, PI1.4)	Dashboards from a monitoring tool showing model accuracy tracked over time; alert records for performance degradation.
Lack of Model Traceability	Processing Integrity (PI1.2)	Git commit history for model code and artifacts; records from a model registry like MLflow or Weights & Biases.
Sensitive Data in Training Sets	Confidentiality / Privacy	Documentation of data anonymization techniques; code showing tokenization or PII removal before training, satisfying C1.2 or P1.1.
Unauthorized Model Access	Security (CC6.3)	IAM role definitions restricting access to model registries; access logs showing only authorized personnel accessed models.

AI governance has become table stakes for a modern SOC 2 audit. Vendor risk teams in 2026 now write model versioning policies, prompt-logging retention, training-data lineage, hallucination handling, LLM subprocessor chains, and AI-literacy training records directly into their AI-vendor questionnaires — and they expect your auditor to have tested the same controls.

Confidentiality and Privacy: Guarding Sensitive Data

If your AI processes sensitive information, the Confidentiality and Privacy criteria are likely in scope. Confidentiality concerns the protection of business data as promised to customers. Privacy concerns the protection of personally identifiable information (PII) according to your privacy notice and established privacy principles.

• Data Handling During Training: A key control is demonstrating how you protect sensitive data before it is used in a training set. This can be evidenced through documentation and code reviews of data anonymization, pseudonymization, or tokenization processes.
• Preventing Data Leakage: You must have controls to prevent a model from inadvertently disclosing sensitive training data in its responses. This can involve specific fine-tuning methods or output filtering, which an auditor would review.

Mapping your AI risks to the established TSCs is the core of SOC 2 prep. It turns a generic checklist into a concrete control plan. For the full criteria reference, see our breakdown of the SOC 2 Trust Services Criteria.

What Are the Essential Controls and Evidence Requirements for an AI Platform?

Passing a SOC 2 audit requires providing objective evidence that your controls are implemented and operating effectively. For an AI company, this means generating tangible proof of governance over the entire machine learning lifecycle.

Data and Model Lineage

An auditor will test your ability to trace a model’s output back to the specific data and code used to create it. This concept, lineage, is foundational to Processing Integrity (PI1.2) and Security (CC7.1).

Actionable Guidance:

• Data Lineage: Track data from its origin through all transformations into your training datasets. Evidence includes ETL/ELT job logs, data flow diagrams, and database schemas. The auditor needs proof that the data fueling your models is complete and accurate.
• Model Versioning: Version-control all models, datasets, and code. Using tools like Git for code and systems like DVC or Git-LFS for large model artifacts is mandatory. Evidence includes commit histories and version tags that link a deployed model back to its source.

A common audit procedure involves the auditor selecting a deployed model version and requesting its complete training history—the exact dataset, code, and parameters used. Your ability to produce this information promptly is a direct test of your controls.

These controls are critical, and the underlying risk is rising fast. Shadow AI — employees feeding data into unapproved AI tools — has become a recurring source of SOC 2 findings, because it pipes confidential data into unvetted subprocessors that never passed change management, access review, or vendor oversight (Linford & Co., 2026).

Access Control and Change Management

Auditors will heavily scrutinize who can access and modify your AI systems. The principle of least privilege must be enforced across your entire MLOps stack, mapping directly to Security criterion CC6.3, which governs logical access.

Your evidence must include:

• IAM Policies: Screenshots and exports of your cloud provider’s Identity and Access Management (IAM) role definitions. These policies must prove that a data scientist cannot unilaterally deploy a model to production or that an ML engineer cannot access raw sensitive data without justification.
• Change Management Tickets: Every model deployment or critical system change must be documented in a system like Jira. These tickets provide a complete audit trail for CC8.1 (Change Management), including documented approvals, testing results, and rollback plans.

Audit-Ready Logging and Monitoring

If a control’s operation cannot be proven with logs, it effectively does not exist for audit purposes. For AI platforms, this extends beyond server access logs to include unique activities within your ML systems, satisfying criteria like CC6.8 (monitoring for anomalies) and A1.2 (monitoring system performance).

To be audit-ready, you must log and monitor:

• Inference Requests: Track every API call to your models with timestamps, user identifiers, and model version. This is your primary defense for detecting model abuse.
• Prompts and Completions — Redacted: If you log prompts and completions, apply PII/PHI redaction before the log is written. Logging raw user prompts that contain regulated data is one of the most common 2026 AI audit findings: an intended audit-trail control becomes a data-leakage exposure. Auditors will sample logs and check whether redaction actually ran.
• LLM Subprocessor Calls: When you route data to a third-party model (OpenAI, Anthropic, or similar), log the call and retain evidence that you configured data-retention and training opt-out. Auditors test this against your vendor risk assessment.
• Model Performance: Continuous monitoring that tracks model accuracy against a defined baseline. Drift alerts are evidence for Processing Integrity.
• Anomalous Behavior: Alerting on patterns like a spike in errors or queries from an unrecognized IP range.

For a structured checklist, see our SOC 2 evidence collection guide.

How Do You Choose an Auditor Who Understands AI?

Selecting an audit firm is a critical decision. The right firm understands the risks of auditing machine learning systems; the cheapest one often does not.

The Vetting Process: Questions That Reveal True AI Expertise

Before signing an engagement letter, you must vet potential auditors rigorously. Their answers to technical questions will reveal their experience with AI technologies.

• “Can you describe your experience auditing AI/ML systems similar to ours?” Ask for specifics on model types (e.g., NLP, computer vision) and platforms (AWS SageMaker, custom-built).
• “How do you test controls for model integrity and data bias?” A strong answer will mention testing model versioning systems, reviewing drift monitoring outputs, and examining data pre-processing scripts for bias mitigation techniques.
• “How do you approach auditing controls around training data?” They should discuss testing access controls on data lakes, validating data anonymization processes, and verifying data lineage from source to model.
• “Can you provide redacted reports for other AI or ML companies you have audited?” This provides direct evidence of their experience and reporting style.

A qualified auditor asks to see the commit history for your model artifacts, reviews change management tickets for model deployments, and discusses how you monitor for anomalous inference patterns. Their questions are the best indicator of their expertise.

Demand for AI-aware audits is rising sharply: in 2026, SOC 2 has moved from a security badge to a procurement gate, with enterprise vendor-risk teams declining to open commercial conversations without an in-date Type 2 report covering AI controls. As of April 2026, first-year SOC 2 Type 2 spend for an AI startup typically lands in the $40k–$120k range depending on scope and remediation (Knowlee, 2026). AI companies selling into the public sector face stricter scrutiny — see our government contractor compliance guide for the additional requirements. More compliance statistics from recent research.

Boutique Firm vs. Big Four: What’s Right for You?

The choice is often between a technology-focused boutique audit firm and a large, traditional firm (e.g., a Big Four). For most AI startups and mid-market companies, a boutique firm is typically a better fit. They are generally more agile, possess deeper technical expertise in modern cloud and AI stacks, and offer more hands-on guidance. A full breakdown can be found in this guide on how to choose a SOC 2 auditor.

How Do You Achieve and Maintain Continuous SOC 2 Readiness?

Obtaining a SOC 2 report is a milestone, but the true objective is maintaining that security posture continuously. This is not a one-time project.

Why does this matter for someone pursuing SOC 2? Continuous SOC 2 readiness means embedding security as a discipline throughout the machine learning lifecycle. Treating SOC 2 as an annual “fire drill” is expensive and leaves your company exposed between audits. Build the program once, and compliance evidence accumulates on its own.

Your SOC 2 Project Timeline: A Realistic View

A realistic project plan is non-negotiable. For a first-time SOC 2, the project should be broken into distinct phases.

A Typical Timeline for Your First SOC 2 Audit:

• Phase 1: Readiness & Scoping (1-3 Months): Define your audit scope, select the appropriate Trust Services Criteria, and perform a gap analysis to identify control deficiencies.
• Phase 2: Remediation & Implementation (2-6 Months): Implement new controls, write policies, and configure logging and monitoring systems to address the identified gaps.
• Phase 3: Evidence Collection for Type 1 (1 Month): Gather evidence that controls are designed and implemented as of a specific point in time for the Type 1 audit.
• Phase 4: Observation Period for Type 2 (3-12 Months): The period during which the auditor tests the operating effectiveness of your controls over time.
• Phase 5: Type 2 Audit & Report (1-2 Months): The auditor reviews evidence from the observation period and issues the final SOC 2 Type 2 report.

Your choice of auditor significantly impacts this timeline and is one of the most critical early decisions.

Vetting an auditor with specific, technical questions ensures you select a partner who understands AI systems and can guide you through the process effectively.

Avoiding Common Pitfalls Post-Audit

The period immediately following a successful audit is when compliance decay often begins.

A SOC 2 report is a snapshot in time. Enterprise customers expect that you will maintain, and even improve, your security posture between audits.

Common post-audit pitfalls to avoid:

• Failing to Maintain Controls: New infrastructure is deployed without proper security configurations, or temporary access rules are not revoked. This “control drift” is a primary cause of findings in subsequent audits.
• Neglecting Evidence Collection: You stop gathering logs, performing access reviews, or documenting model changes, leading to a scramble for evidence at the start of the next audit cycle.
• Treating It as an Annual Event: Security threats are continuous, and so must be your monitoring and response. Automating controls and evidence collection is the only sustainable path to continuous readiness.

The controls you build for the audit — model versioning, change management for deployments, access reviews for data lakes — pay off beyond the report. They make the platform more secure and shorten enterprise security reviews, and they keep each subsequent audit cheaper than the first. Ready to find a firm that has audited AI stacks before? Compare verified SOC 2 auditors by price, timeline, and AI expertise.

---

Finding the right audit firm is the first step toward a successful SOC 2 journey. At SOC2Auditors, we replace endless sales calls with a data-driven matching platform. Compare verified firms by price, timeline, and AI expertise to find the perfect partner for your company, fast. Get your free auditor matches at https://soc2auditors.org.