Kubernetes Compliance: Frameworks, Controls, and Evidence (2026)

What Kubernetes Compliance Actually Means

Kubernetes compliance is the practice of configuring, operating, and evidencing your clusters so they satisfy the security and governance requirements of external frameworks — CIS, SOC 2, ISO 27001, PCI DSS, HIPAA — and of your own internal policies. It is not a product you buy or a report you generate once a year. It is the intersection of three things: knowing which requirements apply to your clusters, mapping each requirement to a concrete Kubernetes control, and being able to prove — with dated, attributable evidence — that the control was in place throughout the audit period.

That last part is where most teams struggle. Kubernetes is unusually good at expressing security controls (RBAC, Pod Security Standards, NetworkPolicies, encryption configuration are all declarative objects) and unusually bad at proving them. Nothing in a default cluster records that a control existed last March, who verified it, or what happened when it briefly stopped passing. This guide covers the full arc: what the major kubernetes compliance standards ask of a cluster, which controls satisfy several frameworks at once, how the shared responsibility line falls on managed Kubernetes, and how to run the scan-fix-evidence loop that turns configuration into audit-ready proof.

Shared Responsibility: What EKS, GKE, and AKS Cover — and What They Don't

Every kubernetes compliance conversation on managed Kubernetes starts with the same misunderstanding: "AWS is SOC 2 compliant, so our EKS cluster is covered." It isn't. The cloud provider's certifications cover the infrastructure they operate — the control plane, etcd, the physical hosts. Everything you can configure remains your responsibility, and it is precisely the things you can configure that auditors examine.

On EKS, GKE, and AKS, your side of the line includes everything you can configure — which is precisely what auditors examine:

• Audit logging — whether control-plane audit logs are even enabled (off by default on EKS).
• Access — every RBAC role and binding, plus IRSA or Workload Identity scoping.
• Workload security — Pod Security Standard enforcement and every workload securityContext.
• Network — all NetworkPolicies; the provider ships a flat pod network.
• Secrets — encryption configuration (KMS envelope encryption is opt-in).
• Nodes — node group hardening and patching.

In practice, roughly 80% of the technical controls an auditor checks in a Kubernetes environment sit on the customer side. The provider's attestation letters cover the other 20% — collect them, file them, and then focus on your own side.

The Kubernetes Compliance Standards That Matter

Five frameworks account for nearly every k8s compliance requirement that engineering teams actually face. They differ in scope, enforceability, and how much of them a scanner can verify — which is worth understanding before you commit to any of them.

CIS Kubernetes Benchmark: The Technical Baseline

The CIS Kubernetes Benchmark is the only framework on this list written specifically for Kubernetes: a consensus-developed list of configuration checks — API server flags, kubelet settings, RBAC minimization, pod security — each with an audit command and a remediation.

It is not a legal requirement, but it functions as the technical floor for every other framework. SOC 2, ISO, and PCI auditors all accept CIS results as evidence of configuration hardening, most compliance tooling implements CIS checks first, and because it is fully machine-verifiable, it is where cluster hardening should start. Our CIS Kubernetes Benchmark implementation guide walks the highest-impact controls with the exact YAML and verification commands.

SOC 2: The Framework Your Customers Ask About

SOC 2 is an attestation over the Trust Services Criteria — most commonly Security (the Common Criteria, CC-series). It is organizational in shape but lands on Kubernetes hard:

• CC6.1–CC6.3 (logical access) → RBAC least privilege, no standing cluster-admin.
• CC6.6 (segmentation) → default-deny NetworkPolicies.
• CC6.7–CC6.8 → encryption in transit and admission restrictions on unauthorized software.
• CC7.1–CC7.2 → audit logging and misconfiguration detection.
• CC8.1 → GitOps-style change management.

Critically, a Type II report attests over a period — typically 6–12 months — so point-in-time screenshots do not suffice; you need recurring, dated checks. Our SOC 2 for Kubernetes guide maps every relevant criterion to its Kubernetes control and evidence artifact.

ISO 27001: The International Certification

ISO 27001 certifies an information security management system (ISMS), with Annex A supplying the control catalog. For clusters, the 2022 revision's technological controls are the relevant surface:

• A.8.2 / A.8.3 (privileged access, access restriction) → RBAC.
• A.8.9 (configuration management) → Pod Security Standards and admission policy.
• A.8.15 / A.8.16 (logging, monitoring) → API audit logs and alerting.
• A.8.22 (network segregation) → NetworkPolicies.
• A.8.24 (cryptography) → secrets encryption.

About two-thirds of the Annex A controls that touch Kubernetes are scannable; the rest are organizational. The full clause-by-clause mapping — including which controls no scanner can check — is in our ISO 27001 Annex A mapping for Kubernetes.

PCI DSS: If Card Data Touches the Cluster

PCI DSS 4.0 applies when workloads store, process, or transmit cardholder data — and unlike SOC 2 or ISO, it is contractually mandatory, with prescriptive requirements. In Kubernetes terms:

• Requirement 1 (network security) → genuine segmentation of the cardholder data environment: default-deny NetworkPolicies, and often dedicated node pools or clusters for CDE workloads.
• Requirement 3 (stored data) → strong cryptography — secrets encryption is necessary but not sufficient; application-layer encryption usually enters the picture.
• Requirements 7–8 → RBAC and identity.
• Requirement 10 → detailed, retained audit logs of all access to cardholder data.
• Requirement 11 → regular security testing.

The most consequential PCI decision is architectural, made before any YAML: keep the CDE as small as possible, because everything inside its segmentation boundary is in scope for all 200+ requirements.

HIPAA: If PHI Touches the Cluster

HIPAA's Security Rule applies to protected health information and is technology-neutral — it never mentions containers — but its technical safeguards map directly:

• 164.312(a) access control → RBAC and unique service identities.
• 164.312(b) audit controls → API audit logging with retention.
• 164.312(c) integrity → image signing and admission control.
• 164.312(e) transmission security → TLS everywhere, mTLS between services.

HIPAA adds two things engineering teams often miss: a required risk analysis (a documented process, not a scan) and Business Associate Agreements with every vendor that touches PHI — including your cloud provider and any platform tooling. Like PCI, the highest-leverage move is isolation: constrain PHI to clearly bounded namespaces or clusters so the compliance surface stays small.

Build each control once — then claim it across every framework that asks for it.

The Controls That Satisfy Every Framework at Once

Lay the five frameworks side by side and a pattern appears: they are asking for the same small set of Kubernetes controls in different vocabularies. This is the single most useful fact in kubernetes security compliance, because it means you should run one hardening program with a mapping table — not one project per framework. Six control families do most of the work:

RBAC least privilege. Namespace-scoped Roles, no standing cluster-admin, dedicated ServiceAccounts per workload, and periodic access reviews. Claimed by CIS 5.1.x, SOC 2 CC6.1–CC6.3, ISO A.8.2/A.8.3, PCI 7.x, and HIPAA 164.312(a). The deep-dive is in our Kubernetes RBAC guide.

Pod Security Standards. Namespace labels enforcing the restricted profile in production — no privileged containers, no host namespaces, non-root users. Claimed by CIS 5.2.x, SOC 2 CC6.8, ISO A.8.9, and PCI secure-configuration requirements. Implementation walkthrough: Pod Security Standards in Kubernetes.

Network segmentation. Default-deny NetworkPolicies with explicit allows, which is simultaneously CIS 5.3.2, SOC 2 CC6.6, ISO A.8.22, PCI Requirement 1 segmentation, and HIPAA transmission safeguards. See Kubernetes NetworkPolicies implementation guide.

Secrets protection. Encryption at rest (KMS envelope encryption on managed clusters), external secret managers, rotation, and no secrets in Git. Claimed by CIS, SOC 2 CC6.x, ISO A.8.24, PCI Requirement 3, HIPAA 164.312(a). Options compared in our secrets management guide.

Audit logging. API-server audit logs enabled, shipped to durable storage, and retained for the audit period. This one control appears in every single framework — SOC 2 CC7.2, ISO A.8.15, PCI Requirement 10, HIPAA 164.312(b) — and is disabled by default on most managed clusters. Full setup, policy YAML, and retention guidance: Kubernetes audit logging for compliance.

Ongoing verification. Recurring configuration scans with tracked remediation, satisfying CIS as a whole, SOC 2 CC7.1, ISO A.8.8, and PCI Requirement 11. The complete control-by-control treatment of all of the above lives in our Kubernetes security checklist — 50 best practices.

From Framework to Evidence: The Loop That Passes Audits

Container compliance fails in audits for a mundane reason: teams treat it as a configuration problem when auditors treat it as an evidence problem. The cluster may well have been compliant all year — but if nobody can produce dated proof, it wasn't, as far as the report is concerned. The working pattern is a four-step loop.

Scan against the framework, not a spreadsheet. Run a scanner that evaluates the live cluster — workloads, RBAC, cluster configuration — and maps findings to framework controls. Manifest-only scanning in CI is valuable for prevention but insufficient for attestation, because auditors ask about the running environment, drift included.

Fix at the field path. A useful finding names the workload and the exact manifest field — securityContext.allowPrivilegeEscalation on a named Deployment in a named namespace — so remediation is a one-line change and a rollout, not an investigation. Batch fixes by control family rather than by workload; changing one field across forty Deployments is one pull request.

Re-scan to prove the fix. The before/after pair — failing scan, remediation, passing scan, all dated — is precisely the "detection and correction" evidence SOC 2 CC7.2 and ISO A.8.16 ask for. A finding that silently disappears between quarterly scans proves nothing; a tracked finding with a closure date proves the process works.

File the artifact. Export the passing report, store it with a timestamp where the audit team can retrieve it, and record who ran it. Repeat quarterly at minimum, and additionally after cluster upgrades, new workloads, and RBAC changes — the three events that most often silently break a passing control.

Scan, fix, re-scan, file — repeated quarterly, this loop is the audit trail.

Operationalizing Kubernetes Compliance: Who Does What, When

The technical controls are half the program; the other half is cadence and ownership, and it is cheap to set up:

• Weekly — the platform team reviews new scanner findings and triages them like bugs: owner, severity, target date.
• Quarterly — run the full loop above, export the evidence pack, and review RBAC bindings for access that should have expired.
• Annually (or per audit cycle) — refresh the control mapping against framework updates. CIS revises the benchmark with Kubernetes releases, and ISO 27001:2022's restructuring of Annex A caught many teams with stale mappings.

Two organizational choices make everything downstream easier. First, name a single owner for cluster compliance — usually the platform lead — because "shared" ownership reliably means unowned. Second, put the framework-to-control mapping table in the repo next to the policies it describes, so an auditor's question ("show me your CC6.6 controls") is a lookup, not a scramble.

Tooling: What Actually Checks the Boxes

The open-source layer is where most teams start: kube-bench executes the CIS node-level audit commands, Kubescape evaluates live clusters against CIS, MITRE ATT&CK, and framework mappings, Trivy covers image and configuration scanning, and OPA Gatekeeper or Kyverno prevent violations at admission. These are excellent at detection and prevention, and we compare them in depth in our open-source Kubernetes security tools guide. What none of them provide alone is the evidence layer — scheduled runs, tracked remediation, dated exports — which is what commercial Kubernetes security and compliance platforms add on top.

Atmosly sits in that second category for the posture-and-evidence slice of the problem: a one-click, on-demand scan (built on Kubescape) evaluates your cluster against CIS v1.10.0, MITRE ATT&CK, SOC 2, and ISO 27001:2022, every finding resolves to the affected workload and exact field path, AI-generated verify-and-fix commands run in an audited, namespace-scoped terminal with a human in the loop, and RBAC roles created through the platform carry automatic expiry so standing privileged access cannot accumulate. It deliberately does not do image CVE scanning or runtime detection — pair it with Trivy and Falco for those layers.

Conclusion: One Program, Many Frameworks

Kubernetes compliance stops being overwhelming the moment you see the structure: five frameworks, one shared responsibility line, six control families that satisfy nearly all of them, and one scan-fix-evidence loop that turns configuration into proof. Build the controls once, map them everywhere, and run the loop on a calendar instead of before an audit deadline.

The practical starting point is knowing which controls your clusters fail today. Run a free Atmosly security scan — read-only, one click — and you'll have your CIS, SOC 2, and ISO 27001 gap list, with field paths, before your next standup.