SOC 2 AWS Checklist: 31 Controls to Automate Today

Why AWS Configuration Matters for SOC 2

SOC 2 auditors do not audit AWS itself — AWS holds its own SOC 2 Type II report, which you can reference under the shared responsibility model. What auditors examine is your configuration of AWS services. Misconfigurations such as public S3 buckets, root account API keys, or disabled CloudTrail are direct audit findings against the Security, Availability, and Confidentiality trust service criteria.

The good news is that AWS provides more native compliance tooling than any other cloud provider. AWS Config, Security Hub, CloudTrail, GuardDuty, IAM Access Analyzer, and Macie collectively generate continuous evidence that maps directly to SOC 2 criteria. A well-configured AWS environment can reduce manual evidence collection by 70–80% compared to on-premise infrastructure.

This checklist is organized by TSC criteria group. For each item, we specify the AWS service, the exact configuration setting, and the SOC 2 criterion it satisfies. All 31 items can be enforced via AWS Config Rules so that non-compliant resources trigger automated findings rather than relying on periodic manual reviews.

IAM Controls (CC6.1, CC6.2, CC6.3)

CC6.1 requires logical access controls to protect information assets. In AWS this starts with IAM. Check 1: Root account MFA — navigate to IAM → Security recommendations and confirm MFA is enabled on the root account. No root account API access keys should exist. Check 2: Enable IAM password policy requiring minimum 14 characters, requiring uppercase, lowercase, numbers, and symbols, and preventing password reuse for 24 generations. Check 3: All human IAM users must have MFA enabled. Use the AWS Config rule `iam-user-mfa-enabled` to enforce this continuously.

CC6.2 (access provisioning) requires that access is granted based on roles and least privilege. Check 4: No inline IAM policies — use managed policies attached to roles. Check 5: Run IAM Access Analyzer and resolve any findings for resources shared externally. Check 6: Use IAM roles for EC2 instances instead of embedding access keys in instance configuration. Check 7: Review and remove IAM users with access keys unused for more than 90 days using the `iam-user-unused-credentials-check` Config rule.

CC6.3 (access removal) requires timely de-provisioning. Check 8: Enable AWS SSO (IAM Identity Center) if you have more than five engineers — this centralises lifecycle management. Check 9: Set up a detective control using an EventBridge rule that fires when an IAM policy is attached directly to a user rather than a group or role. This catches policy drift before an auditor does.

Logging and Monitoring (CC7.2, CC7.3)

CC7.2 requires that the system monitors for threats. Check 10: Enable CloudTrail in all regions with log file validation enabled. Deliver logs to an S3 bucket in a dedicated logging account (separate from workload accounts) and enable S3 Object Lock to prevent deletion. Check 11: Enable AWS GuardDuty in all regions. GuardDuty analyses CloudTrail, VPC Flow Logs, and DNS logs using ML models to detect threats like credential compromise, cryptomining, and exfiltration. It costs roughly $1–3 per million events and is the single highest-ROI SOC 2 control in AWS.

CC7.3 requires responding to identified threats. Check 12: Configure GuardDuty findings to route via EventBridge to SNS and then to PagerDuty or Slack so on-call engineers are notified within minutes. Check 13: Enable AWS Security Hub and subscribe to the CIS AWS Foundations Benchmark standard (v1.4 or v3.0). Security Hub aggregates findings from GuardDuty, Inspector, Macie, and Config and provides a compliance score. Export this score monthly as audit evidence. Check 14: Set up CloudWatch metric filters for the five CIS alarm recommendations: root account usage, unauthorized API calls, MFA console sign-in without MFA, IAM policy changes, and S3 bucket policy changes.

Network and VPC Controls (CC6.6, CC6.7)

CC6.6 (boundary protection) requires controls at network entry and exit points. Check 15: Enable VPC Flow Logs on all VPCs and deliver to CloudWatch Logs or S3. Flow logs provide evidence that network traffic is monitored. Check 16: Ensure no security groups have inbound rules allowing 0.0.0.0/0 on port 22 (SSH) or 3389 (RDP) — use the Config rule `restricted-ssh` and `restricted-rdp`. Check 17: Place all production databases in private subnets with no public IP addresses. Verify with the Config rule `no-unrestricted-route-to-igw`.

CC6.7 requires protecting against unauthorized network access. Check 18: Enable AWS Network Firewall or AWS WAF in front of public-facing applications. WAF should have rules for OWASP Top 10, rate limiting (to prevent brute force), and geo-blocking if your customer base is regional. Check 19: Enable AWS Shield Standard (free, automatic) for all ALBs and CloudFront distributions. Upgrade to Shield Advanced for applications with strict A1.1 availability requirements. Check 20: Use VPC endpoints (PrivateLink) for AWS service access from within your VPC so that traffic to S3, DynamoDB, and SSM does not traverse the public internet.

Data Protection and Encryption (CC6.1, C1.1)

C1.1 requires that confidential information is protected. Check 21: Enable S3 default encryption on all buckets using AWS KMS with a customer-managed key (CMK). Use the Config rule `s3-default-encryption-kms`. Check 22: Enable S3 Block Public Access at the account level — this is a single toggle in S3 console under Block Public Access settings and prevents any bucket from becoming public regardless of bucket policy. Check 23: Enable EBS encryption by default in all regions used. This is an account-level setting under EC2 → EBS → Encryption.

Check 24: Enable RDS encryption at rest on all database instances. This must be set at creation time — you cannot enable it on a running unencrypted instance (you must take a snapshot, copy with encryption, and restore). Check 25: Enable SSL/TLS enforcement on RDS parameter groups by setting `rds.force_ssl = 1` for PostgreSQL and `require_secure_transport = ON` for MySQL. Check 26: Use AWS Secrets Manager for all database credentials, API keys, and service passwords — do not store secrets in environment variables in ECS task definitions or Lambda environment variables without encryption.

Availability Controls (A1.1, A1.2)

A1.1 requires that the system maintains agreed-upon capacity. Check 27: Enable AWS Compute Optimizer and review recommendations quarterly. For Auto Scaling groups, set minimum capacity to at least 2 instances across 2 Availability Zones. Configure CloudWatch alarms on CPU, memory (via CloudWatch agent), and request count to trigger scale-out before capacity is exhausted. Check 28: Enable AWS Health Dashboard notifications via EventBridge to receive proactive notification of AWS infrastructure events affecting your resources.

A1.2 requires backup and recovery capabilities. Check 29: Enable AWS Backup with a backup plan covering all RDS instances, EBS volumes, DynamoDB tables, and EFS file systems. Set retention to 35 days minimum, with monthly backups retained for 1 year. Enable cross-region backup copy for disaster recovery. Check 30: Test restore procedures quarterly and document results. AWS Backup provides restore testing jobs natively — configure automated restore testing and save the test results as audit evidence.

Change Management (CC8.1)

CC8.1 requires that changes to infrastructure are authorised, tested, and documented. Check 31: Enforce infrastructure-as-code by attaching an SCP (Service Control Policy) in AWS Organizations that denies `ec2:RunInstances`, `rds:CreateDBInstance`, and similar creation actions from the AWS Console for production accounts. All production changes must go through a Terraform or CloudFormation pipeline with a pull request approval step. This is the single most impactful change management control and provides continuous audit evidence through your Git history.

Supplement this with AWS CloudTrail data events on critical API calls and a CloudWatch alarm that fires when any change is made outside your IaC pipeline. Export the Config configuration timeline for all resources as supporting evidence in your audit package — it shows auditors every configuration state change with a timestamp and the IAM principal that made it.

Automating Evidence with Security Hub

AWS Security Hub aggregates findings from GuardDuty, Inspector v2, IAM Access Analyzer, Macie, Firewall Manager, and Config. Enable the CIS AWS Foundations Benchmark standard and the AWS Foundational Security Best Practices standard. Security Hub maps its controls directly to NIST 800-53 and PCI DSS, but you can manually map its control IDs to SOC 2 TSC criteria in your compliance platform.

For SOC 2 automation, export Security Hub findings to an S3 bucket on a nightly schedule using EventBridge Scheduler + Lambda. This gives you a timestamped evidence file showing your compliance posture on each date of your audit period. Auditors increasingly accept Security Hub exports as primary evidence for CC7.2, CC7.3, and CC6.x controls, reducing the need for manual control screenshots.

Set a target of 90% or higher Security Hub score before your audit window opens. Any critical or high findings that remain open for more than 30 days should have documented exceptions with business justification and compensating controls — auditors want to see that you have a process for managing known risks, not that you have zero findings.

Full 31-Item AWS SOC 2 Checklist

IAM: (1) Root MFA enabled, no root API keys. (2) IAM password policy — 14+ chars, complexity, 24-gen reuse prevention. (3) MFA for all human IAM users. (4) No inline IAM policies. (5) IAM Access Analyzer — resolve external sharing findings. (6) EC2 instance roles, no embedded access keys. (7) Disable access keys unused 90+ days. (8) IAM Identity Center for centralised lifecycle. (9) EventBridge alert on direct-user policy attachment.

Logging/Monitoring: (10) CloudTrail all-regions, log validation, S3 Object Lock. (11) GuardDuty enabled all regions. (12) GuardDuty findings routed to on-call. (13) Security Hub with CIS benchmark. (14) CloudWatch alarms for five CIS recommendations.

Network: (15) VPC Flow Logs all VPCs. (16) No 0.0.0.0/0 on SSH/RDP. (17) Databases in private subnets. (18) WAF on public endpoints. (19) Shield Standard on ALBs/CloudFront. (20) VPC endpoints for AWS services.

Data Protection: (21) S3 KMS encryption default. (22) S3 Block Public Access account-level. (23) EBS encryption by default. (24) RDS encryption at rest. (25) RDS SSL/TLS enforcement. (26) Secrets Manager for all credentials.

Availability: (27) Auto Scaling min 2 AZs, CloudWatch alarms. (28) AWS Health Dashboard notifications. (29) AWS Backup plan — 35-day retention, cross-region copy. (30) Quarterly restore tests with documented results.

Change Management: (31) SCP blocking console changes to production — all infra via IaC pipeline with PR approval.