SOC 2 Checklist for AI Systems

SOC 2 auditors have started asking about AI: which models are used, who can change prompts, where customer data goes when it enters a prompt, and what happens when the model provider is down. Organizations with mature SOC 2 programs often find their AI systems sit outside the controls that everything else follows. This checklist maps LLM applications and agents to the trust services criteria so they can be brought inside. It complements soc2 for ai vendors and the LLM security checklist. This is general orientation, not audit guidance; confirm scope and design with your auditor.

Who should use this checklist?

Compliance and security teams preparing SOC 2 audits at organizations that build or use AI in their services, and engineering owners of AI systems who need to produce evidence.

Are AI systems scoped and inventoried?

1. AI components supporting the service are in the system description.
2. Models, providers, AI tools, agents, and MCP servers are in the asset inventory with owners.
3. Data flows involving AI, including prompts, retrieval, outputs, and logs, are documented.
4. Risk assessment includes AI-specific risks: injection, leakage, provider dependency, model change.

Reference: ai governance checklist.

Security: is access controlled and reviewed?

Control	AI-specific application
Logical access	AI systems have their own identities; credentials are least privilege, short-lived, revocable
User access	AI acts under user permissions; retrieval enforces entitlements
Access reviews	Periodic review of AI system credentials, tool scopes, and prompt or model change rights
Authentication	SSO and MFA for AI tooling and administrative consoles
Segregation of duties	Prompt or model authors separate from approvers; agents cannot both create and pay
Secrets management	Provider keys and agent credentials in a vault; none in code or prompts

Reference: ai access control and ai secrets management.

Security: are threats addressed and monitored?

1. Prompt injection, leakage, and excessive agency are addressed with documented controls.
2. Logging captures AI requests, tool calls, and administrative actions with redaction.
3. Monitoring and alerting cover anomalous AI activity and security events, feeding the security operations process.
4. Vulnerability management covers AI infrastructure and dependencies.
5. Adversarial testing results are retained as evidence.

Reference: the AI agent security architecture whitepaper.

Change management: are prompts and models controlled?

1. Prompts, model versions, retrieval configurations, and tools are versioned.
2. Changes are reviewed by someone other than the author and approved per risk.
3. Evaluation gates provide testing evidence for behavioral changes.
4. Deployment records link production state to approved versions.
5. Provider model updates are treated as changes with re-evaluation.
6. Rollback capability is documented and tested.

Reference: how to build a prompt management system and how to build a ci-cd pipeline for machine learning.

Availability: are AI dependencies covered?

1. Provider outages are addressed with fallbacks, degraded modes, and capacity planning.
2. Availability commitments to customers account for AI dependencies.
3. Incident response covers AI failures and provider incidents.
4. Backup and recovery include indexes, prompts, configurations, and evaluation datasets.
5. Load and failover testing results are retained.

Reference: how to build an llm gateway and the LLM production readiness whitepaper.

Processing integrity: is AI output quality controlled?

1. Specifications define expected behavior.
2. Evaluation measures correctness before release and in production.
3. Validation and gates prevent incorrect or unauthorized actions.
4. Error handling and human review processes are documented.
5. Monitoring of quality and drift produces evidence.

Reference: how to build an ai quality gate.

Confidentiality: is customer data protected in AI flows?

1. Data classification governs what may enter prompts and reach which providers.
2. Redaction or tokenization protects confidential data where required.
3. Provider terms prohibit training on customer data and define retention.
4. Logs and traces are redacted and access-controlled.
5. Multi-tenant isolation is enforced in retrieval, memory, and outputs.
6. Disposal covers embeddings, caches, and derived data.

Reference: ai data leakage prevention.

Privacy: is personal data handled per commitments?

1. Notices and consent cover AI processing where applicable.
2. Data subject rights processes account for AI data flows.
3. Retention for prompts and outputs follows the privacy policy.
4. Cross-border transfers through providers are addressed.

Reference: ai data privacy compliance.

Vendor management: are AI providers assessed?

1. Model providers and AI tools are in vendor management with risk ratings.
2. Assessments cover security, data terms, availability, and incident history.
3. Contracts include data use, change notification, and exit.
4. Concentration risk and fallbacks are documented.
5. Ongoing monitoring of provider changes is in place.

Reference: ai third-party risk management.

Is evidence being produced continuously?

1. Access reviews, change records, evaluation reports, monitoring dashboards, incident records, and vendor assessments are generated by the systems, not assembled at audit time.
2. Sampling of AI change and access records has been rehearsed.
3. Policies reference AI systems explicitly.

How should gaps be prioritized?

Scoping and inventory first; then access and change management, which produce the evidence auditors sample most; then availability, confidentiality, and vendor management. Where existing controls can be extended to AI systems, extend them rather than creating parallel processes.

How FISTA Solutions supports SOC 2 alignment for AI

FISTA Solutions builds AI systems that produce SOC 2 evidence by design: inventoried components, least-privilege identities with reviews, versioned prompts and models with evaluation-gated change management, gateway-based fallbacks, redacted logging, tenant isolation, and vendor documentation. The AI enablement practice delivers the platform that centralizes these controls, AI agents run inside them, and forward deployed engineers work with your compliance team on scope and evidence. The record behind the approach is 150+ projects with 99.9% uptime.

This checklist is general orientation, not audit guidance. To prepare AI systems for a SOC 2 audit, message FISTA on WhatsApp, or read enterprise ai security for the security foundation.