SOC 2 and AI: Practical Compliance Guide

SOC 2 Was Designed Before AI Existed — Here's How to Make It Work

SOC 2 (System and Organization Controls 2) was created by the American Institute of Certified Public Accountants (AICPA) as a framework for evaluating the security, availability, processing integrity, confidentiality, and privacy of service organizations' systems. It was designed with traditional software applications in mind — defined inputs, predictable processing, documented outputs.

AI systems challenge nearly every assumption that underpins that traditional model. A large language model's outputs are probabilistic, not deterministic. An AI system's "processing" is a mathematical operation across billions of parameters that no human can fully audit. The "inputs" to an AI system may include not just current user data but training data that was collected years ago and whose provenance is difficult to trace.

None of this means SOC 2 does not apply to AI systems — it does. It means that applying SOC 2 thoughtfully to AI requires understanding both the framework and the technology in depth. TrustEdge, drawing on 15+ years of compliance expertise from Jacobian Engineering, helps organizations navigate this intersection.

SOC 2 Basics: The Trust Services Criteria

SOC 2 reports are issued against the AICPA's Trust Services Criteria (TSC). There are five categories:

Security (CC) — Common Criteria, required for all SOC 2 reports. Covers logical and physical access controls, system operations, change management, and risk mitigation.
Availability (A) — System availability for operation and use as committed or agreed. Relevant for AI systems that are customer-facing or part of critical operations.
Processing Integrity (PI) — System processing is complete, valid, accurate, timely, and authorized. Particularly relevant for AI systems that process transactions or make automated decisions.
Confidentiality (C) — Information designated as confidential is protected as committed or agreed. Relevant for AI systems processing proprietary or sensitive data.
Privacy (P) — Personal information is collected, used, retained, disclosed, and disposed of in conformity with the commitments in the entity's privacy notice. Relevant for AI systems processing personal data.

Most organizations pursuing SOC 2 for AI systems should at minimum include Security (required) and Processing Integrity (highly relevant for AI). Confidentiality and Privacy should be included if the AI system handles confidential business data or personal information.

Why AI Creates Unique SOC 2 Challenges

The Model Is a Black Box

Traditional software has source code that auditors can review. The logic is explicit: if X, then Y. AI models — particularly deep learning models — do not work this way. The "logic" is encoded in billions of parameters, the result of training on large datasets. Even the engineers who built the model cannot always explain why it produced a specific output.

This creates a challenge for SOC 2's Processing Integrity criteria, which require that processing be "complete, valid, accurate, timely, and authorized." How do you demonstrate that an AI system's outputs are "accurate" when the system generates probabilistic outputs that vary even for identical inputs?

The answer is not to avoid AI but to implement appropriate testing, monitoring, and validation frameworks — and to document those frameworks for auditors.

Training Data Provenance

A SOC 2 Type II report covers a specific period (typically 12 months) and evaluates whether controls were operating effectively throughout that period. But the behavior of an AI system is heavily influenced by its training data — which may have been collected before the audit period, by a third party, or through means that are difficult to document.

For AI systems that use pre-trained foundation models (like GPT, Claude, or Llama variants), organizations must understand and document the provenance of those models and any fine-tuning data used. For AI systems trained on proprietary data, data collection, labeling, and training processes must be documented as part of the change management and processing integrity controls.

Vendor and Model Drift

AI models change over time. Foundation model providers update their models, sometimes significantly, between versions. Fine-tuned models may drift as they are retrained on new data. Unlike traditional software updates, these changes may not be visible to the organization using the model — they manifest as changes in output behavior.

SOC 2 change management controls (CC8.1) require that changes to systems be authorized, tested, and documented. Organizations must establish processes to detect when AI model updates occur, evaluate their impact, and document the review.

Third-Party AI API Risks

Many organizations access AI capabilities through third-party APIs (OpenAI, Anthropic, Google, Microsoft Azure AI). From a SOC 2 perspective, these are vendors — and SOC 2 requires organizations to assess and monitor vendor risk (CC9.2).

This means obtaining and reviewing SOC 2 reports (or equivalent) from AI API providers, establishing contractual protections for data sent to those APIs, and monitoring for changes in vendor security practices.

Mapping AI to SOC 2 Common Criteria

Here is how the SOC 2 Common Criteria (the security requirements applicable to all reports) apply specifically to AI systems:

CC1: Control Environment

The control environment sets the tone for the organization's overall approach to risk and control. For AI systems, this means:

Executive commitment to responsible AI, including written policies governing AI use
Clear accountability for AI system governance (who owns AI risk?)
Staff competency requirements — do the people managing AI systems understand both the technology and the compliance requirements?

CC2: Communication and Information

SOC 2 requires that relevant information be communicated internally and externally. For AI:

Internal communication about approved AI use cases and data handling requirements
External communication (in privacy notices and terms of service) about how AI is used to process customer data
Disclosure to customers when AI is making decisions that affect them

CC3: Risk Assessment

Risk assessment for AI must address AI-specific risks that traditional risk frameworks may not contemplate:

Model accuracy risk: What is the probability that the AI produces incorrect outputs, and what is the impact?
Bias risk: Does the AI produce systematically biased outputs for certain demographic groups?
Adversarial risk: Can the AI be manipulated through prompt injection, adversarial inputs, or other attacks?
Dependency risk: What happens if a third-party AI API becomes unavailable or changes its behavior?

CC6: Logical Access Controls

Access controls for AI systems must address:

Model access: Who can query the AI model? Are there user-level access controls?
Training data access: Who can access the data used to train or fine-tune the model?
API key management: How are API keys for third-party AI services generated, stored, rotated, and revoked?
Admin access: Who can change AI system configurations, retrain models, or modify system prompts?

CC7: System Operations

Operational monitoring for AI systems requires going beyond traditional uptime monitoring to include:

Output quality monitoring: Are AI outputs meeting accuracy and quality thresholds?
Anomaly detection: Are there unusual patterns in AI system usage (potential abuse or attack)?
Input monitoring: Are users providing inputs that violate policy (e.g., sending PHI to a non-compliant AI tool)?
Cost monitoring: Are AI API costs within expected ranges (unusual cost spikes may indicate misuse)?

CC8: Change Management

AI-specific change management considerations include:

Model version control: Tracking which version of an AI model is deployed in production
Fine-tuning documentation: Documenting training data, training parameters, and evaluation results for any model fine-tuning
Prompt engineering changes: Treating system prompt changes as configuration changes subject to change management controls
Third-party model updates: Monitoring for and evaluating the impact of updates to foundation models from third-party providers

CC9: Risk Mitigation / Vendor Management

For organizations using third-party AI APIs:

Obtain and review the AI vendor's SOC 2 report or equivalent (ISO 27001, etc.)
Ensure vendor contracts include appropriate data processing terms, breach notification obligations, and security requirements
Monitor vendor security bulletins and news for incidents that may affect your AI systems
Maintain backup plans for AI vendor outages or service terminations

Processing Integrity for AI: The Hardest Criterion

Processing Integrity is where AI most significantly challenges traditional SOC 2 assumptions. The criteria require that processing be:

Complete: All transactions and events are recorded. For AI, this means logging all inputs and outputs — not just successful requests but errors, timeouts, and rejected inputs.

Valid: Processing is authorized and in accordance with established specifications. For AI, this means having clear specifications for what the AI should and should not do — and testing to verify the AI adheres to those specifications.

Accurate: Outputs correctly represent the inputs processed. For AI, accuracy is probabilistic and must be measured against benchmark datasets, not assumed.

Timely: Processing occurs within established time frames. For AI, this means SLAs for response time and processes for detecting and alerting on performance degradation.

Authorized: Processing is only performed by authorized personnel and systems. For AI, this means access controls on who can use the AI system and audit logs tracking all usage.

Practical AI Testing for SOC 2

To demonstrate Processing Integrity for AI systems, organizations should implement:

Baseline Testing: Establish benchmark datasets representing the expected inputs and outputs of the AI system. Test the deployed model against these benchmarks before deployment and after any changes.

Ongoing Accuracy Monitoring: Sample AI outputs regularly and evaluate them against human judgments or ground truth labels. Track accuracy metrics over time and alert on degradation.

Adversarial Testing: Regularly test the AI system with adversarial inputs designed to elicit incorrect, harmful, or policy-violating outputs. Document the testing and the controls in place to address identified vulnerabilities.

Boundary Testing: Test the AI system's behavior at the edges of its intended use — very long inputs, unusual characters, requests near policy boundaries — to identify unexpected behavior.

Privacy Criteria and AI

If your SOC 2 report includes the Privacy Trust Services Criteria, AI systems create specific challenges:

P1 (Privacy Notice): Your privacy notice must accurately describe how AI is used to process personal information. Generic privacy notices that do not mention AI may be deficient.

P3 (Collection): Personal information should only be collected for the purposes stated in your privacy notice. If users are sending personal information to an AI chatbot for customer service purposes, that use must be disclosed and consistent with the purposes for which the information was originally collected.

P4 (Use, Retention, Disposal): Personal information must only be used for the purposes disclosed. If your AI vendor uses customer interactions to improve their model, that may constitute a secondary use not covered by your privacy notice.

P6 (Disclosure): Personal information should not be disclosed to third parties except as disclosed. Sending customer data to a third-party AI API is a disclosure that must be covered in your privacy program.

P8 (Individual Participation): Individuals have rights to access, correct, and delete their personal information. For AI systems that process personal information, you must be able to identify, retrieve, and delete personal information from training data and system logs upon request.

SOC 2 Report Structure for AI Companies

If your organization is an AI company seeking SOC 2 certification, your auditors will want to understand:

System Description: A clear description of your AI system, including the models used, the data processed, the clients served, and the infrastructure used
Subservice Organizations: Third-party AI providers (OpenAI, AWS, Azure) are subservice organizations that must be disclosed in your SOC 2 report
Complementary User Entity Controls (CUECs): Controls that users of your AI system must implement for the system as a whole to meet the criteria
Complementary Subservice Organization Controls (CSOCs): Controls that your AI API providers must implement

Timeline and Cost Expectations

For organizations pursuing SOC 2 Type II for AI systems, realistic expectations:

Readiness Assessment: 4-6 weeks to identify gaps between current state and SOC 2 requirements Gap Remediation: 3-6 months to implement missing controls, depending on the size of the gaps Audit Period: 12 months (for Type II) of operating controls effectively Audit Execution: 4-8 weeks for the auditor's testing and report issuance Total Timeline: 18-24 months from start to first SOC 2 Type II report

Costs vary significantly by organization size, complexity, and auditor. For mid-market organizations, expect $30,000-$80,000 in audit fees alone, plus internal and consulting costs for readiness and remediation.

Conclusion: SOC 2 Is Achievable for AI — With the Right Approach

SOC 2 compliance for AI systems is achievable, but it requires more sophisticated thinking than traditional SOC 2 engagements. The probabilistic nature of AI, the complexity of training data provenance, and the reliance on third-party model providers all create challenges that must be addressed through thoughtful architecture, robust monitoring, and clear documentation.

Organizations that invest in getting SOC 2 right for their AI systems gain a significant competitive advantage — particularly when selling to enterprise customers who require SOC 2 as a procurement condition.

Ready to start your SOC 2 journey for AI systems? Schedule a consultation with TrustEdge. Our team, built on 15+ years of compliance engineering expertise through Jacobian Engineering, has helped organizations across healthcare, financial services, and technology achieve and maintain SOC 2 certification. Call (888) 555-EDGE or reach out through our website.