The problem is structural. The AICPA's Trust Services Criteria (TSC) were built to govern cloud and SaaS environments, not AI decision systems. A vendor can pass a SOC 2 audit with flying colors and still have zero tested controls around model accuracy, drift detection, or training data integrity. For enterprise buyers, that's a meaningful gap — not a technicality.
This guide explains how each TSC category applies to AI systems, what control categories auditors expect to see, and how to evaluate or build an AI-aware SOC 2 posture — whether you're a buyer assessing a vendor or a provider strengthening your own program.
TL;DR
- Most vendors only include Security in SOC 2 scope — leaving model accuracy, data privacy, and AI governance untested across all five Trust Services Criteria
- Processing Integrity is the most AI-specific criterion and is often missing from vendor reports; its absence is a signal worth probing
- Three control domains matter most for AI: data lifecycle governance, model lifecycle controls, and AI governance and compliance
- SOC 2 does not natively cover AI bias, fairness, or explainability; ISO 42001 fills those gaps
- A SOC 2+ examination can layer ISO 42001 controls onto an existing report without requiring a separate certification
- Enterprise buyers should request the full report, check which TSC categories are in scope, and look for explicit AI coverage in the system description
How SOC 2 Trust Services Criteria Apply to AI Systems
SOC 2's five TSC categories — Security, Availability, Processing Integrity, Confidentiality, and Privacy — were designed for cloud and SaaS environments. But each has a direct parallel in AI system risk. The catch: according to A-LIGN, only Security (Common Criteria) is required. The other four are optional — which means most AI vendors' reports leave significant risk untested.
Security and Availability
The Security criterion governs how a system protects itself from unauthorized access, damage, and disclosure. For AI systems, this maps to:
- CC6: Access controls to model endpoints, training data repositories, and inference APIs
- CC8.1: SDLC controls governing AI model development and retraining pipelines
- CC9.2: Third-party and supply chain risk for external AI APIs, map data providers, and cloud inference services
Consider something concrete: controlling who can push code changes to a route optimization algorithm is a CC6/CC8.1 question, not just a generic software security question. The controls need to explicitly name AI components to be meaningful.
Availability matters differently for AI-powered platforms. A route optimization engine going offline during a morning dispatch window isn't just an IT incident — it has direct customer and financial consequences. For systems supporting real-time operations, monitoring AI uptime and failure modes is an auditable commitment, not a background metric.
Processing Integrity, Confidentiality, and Privacy
Processing Integrity is the criterion most directly applicable to AI. The AICPA's TSC requires that system processing be complete, valid, accurate, timely, and authorized. For AI systems, that means auditors look for evidence of controls addressing:
- Model drift — accuracy degrading as real-world conditions change (traffic patterns, address databases, fleet behavior)
- Data poisoning — corrupted inputs that manipulate model outputs
- Hallucinations — in generative components, outputs that are fabricated or inconsistent
- Biased outputs — systematic errors affecting specific routes, drivers, or service areas
Schellman notes that Processing Integrity is among the rarest SOC 2 categories in practice, yet becomes nearly mandatory when a product makes automated operational decisions. If a vendor's report excludes it, ask directly: request the specific TSC categories in scope and ask what compensating controls address model accuracy and output integrity.
Confidentiality governs sensitive information flowing through AI systems — proprietary fleet routes, customer location data, shipper business logic. Vendors should document data retention schedules, disposal procedures, and access restrictions that specifically apply to AI-processed data.
Privacy takes this further, covering personally identifiable information in AI pipelines: driver locations, recipient addresses, and behavioral patterns. For this criterion, look for documented consent mechanisms, data minimization practices, and breach response procedures scoped to how the AI system actually handles that data.
The Three Core AI Control Categories in Your SOC 2 Report
The COSO Internal Control Framework surfaces three risk domains that matter most when AI systems touch sensitive data or automated decision-making. Auditors expect controls across all three for organizations whose AI outputs have material business consequences.
Data Privacy and Data Lifecycle Controls
AI systems often ingest large, diverse datasets — location history, behavioral data, real-time telemetry, third-party feeds. That makes data lifecycle governance foundational. The four stages auditors examine:
- Collection — legal basis, source authorization, and consent documentation
- Storage and access — encryption at rest and in transit, RBAC, least-privilege principles
- Processing — use of only approved datasets, accuracy checks, input validation
- Retention and disposal — documented policies for when training data is purged and how deletion is verified
These controls map primarily to SOC 2's Privacy and Confidentiality criteria.
When AI depends on external APIs, map data providers, or cloud inference services, CC9.2 requires documented vendor risk management. For a platform like NextBillion.ai (which uses providers including Google Cloud Platform and AWS, and map data from sources like OpenStreetMap and TomTom), this means vendor security assessments, contract-based data handling clauses, and documented due diligence on each subprocessor.
Model Lifecycle and Bias Controls
Model lifecycle controls are the AI equivalent of traditional software change management. Under Processing Integrity, auditors look for evidence across three stages:
- Development — use of only approved, authorized training datasets with documented oversight on feature selection
- Validation — rigorous accuracy and bias testing before any model is promoted to production
- Versioning — formal change management documenting all retraining events, architecture changes, and rollback procedures
Input validation sits alongside these controls. For systems processing real-time GPS telemetry, traffic feeds, and delivery-window data, this means schema validation, anomaly detection on incoming feeds, and rejection protocols for corrupt or out-of-range inputs.
NIST's AI Risk Management Framework specifically warns that datasets can become stale or detached from deployment context. For a route optimization engine, that means changing traffic patterns, address database updates, and shifting seasonal demand can all degrade model accuracy — with no security incident to trigger an alert.
Continuous monitoring completes the picture. This means:
- Tracking model performance metrics over time
- Detecting drift — where accuracy degrades as real-world conditions shift
- Logging outputs for auditability
- Triggering alerts when anomaly thresholds are breached
Audit trails mapping data flows, model changes, and AI system interactions are the evidentiary backbone of a Processing Integrity claim. Without them, there's nothing for an auditor to test in a Type II examination.
AI Governance and Compliance Controls
Those audit trails only capture what governance policies tell them to track. That's why governance controls complete the triad — and what they cover in a SOC 2 context:
- Comprehensive AI use policies documenting what the system can and cannot do
- Risk registers enumerating AI-specific threats (bias, misuse, model compromise, data poisoning)
- Access controls governing who can modify, retrain, or override models
- Incident response plans covering AI-specific failures — model compromise, unexpected discriminatory outputs, poisoned training data
This aligns with the COSO Control Environment and Risk Assessment components. COSO now publishes AI-specific resources to help organizations align risk management with AI strategy — useful scaffolding for drafting AI governance documentation that auditors recognize.
Explainability is now a practical expectation for auditors, even where current TSC stops short of requiring it formally. Organizations running AI in regulated sectors — healthcare logistics, pharmaceutical cold-chain, NEMT — face heightened scrutiny and should proactively document model decision logic. Enterprise buyers in those sectors are already asking for it in security questionnaires.
SOC 2 vs. ISO 42001: Choosing the Right AI Governance Path
These two frameworks solve fundamentally different problems. SOC 2 asks whether your controls operated effectively over a defined period. ISO 42001 asks whether you have a mature AI management system governing the full lifecycle — including fairness, explainability, ethical use, and safety.
ISO/IEC 42001:2023, released in December 2023, is the first international standard specifically designed for AI management systems. Neither ISO 27001 nor SOC 2 alone constitutes comprehensive AI risk management — the frameworks address security and control effectiveness, not AI governance maturity.
| Dimension | SOC 2 | ISO 42001 |
|---|---|---|
| Form | Attestation report over selected controls | Management system standard |
| AI specificity | Not originally designed for AI risks | Purpose-built for AI governance |
| Covers bias/fairness/ethics? | No | Yes |
| Audit period | Point-in-time (Type I) or 6–12 months (Type II) | Ongoing certification cycle |
| Scope flexibility | Security required; others optional | Covers full AI development and use |
The most practical option for most organizations is a SOC 2+ examination. The AICPA explicitly allows organizations to layer additional criteria — including AI-specific controls aligned to ISO 42001 — into a SOC 2 engagement. This lets organizations report on AI governance within the same audit without pursuing a full, separate ISO 42001 certification.
Where you start depends on your current posture and market:
- Already have SOC 2, limited resources? Re-scope to add Processing Integrity and Privacy, then layer AI-specific control language into existing CC4, CC6, CC8.1, and CC9.2 criteria
- AI-native product or regulated market? Target ISO 42001 certification as a roadmap item; use SOC 2+ as a working bridge in the interim
- Selling into enterprise logistics, healthcare, or government? Procurement teams in these verticals are beginning to expect both — start with SOC 2+ and communicate your ISO 42001 roadmap proactively
Practical Steps to Incorporate AI Controls into Your SOC 2
Step 1: Conduct an AI-Specific Risk Assessment
Before touching controls, map every AI system in scope. Document:
- Data flows and input sources (real-time feeds, training datasets, third-party APIs)
- Model types and decision outputs
- Downstream business impact of incorrect or unavailable outputs
- Which TSC categories are implicated (most AI systems will touch Security, Confidentiality, Privacy, and Processing Integrity at minimum)
Build an AI risk register documenting specific threats: model drift, data poisoning, unauthorized retraining, biased outputs. This aligns with COSO's Risk Assessment component and gives auditors a documented basis for evaluating your control environment.
Step 2: Expand In-Scope TSC Categories and Write AI-Specific Control Language
Generic security controls don't cover AI risks. Extend existing criteria with AI-specific language:
- CC6: Extend to include model endpoint access, training data repository permissions, and inference API authorization
- CC8.1: Extend SDLC controls to cover model training, retraining, and validation pipelines as distinct from standard software development
- CC4: Add model performance monitoring, drift alerting, and anomaly detection as documented monitoring activities
- CC9.2: Name AI subprocessors — map data providers, cloud inference services, open-source dependencies — in vendor risk assessments
Step 3: Build Evidentiary Systems Before the Audit Period Starts
SOC 2 Type II assesses operating effectiveness over 6–12 months. Controls must produce evidence throughout that window — retrofitting before the audit closes doesn't work.
Continuous AI control evidence should include:
- Automated access logs for training data and model artifacts
- Model version histories with change approvals
- Bias and accuracy testing results, timestamped across the audit period
- Drift detection alerts and remediation records
- Incident tickets covering AI-specific events
- Completed vendor assessments for AI subprocessors
Step 4: Decide on SOC 2+ or Standalone ISO 42001
The choice between SOC 2+ (with additional AI-specific criteria appended) and a standalone ISO 42001 certification depends on your customers' expectations and how central AI is to your trust story.
Engage a CPA firm experienced in both AI governance and SOC 2 before scoping the examination. The right auditor will identify which AI-specific controls are most relevant to your use cases and can formally include additional criteria in the report.
What to Look for in an AI Vendor's SOC 2 Report
A SOC 2 badge tells you almost nothing about AI-specific risk. A Security-only report tells a logistics buyer whether access controls are tested — not whether the route optimization engine produces valid, accurate, timely outputs.
Work through the report in this order:
Check TSC scope first. The absence of Processing Integrity from an AI vendor's report is a meaningful signal. Follow up in security questionnaires: ask why it's excluded and what alternative evidence exists for model output accuracy.
Read Section 3 (system description). It should explicitly describe AI components, model types, training data sources, and governance procedures. No AI mention in the system description means the audit didn't test AI risks.
Review Section 4 for additional criteria. This is where SOC 2+ frameworks appear. If a vendor claims ISO 42001 alignment, verify whether it's a formal certification, a SOC 2+ tested scope, or self-attestation — the three carry very different weight.
Specific controls to look for:
- Model lifecycle controls (development authorization, validation testing, versioning, rollback procedures)
- Data lifecycle controls (collection authorization, RBAC, encryption, retention/disposal)
- Third-party AI subprocessor risk management
- Continuous model monitoring with documented drift and anomaly procedures
That checklist defines what a defensible governance posture actually looks like in practice. NextBillion.ai holds SOC 2 Type II certification alongside ISO/IEC 27001:2013, providing both audited operational controls and a formal information security management system. For enterprise logistics buyers, that pairing is the baseline to expect from AI vendors. TSC categories in scope and detailed AI control documentation are available through NextBillion.ai's trust center at nbai.scrut.io.
Request the full restricted-use report under NDA, not a summary letter or compliance badge. The Cloud Security Alliance's AI Controls Matrix is a useful complementary checklist — particularly for areas where a vendor's report doesn't include Processing Integrity or Privacy — as it maps AI-specific controls to ISO 42001 and NIST AI RMF.
For AI systems making consequential operational decisions — fleet routing, NEMT dispatch, pharmaceutical cold-chain logistics — weigh whether the vendor's governance posture actually matches the risk level of the decisions being automated. Treat a SOC 2 badge as the beginning of due diligence, not the end of it.
Frequently Asked Questions
Does SOC 2 cover AI-specific risks like bias and explainability?
SOC 2's Trust Services Criteria do not natively address AI fairness, bias, or explainability — that's the gap ISO 42001 was built to fill. Organizations can partially address AI risks through Processing Integrity and Privacy criteria, but comprehensive AI governance requires either ISO 42001 certification or a SOC 2+ examination that incorporates AI-specific controls.
What is the difference between SOC 2 Type I and Type II for AI controls?
Type I assesses whether AI controls are designed appropriately at a single point in time; Type II assesses whether those controls operated effectively over a defined period, typically 6–12 months. For AI systems, Type II is significantly more valuable because it demonstrates that model monitoring, validation, and data governance controls were consistently applied in production — not just at design time.
What is a SOC 2+ report and how does it help with AI governance?
A SOC 2+ report layers additional control frameworks — including AI-specific criteria aligned with ISO 42001 — onto a standard SOC 2 examination. This lets organizations test and report on AI governance controls within the same audit engagement, without pursuing a separate certification.
Which SOC 2 Trust Services Criteria are most relevant to AI systems?
Processing Integrity is the most AI-specific criterion, governing model output accuracy, completeness, and authorization. Privacy and Confidentiality are critical for AI systems handling personal or sensitive operational data. Security is foundational for all systems; Availability matters when AI supports real-time or mission-critical operations like dispatch or route optimization.
How does Processing Integrity apply to AI model outputs?
Processing Integrity requires AI outputs to be complete, valid, accurate, timely, and authorized. In practice, organizations must implement model validation testing, input data integrity checks, output anomaly monitoring, and documented error-handling procedures — ensuring deviations are detected and remediated.
What should I look for in an AI vendor's SOC 2 report?
Start by confirming the report covers Processing Integrity and Privacy — not just Security. Then check for:
- AI components and model governance explicitly named in the system description
- SOC 2+ additional criteria in Section 4
- Evidence of model lifecycle controls, continuous monitoring, and third-party AI subprocessor oversight
