SOC 2 on AWS: What You Actually Need to Pass the Audit

The AWS controls that actually matter for SOC 2 Type II, and the ones that are pure checkbox theater. Based on real audit experience.

SOC 2 on AWS is more tractable than most companies think, but only if you understand what auditors actually look for. After going through this process with multiple clients, we've seen the same controls matter repeatedly and the same areas of over-engineering waste time and money.

What SOC 2 Type II actually measures

SOC 2 Type II assesses your controls over a time period (usually 6–12 months) across the Trust Services Criteria: Security (CC), Availability (A), Confidentiality (C), Processing Integrity (PI), and Privacy (P). Most companies pursuing SOC 2 only need Security + Availability + Confidentiality.

The most common mistake is treating SOC 2 as a technical exercise. It's not — it's an operational one. Auditors want to see that you have controls AND that you consistently followed them over the audit period. A perfect AWS architecture with no evidence of monitoring or access reviews will fail.

The AWS controls that actually matter

Access control and IAM

• All access via IAM roles — no long-term access keys in production

• MFA enforced for human console access (SCP to prevent disabling MFA)

• Least-privilege role policies — auditors will ask how you verify this

• Separation of production and non-production access

• Documented user access review process (quarterly is sufficient)

Audit logging

• CloudTrail enabled in all regions, with log file validation

• CloudTrail logs sent to an immutable S3 bucket (object lock, no-delete policy)

• Centralized in a separate logging account, not accessible from the application account

• Config rules to detect and alert on security group and IAM changes

Encryption

• All data at rest encrypted — RDS, S3, EBS, DynamoDB

• All data in transit over TLS — enforce via bucket policies and ALB redirect rules

• KMS customer-managed keys for data with high sensitivity requirements

• Secrets in Secrets Manager, not environment variables or parameter store plain text

Detection and monitoring

• GuardDuty enabled across all accounts — this is a non-negotiable

• Security Hub with AWS Foundational Security Best Practices standard enabled

• CloudWatch alarms on root account usage, security group changes, failed API calls

• Documented incident response process (can be simple — auditors want evidence you have one)

What you don't need to overcomplicate

We've seen teams spend months on things auditors don't focus on: complex SIEM setups, real-time threat intelligence feeds, and elaborate WAF rule configurations. For SOC 2 Type II, demonstrating consistent operation of simpler controls matters more than sophisticated controls applied inconsistently.

The evidence collection problem

The operational piece of SOC 2 that most teams underestimate is evidence. Auditors need evidence that controls ran continuously over the audit period. This means: quarterly access reviews with documented sign-off, change management logs showing who approved production changes, incident records (even for false alarms), and vulnerability scan results across the audit period.

Start collecting evidence on day one. If you're planning a Type II audit 12 months from now, the controls and evidence collection need to start now — not three months before the audit.