SOC 2 Type II for AI Systems: Audit Preparation Guide for 2026

Security (CC6-CC9)

• CC6.1 — Logical access: Who can access model weights, training data, and inference endpoints? RBAC on ML pipelines, model registries, and feature stores. MFA for model deployment.
• CC6.6 — System boundaries: AI systems often span multiple services (data ingestion, training compute, model registry, inference endpoints, monitoring). Define and document all boundaries.
• CC6.7 — Information transmission: Training data flowing to compute, model artifacts moving to production, inference requests/responses — all need encryption in transit.
• CC7.2 — Monitoring: Beyond traditional monitoring: model performance degradation, data drift detection, anomalous inference patterns (potential adversarial inputs).

Availability (A1)

• A1.1 — Capacity planning: AI inference is GPU-bound and unpredictable. Document autoscaling policies, GPU reservation strategy, and burst capacity plans.
• A1.2 — Recovery: If your model serving infrastructure fails, what's the recovery procedure? Model rollback, fallback to previous version, or graceful degradation to rule-based systems?
• AI-specific: Model retraining recovery. If a training run is corrupted or a deployed model degrades, how quickly can you retrain and redeploy? Document the procedure with RTO/RPO.

Processing Integrity (PI1)

• PI1.1 — Processing objectives: This is where AI gets tricky. Traditional systems have deterministic outputs. AI systems have probabilistic outputs. Define acceptable accuracy thresholds, confidence scores, and quality gates.
• PI1.4 — Error handling: What happens when a model returns a low-confidence prediction? When does the system defer to human judgment? Document your fallback logic.
• AI-specific controls:
  • Model validation before production deployment (evaluation benchmarks)
  • Input validation (reject malformed or adversarial inputs)
  • Output validation (confidence thresholds, safety filters)
  • Data quality gates (training data validation before model updates)

What Auditors Flag

1. No model versioning: "Which model version was serving traffic on March 15?" If you can't answer this instantly, it's a finding.
2. Training data lineage gaps: "Show me the provenance of data used to train the production model." No data lineage = no audit trail.
3. No access review for ML pipelines: Access reviews cover production servers but skip Jupyter notebooks, training clusters, and model registries.
4. Missing change management: Model updates deployed without formal change approval. In regulated environments, model deployment IS a change that requires CAB review.
5. Monitoring gaps: Traditional APM monitoring exists, but no model-specific monitoring (drift detection, prediction quality degradation).
6. No incident response for AI failures: Incident playbooks cover infrastructure failures but not "model started producing biased/incorrect outputs."

Automate Your Audit Evidence

• Model registry with immutable versioning: MLflow, Weights & Biases, or Azure ML Registry. Every model version, its training parameters, evaluation metrics, and deployment timestamp — automatically logged.
• Data lineage tools: Apache Atlas, Amundsen, or cloud-native lineage (AWS Glue Catalog, Azure Purview). Track data from source → transformation → training → model.
• Policy-as-code for ML: OPA policies that enforce "no model deployment without passing evaluation threshold" and "no training on data without approved classification."
• Automated access reviews: Script quarterly access reviews for ML infrastructure. Export IAM roles, service account permissions, and notebook server access lists.
• Continuous control monitoring: Tools like Vanta, Drata, or Secureframe can be configured to monitor AI system controls alongside traditional infrastructure.