SOC 2 on AWS: The Controls That Get Audited

SOC 2 evidence sounds easy. Export some logs, show your access policies, prove encryption is on. And it is easy - if your AWS infrastructure is built to produce that evidence in the first place.

Most teams discover the gap during audit prep. The logs exist, but they are not centralized. Encryption is enabled, but not with customer-managed keys. IAM policies are in place, but nobody can explain who has access to what or why. The auditor asks a straightforward question and the answer takes two engineers a week to find.

We have been through dozens of SOC 2 Type I and Type II audits on AWS. We sit on the other end of the auditor's questions. This guide covers the controls that take the most time, the AWS services that satisfy them, and how to build infrastructure that makes evidence collection automatic.

The Five Controls Auditors Spend the Most Time On

SOC 2 Trust Services Criteria lists dozens of controls. In practice, auditors focus on six areas where SaaS companies fail most often. If these six are solid, the rest goes fast.

• CC6.1 - Logical access. Who has access, how they got it, and how it is reviewed and removed.
• CC6.6 - Encryption and data protection. Encryption at rest, in transit, and key management.
• CC6.7 - Network security. How your systems are protected from unauthorized network access.
• CC7.2 - Threat detection and monitoring. Can you detect problems, and can you prove you acted on them?
• CC8.1 - Change management. Every production change must be reviewed, approved, and traceable.
• A1.2 / A1.3 - Disaster recovery and backup. Can your systems recover from failure, and have you tested it?

CC6.1 - Access Control: IAM Roles, Least Privilege, and SSO

This single control usually takes 30 to 40 percent of the audit. The auditor wants to see your full identity lifecycle: how access is granted, how it is reviewed, and how it is removed when someone leaves.

On AWS, this starts with IAM. The most common mistake we see: teams using long-lived IAM access keys instead of IAM roles with temporary credentials. Auditors flag this immediately. Roles with short-lived tokens, assumed through SSO, are the baseline.

What auditors want to see: IAM Identity Center with permission sets mapped to groups, not individual users. MFA enforced on every human account. No root account usage outside of initial setup. Permission boundaries that prevent privilege escalation. Quarterly access reviews with documented sign-off - not just a CSV export, but proof that someone actually reviewed it and took action.

CC6.6 - Encryption: KMS, ACM, and Bucket Policies

Encryption at rest and in transit is a pass/fail control. Either everything in scope is encrypted, or it is not. But auditors do not just check if encryption is on - they check how it is managed.

For encryption at rest, use AWS KMS with customer-managed keys, not the default AWS-managed keys. Customer-managed keys give you key rotation control, usage audit logs in CloudTrail, and the ability to revoke access. Enable default encryption on S3 buckets, RDS instances, EBS volumes, and any other data store in scope.

For encryption in transit, use ACM to manage TLS certificates. ACM handles automatic renewal, so you do not end up with expired certificates that fail the audit. Enforce TLS 1.2 or higher on all load balancers and API endpoints. S3 bucket policies should deny any request that does not use HTTPS.

CC6.7 - Network Security: VPN, WAF, and Security Groups

Auditors want to see that your production systems are not directly exposed to the internet. This means private subnets for application and database tiers, VPN or bastion access for engineers, and clear network segmentation between environments.

AWS WAF is important, but it needs to be configured correctly. We see teams deploy WAF with default rules that either block nothing useful or block legitimate traffic. The goal is a rule set that protects against OWASP Top 10 (SQL injection, XSS, request flooding) without creating false positives that hurt your users. AWS Managed Rules are a good starting point, but you need to tune them for your application.

Security groups should follow least-privilege for network access: only the ports and sources that are needed. No security group should allow 0.0.0.0/0 on SSH or RDP. VPC Flow Logs should be enabled so you can prove to the auditor what traffic actually reached your systems.

CC7.2 - Threat Detection: GuardDuty, Inspector, and CloudTrail

Monitoring is not just dashboards. Auditors want to see that you can detect threats, that you are aware of vulnerabilities in your environment, and that you act on findings - not just collect them.

Amazon GuardDuty is the foundation. It monitors CloudTrail logs, VPC Flow Logs, and DNS queries for suspicious activity: unauthorized API calls, cryptocurrency mining, compromised credentials, unusual data transfers. Enable it in every region, not just the ones you use. Auditors will ask.

AWS Inspector scans your EC2 instances and container images for known CVEs. This is how you prove to the auditor that you are aware of vulnerabilities and acting on them. Run Inspector continuously, not just before the audit. Feed the findings into your ticketing system so there is a paper trail of remediation.

CloudTrail is non-negotiable. It logs every API call in your AWS account. Send CloudTrail logs to a centralized, locked S3 bucket with log-file validation enabled. The auditor will ask: 'Can someone delete or modify these logs?' The answer must be no. Use an S3 bucket policy that denies deletion, and enable MFA Delete if possible.

AWS Security Hub ties it together. It pulls findings from GuardDuty, Inspector, Config, and third-party tools into one view. Enable the CIS AWS Foundations Benchmark and the AWS Foundational Security Best Practices standard. These give you a compliance score the auditor can review.

CC8.1 - Change Management: From Code to Production

Every production change must be reviewed, approved, and linked to a ticket. Auditors want to trace a change from the business request to the code review to the production deploy.

What works: branch protection rules in GitHub or GitLab that require at least one approval. CI/CD pipelines that gate production deploys behind automated tests and a manual approval step. Issue keys in PR titles so every change links back to a ticket. Deploy logs retained for at least 12 months.

Infrastructure changes through Terraform should follow the same process: plan reviewed in a PR, applied through a pipeline, state file versioned and access-controlled. No manual changes in the AWS console. If the auditor sees console-based changes in CloudTrail that are not linked to a change ticket, they will flag it.

A1.2 / A1.3 - Disaster Recovery: Backups, Failover, and Proof That You Tested It

If you include Availability in your SOC 2 scope - and most SaaS companies do - the auditor will ask one question that surprises most teams: when was the last time you tested your disaster recovery plan? Not wrote it. TESTED IT.

DR starts with two numbers: RPO and RTO. Recovery Point Objective is how much data you can afford to lose. Recovery Time Objective is how long your service can be down. These two numbers decide everything: how often you back up, whether you copy data to another region, and how fast your systems can switch over. The auditor expects these numbers to be written down, approved by leadership, and matched by infrastructure that actually meets them.

On AWS, use AWS Backup to manage backup policies in one place across RDS, DynamoDB, EBS, EFS, and S3. Set backup frequency, how long backups are kept, and cross-region copy rules in a single backup plan. For RDS, turn on automated snapshots and make sure point-in-time recovery actually works - not just that the setting is enabled, but that you have restored from a snapshot and confirmed the data is correct.

For workloads that need high availability, use Multi-AZ on RDS and ElastiCache, and run your application across at least two Availability Zones behind an Application Load Balancer. If your RTO requires faster recovery, set up a standby environment in a second AWS region with Route 53 health checks that switch DNS automatically when the primary region goes down.

S3 cross-region replication keeps a copy of important data in a separate region. Combined with S3 Versioning and Object Lock, this protects against accidental deletion, ransomware, and regional outages. The auditor wants to see that your backups are stored separately from your main environment - so a single failure does not take out both your systems and your backups.

The Infrastructure is the Evidence

The common mistake is treating compliance as a documentation project. Teams write policies, collect evidence manually, and hope it is enough. It never is.

The right approach: build the infrastructure so that evidence is a byproduct of how things already work. CloudTrail logs every API call. KMS logs every key usage. GuardDuty flags every threat. Config tracks every resource change. When the infrastructure is ready, collecting evidence for the auditor takes a couple of hours - not weeks of scrambling before the audit window.

That is what we build for our customers. Not a compliance checklist, but an AWS environment where evidence is generated continuously and the next audit takes days, not months. If you want to see how this maps to your specific setup, reach out - we do a free compliance readiness check.