Subject: AI systems in scope — SOC 2 & ISO 27001
Somewhere around the second day of fieldwork, your assessor looks up and asks how you use AI. It is a friendly question. It is also the opening of a thread that runs through access control, change management, vendor risk and your logging pipeline — and most teams have never rehearsed the answer.
The reflex is to go looking for the new checklist. There isn’t one. That is the single most useful thing to understand before your next audit, so let’s start there.
The criteria never changed. Your systems did.
As of 2026 the AICPA has not released an AI module for SOC 2. The Trust Services Criteria are the same principles-based criteria they have been. Nobody is going to hand you a fresh control set to implement.
What changed is what those criteria are now pointing at. CC6 (logical access), CC7 (monitoring), CC8 (change management) and CC9 (vendor management) were written before your product called a model API, before an agent held a credential, and before your logs filled up with whatever your users typed. The words didn’t move. The systems underneath them did.
So the question in the room is not which AI framework do we need. It is narrower and more uncomfortable: can you produce evidence for controls you already claim to operate, now that they cover systems you didn’t have when you wrote them?
The six questions
Here is the mapping assessors are working from — existing criteria, new evidence.
| What they ask for | Maps to |
|---|---|
| Model versioning and prompt audit trails | CC7, CC8 |
| LLM sub-processor chain and vendor reviews | CC9 |
| Access controls for promoting a model | CC6 |
| Prompt injection and abuse testing | CC6, CC7 |
| Output verification and review | Processing Integrity |
| AI literacy training records | CC1 |
This is usually the opener, and it is a good one, because it tests four controls at once. They want the exact dataset, the code, the parameters, and the approval that put that specific version into production.
What closes itA change ticket for the model deployment that looks exactly like a change ticket for a code deployment — version, diff, tester, approver, date. If your models ship through a different door than your code, that door is the finding.
CC8 · CC7
You logged prompts and completions for debugging and for the audit trail. Reasonable. The problem is what your users typed into them — account numbers, health details, an entire customer email thread pasted in for summarising.
What closes itRedaction that happens before the log is written, not a cleanup job afterwards, plus a retention period you can actually evidence. Show the masking rule, then show a sampled log proving it fired.
CC7 · Confidentiality
Every provider you route data to is a sub-processor, and the chain often runs deeper than one hop — your vendor’s vendor is in scope too. Assessors test this against your vendor risk assessment and, increasingly, against your public sub-processor list.
What closes itEach provider in the vendor register with a completed review, plus evidence you configured data retention and opted out of training. A screenshot of the setting and the contractual terms behind it.
CC9Straightforward access control, asked about a path that frequently escapes it. Model weights, system prompts and agent configurations are production changes, but they often live outside the pipeline that governs everything else.
What closes itA named, reviewed list of who can promote, and an access review that includes those systems. Agent credentials are the sharp edge here — if an agent holds a token, that token needs an owner, a scope and a rotation schedule like any other.
CC6If the model touches anything a customer relies on, this becomes a processing integrity question. The assessor is looking for a defined check, not a claim that the team keeps an eye on it.
What closes itEvaluation results, human-in-the-loop review where the stakes justify it, drift monitoring output, and a documented path for what happens when the model is wrong. That last one is where most programmes are thinnest.
Processing IntegrityThe quiet one, and an easy finding to write. Your annual security training almost certainly predates the tools your team now uses daily.
What closes itA short AI-use module with a completion roster, and a written acceptable-use standard that says which tools are sanctioned and what must never be pasted into them.
CC1The findings that actually show up
Worth noticing how mundane these are. Almost none of them are exotic AI failures — they are the same control failures that have always shown up, now occurring in a place nobody was watching.
We have made this argument before about breaches, and it holds here: the boring control you skipped is the one that generates the finding. AI hasn’t changed that. It has just given the boring controls new territory to cover.
Your customers are asking the same questions
The mirror image of the audit is procurement. Enterprise security questionnaires now carry an AI section as standard, and it asks for the same things: model versioning policy, prompt log retention, training-data lineage, how you handle hallucinations, your sub-processor chain, and evidence of AI training.
Here is the trap. Sales answers the questionnaire optimistically in March. The auditor tests the same control in September and finds something narrower. Now you have a documented gap between what you told a customer and what you can evidence — which is a materially worse problem than the control gap itself.
The 30-day version
None of this requires a new framework, a platform purchase, or an ISO 42001 programme. For most teams it is about a month of unglamorous work.
- Inventory every place a model touches your data. Include the features shipped without a review and the tools someone expensed. You cannot scope what you cannot see.
- Trace one model end to end. Pick something in production and try to produce its full lineage. However long that takes you is your honest readiness score.
- Go and read your prompt logs. Not the policy about them — the logs. Search for email addresses and account numbers. Assume you will find something.
- Put every model provider in the vendor register with a completed review, retention configuration and training opt-out evidence attached.
- Gate model promotion the way you gate deploys. Same approvals, same tickets, same reviewers. Bring agent credentials into the access review while you are there.
- Ship a twenty-minute AI training and keep the completion roster. It is the cheapest finding you will ever close.
The teams that struggle with AI in an audit are rarely the ones doing something reckless. They are the ones who added capability faster than they extended their control set, and then met an assessor pointing familiar criteria at unfamiliar systems. The fix is not more governance theatre. It is making your existing controls reach the systems you actually run.
Sources & further reading
- SOC 2 Type 2 for AI Companies: AI-Specific Evidence Auditors Look For — Knowlee
- SOC 2 for AI Companies: What Auditors Test First — SOC2Auditors.org
- What Your SOC 2 Auditor Will Ask About AI Governance — containment.ai
- AI Vendor Risk Assessment: Questions to Ask Any LLM Provider — DeepInspect
- Does SOC 2 Cover AI Risk? What Auditors Now Ask — Pentest Testing
- ISO 42001: The Missing Piece in Your AI Compliance — Illumen, Issue #010
- Cowboy Carl & Careful Carol: A Grown-Up’s Guide to AI in GRC — Illumen, Issue #021
