SOC 2 still applies to AI systems, and it works through the same Trust Services Criteria your auditor has always used. What’s changed is the evidence: auditors now ask for model lineage, inference logs, and drift monitoring, not just access reviews. If your controls aren’t mapped to something like the AI Controls Matrix, read your system description closely. It will show you exactly what was tested, and what wasn’t.

TL;DR:

  • Prioritize contemporaneous model lineage, per inference logs with redaction, and drift records linked to remediation tickets; auditors cannot rely on policies without operating evidence.
  • AICM has 247 control objectives across 18 domains for evidence; use NIST AI RMF to prioritize risk, ISO 42001 for governance, and STAR for attestation.
  • Scope each AI system, its operator, hosting location, and subprocessors handling data in the system description, then name relevant control categories in the management assertion.
  • Allow 60 to 90 days for preparation before engagement, and test kill switches and key rotation before the audit; continue monitoring throughout the observation period.
tekRESCUE
Build a More Secure AI Roadmap
tekRESCUE’s AI Profit & Growth Assessment maps tailored strategies and potential vulnerabilities to help businesses adopt AI with security in mind.
Explore the AI assessment

Table of Contents

Which Trust Services Criteria matter most for AI systems

Security is the one criterion every SOC 2 report must cover, and with AI in scope, auditors stretch it further. They want to see agent identity management, API key rotation, and proof that your AI tools only get the access they need to do their job.

Processing integrity gets more complicated too. AI systems don’t behave the same way twice, so auditors start asking different questions: how do you define accuracy, what’s your drift threshold, and can you show validation evidence when a model’s behavior shifts?

Confidentiality and privacy both hinge on how you handle data moving through prompts. Auditors want to know what’s captured in prompt logs, whether personal data shows up there, and how long you keep it before deletion kicks in.

Availability matters more when a product depends on an AI agent to function. If the agent goes down, does the service go down with it? Auditors increasingly test for that, including whether your kill switch actually works.

  • Security: agent identity, API key management, least-privilege access for AI tools
  • Processing integrity: drift thresholds, validation evidence, defined accuracy metrics
  • Confidentiality and privacy: prompt data handling, PII exposure, retention and deletion rules
  • Availability: agent dependency risk, kill-switch testing

AI-specific control categories auditors now request

Auditors have started asking for evidence that didn’t exist in a typical SOC 2 engagement two years ago. Here’s what tends to come up first.

  1. Model lifecycle controls: documentation covering training, validation, promotion to production, and rollback procedures.
  2. Lineage and artifact capture: dataset snapshots, code commits, hyperparameter records, and model version IDs tied together so you can reconstruct what shipped and when.
  3. Prompt and inference logging: records of what went into the model and what came out, with redaction practices for anything sensitive.
  4. Drift detection: defined metrics, monitoring dashboards, and incident tickets that show when drift was caught and how it was fixed.
  5. Subprocessor and supply-chain controls: vendor attestations and contractual language covering any third-party model or data provider you rely on.
  6. Testing: adversarial testing, unit tests, and behavioral validation that confirm the model does what it’s supposed to before it touches production.

This list lines up closely with what practitioners describe in a recent research note on the SOC 2 AI gap: auditors are improvising these categories because the underlying Trust Services Criteria predate generative AI, and they’re mapping new evidence back to old language.

Pro Tip: Keep a running log of model changes as they happen, not reconstructed after the fact. Auditors trust a contemporaneous record far more than a retroactive summary.

Mapping AI controls to SOC 2 evidence auditors will accept

Your system description is where all of this gets written down, and it matters more now than it used to. It should define what’s actually in scope: which AI systems, who operates them, where models are hosted, and which subprocessors touch the data.

AI system scope and data relationships

Your management assertion needs similar precision. Don’t just say “AI controls were operating effectively.” Name the categories: model lifecycle, lineage, inference logging, drift monitoring, subprocessor review, whatever applies to your environment during the observation period.

For artifacts, auditors tend to accept things like:

  • Model snapshot IDs tied to specific training runs
  • Change control tickets with documented approvals
  • Drift-monitoring screenshots linked to remediation tickets
  • Redacted prompt and inference logs
  • SOC reports from AI subprocessors you rely on

A vague system description leaves buyers guessing about what was tested. A specific one lets a prospective customer compare your report against a competitor’s and see, concretely, whether AI risk was part of the audit at all. That comparability is becoming a real differentiator in vendor due diligence, especially as more companies ask AI-specific questions during procurement. For deeper guidance on the vendor side of this, see our practical guide to AI vendor risk.

How CSA AICM, STAR for AI, ISO 42001, and NIST AI RMF fit together

None of these frameworks replace SOC 2. They fill the gaps auditors are currently improvising around, and each one does a different job.

The AI Controls Matrix (AICM) v1.1 is the most directly useful for audit prep. It’s a control catalog built specifically for AI, with 247 control objectives spread across 18 domains, including a dedicated Model Security domain, plus implementation and auditing guidelines you can hand straight to your audit team.

247 control objectives across 18 domains: that’s the scope AICM v1.1 covers, with machine-readable formats built to support automated evidence collection rather than manual spreadsheets.

STAR for AI gives you a registry and attestation path you can publish alongside your SOC 2 report, which helps buyers see your AI posture without waiting for a full report exchange.

ISO/IEC 42001 works at a different altitude. It’s a management system standard, so it covers governance structure, roles, and continual improvement rather than discrete technical controls.

The NIST AI Risk Management Framework rounds things out by framing risk at the portfolio level, helping you decide which AI systems need the most scrutiny before you even get to control mapping.

  • Use NIST AI RMF to frame and prioritize risk across your AI portfolio
  • Use AICM to operationalize controls and generate audit evidence
  • Use ISO 42001 for governance structure and continual improvement
  • Use STAR for AI as a public attestation layer alongside SOC 2

A checklist to prepare for a SOC 2 audit that includes AI

Getting ready doesn’t have to be chaotic if you sequence it right.

  1. Scope first: inventory every AI system in use, classify each by risk tier, and decide which ones fall inside your observation period.
  2. Collect artifacts early: pull together model snapshots, code commits, change approvals, drift logs, and subprocessor SOC or ISO reports before the audit starts, not during it.
  3. Enable logging and redaction: turn on per-inference logging with redaction rules so sensitive data never sits unprotected in your logs.
  4. Test what you’d rather not test: schedule kill-switch tests and confirm key-rotation policies are actually enforced, not just written down.
  5. Set a timeline: plan for 60 to 90 days of pre-engagement prep for either a Type I or Type II report, then move to a continuous monitoring cadence once the audit period begins.

Pro Tip: Run a mock evidence request two weeks before your audit kickoff. If your team can’t produce a drift log or a model snapshot on short notice, your actual auditor won’t be able to either.

Common gaps we see and how to close them

Across AI readiness work, the same gaps show up again and again: missing lineage records, inference logs that were never turned on, kill switches nobody tested, and subprocessor risk that was never documented past a signature on a contract.

The fix usually starts with an honest assessment, not a tooling purchase. Once you know where the gaps actually are, prioritize the controls that produce auditable artifacts first: lineage, logging, and drift monitoring tend to matter most to auditors right now. Operational monitoring comes after that groundwork is in place.

— Randy Bryan

Why checkbox compliance won’t satisfy an AI-literate auditor

Most SOC 2 advice still treats AI as an afterthought bolted onto existing controls, and that’s the part we’d push back on. A model governance policy that nobody can produce logs for isn’t a control, it’s a document. Auditors have figured this out faster than many vendors have, which is why lineage records and inference logs are showing up as standard evidence requests rather than exceptions.

The overrated move is waiting for the AICPA to issue official AI points-of-focus before doing anything. That could take years, and in the meantime, practitioners are already building evidence expectations around frameworks like AICM. Treat AICM as the de facto standard now, not a nice-to-have.

If we had to pick one priority for a team starting from zero, it’s turning on inference logging with redaction. Everything else, drift monitoring, lineage capture, subprocessor review, is easier to build once you have a real record of what your models are actually doing in production.

Why checkbox compliance won't satisfy an AI-literate auditor — overview diagram

How tekRESCUE AI gets your AI systems audit-ready

We offer an AI Profit and Growth Assessment designed to help close the gap between having AI in production and being able to prove it’s controlled. The assessment maps your AI systems, flags where lineage, logging, or drift monitoring is missing, and hands you a roadmap built around the evidence an auditor will actually ask for.

tekRESCUE

We integrate security into that roadmap from the start rather than treating it as a separate project, focusing on controls that are tested in production to support auditor reliance. For organizations that need ongoing coverage after the assessment, our Managed AI Security service keeps monitoring and evidence collection running between audit cycles.

If your AI systems need to be audit-ready, start with the AI Profit and Growth Assessment and get a clear picture of where you stand before your next SOC 2 engagement.

FAQ

Is there a SOC 2 for AI specifically?

There’s no separate SOC 2 report for AI. The existing Trust Services Criteria still apply, but auditors now expect AI-specific evidence like model lineage and inference logs, often mapped using frameworks like AICM v1.1.

What are some examples of SOC 2 controls for AI systems?

Common examples include agent identity management, per-inference logging with redaction, drift detection tied to incident tickets, and subprocessor attestations for any third-party model provider. These map back to the Security, Processing Integrity, and Confidentiality criteria.

What evidence do auditors accept for AI model changes?

Auditors generally accept model snapshot IDs, change control tickets with documented approvals, and dataset or hyperparameter records that let them reconstruct a model’s history. These artifacts need to exist contemporaneously, not be assembled after the fact.

How does ISO 42001 relate to SOC 2 for AI governance?

ISO/IEC 42001 provides management-system requirements for AI governance, covering roles, risk management, and continual improvement. SOC 2 then tests whether the operational controls under that governance structure actually worked during a given period.

How can tekRESCUE AI help us prepare for a SOC 2 audit covering AI?

Our AI Profit and Growth Assessment scopes your AI systems, identifies missing evidence categories like lineage or drift monitoring, and builds a roadmap toward audit readiness. Pricing for ongoing services like Managed AI Security is available once we understand your scope.

Sources