April 4, 2026 · Tim Fraser, Cloud Operations Lead

AWS Security Audit Checklist for SOC2 Compliance

If your company runs on AWS and a customer has asked about SOC2, you're about to learn a lot about audit evidence. SOC2 isn't a certification you pass once — it's an ongoing demonstration that your organisation handles data responsibly. And if your infrastructure lives in AWS, most of the evidence comes from how your account is configured.

Here's what SOC2 auditors actually look for in an AWS environment, and how to make sure you're ready.

What SOC2 auditors care about

SOC2 is built around five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. Most audits focus heavily on security and availability. In practice, that translates to a set of recurring questions about your AWS setup.

The auditor doesn't care which AWS services you use. They care whether you can demonstrate controls are in place — and that they've been in place consistently, not just on the day of the audit.

The checklist

1. Identity and access management

• MFA on the root account. This is non-negotiable. If your root account doesn't have MFA enabled, stop reading and go enable it now.
• MFA on all IAM users with console access. Every human user who can log into the AWS console should have MFA.
• No long-lived access keys on the root account. Root access keys should not exist. Delete them if they do.
• Least privilege IAM policies. Auditors will ask whether users and roles have only the permissions they need. Policies with "Action": "" and "Resource": "" are red flags.
• Regular access reviews. Can you show that you review who has access and what they can do? Quarterly is the typical expectation.

2. Encryption

• Encryption at rest. S3 buckets should have default encryption enabled. RDS instances should use encrypted storage. EBS volumes should be encrypted. Auditors will check.
• Encryption in transit. All public-facing endpoints should use TLS. Internal traffic between services should also be encrypted where feasible — load balancers to targets, application to database.
• Key management. If you're using KMS, auditors will want to see that key rotation is enabled and that key policies follow least privilege.

3. Logging and monitoring

• CloudTrail enabled in all regions. This is your audit trail for every API call made in your account. It should be writing to an S3 bucket with versioning and lifecycle policies.
• CloudTrail log file validation. Enable log file integrity validation so you can prove logs haven't been tampered with.
• CloudWatch alarms for critical events. At minimum: root account usage, IAM policy changes, security group changes, and failed authentication attempts.
• VPC Flow Logs enabled. Auditors want to see network-level logging, especially for VPCs containing sensitive data.

4. Network security

• No unnecessary public access. Security groups should not expose databases, SSH, or RDP to 0.0.0.0/0. Load balancers and web servers on 80/443 are fine; everything else needs justification.
• S3 buckets are private by default. Public Block Access should be enabled at the account level. Any exceptions should be documented and intentional.
• VPC architecture. Sensitive resources (databases, internal services) should be in private subnets with no direct internet access.

5. Incident response

• Documented incident response plan. Auditors will ask to see it. It doesn't need to be elaborate — it needs to be real and practiced.
• Evidence of incident detection. How would you know if an unauthorised user accessed your account? CloudTrail + alerting covers this.
• Evidence of past incidents and remediation. If you've had incidents, auditors want to see that you handled them properly and improved your controls afterward.

6. Change management

• Infrastructure changes are tracked. Whether you use CloudFormation, Terraform, or CDK, auditors want to see that changes go through a defined process — not ad-hoc console clicks.
• Deployment history. Can you show what changed, when, and by whom? Version-controlled infrastructure templates and CI/CD pipelines make this straightforward.

The evidence problem

Here's where most companies struggle: SOC2 isn't just about having controls in place today. It's about proving they were in place throughout the audit period — typically 6 or 12 months.

That means you need continuous evidence. Showing an auditor a clean IAM configuration on audit day doesn't help if you can't demonstrate it was clean in June, August, and October too.

This is what makes SOC2 genuinely difficult. It's not a technical challenge — most of the controls above are straightforward to implement. The hard part is maintaining them consistently and proving it.

How plainfra provides continuous audit evidence

This is where plainfra's weekly health reports become directly useful for SOC2. Every week, plainfra scans your connected AWS accounts with read-only access and produces a prioritised report covering security, access, encryption, and network configuration.

Each weekly report is a timestamped record of your security posture. Over a 12-month audit period, that's 52 data points showing that your controls were consistently in place — or flagging the week something drifted.

When an auditor asks "how do you monitor for overly permissive IAM policies?" or "how would you detect a public S3 bucket?", the answer is simple: plainfra checks every week and alerts on findings. Here are the reports.

Between audits, you can ask plainfra direct questions: "Which IAM users don't have MFA?", "Are all my EBS volumes encrypted?", "Show me security groups open to the internet." It makes the API calls, reads the responses, and gives you a clear answer in seconds — no console spelunking required.

The always-on monitoring means you catch configuration drift the week it happens, not eleven months later when the auditor finds it. That's the difference between a smooth audit and a scramble.