SOC 2 for AI companies, model-aware.
AI startups have audit exposure traditional firms don't understand: foundation-model sub-processors, training-data controls, prompt logging, and vector-store isolation. Skadi is built for it. Senior CPAs from our network of Independent CPA audit firms scope around model architecture, and the audit runs on Skadi audit intelligence so your evidence is verified, tested, and cross-checked without leaving for a third-party LLM.
Audit challenges we solve for you.
Every hosted LLM you call is a sub-service org. Your system description, security review, and monitoring evidence must reflect that — and buyers now ask specifically about enterprise-tier data terms.
Customer data used for embeddings, RAG, or fine-tuning creates retention, lineage, isolation, and deletion obligations most SOC 2 templates miss entirely.
You sell privacy to customers, then hand screenshots and logs to auditors using public LLMs. Skadi's audit intelligence closes that gap by design.
Prompts, model versions, and eval suites change weekly. Change-management controls that were fine for a stable app fail here without adaptation.
Controls that matter most for your business.
Who can call production models, deploy new prompts, or change fine-tunes. Role-based access, approvals, and audit trails on model gateways.
Data lineage, classification, opt-out handling, and deletion evidence — especially for tenants who contractually forbid their data being used for training.
Namespace or per-tenant index partitioning, prompt-context isolation, and evidence one customer's embeddings cannot surface in another's session.
Policy, technical enforcement, and retention windows aligned to customer contracts; access controls on logs that may contain sensitive inputs; scheduled deletion evidenced.
Formal inventory of OpenAI, Anthropic, Pinecone, Weaviate, and every inference/vector vendor — with DPA, enterprise-tier data terms, security review, and monitoring evidence.
Approvals and rollback for prompt changes, model version bumps, and eval-gated releases — the fastest-changing surface in an AI company, and the one auditors most often find under-controlled.
Documented evaluation cadence for safety, bias, and jailbreak resistance where contractually promised, with release gating evidenced from CI.
Deletion propagated to embeddings, fine-tune datasets, cached prompts, and evaluation corpora — not just the source database.
What actually fails in this vertical.
Real deviations we see in SOC 2 Type II fieldwork — and what your platform and security teams should fix before the observation window starts.
Production traffic routed through OpenAI/Anthropic default terms where inputs may be retained. Enterprise/zero-retention tier not enabled — the single most-cited AI-specific finding in 2025.
- Executed enterprise/zero-retention agreement with each model vendor
- Screenshot of API org settings showing zero-retention flag enabled
- Egress config or model-gateway policy pinning production to the enterprise endpoint
- Sub-processor register listing each model vendor + data-handling tier
Single Pinecone/Weaviate index storing embeddings for multiple customers with only application-layer filtering. One query bug and you have a cross-tenant leak — auditor calls this a design deficiency.
- Architecture diagram showing per-tenant namespace / index
- Terraform or vector-DB config snippet enforcing tenant filter
- Automated isolation test in CI with passing run logs
- Threat model doc covering cross-tenant retrieval risk
Contract promises 30-day deletion; logs sit in an S3 bucket for a year because no lifecycle rule was set. Deletion must be technical, scheduled, and evidenced.
- S3 lifecycle policy / log-store retention config
- Retention policy document referencing customer commitments
- Sample deletion-job log for the window
- MSA/DPA excerpt with the committed retention window
Opt-out flag exists in the app DB but the training pipeline reads a raw dump that ignores it. Data-lineage control fails on first walkthrough.
- Data-lineage diagram from source to training corpus
- Pipeline code / DAG showing opt-out filter
- Sample training-dataset manifest with opt-out counts
- Ticket for opt-out reconciliation run during the window
Prompts edited directly in a config dashboard, no PR, no reviewer, no rollback plan. Change management (CC8.1) exception on nearly every AI startup's first audit.
- Git history for prompts/model configs under version control
- PR with reviewer approval + CI evals passing
- Change-management policy covering prompts and model versions
- Rollback runbook with a recent execution log
Safety and regression evals exist but running them is not enforced in CI. Marketing claim exists ('we test for jailbreaks'); control to back it does not.
- CI workflow file with required eval job (branch protection references it)
- Eval report artifact for a sampled release
- Written eval policy with pass/fail thresholds
- Release ticket linking to eval artifact and approver
Why traditional auditors miss the risk
Most audit firms wrote their SOC 2 playbooks before generative AI existed. They treat an inference API as 'just another SaaS vendor' and miss the actual risks: training-data leakage, prompt injection into logging pipelines, and customer contracts that forbid third-party model training. Skadi's methodology was rebuilt around modern AI architecture from the ground up.
The AI-company evidence problem
AI companies face a specific paradox at audit time: they sell privacy and data protection, then are asked to upload screenshots and system exports to consultants who process them with public LLMs. Skadi's audit is performed by audit intelligence running inside the audit environment. Evidence stays put, and the CPA reviews it in place — the same posture your customers demand of you.
Enterprise readiness for AI buyers
Enterprise procurement is now asking AI vendors questions no one asked two years ago: model provenance, training opt-outs, prompt logging retention, tenant isolation on vector stores, and deletion in embeddings. A SOC 2 Type II report that speaks to those specifically — instead of pretending the AI layer doesn't exist — is a practical way to unlock those deals.
Preparing for ISO 42001 and AI-specific frameworks
ISO/IEC 42001 (AI management systems) and the NIST AI RMF are becoming the next enterprise ask. We scope SOC 2 so the same governance, risk-assessment, and monitoring evidence extends cleanly to a 42001 program later. One control library, multiple attestations — instead of duplicated work across frameworks.
Questions we hear from teams like yours.
Ready to scope your SOC 2 Type II?
Book a call and we'll walk you through timeline, scope, and pricing for your company.