DEV Community: Raphael

The AWS Misconfigurations That Show Up on Almost Every SOC 2 Audit

Raphael — Fri, 05 Jun 2026 15:51:20 +0000

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.

I built an open-source AWS SOC 2 readiness scanner because SOC 2 prep is still too manual

Raphael — Mon, 01 Jun 2026 11:45:18 +0000

Most startups don’t fail SOC 2 because they lack security.

They fail because they don’t know what “audit-ready” actually looks like until it’s too late.

I kept seeing the same pattern over and over:

Teams already use AWS securely
They pass internal security reviews
Then SOC 2 happens… and everything breaks

Not because of major security flaws, but because of missing evidence, unclear control mapping, and manual checklist chaos.

So I built something to fix that.

The problem: SOC 2 is still an evidence problem, not a security problem

If you’ve gone through SOC 2, you probably recognize this workflow:

Pull IAM configs manually
Screenshot AWS settings
Export CloudTrail logs
Map everything into a spreadsheet
Try to match it to SOC 2 controls
Repeat across dozens of checks

And somehow this still takes weeks of engineering time.

Most of the data already exists in AWS. It’s just not structured in a way auditors can use.

That gap is where most teams get stuck.

Introducing TrailScan

TrailScan is a free, open-source AWS SOC 2 readiness scanner.

It runs locally against your AWS account and tells you:

What SOC 2 controls you’re failing
Why it matters
How severe it is
How ready you are for audit

What it does

TrailScan runs 35 automated AWS checks across:

IAM
S3
EC2
RDS
CloudTrail
GuardDuty
VPC
KMS
CloudWatch

Each check is mapped directly to SOC 2 Trust Services Criteria.

What makes TrailScan different

1. SOC 2-specific focus (not generic cloud security)

Most tools scan for “security best practices.”

TrailScan focuses specifically on SOC 2 audit readiness, which is a different problem.

2. Readiness score you can actually understand

You don’t just get findings.

You get a 0–100% SOC 2 readiness score, plus:

Pass / Fail / Warning breakdown
Control mapping
Exportable reports (JSON / CSV)

3. CI-friendly design

TrailScan is built for engineers:

Exit codes for CI pipelines
Fast execution (~2 minutes)
No SaaS lock-in
No data sent externally

4. Fully open-source

You can inspect every check.

No black box. No hidden logic.

TrailScan vs Prowler and similar tools

There are already strong AWS security tools in the ecosystem, especially open-source projects like Prowler, as well as cloud-native services like AWS Security Hub.

Here’s how TrailScan is different:

1. Purpose: SOC 2 readiness vs general security posture

Prowler / Security tools: Broad AWS security benchmarking (CIS, NIST, general best practices)
TrailScan: Narrow focus on SOC 2 Trust Services Criteria mapping

Instead of asking:

“Is your AWS secure?”

TrailScan asks:

“Are you audit-ready for SOC 2?”

2. Output: compliance narrative vs security findings

Prowler-style tools: Security findings, misconfigurations, compliance checks
TrailScan: Readiness scoring + SOC 2 control mapping

Each finding is designed to answer:

Which SOC 2 control is impacted
Why it matters in audit context
Whether it blocks certification readiness

3. Audience: security engineers vs audit-bound startups

Prowler: Security teams, cloud engineers, SecOps
TrailScan: Founders, startups, DevOps teams preparing for SOC 2

It’s optimized for a very specific moment:

“We need SOC 2 in the next few months and don’t know where we stand.”

4. Signal-to-noise ratio

Generic security tools often return hundreds of findings.

TrailScan intentionally limits scope to SOC 2-relevant checks only, reducing noise and focusing attention on audit blockers.

Why I built this as open-source first

SOC 2 tooling has a trust problem.

Security teams don’t like black boxes touching their infrastructure.

So TrailScan is intentionally:

Local-first
Read-only
Transparent
Inspectable

The idea is simple:

If you don’t trust it, you should still be able to verify it.

Who this is for

TrailScan is useful if you are:

A startup preparing for SOC 2 Type I or II
A DevOps engineer responsible for AWS security
A founder dealing with enterprise security reviews
A team that wants a quick readiness snapshot without adopting a full GRC platform

What TrailScan is NOT

It is not:

A full compliance platform
A policy generator
A continuous monitoring system
A replacement for auditors or GRC tools

It’s intentionally narrow:

A fast way to understand where you stand before SOC 2 becomes painful.

Try it out

GitHub: https://github.com/1amplant/trailscan

It takes about 2 minutes to run, and you’ll get a SOC 2 readiness report from your AWS environment.

Feedback welcome

I’m actively improving the checks and mapping.

If you’ve gone through SOC 2 before, I’d love feedback on:

Missing checks
False positives
Real audit gaps
Useful improvements

Open issues on the repo anytime.

TL;DR

TrailScan is an open-source AWS scanner that:

Runs 35 SOC 2-focused checks
Maps results to SOC 2 controls
Gives a readiness score
Exports audit-friendly reports
Runs locally in ~2 minutes

It’s built to answer one question:

“Are we actually ready for SOC 2, or about to find out the hard way?”