Compliance · SOC 2
SOC 2 evidence for AI and LLM systems
Auditors now find LLMs and agents inside SOC 2 scope. Most of the evidence they sample for those systems falls under CC7 (system operations) and CC8 (change management). Here is what each control asks for and the telemetry that answers it.
Last reviewed by the Perimattic AI Suite team
In short
What SOC 2 evidence do AI systems need for CC7 and CC8?
For CC7.2, auditors sample proof that you monitor the AI system for anomalies: alert rules, alert history and who responded. For CC7.3 and CC7.4, they want incidents evaluated and handled through your response process. For CC8.1, they look for authorisation, testing and approval of changes, which for AI includes model versions, system prompts and retrieval settings. Request-level traces with version metadata supply all three.
Prompts are configuration
A system prompt or model version change alters behaviour as much as a code change. If it isn’t in the change log, CC8.1 has a gap.
Type II needs history
An auditor samples the whole period. Monitoring that started last month can’t evidence a twelve-month window, so retention matters as much as coverage.
Regulation overview
What SOC 2 requires
SOC 2 is an attestation, not a certification. A Type I report assesses control design at a point in time; a Type II report tests whether controls operated effectively over a period. Security (the Common Criteria) is always in scope; the other categories are chosen by the organisation.
- Authority
- American Institute of Certified Public Accountants (AICPA); reports are issued by independent CPA firms
- Legal basis
- AICPA Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy
- Penalties
- No fines. The cost of failure is a qualified opinion or exceptions in your report, which customers and procurement teams read closely.
Capabilities
How Perimattic AI Suite produces SOC 2 evidence
Monitoring you can show
Threshold alerts on quality, cost, latency and errors, with each alert and its handling kept against the traces that triggered it.
Signal it produces: CC7.2 alert history
Change records for models and prompts
Every span carries the model, prompt version and retrieval configuration in use, so a change can be matched to the ticket that approved it.
Signal it produces: CC8.1 version timeline
Period exports
Evidence packages for the audit window, covering monitoring, incidents, changes and access, in a form your auditor can sample.
Signal it produces: Audit-period evidence pack
Vendor performance
Availability and error rates for each LLM provider, measured from your traffic rather than the vendor’s status page.
Signal it produces: CC9.2 vendor monitoring data
Control to signal
SOC 2 controls mapped to AI telemetry
Control wording is paraphrased from the AICPA criteria. Use the right-hand column to plan what your auditor will sample for each AI system in scope.
| Criterion | What it asks | AI telemetry signal | Evidence auditors sample |
|---|---|---|---|
| CC6.1 | Restrict logical access to systems and data | User and service identity on every model call; role-limited access to traces | Access list for the AI system and its logs, with review dates |
| CC7.1 | Detect configuration changes that introduce vulnerabilities | Model, prompt and tool configuration captured on each span | Configuration history showing when settings changed |
| CC7.2 | Monitor components for anomalies and analyse them | Alerts on error rate, latency, cost, quality scores and injection attempts | Alert rules plus a sample of fired alerts and their triage |
| CC7.3 | Evaluate security events to decide if they are incidents | Flagged traces linked to the event being evaluated | Event log showing the evaluation and decision |
| CC7.4 | Respond to incidents through a defined programme | Incident record tied to the affected requests | Incident tickets with timeline, root cause and remediation |
| CC7.5 | Recover from incidents | Before and after quality and error metrics | Evidence that service returned to normal |
| CC8.1 | Authorise, test and approve changes before release | Version metadata for models, prompts and retrieval; evaluation results per release | Change tickets matched to deployed versions and test results |
| CC9.2 | Assess and manage vendor risk | Provider availability, latency and error rates per LLM vendor | Vendor monitoring data used in vendor reviews |
Processing Integrity (PI1) applies if you include that category: evaluation scores on live traffic help show outputs stay complete and accurate.
Sample evidence
What a CC8.1 change record looks like
The change ticket says what was approved. The trace record proves what actually ran, and when.
Perimattic AI Suite produces evidence for your SOC 2 programme. It does not issue SOC 2 reports; only an independent CPA firm can.
{
"record_type": "soc2.cc8_1.change",
"service": "support-agent",
"change": { "prompt_version": "v14 -> v15", "model": "<provider/model@version>" },
"ticket": "CHG-2291",
"eval_before_release": { "faithfulness": 0.91, "passed": true },
"first_seen_in_production": "2026-09-02T10:41:17Z"
}Criteria references last checked on 1 October 2026.
FAQ
Common questions
Short answers to common questions. They are general information, not legal advice.
Are LLM systems in SOC 2 scope?
If they process data covered by your system description, yes. The model API, orchestration code, vector database and the observability tool itself become system components. Each vendor in that chain needs its own SOC 2 report or must be covered by your vendor management controls (CC9.2).
What evidence does CC7.2 need for an AI system?
Proof that monitoring exists and runs: the alert rules, a history of alerts over the audit period, and records showing someone analysed them. For AI, alerts usually cover error rate, latency, cost and quality scores such as hallucination rate.
Do model and prompt changes fall under CC8.1?
They should. A new model version or system prompt changes how the system behaves. Treat them like code: ticket, test (for example an evaluation run), approval and a record of when the change reached production.
How should SOC 2 treat hallucinations?
The criteria don’t name hallucinations, but a spike in wrong answers is an anomaly under CC7.2. If it affects customers or data integrity, it should go through your CC7.3 evaluation and CC7.4 incident process.
Does our observability vendor need a SOC 2 report?
If it stores prompts, outputs or user data from in-scope systems, it is part of your vendor chain, so you should obtain its report or keep the data in an environment you already control.
Which other frameworks overlap with SOC 2 for AI?
HIPAA for health data, DORA for EU financial entities and the EU AI Act for high-risk systems. The compliance hub shows how one set of telemetry supports all of them.
Go further
Related tools, guides and services
- Free toolAI compliance readiness assessmentScore your readiness across SOC 2, DORA, the EU AI Act, HIPAA and GDPR.Open
- White papersEnterprise AI white papersIncludes “AI in Regulatory Compliance”, on governance in practice.Open
- ServiceDevOps and platform engineeringChange pipelines and monitoring stacks that hold up in an audit.Open
See what your AI systems are doing, with evidence to back it up
Perimattic AI Suite is in early access. Tell us what you are building and a Perimattic engineer will follow up to scope your first instrumented system.
Prefer email? sales@perimattic.com