EKS SOC 2 Readiness: What Auditors Actually Check

For an EKS-based SaaS platform, SOC 2 readiness is less about passing a Kubernetes security checklist and more about demonstrating three things: that security controls are implemented, that they are consistently enforced, and that there is evidence to prove both.

That last part is where teams underestimate the work. Enabling a control takes an afternoon. Showing an auditor that it operated correctly for every week of the audit period takes planning from the first day of that period.

Short answer: prepare evidence in six areas - access control, change management, logging and monitoring, vulnerability management, network and workload security, and backup and recovery. Map each SOC 2 control to its implementation, evidence source, owner and collection frequency, and automate the collection. Every important security claim should have an identifiable owner and verifiable evidence.

Why EKS makes SOC 2 evidence harder

• Two identity layers. AWS IAM decides who can reach the cluster and what workloads can do in AWS; Kubernetes RBAC decides what they can do inside it. Auditors need to see both, and see that they agree.
• Shared responsibility moves. AWS runs the control plane; you own node hardening, RBAC, network policy and everything in the pods. The EKS security best practices draw the line - your evidence has to show your side of it.
• Everything is ephemeral. Pods live for minutes and nodes are replaced automatically. A screenshot of the cluster today says nothing about the cluster three months ago, which is the period a Type II audit examines.

The evidence to prepare, in six categories

The SOC 2 criteria references are to the AICPA Trust Services Criteria; your auditor's control list will map onto them.

1. Access control and identity management (CC6.1-CC6.3)

• AWS IAM policies and trust relationships for workload identities (IRSA or EKS Pod Identity).
• EKS access entries, cluster access configuration, and Kubernetes RBAC roles and bindings.
• SSO and MFA enforcement for privileged AWS access.
• Access reviews, and evidence that employee access is revoked when no longer required.

aws eks list-access-entries --cluster-name prod
kubectl get clusterrolebindings,rolebindings -A -o yaml

Auditors usually sample: pick a leaver from the period and ask when their access was removed. The answer needs a record, not a recollection.

2. Infrastructure changes and deployment controls (CC8.1)

• Pull requests showing review and approval before production changes.
• CI/CD workflow configuration and branch protection rules.
• Terraform plans and deployment records that link each infrastructure change to an approved pull request.
• Evidence that production deployments are restricted to authorised identities - for example, CI roles assumed through OIDC, with no human deploy credentials.

# Merged PRs in the audit period, with their review decision
gh pr list --repo acme/platform --state merged \
  --search "merged:2026-07-01..2026-09-30" --limit 500 \
  --json number,title,author,mergedAt,reviewDecision

3. Logging and monitoring (CC7.2-CC7.4)

• EKS control plane audit logs and the relevant CloudTrail events.
• Centralised log retention settings, and evidence that logs are accessible to authorised personnel only.
• Security alert configuration, and examples of alerts that were investigated.
• Documented incident response procedures, with records of incidents or exercises during the period.

4. Vulnerability and image management (CC7.1)

• Container image scanning results and remediation records.
• Dependency scanning and infrastructure vulnerability findings.
• The policy for approved images and deployment security.
• Evidence that critical vulnerabilities were tracked through to resolution - the ticket trail matters as much as the scanner.

5. Network and workload security (CC6.6, CC6.8)

• VPC architecture, security groups and network access rules.
• Kubernetes network policies, where implemented.
• Workload security configuration: privileged containers, Linux capabilities, service account permissions.
• Evidence that production and non-production environments are separated.

The technical checks behind this category are in the EKS security audit checklist, each with a command to verify it.

6. Backup, recovery and operational controls (A1.2, A1.3, CC7.5)

• RDS backup configuration and retention policies.
• Evidence of backup restoration or disaster recovery tests.
• Documented on-call responsibilities, incident management procedures and operational reviews.
• Records showing that control failures found along the way were tracked and remediated.

aws rds describe-db-instances \
  --query 'DBInstances[].{db:DBInstanceIdentifier,retentionDays:BackupRetentionPeriod,multiAZ:MultiAZ}'

What takes the most effort: evidence for the whole period

The challenge to plan for is not enabling the controls. It is producing consistent evidence that they operated throughout the audit period.

A SOC 2 Type I report looks at whether controls are designed properly at a point in time. A Type II report looks at whether they operated effectively over a period - typically several months to a year. That changes what counts as evidence.

Branch protection is the clearest example. Having it enabled today doesn't, by itself, demonstrate that production changes were reviewed throughout the period under examination. It could have been switched on last week; an admin could have bypassed it in August. What the auditor wants is the record: protection settings captured over time, and the merged pull requests from the period with their approvals.

The same applies to RBAC bindings, access reviews, log retention and scan results. If you only capture them when the auditor asks, you can only show the present.

The evidence matrix

The tool that makes this manageable is an evidence matrix: every applicable SOC 2 control mapped to its implementation, evidence source, owner, collection frequency and retention. A few rows from a typical EKS matrix:

Writing the matrix forces the useful questions early: which controls have no owner, which evidence nobody collects, and which claim in your security questionnaire you can't currently prove.

Automate evidence collection

Wherever possible, collect evidence from AWS, GitHub and the security stack on a schedule rather than by hand. A weekly job that snapshots the state auditors ask about, into a bucket with S3 Object Lock so the records can't be altered afterwards:

#!/usr/bin/env bash
set -euo pipefail
D=$(date +%F)
B=s3://acme-soc2-evidence/$D

kubectl get clusterrolebindings,rolebindings -A -o yaml | aws s3 cp - "$B/k8s-rbac.yaml"
aws eks list-access-entries --cluster-name prod     | aws s3 cp - "$B/eks-access-entries.json"
gh api repos/acme/platform/branches/main/protection | aws s3 cp - "$B/branch-protection.json"
aws logs describe-log-groups --log-group-name-prefix /aws/eks/prod \
  --query 'logGroups[].{name:logGroupName,retentionDays:retentionInDays}' \
  | aws s3 cp - "$B/log-retention.json"

Run it from CI on a schedule with a read-only role, and the "operated throughout the period" question answers itself: there is a dated record for every week. For broader coverage, AWS Audit Manager includes a SOC 2 framework that collects AWS-side evidence automatically; compliance platforms do the same across AWS, GitHub and HR systems.

Mistakes that create audit findings

• Collecting evidence only when the auditor asks. You can show today's configuration, not the period's.
• Controls without owners. A control nobody owns stops operating quietly, and nobody notices until the sample fails.
• Checking IAM and RBAC separately. Broad IAM roles mapped to tidy-looking RBAC groups read as a contradiction - show how the two layers line up.
• Scanning without remediation records. Scan output proves you looked; tickets closed within your stated timelines prove the control works.
• Untested backups. A backup configuration is a design; a restore test with a timestamp is evidence.

FAQ

What is the difference between SOC 2 Type I and Type II for EKS?

Type I assesses whether controls are suitably designed at a point in time. Type II assesses whether they operated effectively over a period, typically several months to a year. Type II is what most customers ask for, and it is why continuous evidence collection matters.

How long does EKS SOC 2 readiness take?

Closing the major gaps - RBAC and IAM cleanup, logging, change controls, scanning - commonly takes several weeks for a team starting from scratch. The Type II observation period then runs for months, so the evidence collection needs to be working before it starts.

Do SOC 2-scoped workloads need a separate EKS cluster?

Not necessarily. Namespace isolation with RBAC, network policies and resource quotas can satisfy scoping for many audits, while some data sensitivity levels justify a dedicated cluster. Agree the scope with your auditor early.

Does SOC 2 require a specific Kubernetes version?

No, but auditors expect a supported version and a documented patching process. A cluster running well past end of support suggests the patch management control isn't operating.

Preparing for a SOC 2 audit on EKS?

I help teams build the controls, the evidence matrix and the automated collection as part of Kubernetes and EKS consulting and the AWS architecture review.