29 Buyer-Ready Matrices: SOC 2 Type II Evidence List for MLOps-as-a-Service (≥ 1-Year Logs, 2025 US)

“Pull last June’s CloudTrail event—now.” When the result appears in three seconds, deals move and support breathes—like switching on a small desk lamp in a dim room. You need evidence that’s quick to locate and simple to defend.

This page gives you auditor-ready evidence: AWS/GCP/Azure side-by-side matrices, realistic cost and timeline bands, and one-screen buyer answers you can paste into security questionnaires, and we name the Trust Services Criteria (TSC) control and show the proof pattern—so you can ship features and still pass this quarter, aligned to AICPA & CIMA guidance as of 2025-06 (SOC 2 Type II, sometimes written SOC 2 Type 2). Prefer auditability over glossy dashboards? So do we, and we’ll unpack any term that might slow you down.

• Map control → proof. For each TSC (e.g., CC6.6), name the exact artifact: the log query, IAM change record, ticket ID, runbook, retention setting.
• Capture with boundaries. Include who/when/where and scope (account/project, region, service). Example: CloudTrail LookupEvents for 2024-06 on the affected account.
• Normalize by cloud. Show the AWS/GCP/Azure analogs side-by-side so reviewers don’t translate on the fly.
• Package once. One PDF per control with screenshots + query text; no loose tabs, no guesswork.

Next step: open the logging row in the matrix and pull one 2024-06 event now—save the query and screenshot to your CC6.6 folder. You’re closer than you think.

Above-the-fold value: CloudTrail Lake includes a 1-year retention option (extendable) and S3 can be indefinite via lifecycle; GCP Log Buckets support multi-year retention; Azure Log Analytics workspaces can be extended beyond 12 months—set ≥ 365 days everywhere today. Run the 60-second estimator below. (Amazon Web Services, 2025-06; Google Cloud, 2025-05; Microsoft Azure, 2025-04)

Compare AWS/GCP/Azure matrix ↓

What Type II actually attests to (TSC, 2025)

A SOC 2 Type II (often written “Type 2”) report says that, over a defined period—typically 3–12 months—your controls were both suitably designed and operated effectively to meet the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). It is a period-of-coverage opinion, not a one-day snapshot.

If last year felt murky, this year favors plain labels and dated proof. Auditors quote the TSC; give them control names they can quote and artifacts tied to real timestamps.

1. Name controls with the TSC code. Use a visible pattern like “CC6.6 — Logical access” or “A1.2 — Availability incident response.” Pair each name with one primary artifact: log query, ticket ID, configuration, or retention policy.
2. State scope and dates exactly. Example: “Scope: Security only; Period: 2024-07-01–2025-06-30.” Put this near the top of your control list and in your evidence index so reviewers never guess coverage.
3. Map control → evidence you can pull fast. Link the query or path you will run during testing (e.g., CloudTrail lookup, IAM change ticket, SIEM dashboard). The artifact must sit inside the period.
4. Record exceptions with fixes. If a control missed a day, note the deviation and the remediation date; a brief, factual exception narrative often reads stronger than silence.

For deeper cross-references, keep your TSC matrix handy: SOC 2 TSC matrix. Canonical reference: AICPA Trust Services Criteria. If Privacy isn’t ready this cycle, many teams start Security-only and expand next period—just disclose scope clearly.

Next: rename three control titles to include their TSC codes and attach one dated artifact to each.

Micro-episode: The shortest walkthrough we ever had? A one-page TSC map with owner names and a dated artifact link per control. We cut 25 minutes off the room schedule in 2024.

Why ≥ 1-year logs matter: SOC 2 doesn’t hard-code “365 days,” but US buyers and many auditors expect you to reconstruct events across fiscal cycles and model retrains—12 months is the practical floor. (NIST CSF 2.0 “Govern”, 2024-02)

🔗 Non-Owner SR-22 Same-Day Filing (2025) Posted 2025-10-13 05:09 UTC

Cost & timeline, 2025 (US)

Security/GRC leads need bands—not vibes. Here are conservative ranges we see in US SaaS (Series A–C) with lean but serious programs. Your scope, regions, and evidence maturity will move you up or down. (Audit firms & cloud providers, 2025-06)

Item (2025, US)	Type I	Type II (3–12 mo period)	Drivers / Notes
External audit fees	~$12k–$35k	~$25k–$85k	Scope, size, multi-region, privacy scope, period length
Readiness tooling / gap close	$0–$20k	$10k–$60k	Platform subscriptions, evidence migration, automation depth
Internal lift (people time)	2–4 weeks	6–12 weeks total across period	Control maturity, ticket hygiene, “single pipeline to prod”
IR tabletop cadence	—	4–8 hours/quarter	Include “poisoned dataset” & “compromised API key” scenarios
Typical retrieval costs	—	S3 $/GB-mo low; Lake/BigQuery/Log Analytics adds query fees	See estimator below; confirm provider fee schedule (2025 prices)

AWS vs GCP vs Azure: ≥ 1-year log retention quick map (2025)

Anglosphere buyers expect tri-cloud fluency. Use this matrix to align retention, queries, and screenshot proof patterns by provider. Defaults vary by log type; set explicit ≥ 365-day policies and paste the proof into your binder. (Amazon Web Services, 2025-06; Google Cloud, 2025-05; Microsoft Azure, 2025-04)

Topic	AWS	GCP	Azure
Primary log sources	CloudTrail (to S3), CloudTrail Lake (queryable), CloudWatch Logs	Cloud Logging (Audit Logs) → Log Buckets; optional BigQuery export	Azure Activity + Resource Logs → Log Analytics workspace / Storage
Retention knobs	S3 lifecycle (indefinite if unset); Lake 1-year included option (extendable)	Bucket retention days; BigQuery table partition expiration (set >= 365)	Workspace data retention (set >= 365); table-level policies; archive tiers
Typical defaults (2025)	Control Tower often 1-year for standard logs; access logs longer	Admin Activity often long-retained; Data Access shorter—set buckets explicitly	Activity default is short; extend in Log Analytics for ≥ 12 months
Where to screenshot proof	S3 Lifecycle JSON; Lake retention screen; Control Tower log-archive policy	Log Bucket “Retention” pane; BigQuery table expiration screen	Log Analytics “Usage and estimated costs” & “Data retention” settings
Sample retrieval query	select eventTime, eventName from cloudtrail where eventTime between '2024-06-01' and '2024-06-30' limit 1;	SELECT timestamp, protoPayload.methodName FROM `project.logs.cloudaudit_googleapis_com_activity_*` WHERE DATE(timestamp) BETWEEN '2024-06-01' AND '2024-06-30' LIMIT 1;	AppTraces | where TimeGenerated between (datetime(2024-06-01) .. datetime(2024-06-30)) | take 1 (Kusto)
Audit walkthrough script	Show retention setting → run Lake query → copy event ID → show S3 object path	Show bucket retention → run BigQuery/Logs query → paste row ID	Show workspace retention → run Kusto → show table policy screen

Micro-episode: A buyer asked, “If we switch regions, do your logs follow?” We showed the bucket policy & export job in 90 seconds. Questionnaire closed same day.

Buyer-ready answers (one screen)

Kubernetes audit evidence that passes (EKS/GKE/AKS)

Enable Kubernetes API server audit logs and keep at least 12 months of searchable history; prove it with a year-range query that returns a real event (for example, a ServiceAccount token rotation or a RoleBinding update), not a flood of low-signal list calls. If your cluster is quiet, a small RBAC change will do—what matters is that the event is real and searchable over the full year.

Be ready to show the cluster is within the EKS/GKE/AKS support window and that logs have loss protections (no drops) plus a named rotation/retention policy. Example (GKE): jsonPayload.verb="update" AND jsonPayload.objectRef.resource="rolebindings" AND timestamp>="2024-10-18T00:00:00Z"; export the first hit as a PDF and file it—auditors often ask for the literal query with the artifact.

Trimmed audit policy (example)

 apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata verbs: ["create","update","patch","delete"] resources: - group: "" resources: ["pods","secrets","configmaps","serviceaccounts"] - group: "rbac.authorization.k8s.io" resources: ["rolebindings","clusterrolebindings","roles","clusterroles"] - level: RequestResponse verbs: ["create","update","patch","delete"] resources: - group: "batch" resources: ["jobs","cronjobs"] 

12-month query examples (per platform)

• EKS → CloudWatch Logs Insights: fields @timestamp, user.username, verb, objectRef.resource | filter @timestamp >= '2024-06-01T00:00:00Z' and @timestamp < '2024-06-30T23:59:59Z' | limit 1
• GKE → BigQuery export: SELECT ts, protoPayload.requestMetadata.callerSuppliedUserAgent FROM `project.dataset.k8s_audit_*` WHERE DATE(ts) BETWEEN '2024-06-01' AND '2024-06-30' LIMIT 1;
• AKS → Log Analytics (Kusto): AzureDiagnostics | where TimeGenerated between (datetime(2024-06-01) .. datetime(2024-06-30)) | where Category == "kube-audit" | take 1

Log-retention cost mini-calculator (60 seconds)

Decision card: S3 lifecycle vs CloudTrail Lake vs SIEM (2025, US)

The minimal audit binder (MLOpsaaS)

• Governance & risk (NIST CSF 2.0 “Govern”): Risk register with ML-specific risks (lineage gaps, drift, rollback) mapped to TSC. (NIST CSF 2.0, 2024-02)
• Policies & standards: Information Security, Access Control, Change Mgmt, Incident Response, Vendor Mgmt, Secure SDLC, Log Retention ≥ 12 months, Data Retention/Deletion, Privacy.
• Access controls: SSO/MFA proof, quarterly reviews (IAM, notebooks, registry, feature store, DB/Warehouse), least-privilege diffs, J/M/L tickets.
• Logging & monitoring (prove ≥ 1 year): CloudTrail S3 lifecycle JSON + sample 12-month event; Lake retention config; Control Tower defaults; K8s audit policy + backend + 12-month query.
• Model lifecycle: Registry event history; deployment change tickets; signed image digests; CI/CD logs; feature-store schema change log.
• Data controls: Dataset register; PII classification; warehouse/DB audit logs; privacy impact assessments; deletion proof bundles.
• Secure SDLC: PR reviews; static/dynamic scans; SBOMs; container image scans; critical vuln remediation evidence.
• Ops resilience: Backup/restore test results; DR plan; capacity/health SLOs; drift & freshness alerts with playbooks.
• Vendor management: DPAs; subprocessors’ SOC reports/pen-tests (cloud, labeling, experiment platforms).
• Incident management: Runbooks; postmortems; tabletop minutes; pager schedules.
• System description: Scope, boundaries, services, complementary user-entity controls (AICPA description criteria). (AICPA & CIMA, 2025-06)

📄 Download the Binder Index (2025-US, PDF)

Evidence-pack templates you can copy

Model Change Evidence Pack

• PR review + CI logs + signed image digest
• Deploy record + model registry event (promote/demote)
• Change ticket + (optional) drift screenshot

Privacy Deletion Proof Pack

• Request → approval → job run logs
• Storage delete markers or tombstones
• Dataset register entry updated with date

📄 Download the Evidence Pack Checklist (2025-US, PDF)

System description boundaries (scope honesty)

Clear lines get you paid and help you clear the audit; draw the border like a map—no fuzzy edges. Say what’s inside the system, what’s outside, and what the customer operates. If something isn’t hosted by you, don’t claim it; note the integration instead. (AICPA & CIMA, 2025-06)

In scope

• API
• Data pipelines
• Training
• Feature store
• Model registry
• Inference service
• Supporting infrastructure

Out of scope

• Customer-managed models
• Optional add-ons
• Third-party UIs you don’t host

Complementary user-entity controls

• Restrict API keys (least privilege)
• Configure IP allowlists
• Rotate credentials quarterly

Next: insert these three lists into your “System Description” and map each item to its control owner.

Note for UK buyers (ISO 27001 & UK GDPR)

p>This page is scoped to US SOC 2 (AICPA). UK teams often want a clear line to ISO/IEC 27001 and UK GDPR/Data Protection Act 2018. The short version: the evidence you already keep—log retention and change control—travels well. Map it to Annex A themes (event logging, privileged access, change management) and state where data resides or how it’s lawfully transferred. We’re not rebuilding your program; we’re showing equivalence.

• Show the cross-walk. Add a one-page appendix that links key TSC points to Annex A controls using the artifacts you already maintain (audit-log queries, approval records, runbooks). Keep terms straight: SOC 2 speaks to “criteria,” ISO to “controls.”
• Prove logging in practice. Demonstrate searchable security events across your defined retention window and the controls that prevent tampering; include one real query output and the retention setting so reviewers can verify.
• Tighten privileged access. Provide evidence of role reviews and break-glass procedures, plus change tickets or approvals for admin changes—enough to show a consistent path from request to implementation.
• Address UK data expectations. If hosting in the UK/EU isn’t feasible, document transfer safeguards (IDTA/SCCs) and name subprocessors and regions clearly; if in doubt, state the region explicitly.

Next: publish the appendix with your buyer pack so UK reviewers can tick ISO/UK GDPR boxes without extra rounds.

ISO 27001 Annex A control	SOC 2 TSC mapping	Evidence example
A.12 — Log event management	Security / Availability	≥ 365-day retention settings + month-13 retrieval screenshot

Short Story: The June log that saved July

On a hot Friday in July, a customer swore our model had “changed tone.” The error looked human: a feature flag toggled at some midnight deploy. We pulled three threads. CloudTrail Lake showed a June role update against our registry’s service account. The registry’s timeline confirmed a promotion the week after. A tidy GitHub PR showed the approved rollback plan if drift spiked. The fix was two lines. The trust came from one screenshot: an event dated thirteen months back, with an owner’s name in the corner. During the audit, months later, we ran that same script. The auditor’s eyebrows rose the way eyebrows do right before an easy “no further questions.”

FAQ

1) Is ≥ 1-year log retention required by SOC 2?

No. SOC 2 doesn’t prescribe a number, but US buyers and many auditors expect ≥ 12 months for security-relevant logs. Write it into policy and match every system. 60-second action: Add “≥ 365 days” to your Log Retention Standard. (NIST CSF 2.0, 2024-02)

2) What exactly does Type II attest to?

Design and operating effectiveness of controls over a period (commonly 3–12 months) against TSC. The test isn’t “do you have a lock?” but “did the lock hold during the period?” (AICPA & CIMA, 2025-06)

3) How do I prove K8s who-did-what a year later?

Enable audit logging with a policy + durable sink; keep ≥ 365 days; keep a sample query that returns a last-year token or RoleBinding change. 60-second action: Add “K8s audit YAML + month-13 query” to the binder.

4) Which cloud should hold “auditor-demo” logs?

If you need frequent forensics and joins, keep 90 days in a queryable store (Lake/BigQuery/Log Analytics) and archive the rest to object storage. 60-second action: Document “90d queryable + 21m archive” split. (Amazon Web Services, 2025-06)

5) What slows Type II the most?

Shadow notebooks with direct PII pulls, secrets in code, and “optional” change tickets. 60-second action: Require a Model Change Evidence Pack to close any prod deploy.

Conclusion: Pass fast, keep shipping

You’re juggling releases and reviews under a small desk lamp; this is control you can prove, not theater.

In 15 minutes, lock it in—steady hands, clear steps:

1. Set a universal log-retention policy ≥365 days across AWS CloudTrail, GCP Audit Logs, and Azure Activity Log, and save a dated screenshot.
2. Add the three demo queries/scripts to your binder and label them “AWS / GCP / Azure — last-June pull.”
3. Template the Model-Change Evidence Pack: ticket ID, commit hash, approver, before/after metrics, rollout window, rollback note.

When someone says “pull last June,” you’ll have it in seconds—no drama—and you’ll close.

Next action: set 365-day retention now and file the screenshot under today’s date, then get back to shipping.

Infographic: Evidence flow on one page

💡 Read the AICPA SOC 2 overview

Update log

• Last reviewed: 2025-06
• Next review: 2025-11
• Changes: Added tri-cloud matrix; expanded K8s query examples; inserted cost & timeline table; added HowTo schema; improved estimator with copy & presets; added UK ISO Annex A mapping row; inserted internal anchor CTA; created two downloadable PDFs with “2025-US” filenames.
• Sources referenced: AICPA & CIMA; Amazon Web Services; Google Cloud; Microsoft Azure; Kubernetes; NIST CSF 2.0. (2025-04 to 2025-06)

SOC 2 Type II evidence list, Kubernetes audit logging, CloudTrail Lake vs S3, GCP Audit Logs retention, Azure Log Analytics retention

🔗 Narrow AI vs AGI Checklist for SOC 2 and ISO 27001 Posted 2025-10-08 11:46 UTC 🔗 AI Waiver Planner Wins Posted 2025-10-02 03:02 UTC 🔗 Artificial Intelligence Posted 2025-09-27 23:48 UTC 🔗 AI Diet Apps for Type 2 Diabetes Posted (no date recorded)