HIPAA on Kubernetes: The 23 Controls Auditors Check

Most “HIPAA on Kubernetes” articles map five categories to ten vague controls and stop. Auditors do not stop there. They ask for the actual YAML, the actual log retention configuration, the actual KMS key ARN.

This is the post for the people who have to produce that evidence. The 23 specific Kubernetes controls that satisfy HIPAA’s Technical Safeguards under 45 CFR § 164.312, what changes under the 2025 Security Rule NPRM, where the cloud provider’s BAA ends and yours begins, and the eight findings auditors keep surfacing on real EKS, AKS, and GKE clusters.

This is also the post we hand to clients during the Kubernetes Production Readiness Audit when they ask “what would a HIPAA auditor actually want from us?”

What changed in 2025: the NPRM you cannot ignore

On January 6, 2025, HHS published the HIPAA Security Rule Notice of Proposed Rulemaking (NPRM) in the Federal Register. The comment period closed in March 2025. The final rule is expected in late 2025 or 2026, with a 240-day compliance window after publication.

Two reclassifications change how Kubernetes deployments need to be configured:

1. Encryption of ePHI at rest and in transit moves from Addressable to Required.
2. Multi-factor authentication becomes explicitly required at every access point to ePHI.

In practice, every “Addressable” item in the table below should now be treated as Required if you serve healthcare workloads in the United States. If you have not enabled KMS-backed Secret encryption at the Kubernetes API layer, or MFA on every IdP integration with your clusters, you have a 240-day compliance clock starting when the final rule publishes.

Cloud provider BAA scope: where your liability begins

Before the controls, a critical reset on shared responsibility. All three major managed K8s services are HIPAA-eligible, but the BAA covers the platform - not your configuration.

Provider	K8s service in BAA	How BAA is signed	What is your responsibility
AWS / EKS	Yes (EKS, EKS Fargate)	Self-serve in AWS Artifact, no cost	Node AMI patching, aws-auth and IAM Roles for Service Accounts (IRSA), audit log routing to S3 with object lock, KMS encryption configuration, NetworkPolicies, all workload-level controls. Must use HIPAA-eligible services only (S3, RDS, KMS, Secrets Manager, etc.).
Azure / AKS	Yes	Automatic via Microsoft Product Terms on EA, MCA, or CSP	AAD-integrated RBAC, MFA via Conditional Access, private cluster configuration, customer-managed keys, Azure Policy / Defender for Containers, Log Analytics retention, node patching.
GCP / GKE	Yes (Standard and Autopilot)	Signed in Google Cloud Console; covers BAA-listed services in the project	Workload Identity Federation, Binary Authorization, VPC-native networking, Cloud KMS-backed application-layer Secret encryption (must explicitly enable on GKE - it is opt-in), private cluster config, Cloud Audit Logs configuration and retention.

The platform team usually understands “the cloud is HIPAA-eligible.” Auditors care about whether you configured the platform correctly. A misconfigured public API server endpoint, plaintext etcd Secrets (because you did not enable KMS encryption), or unrestricted RBAC are entirely your liability under the shared responsibility model.

The 23 Kubernetes controls auditors check

Mapped to 45 CFR § 164.312 Technical Safeguards, plus cross-cutting controls that auditors verify alongside.

Standard 1: Access Control - 164.312(a)(1)

Control 1: Unique User Identification (Required - 164.312(a)(2)(i))

The Kubernetes mechanism: OIDC integration of kube-apiserver with corporate IdP (Okta, Microsoft Entra, Google Workspace). No shared kubeconfigs, no static system:masters bindings. AWS uses IAM-to-RBAC via the aws-auth ConfigMap or EKS Access Entries. Azure uses AAD-integrated AKS. GCP uses GKE Workload Identity Federation.

What auditors ask for: the kube-apiserver startup args showing --oidc-issuer-url and --oidc-client-id; the corporate IdP user list mapped to ClusterRoleBinding subjects; evidence that offboarding removes cluster access.

Control 2: Emergency Access Procedure (Required - 164.312(a)(2)(ii))

The Kubernetes mechanism: Documented break-glass procedure. Sealed root kubeconfig in a vault (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Separate cluster-admin ClusterRoleBinding that logs to SIEM. Time-boxed just-in-time access via Teleport, AWS SSM Session Manager, or similar.

What auditors ask for: the written runbook, the access log showing break-glass was used (or not used) in the last 12 months, evidence of post-incident review when used.

Control 3: Automatic Logoff (Addressable, Required under NPRM 2025 - 164.312(a)(2)(iii))

The Kubernetes mechanism: Short-lived OIDC tokens. IdP session lifetime configured (most enforce 8-12 hours maximum). ServiceAccount tokens with bound projection and expirationSeconds - no long-lived ServiceAccount tokens for human users.

What auditors ask for: IdP session policy showing maximum duration; absence of long-lived ServiceAccount secrets in the cluster.

Control 4: Encryption at Rest (Addressable, Required under NPRM - 164.312(a)(2)(iv))

The Kubernetes mechanism: kube-apiserver EncryptionConfiguration using KMS provider v2. AWS KMS for EKS, Azure Key Vault for AKS, Cloud KMS for GKE. Encrypted EBS / Azure Disk / persistent disk volumes. Encrypted snapshots and Velero backups.

What auditors ask for: the EncryptionConfiguration YAML showing kms provider (not aescbc or identity); evidence of KMS key rotation; encrypted backup target configuration.

Standard 2: Audit Controls - 164.312(b)

Control 5: kube-apiserver audit policy

The Kubernetes mechanism: Audit policy file mounted into kube-apiserver. RequestResponse level for Secrets, RBAC changes, and exec/portforward operations. Metadata level for everything else. See Kubernetes auditing documentation.

What auditors ask for: the audit policy YAML; sample audit log entries showing Secret access and RBAC changes are captured at RequestResponse level.

Control 6: Audit log immutability and retention

The Kubernetes mechanism: Audit logs shipped to immutable, WORM-style storage. CloudWatch Logs with S3 object lock on EKS. Log Analytics with immutable storage account on AKS. Cloud Logging with bucket lock on GKE. HIPAA requires a minimum of six years of retention for required documentation.

What auditors ask for: the destination bucket configuration showing object lock or immutable retention; the lifecycle policy; evidence that 6 years of audit logs are accessible.

Control 7: Runtime audit at the syscall layer

The Kubernetes mechanism: Falco or Tetragon for syscall-level events. Detects exec into pod, mount of /etc/shadow, unexpected outbound connections, privilege escalation attempts. Falcosidekick forwards alerts to Slack, PagerDuty, or SIEM.

What auditors ask for: Falco rules configuration; sample alerts and the team’s response process; evidence that runtime security alerts are reviewed.

Control 8: Container image and registry audit

The Kubernetes mechanism: Trivy or Grype scanning images at build time and in the registry. Signed provenance via Cosign and Sigstore. Admission-time enforcement that rejects unsigned or critically-vulnerable images.

What auditors ask for: the vulnerability scanner report archive; image signing key chain of custody; admission controller policies that block unsigned images.

Standard 3: Integrity - 164.312(c)(1)

Control 9: ePHI authentication mechanism (Addressable - 164.312(c)(2))

The Kubernetes mechanism: Read-only root filesystem on Pods (readOnlyRootFilesystem: true). File integrity monitoring via Falco rules or sidecar. Database row-level checksums or HMAC for ePHI columns at the application layer. Signed container images enforced at admission.

What auditors ask for: SecurityContext policy showing readOnlyRootFilesystem; FIM alert rules; application-layer integrity controls for the database.

Control 10: Workload integrity via Pod Security

The Kubernetes mechanism: Pod Security Admission with the restricted profile enforced at the namespace level. Kyverno or OPA Gatekeeper policies blocking privileged: true, hostNetwork, hostPID, unsigned images.

What auditors ask for: namespace labels showing pod-security.kubernetes.io/enforce: restricted; admission policy YAMLs.

Control 11: Supply chain integrity

The Kubernetes mechanism: SBOM generation (Syft, Anchore). SLSA Level 3 build provenance. Cosign verification ClusterPolicy via Kyverno. Image registries restricted to signed images only.

What auditors ask for: SBOM artifacts for production images; signature verification policy; the registry access policy.

Standard 4: Person or Entity Authentication - 164.312(d)

Control 12: MFA at every IdP access path (Required under NPRM 2025)

The Kubernetes mechanism: MFA enforced at the IdP for every human reaching kube-apiserver. The NPRM makes MFA explicitly required at all access points to ePHI.

What auditors ask for: IdP policy showing MFA enforcement for all user groups with cluster access; audit logs showing MFA used.

Control 13: Workload identity for pod-to-cloud auth

The Kubernetes mechanism: IRSA on EKS, Workload Identity on GKE, Azure AD Workload Identity on AKS. No long-lived cloud credentials in Secrets.

What auditors ask for: scan results showing no AWS access keys or Azure connection strings in Secrets; the IRSA / Workload Identity trust configuration.

Control 14: Pod-to-pod identity (SPIFFE/SVID)

The Kubernetes mechanism: SPIFFE/SPIRE or service mesh-issued SVIDs for pod-to-pod authentication. ServiceAccount token volume projection with audience binding.

What auditors ask for: mesh configuration showing automatic identity issuance; absence of static API tokens in deployments.

Standard 5: Transmission Security - 164.312(e)(1)

Control 15: Integrity controls (Addressable - 164.312(e)(2)(i))

The Kubernetes mechanism: TLS 1.2 minimum (TLS 1.3 preferred) with modern cipher suites. HSTS at ingress. Certificate pinning for partner API connections where appropriate.

What auditors ask for: TLS configuration at ingress; cipher suite list; HSTS headers.

Control 16: Encryption in transit (Addressable, Required under NPRM - 164.312(e)(2)(ii))

The Kubernetes mechanism: Strict mTLS via Istio PeerAuthentication: STRICT or Linkerd automatic mTLS for all east-west pod traffic. cert-manager + Let’s Encrypt or private CA at ingress.

What auditors ask for: the PeerAuthentication resource showing mtls.mode: STRICT; cert-manager Certificate resources for ingress; evidence that plaintext traffic is rejected.

Control 17: NetworkPolicies

The Kubernetes mechanism: Default-deny baseline via NetworkPolicy or Cilium policies. Namespace-scoped allow rules. Explicit egress allowlists for PHI databases and partner endpoints. Read more in our eBPF observability post for network observability validating these policies.

What auditors ask for: NetworkPolicy YAMLs; evidence of default-deny in production namespaces; flow logs showing policies enforce as intended.

Control 18: Private control plane endpoint

The Kubernetes mechanism: EKS with private endpoint enabled. AKS API server VNet integration. GKE private cluster. No public IP reachability for kube-apiserver.

What auditors ask for: the cluster’s API endpoint configuration showing private-only access; the bastion or VPN access path documented.

Cross-cutting controls auditors verify alongside 164.312

Control 19: Secrets management

The Kubernetes mechanism: External Secrets Operator integrated with AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. No PHI or credentials in environment variables, ConfigMaps, or committed Helm values.

What auditors ask for: scan results showing no PHI or credentials in plaintext in cluster manifests; the External Secrets configuration showing the upstream secret store; rotation policy.

Control 20: Backup encryption and tested restore

The Kubernetes mechanism: Velero backups encrypted with KMS-backed keys. Backup target in a separate region or account. Quarterly restore drills with documented timing and outcome. Required under 164.308(a)(7) contingency plan, but auditors check it on K8s.

What auditors ask for: Velero schedules; KMS encryption configuration on the backup bucket; the last restore drill report; RTO and RPO commitments.

Control 21: Vulnerability management

The Kubernetes mechanism: Continuous Trivy or Grype scanning of running images. Documented patch SLA (e.g., Critical CVEs within 7 days, High within 30). Base image refresh cadence (typically every 30-60 days).

What auditors ask for: the scan history; CVE remediation timeline samples; base image refresh evidence.

Control 22: Application-layer ePHI access logging

The Kubernetes mechanism: Structured application logs capturing user ID, action, record ID, and timestamp for every ePHI access. Shipped to SIEM via Loki, OpenSearch, or equivalent. kube-apiserver audit logs do not capture application-layer reads of ePHI - this is a separate logging stream that the auditor will explicitly ask for.

What auditors ask for: sample application logs showing user-to-record access; the SIEM retention policy; the audit trail demo showing they can answer “who accessed record X on date Y.”

This is a near-universal blind spot. Most teams confuse kube-apiserver audit logs (cluster-level, captures kubectl access) with application-level audit logs (captures who read which patient record). Auditors require both.

Control 23: Configuration drift detection

The Kubernetes mechanism: GitOps via Argo CD or Flux as the source of truth. OPA Gatekeeper or Kyverno audit reports. Monthly CIS Kubernetes Benchmark via kube-bench. Drift between Git and live cluster state alerts to the platform team.

What auditors ask for: the Argo CD or Flux configuration; the last kube-bench report; evidence that drift is detected and resolved.

2024-2025 OCR enforcement: what auditors are actually catching

The HHS Office of Civil Rights issued more than $15M in HIPAA fines across 2024-2025. None are explicitly labeled “Kubernetes” in public resolution documents, but the failure patterns are directly applicable:

• Solara Medical Supplies (January 2025): $3 million settlement. Phishing breach plus risk-analysis failure. Risk-analysis deficiencies are the through-line in nearly every recent OCR action.
• Illinois business associate (March 2025): $227,816. Server misconfiguration exposed ePHI for 4,304 individuals over multiple years. Exactly the pattern that maps to a public ingress on a misconfigured K8s service.
• VPN Solutions (2024): $90,000. Ransomware following missing risk analysis.
• OCR’s Risk Analysis Initiative (launched late 2024) has produced seven enforcement actions in the first six months. Targets are entities hit by ransomware or misconfiguration who never did a proper risk analysis. This is the pattern an auditor of a K8s deployment will follow.

The translation to Kubernetes risk: every audit failure starts with “you did not have a documented risk analysis, and you did not implement the controls a risk analysis would have surfaced.” Most clusters we audit fail the controls in this post not because the team did not care but because the risk analysis was never done at the K8s layer.

The 8 most common audit findings we see

In our Kubernetes Production Readiness Audit engagements, we keep finding the same eight patterns on clusters that thought they were HIPAA-ready:

1. RBAC sprawl. ClusterRoleBinding granting cluster-admin to broad groups or wildcarded ServiceAccounts. Orphaned admin ServiceAccounts. Default ServiceAccount auto-mounted into every pod.
2. etcd Secret encryption not enabled or misconfigured. Default aescbc or identity provider instead of a KMS provider. Especially common on self-managed clusters and on GKE, where Cloud KMS-backed application-layer Secret encryption is an opt-in.
3. Audit logging missing, misconfigured, or under-retained. kube-apiserver audit policy left at None for Secrets, audit logs shipped to a mutable bucket, retention under the HIPAA 6-year minimum.
4. PHI or credentials in plaintext. Inside ConfigMaps, environment variables, container args, Helm values committed to Git, or inside Secrets that are not KMS-encrypted at the API layer.
5. NetworkPolicies absent or namespace-wide allow. Default-allow east-west traffic. PHI databases reachable from any pod. No egress controls.
6. OIDC and IdP not integrated. Long-lived kubeconfigs distributed to engineers. No MFA path to the cluster. No SSO offboarding tie-in.
7. Public API server endpoint still open to the internet. Control plane reachable from any IP.
8. No image provenance enforcement. Unsigned images. No admission policy blocking :latest. No vulnerability scan gate. Runtime pods with privileged: true or hostNetwork: true.

If any of these are true on your cluster, you have an audit problem. None of them are theoretical - all eight show up in clusters that have been running HIPAA workloads for over a year.

The auditor’s clipboard: evidence list per control

If you remember nothing else from this post, save this list. When an OCR auditor, HITRUST assessor, or SOC 2 + HIPAA combined audit team asks for evidence, this is what they want:

Control	Evidence to have ready
Unique user ID (Ctrl 1)	OIDC config on kube-apiserver; IdP user list
Audit policy (Ctrl 5)	Audit policy YAML + sample log entries
Audit retention (Ctrl 6)	Bucket lock / object lock policy; 6-year retention proof
etcd encryption (Ctrl 4)	EncryptionConfiguration with kms provider
Runtime security (Ctrl 7)	Falco rules + sample alerts
MFA (Ctrl 12)	IdP policy + audit log proof
Workload identity (Ctrl 13)	IRSA / Workload Identity config + Secret scan
Strict mTLS (Ctrl 16)	PeerAuthentication: STRICT resource
NetworkPolicy (Ctrl 17)	Policy YAMLs + flow log evidence
Private API endpoint (Ctrl 18)	Cluster endpoint config
Secrets in vault (Ctrl 19)	External Secrets config + plaintext scan
Tested restore (Ctrl 20)	Last quarterly restore drill report
App-layer audit logs (Ctrl 22)	Sample logs + SIEM retention
GitOps source of truth (Ctrl 23)	Argo CD / Flux config + drift detection alerts

A real audit goes through every row. Be ready with the artifact, not a description.

How this fits into our work

The 23 controls map onto categories in our 47-point Kubernetes Production Readiness Checklist - specifically the Security, Compliance, and Observability categories. The free checklist is the self-assessment version. The paid audit runs the same controls with a senior engineer producing the artifact list above.

For organizations that need full HIPAA-aligned implementation, our Production Kubernetes Cluster Setup Compliance Hardening add-on (an additional $2,495 on top of the $2,995 core setup) maps directly to these 23 controls. We deliver the EncryptionConfiguration, the audit policy, the OIDC integration, the NetworkPolicies, the External Secrets configuration, and the documentation auditors expect.

For ongoing HIPAA operations - quarterly restore drills, MFA policy reviews, vulnerability remediation cadence, app-layer audit log review - our Kubernetes consulting service covers the operational side.

---

Get help with HIPAA on Kubernetes

If you are running ePHI on EKS, AKS, or GKE and need to be audit-ready (or are already failing audit findings), here are the entry points:

• Kubernetes Production Readiness Audit ($495, 2 weeks): a senior engineer runs the Security and Compliance categories of our 47-point checklist against your cluster, including the controls in this post. You get a scored report and a 90-day remediation roadmap.
• Production Kubernetes Cluster Setup with Compliance Hardening ($2,995 core + $2,495 Compliance Hardening add-on): new EKS, AKS, or GKE cluster with HIPAA-aligned configuration from day one. Includes the control mapping document auditors expect.
• Free 47-point Kubernetes Production Readiness Checklist: self-assess against the same methodology, no email required.

We have delivered HIPAA-aligned Kubernetes work for healthcare SaaS, EHR integrators, and clinical research platforms. The 23 controls above are not theoretical for us - they are what we ship.

For questions on specific implementation: book a 20-minute fit call.