5 AWS Misconfigurations That Will Fail Your SOC 2 Audit (And How to Fix Them in 10 Minutes)

I review AWS environments for SOC 2 readiness regularly. The same misconfigurations show up every single time. Not obscure edge cases — basic settings that get missed because nobody told the team they were required.
All of them are fixable in under 10 minutes once you know about them. The problem is most teams find out during the audit, when time pressure makes everything worse.
Here are the ones to check right now.

1. MFA Not Enforced on IAM Users

The most common finding by a wide margin. Teams create IAM users, set passwords, and move on. MFA gets added when someone thinks to ask about it, which is often never.
SOC 2 requires MFA for all users with console access. No exceptions.
To check, generate a credential report from the IAM console under Credential report. Download it and look for any row where mfa_active is false and password_enabled is true. Those are your findings.
Also check the root account separately. Go to IAM and look at the Security status section on the dashboard. Root MFA is its own control and auditors check it specifically.
Fix it by going to IAM, selecting each affected user, opening the Security credentials tab, and assigning a virtual MFA device. For the root account, sign in as root and do the same from Account settings.

2. CloudTrail Not Enabled in All Regions

Most teams enable CloudTrail when they set up their account — in us-east-1 — and forget about it. If you have ever run workloads in another region, even briefly, you have a gap in your audit trail.
SOC 2 auditors want multi-region CloudTrail with log file validation enabled. These are two separate settings and both get checked.
To verify, go to CloudTrail in the AWS console, open your trail, and check whether Multi-region trail is enabled. Then check that Log file validation is also on. If either is missing, edit the trail and enable both.
Log file validation creates a digest file that proves your logs have not been tampered with. Auditors specifically ask for this. It takes one click to enable and there is no reason not to have it on.

3. S3 Buckets Without Encryption

Encryption at rest is required for any S3 bucket holding customer or sensitive data. Most teams have it on their main application buckets but miss the ones created quietly by other services — log buckets, backup buckets, buckets spun up by infrastructure tools with default settings.
To find unencrypted buckets, go to S3 in the console, open each bucket, go to the Properties tab, and look at Default encryption. Any bucket showing that encryption is not enabled is a finding.
Fix it by opening the bucket, going to Properties, scrolling to Default encryption, clicking Edit, and enabling SSE-S3 or SSE-KMS. Do this for every bucket that holds anything sensitive.

4. GuardDuty Not Enabled

GuardDuty is AWS threat detection. It watches CloudTrail, VPC flow logs and DNS logs for suspicious activity. SOC 2 auditors treat it as a required monitoring control.
A lot of teams know about GuardDuty but have not turned it on because it never made it into the sprint. It takes about two minutes to enable.
Go to GuardDuty in the AWS console and click Enable GuardDuty. Do this in every region you operate in — GuardDuty is region-specific and a trail that only covers one region is incomplete.
Having GuardDuty enabled is not enough by itself. Auditors will ask whether you have a process for reviewing findings. Set up an SNS notification so you get alerted when something is flagged, even if you review it manually. That shows intent, not just a checkbox.

5. Security Groups Open to the World

Unrestricted inbound access on sensitive ports is one of the most serious findings. Port 22 open to 0.0.0.0/0 means anyone on the internet can attempt SSH connections against your instances. The same goes for database ports like 3306, 5432 and 27017.
To check, go to EC2, open Security Groups, and filter for rules with source 0.0.0.0/0. Port 80 and 443 open to the world is expected for web servers. Everything else needs a justification or needs to be restricted.
The fix for SSH is to restrict it to your office IP range or a VPN CIDR. Better yet, use AWS Systems Manager Session Manager instead of direct SSH. It eliminates the need to open port 22 entirely and gives you a full audit trail of every session, which auditors appreciate.

Running These Checks Continuously

The checks above take 30 to 45 minutes to run manually across a single account. For SOC 2 Type II you need to run them continuously over 6 to 12 months and keep dated evidence of each run. That is where doing it manually stops being practical.
If you want a quick point-in-time check right now, there is a free open source CLI called trailscan that runs 35 SOC 2 checks across your AWS account and gives you a readiness score in about 2 minutes. No signup, no cloud connection, works with your existing AWS credentials.
https://github.com/1amplant/trailscan

For continuous monitoring with dated evidence, automated executive summaries and the full audit preparation workflow, that is what TrailProof is built for.