Thirty-two audit gaps and 47 proposed control objectives. That’s the punchline from practitioner research cited by the Arizona Society of CPAs (ASCPA) on where artificial intelligence fits inside SOC 2. The piece, by Michael S. Nyman, asks a pointed question: should the AICPA add a sixth Trust Services Criteria (TSC) category for AI governance? The numbers suggest current SOC 2 AI controls aren’t catching what matters most in model-heavy environments.
Where SOC 2 AI controls are failing today
According to the ASCPA article, auditors are finding gaps across all five TSC categories—security, availability, processing integrity, confidentiality, and privacy. The AICPA has revised guidance on how management prepares SOC 2 reports and how auditors evaluate controls, but those changes are incremental. They don’t yet create a dedicated place for AI risk.
The gaps are predictable if you run or buy AI. Teams struggle to maintain an inventory of models and prompts in production. Change management misses fine-tuning runs, parameter tweaks, or retrieval updates. Security testing often covers networks and endpoints but leaves out red-teaming for prompt injection and jailbreaks. Processing integrity covers jobs and data pipelines, yet evaluation baselines for models—and drift detection—are thin. Privacy reviews focus on customer data at rest, while training data provenance and retention for model artifacts are murky.
These blind spots live inside the existing TSC, but they cut across them. That’s why a control that looks complete on paper can still leave a model exposed in practice. It also explains why different auditors reach different conclusions on similar environments: the framework isn’t explicit about AI system lifecycles, so evidence expectations vary.
How a sixth Trust Services category would reset audits
Nyman’s question lands at a sensitive time. The NIST AI Risk Management Framework (AI RMF 1.0) has been available since January 2023. The ISO/IEC 42001 standard for AI management systems arrived in 2023. The EU AI Act took effect in August 2024. SOC 2, by contrast, still orients around five trust categories shaped before widespread model deployment.
A sixth TSC aimed at AI would do three things. First, it would define scope: what counts as an AI system, which third-party services fall under audit, and which lifecycle stages require controls. Second, it would normalize evidence. Expect to see model cards, evaluation reports, red-teaming results, and AI incident logs treated as first-class artifacts. Third, it would set governance expectations—risk registers specific to AI use cases, escalation paths for unsafe outputs, and decision rights for when a model is pulled from production.
The impact on time and cost would be real. More walkthroughs. More control owners outside traditional IT, including product and data science. But the tradeoff is fewer surprises during fieldwork, and a report that actually reflects how systems behave under stress.
Mapping ISO 42001 and NIST AI RMF into AI controls for SOC 2
The ASCPA piece argues the AICPA’s recent tweaks are helpful yet insufficient for AI-heavy workloads. That doesn’t leave teams stuck. Many ISO 42001 and NIST AI RMF practices can be mapped today into SOC 2’s five pillars, creating audit-ready coverage while the standards community debates a sixth category.
Security: align with NIST’s “Map–Measure–Manage” cycles for adversarial risk. Include documented prompt and tool red-teaming, model isolation, and abuse monitoring. Evidence can include test scenarios, findings, fixes, and retest outcomes. Tie access controls to model endpoints, not just data stores.
Processing integrity: adopt evaluation baselines and quality gates as change-control criteria. Require defined acceptance thresholds for accuracy, toxicity, and bias before promotion. Keep drift monitors and rollback plans for model updates. Retain runbooks and metrics histories as evidence.
Confidentiality and privacy: document training and fine-tuning data sources, retention periods, and scrubbing of personal data. Add controls for retrieval filters to prevent leakage of secrets through generated content. Reference ISO 42001 clauses on data and model management and align with privacy rights handling required under the EU AI Act where applicable.
Availability: plan for model and vendor outages with traffic shedding, caching, or non-AI fallbacks. Record chaos tests for model dependencies. Treat rate limiting and quota management as uptime controls when shared providers are used.
Governance across all pillars: establish a single model registry, a risk register tied to use cases, and RACI assignments so auditors know who decides when a model ships, pauses, or retires. That mirrors ISO 42001’s management-system approach and makes SOC 2 evidence easier to collect.
What compliance leaders should do before the next audit
SOC 2 AI controls don’t have to wait on a new trust category. A focused 90-day push can lift audit readiness and reduce real risk at the same time.
- Inventory: list every model in prod and pre-prod, including prompts, embeddings, RAG pipelines, and external APIs. Record owners and data sources.
- Change control: require evaluation packs—metrics, toxicity tests, security findings—before promotion. Treat them like code reviews with sign-off.
- Security testing: add AI-specific red-teaming to your annual plan. Include prompt injection, data exfiltration via outputs, and tool misuse flows.
- Data governance: document training and fine-tuning datasets, retention windows, and deletion methods. Prove PII handling aligns with your privacy controls.
- Incident response: extend IR playbooks to cover unsafe outputs, model drift, and vendor model regressions. Track and close incidents like any other.
- Third parties: update vendor due diligence to ask for model cards, evaluation summaries, and TSC-aligned attestations where available.
These steps echo NIST AI RMF and ISO 42001 expectations, but they also translate cleanly into SOC 2 evidence that auditors can test.
Why the debate matters beyond compliance
The call for an AI-specific trust category isn’t about standards politics. It’s about clarity. Without shared expectations, two organizations with similar risk can earn very different reports. The ASCPA article flags that mismatch by pointing to dozens of gaps and dozens more proposed objectives. Those proposals will evolve, but the thrust is clear: controls must reflect how models are built, deployed, and abused.
There’s also regulatory gravity. The EU AI Act sets risk-tiered obligations. ISO 42001 asks leaders to run AI as a managed system, not a set of tools. NIST AI RMF promotes measurement and iteration. SOC 2 will need to absorb that direction, whether through sharper guidance or a sixth category that makes AI governance explicit.
For service organizations, the pragmatic move is to formalize model lifecycle oversight now and collect the artifacts future auditors will expect. Do that, and SOC 2 AI controls become less guesswork and more engineering discipline. When the framework catches up, you’ll already be there. For more on this, see bloomberg.com and nytimes.com.