May 15, 2026 · 4 min read
The 3 AWS Misconfigurations That Come Up on Almost Every SOC 2 Audit
After reviewing dozens of AWS environments for SOC 2 readiness, these three findings appear on nearly every assessment. All three are five-minute fixes once you know about them.
After reviewing a lot of AWS environments for SOC 2 readiness, three misconfigurations come up on nearly every assessment. They are not obscure or complex. They are all five-minute fixes. The problem is that most teams only find out about them during the audit window, when there is less time and more pressure to fix everything at once.
Here they are.
1. S3 public access is not blocked at the account level
Most engineers know to check individual bucket permissions. What they miss is the account-level S3 Block Public Access setting.
Even if every bucket has public access blocked individually, auditors want to see the account-level block enabled. It acts as a safety net — if someone creates a new bucket and forgets to configure its permissions, the account-level block catches it.
Where to fix it: AWS Console → S3 → Block Public Access settings for this account → enable all four options.
This maps to CC6.1 in the SOC 2 Common Criteria and comes up on virtually every AWS assessment.
2. CloudTrail is not enabled in all regions
Most teams enable CloudTrail in their primary region — us-east-1, eu-west-1, wherever their main infrastructure lives. What they miss is that CloudTrail needs to be active in every region, including regions they do not actively use.
The reason: an attacker who gains access to your AWS account might create resources in an unused region specifically because they know logging is sparse there. Auditors know this and check for it.
The fix is to enable a multi-region CloudTrail trail rather than regional ones. A single multi-region trail covers all current and future regions automatically.
Where to fix it: AWS Console → CloudTrail → create a trail → enable "Apply trail to all regions."
This maps to CC7.2 and is one of the most commonly flagged findings in AWS environments.
3. IAM users with console access have no MFA
This one sounds obvious but it comes up constantly. The usual culprits:
- Old service accounts that were set up with console access for convenience and never cleaned up
- Contractor accounts that were not removed after the engagement ended
- The root account itself, which still has no MFA enabled
Auditors check every IAM user with console access for MFA. All of them. Not just the active ones you use daily.
The fix has two parts: enable MFA on every active IAM user with console access, and disable or remove any IAM users that no longer need access. For the root account, enable a hardware MFA key or authenticator app immediately.
Where to fix it: AWS Console → IAM → Users → check the MFA column for each user.
This maps to CC6.1 and CC6.3 and is present in nearly every environment that has not been explicitly hardened for compliance.
All three of these are checked automatically by TrailProof on every scan. If you want to see the full picture of where your AWS environment stands before starting a formal SOC 2 assessment, the free checklist covers all 65 controls across access control, infrastructure, monitoring, and more.
Ready to check your SOC 2 readiness?
Free interactive checklist — 65 controls, saves progress, no signup required.
Open the free checklist →