SOC 2 is a framework for demonstrating that your organization has controls in place around security, availability, processing integrity, confidentiality, and privacy. It was originally designed for SaaS companies with conventional software products. As ML systems have become core to more enterprise products, SOC 2 auditors have begun asking questions about model lifecycle controls that most ML teams are unprepared to answer.
This is not yet standardized — different auditors ask different questions with different levels of specificity. But patterns have emerged, and teams that have been through ML-inclusive SOC 2 reviews report a consistent set of evidence categories that auditors request. This guide covers what those categories are, what evidence satisfies each, and where model governance tooling helps you produce that evidence without manual archaeology.
Why ML systems fall under SOC 2 processing integrity controls
SOC 2's Trust Services Criteria (TSC) for processing integrity (PI) covers whether system processing is complete, valid, accurate, timely, and authorized. For a software product whose core functionality is delivering predictions from an ML model — a fraud score, a credit recommendation, a clinical risk flag — the model's behavior is the processing. If the model silently degrades, the processing is not accurate. If a model update goes to production without proper authorization, the processing is not authorized.
Note: SOC 2 controls are designed and assessed by licensed CPA firms. What follows is not legal or compliance advice — it's a description of the kinds of evidence categories that ML-inclusive SOC 2 reviews have required, based on publicly available guidance and practitioner accounts. Your specific evidence requirements depend on your auditor's assessment scope.
Evidence category 1: change management for model versions
SOC 2 change management controls (CC8 in the 2017 TSC) require evidence that changes to production systems go through a defined, authorized change process. For conventional software, this is usually documented in your code review and deployment pipeline (PR approvals, deployment records, rollback capability). For ML models, the equivalent is the model promotion record.
What auditors ask for: a list of all model version changes during the review period, with evidence of who authorized each change and when. If you can produce a structured export showing that for every model promotion event during the SOC 2 review window, there is an approval record with actor identity, timestamp, and policy reference, you satisfy this category cleanly.
What's hard to produce without tooling: the evidence is scattered across MLflow run records, Slack threads, and Jenkins deployment logs. Stitching these together for an auditor is time-consuming and produces evidence that looks fragile because it is fragile — reconstructed from systems that weren't designed to answer the governance question.
Evidence category 2: access controls for model promotion
Logical access controls (CC6 in the 2017 TSC) require that only authorized individuals can perform sensitive operations. For ML systems, the sensitive operations include model promotion to production and modification of model-serving configuration.
What auditors ask for: evidence that your model governance system enforces role-based access, a list of who holds promotion authority, and evidence that this access is reviewed periodically (typically annually). The review requirement means you need a record not just of who has access today but of when access was granted and when it was last reviewed.
A model governance platform that logs RBAC assignments and role changes as governance events satisfies this directly. An informally managed list in a spreadsheet is technically evidence but raises questions about how reliably it's maintained.
Evidence category 3: monitoring and alerting for model degradation
SOC 2 availability controls (A1) require evidence that you detect and respond to system degradation. For ML systems serving production predictions, model performance degradation is a form of system degradation that affects service availability in a functional sense.
What auditors typically ask for: evidence of a monitoring system for model prediction quality, records showing that alerts were investigated and responded to within a defined SLA, and documentation of the process for responding to model quality incidents.
Drift detection logs with timestamps, alert acknowledgment records, and retrain proposal records (showing that drift was detected and a response was initiated) collectively satisfy this category. The key is that the records exist as structured, queryable data rather than informal Slack responses to PagerDuty alerts.
Evidence category 4: processing integrity for predictions
This is the category most specific to ML systems. Processing integrity controls require evidence that your system processes data completely, accurately, and as authorized. For an ML model, this translates to: evidence that the model in production was the intended version, that it was authorized to serve predictions by an appropriate approval chain, and that known quality issues were responded to within appropriate time bounds.
The evidence package for this category includes: current production model version with authorization record, the quality gate criteria that model passed before promotion, the retrain policy configuration governing this model, and a record of any quality incidents during the review period with response timelines.
The audit preparation timeline problem
The practical challenge is that SOC 2 reviews typically request evidence for a 12-month window (for Type 2 reviews). If your model governance records exist in structured, queryable form, producing a 12-month export for three models is a matter of API calls and a few minutes of formatting. If they exist as Slack threads and manually maintained spreadsheets, producing the same evidence reliably takes days and produces results that don't fully satisfy auditor questions about completeness.
Teams that prepare for ML-inclusive SOC 2 reviews for the first time universally report that the hardest part is not understanding what the auditor needs — it's that the evidence they need exists somewhere but isn't in a form that can be extracted and presented confidently. The second review, if they've implemented structured governance in the interim, is dramatically faster.
What to build before your first ML-inclusive SOC 2 review
If your SOC 2 review is more than six months away, the highest-leverage investment is implementing structured governance records now so that you accumulate auditable history during the review window. Structured governance records retroactively built the week before a review do not satisfy a Type 2 review — Type 2 auditors assess whether controls were operating consistently throughout the period, not just whether they exist now.
The minimum viable ML governance posture for a SOC 2 preparation is: immutable promotion records with actor and policy attribution, role-based access control with periodic access review records, drift monitoring with documented alert response process, and the ability to export all of the above for any date range in under an hour.