How to Verify Your AWS Environment for SOC 2: The Checks That Actually Matter

When you're preparing for SOC 2 — or just trying to answer an enterprise security questionnaire honestly — “is our AWS environment secure?” is too vague to act on. SOC 2 isn't a single switch; it's a set of Trust Services Criteria, and your AWS configuration either supports them or it doesn't.

This guide walks through the AWS checks that actually map to the SOC 2 Common Criteria, organized by what an auditor (or a procurement team) is really asking. It's written to be useful whether you verify these by hand or with tooling.

CC6: Logical and physical access controls

This is the largest bucket and the one questionnaires probe hardest. It's about who and what can access your systems, and how that access is restricted.

Encryption at rest.Check that S3 buckets have default encryption enabled, EBS volumes are encrypted, RDS instances have encryption on, and that you're not relying on someone remembering to tick the box per resource. The common failure isn't “we don't encrypt” — it's one or two resources that slipped through without it.

Encryption in transit.Confirm load balancers enforce TLS, CloudFront distributions require HTTPS, and that you're not serving anything sensitive over plain HTTP with no redirect.

Identity and access management. This is where most environments have real findings:

• No IAM users with AdministratorAccess attached directly (use roles and groups, least privilege).
• MFA enabled on all human users, especially anyone with elevated access.
• Access keys rotated — keys that haven't been rotated in 90+ days are a classic finding.
• No overly permissive policies granting * actions on * resources.

Network exposure. Security groups that allow unrestricted inbound access (0.0.0.0/0) on sensitive ports, S3 buckets that allow public access, RDS instances reachable from the internet — these are the findings that turn into questionnaire red flags.

CC7: System operations and monitoring

This is about detecting and responding to issues — can you see what's happening in your environment?

Logging.CloudTrail enabled across all regions (a single-region trail is a common gap), with log file validation on. Without comprehensive audit logging, you can't answer “how would you detect a breach?” honestly.

Monitoring and alarms.CloudWatch alarms for the security-relevant events — root account usage, IAM policy changes, unauthorized API calls, S3 bucket policy changes, network configuration changes. Auditors and questionnaires increasingly ask whether you'd know if these happened.

CC8: Change management

How do changes get made, and what stops a bad one?

On the AWS side this includes things like infrastructure being managed declaratively rather than clicked together by hand, and controls around how production configuration changes. It overlaps heavily with your source-control practices (branch protection, required reviews) — which is why verifying SOC 2 posture means looking at both your cloud and your code workflow, not just one.

CC6 again, but for secrets

Worth calling out separately because it's so often missed: secrets should be in a secrets manager (AWS Secrets Manager or Parameter Store with encryption), with rotation enabled where possible — not hardcoded in environment variables, AMIs, or, worse, source code. A questionnaire asking “how do you manage secrets?” expects a real answer here.

The honest hard part: keeping it current

Here's what makes this genuinely difficult, and why a one-time audit isn't enough. You can verify all of the above today, fix the findings, and feel good — and then next week someone spins up an unencrypted bucket, or attaches an admin policy directly, or opens a security group to debug something and forgets to close it. Your SOC 2 posture isn't a state you reach; it's a state you maintain.

This is also why answering a security questionnaire from memory is risky. The honest answer to “is your data encrypted at rest” is whatever your environment is actually configured as right now — which may differ from what it was when you last checked.

Verifying this without doing it all by hand

You can check every item above manually through the AWS console and CLI, and for a small environment that's a reasonable afternoon. The challenge is doing it thoroughly, repeatedly, and mapping each finding back to the specific SOC 2 criterion it affects — which is the part that makes the results actually useful for an audit or a questionnaire.

This is the problem ComplyReady was built to solve: it connects to AWS read-only, runs these checks (and many more) automatically, maps each to its SOC 2 criterion, and can answer security questionnaires from the verified results rather than from a guess. It's free in open beta if you want to try it — but whether you use it or a script of your own, the principle is the same: verify against your real configuration, map to the criteria, and keep it current. That's what turns “we think we're secure” into something you can defend in front of an auditor or an enterprise buyer.

A short checklist to start

If you do nothing else, verify these first — they're the highest-signal findings:

1. Any S3 bucket allowing public access
2. Any IAM user with AdministratorAccess attached directly
3. MFA missing on any human user
4. CloudTrail not enabled in all regions
5. Unencrypted RDS instances or EBS volumes
6. Security groups open to 0.0.0.0/0 on sensitive ports
7. Access keys older than 90 days

Each of these maps to a SOC 2 Common Criterion, and each is the kind of thing an enterprise security questionnaire will ask about — directly or indirectly. Fixing them is the fastest way to move your real posture (and your honest answers) in the right direction.