TL;DR
- SOC 2 Type II audits require continuous evidence that your Kubernetes clusters meet security controls — not just a point-in-time snapshot
- CIS Kubernetes Benchmarks map directly to SOC 2 Trust Service Criteria, giving you a compliance foundation
- Most teams spend 2-4 weeks per audit cycle manually collecting evidence from kubectl exports and screenshots
- Automated compliance scanning eliminates this manual work and catches drift between audits
Why SOC 2 for Kubernetes Is Different
SOC 2 compliance for Kubernetes environments is fundamentally different from traditional infrastructure audits. Kubernetes is dynamic — pods are created and destroyed every minute, RBAC policies change with every deployment, and network policies shift as services scale. An auditor asking "show me your access controls" expects a clear answer, but in Kubernetes, the answer changes every hour.
According to the Cloud Security Alliance’s 2025 report, 78% of organizations running Kubernetes report that compliance evidence collection is their biggest operational burden. Not security itself — the evidence collection.
The core challenge is that SOC 2 was designed for static infrastructure. Servers had names, access lists were spreadsheets, and firewall rules changed quarterly. Kubernetes breaks all of those assumptions. Your "servers" are ephemeral pods. Your "access lists" are RBAC manifests versioned in Git. Your "firewall rules" are NetworkPolicies that change with every Helm upgrade.
This guide shows you how to bridge that gap — mapping Kubernetes-native controls to SOC 2 requirements and automating the evidence trail.
SOC 2 Type I vs Type II: What Your Auditor Actually Wants
Type I evaluates whether your controls are designed properly at a single point in time. Type II evaluates whether those controls operated effectively over a period (usually 6-12 months). Most enterprise customers require Type II.
For Kubernetes, this distinction matters enormously. A Type I audit might accept a screenshot of your RBAC configuration. A Type II audit needs evidence that RBAC was consistently enforced over the entire audit window — that no one had cluster-admin who shouldn’t, that pods didn’t run as root, that secrets weren’t exposed.
This is where most teams fail. They can show their Kubernetes security posture today, but proving it was consistent for the past 12 months requires either continuous monitoring or very good record-keeping.
The 5 Trust Service Criteria Mapped to Kubernetes
SOC 2 is built on five Trust Service Criteria (TSC). Here is how each maps to Kubernetes controls:
1. Security (Common Criteria)
This is the only mandatory TSC. It covers protection against unauthorized access.
| SOC 2 Requirement | Kubernetes Control | Evidence |
|---|---|---|
| Logical access controls | RBAC policies, ServiceAccount restrictions | kubectl get clusterrolebindings |
| Network segmentation | NetworkPolicies, namespace isolation | NetworkPolicy manifests + enforcement logs |
| Vulnerability management | Image scanning, CVE patching | Scan reports with timestamps |
| Encryption in transit | TLS on all services, mTLS (Istio/Linkerd) | Certificate inventory, Ingress TLS config |
| Encryption at rest | etcd encryption, Secret management | etcd encryption config, KMS integration |
| Change management | GitOps, Helm release history | Git commits, Helm revision logs |
2. Availability
Covers system uptime and disaster recovery.
- Pod disruption budgets ensure minimum replicas during maintenance
- Horizontal Pod Autoscaler provides scaling evidence
- Liveness and readiness probes prove health monitoring exists
- Multi-cluster or multi-zone deployment demonstrates redundancy
3. Processing Integrity
Ensures data is processed correctly and completely.
- Admission controllers (OPA Gatekeeper, Kyverno) enforce processing rules
- Resource quotas prevent resource starvation
- Quality of Service classes guarantee critical workload priority
4. Confidentiality
Protects sensitive data from unauthorized disclosure.
- Kubernetes Secrets management (ideally with external vault)
- Pod Security Standards prevent privilege escalation
- Secrets scanning detects hardcoded credentials
- RBAC restricts who can read sensitive ConfigMaps and Secrets
5. Privacy
Governs personal data handling (if applicable).
- Namespace-level isolation for PII workloads
- Audit logging of access to PII-containing pods
- Data retention policies enforced via CronJobs or TTL controllers
CIS Kubernetes Benchmarks: Your Compliance Foundation
The Center for Internet Security (CIS) publishes Kubernetes Benchmarks — over 200 specific security checks organized into categories. These benchmarks are the bridge between Kubernetes configuration and SOC 2 controls.
CIS benchmarks check things like:
- Is the API server configured with proper authentication?
- Are kubelet permissions restricted?
- Is etcd encrypted at rest?
- Are pod security standards enforced?
- Are audit logs enabled and retained?
Each CIS check can be mapped to one or more SOC 2 Trust Service Criteria. For example:
| CIS Check | Description | SOC 2 TSC |
|---|---|---|
| 1.2.1 | Ensure API server authentication is not set to anonymous | Security CC6.1 |
| 1.2.6 | Ensure authorization mode includes RBAC | Security CC6.3 |
| 3.2.1 | Ensure a minimum audit policy is created | Security CC7.2 |
| 4.2.1 | Ensure kubelet authentication is not anonymous | Security CC6.1 |
| 5.1.1 | Ensure default ServiceAccount is not used | Security CC6.3, Confidentiality C1.1 |
| 5.2.2 | Minimize admission of privileged containers | Security CC6.1, Processing Integrity PI1.3 |
Running CIS benchmarks regularly and mapping results to SOC 2 criteria is the most efficient path to Kubernetes compliance.
What Your Auditor Will Ask (And How to Answer)
Here are the 10 most common SOC 2 audit questions for Kubernetes environments, based on real audit engagements:
Q1: "Show me who has admin access to your clusters." Provide: ClusterRoleBindings with cluster-admin role, list of ServiceAccounts with elevated privileges, SSO group mappings.
Q2: "How do you ensure containers don’t run as root?" Provide: Pod Security Standards enforcement (Restricted profile), OPA/Gatekeeper policies blocking privileged pods, evidence of violations detected and remediated.
Q3: "What is your vulnerability management process for container images?" Provide: Image scanning reports with CVE counts over time, policy for blocking critical CVEs from deployment, patching SLA evidence.
Q4: "How do you detect unauthorized changes to your clusters?" Provide: Kubernetes audit logs, GitOps change history (Flux/ArgoCD), drift detection reports showing unauthorized vs authorized changes.
Q5: "Show me your network segmentation." Provide: NetworkPolicy manifests per namespace, evidence of default-deny policies, network traffic flow logs.
Q6: "How do you manage secrets?" Provide: External secrets operator config, vault integration, secrets scanning reports showing no hardcoded credentials.
Q7: "What is your incident response process for container security events?" Provide: Alerting rules for security events, escalation policies, on-call schedules, incident post-mortem examples.
Q8: "How do you ensure system availability?" Provide: PodDisruptionBudget configs, HPA policies, multi-zone deployment evidence, uptime monitoring dashboards.
Q9: "Show me your change management process." Provide: Git-based approval workflow, Helm release history with who deployed what and when, rollback evidence.
Q10: "How often do you assess your security controls?" Provide: This is where continuous scanning wins. Instead of "we run an annual assessment," you show real-time compliance dashboards with historical trends.
The Manual Evidence Problem
Most teams collect SOC 2 evidence manually. The typical process looks like this:
- Auditor sends a 50-item evidence request list
- Engineers spend 2-4 weeks running kubectl commands and taking screenshots
- Someone puts everything in a shared Google Drive folder
- Auditor reviews, asks for 15 clarifications
- Engineers spend another week gathering more evidence
- Repeat every 12 months
This process has three fundamental problems:
It is a snapshot, not continuous. The evidence shows your state during the collection period. If RBAC was misconfigured for 3 months before the audit, nobody knows.
It is error-prone. Manually running kubectl commands and formatting output is tedious and mistakes happen. Missing one ClusterRoleBinding can mean a finding.
It burns engineering time. At an average engineering cost of €100-150/hour, a 2-week evidence collection effort costs €8,000-12,000 per audit cycle — not counting the auditor’s fees.
Automated Compliance: Continuous Scanning vs Annual Scramble
The alternative is automated compliance scanning that runs continuously and maps findings to compliance frameworks automatically.
| Aspect | Manual Approach | Automated Approach |
|---|---|---|
| Frequency | Annual or semi-annual | Continuous (hourly/daily) |
| Evidence format | Screenshots, kubectl exports | Timestamped reports with trend data |
| Drift detection | None (hope nothing changed) | Real-time alerts on compliance violations |
| Time to prepare for audit | 2-4 weeks | Minutes (export report) |
| Coverage | Whatever engineers remember to check | All CIS benchmarks, every scan |
| Cost per audit cycle | €8,000-12,000 in engineering time | Platform subscription |
Who Does What: The Tool Landscape
Not all tools cover both Kubernetes operations and compliance. Here is the reality:
| Tool | K8s Operations | Compliance Scanning | Framework Mapping | Audit Reports |
|---|---|---|---|---|
| SRExpert | Full (monitoring, alerting, Helm, AI) | CIS benchmarks | SOC 2, HIPAA, PCI-DSS, ISO 27001 | Yes, on-demand |
| Komodor | Troubleshooting, drift detection | No | No | No |
| Lens | Cluster browsing (desktop) | No | No | No |
| Rancher | Cluster management | Basic CIS scanning | No framework mapping | No |
| Wiz | No (cloud security, not K8s ops) | Cloud-wide | SOC 2, HIPAA, PCI-DSS | Yes |
| Drata | No (compliance platform) | Partial (cloud, not K8s native) | SOC 2, HIPAA, ISO | Yes |
| Vanta | No (compliance platform) | Partial (cloud, not K8s native) | SOC 2, HIPAA, ISO | Yes |
The gap is clear: traditional compliance tools (Wiz, Drata, Vanta) don’t manage Kubernetes operations. K8s operations tools (Komodor, Lens, Rancher) don’t provide compliance. SRExpert bridges both — operations and compliance in one platform. Read more about this gap in our post on Kubernetes compliance without spreadsheets.
How SRExpert Automates SOC 2 for Kubernetes
SRExpert runs CIS Kubernetes Benchmarks continuously and maps each finding to the relevant SOC 2 Trust Service Criteria automatically. Here is what that means for your team:
Continuous CIS scanning. Every cluster connected to SRExpert is scanned against CIS benchmarks on a configurable schedule. Results are stored with timestamps, creating the historical evidence trail your auditor needs for Type II.
Automatic framework mapping. Each CIS finding is tagged with the SOC 2 control it satisfies. No manual spreadsheet mapping required. The same findings also map to HIPAA, PCI-DSS, and ISO 27001 if you need multiple frameworks.
Audit-ready reports. When your auditor asks for evidence, export a report filtered by framework, time range, and cluster. The report includes finding details, remediation status, and trend data.
Drift alerts. If a cluster falls out of compliance — someone creates a privileged pod, disables audit logging, or adds an overly permissive RBAC binding — SRExpert alerts your team immediately instead of waiting for the next annual audit.
Security scanning beyond CIS. SRExpert also scans container images for CVEs, detects misconfigurations, finds hardcoded secrets, and manages OPA/Gatekeeper policies. All of this feeds into the compliance evidence.
Combined with smart alerting that reduces noise by 70% and 6+ AI models for diagnostics, SRExpert replaces the compliance spreadsheet, the monitoring dashboard, the security scanner, and the alerting tool — with one platform.
Getting Started
SRExpert’s free tier includes 1 cluster with full compliance scanning. No credit card required.
- Install SRExpert on your cluster via Helm
- Connect your first cluster
- Run your first CIS benchmark scan
- Export a compliance report mapped to SOC 2
See all capabilities on our features page, or check pricing to find the plan that fits your team. For a hands-on walkthrough, visit docs.srexpert.cloud.
Your next SOC 2 audit doesn’t have to be a fire drill. Start free at srexpert.cloud/try-now.