AWS Security Checklist for SOC 2: The Complete Guide
Your AWS configuration is one of the first things auditors will examine. IAM policies, S3 encryption, CloudTrail logging — here's exactly what they expect and how to fix every gap.
AWS is the infrastructure backbone for most SaaS startups, and SOC 2 auditors know it. They will ask pointed questions about your IAM configuration, encryption posture, logging setup, and access management. Unlike application-level security, most AWS compliance gaps are configuration issues you can fix in a day — if you know what to look for.
This guide covers the six AWS controls that auditors examine most frequently, with specific instructions for each one. These map directly to the AICPA Trust Services Criteria, primarily CC6 (Logical and Physical Access Controls) and CC7 (System Operations).
1. IAM Password Policy
Your AWS account's IAM password policy defines the minimum complexity and rotation requirements for all IAM users. Auditors check this because it maps to CC6.1 — you need to demonstrate that access credentials meet a defined security standard.
What auditors look for
- Minimum password length of 14 characters (12 is the absolute minimum most auditors accept)
- Require at least one uppercase letter, one lowercase letter, one number, and one symbol
- Password expiration set to 90 days or less
- Prevent password reuse for at least 24 previous passwords
- Allow users to change their own passwords
How to fix it
Go to IAM > Account settings > Password policy > Edit. Set each parameter to meet the requirements above. This is a single configuration page — it takes less than 5 minutes. The change applies immediately to all new passwords; existing passwords are not retroactively checked, but the policy will enforce the rules on the next password change or rotation.
Evidence to collect
- Screenshot of the IAM password policy configuration page showing all parameters
- AWS CLI output: aws iam get-account-password-policy (save as JSON)
2. MFA Enforcement
Multi-factor authentication on AWS is the single most impactful security control you can enable. It maps to CC6.1 and CC6.6, and auditors will specifically check whether the root account and all IAM users with console access have MFA enabled.
What auditors look for
- Root account has a hardware or virtual MFA device attached
- All IAM users with console access have MFA enabled
- Service accounts (programmatic-only) do not have console access enabled
- IAM policy requiring MFA for sensitive operations (optional but impressive)
How to fix it
For the root account: Sign in as root, go to Security credentials > Assign MFA device. Use a virtual MFA app like Authy or Google Authenticator. For IAM users: Each user enables their own MFA under My Security Credentials, or an admin can enforce it by attaching an IAM policy that denies all actions except MFA setup until MFA is configured.
Evidence to collect
- IAM Credential Report export (CSV) showing MFA status for all users
- Screenshot of root account security credentials showing MFA device assigned
3. S3 Encryption at Rest
All S3 buckets should have default encryption enabled. This maps to CC6.7 (restricting access to data at rest) and is one of the easiest controls to verify and fix. Since January 2023, AWS encrypts all new S3 objects with SSE-S3 by default — but auditors still want to see explicit encryption configuration, and older buckets may not have it.
What auditors look for
- Default encryption enabled on every S3 bucket (SSE-S3 minimum, SSE-KMS preferred)
- No unencrypted objects in any bucket (check existing objects, not just the default setting)
- Bucket policies that deny unencrypted uploads (defense in depth)
How to fix it
For each bucket: S3 > Select bucket > Properties > Default encryption > Edit > Enable SSE-S3 (or SSE-KMS if you need key management). To enforce encryption at the policy level, add a bucket policy that denies s3:PutObject requests where the x-amz-server-side-encryption header is missing. This prevents any client from uploading unencrypted objects, regardless of the default setting.
Evidence to collect
- Screenshot of default encryption settings for each bucket
- Bucket policy JSON showing encryption enforcement (if applicable)
- AWS CLI output: aws s3api get-bucket-encryption --bucket BUCKET_NAME for each bucket
4. S3 Public Access Blocking
Public S3 buckets are one of the most common causes of data breaches in cloud environments. Auditors will check both the account-level public access block and the per-bucket settings. This maps to CC6.1 and CC6.3.
What auditors look for
- Account-level S3 Block Public Access is enabled (all four settings turned on)
- Each individual bucket also has Block Public Access enabled
- No bucket policies that grant public read or write access
- No ACLs that grant public access
How to fix it
First, enable the account-level block: S3 > Block Public Access settings for this account > Edit > Enable all four checkboxes. Then verify each bucket individually. If you have a legitimate public bucket (for a static website, for example), document it with a business justification — auditors accept intentional public access if it is documented and scoped appropriately.
Evidence to collect
- Screenshot of account-level Block Public Access settings
- Per-bucket public access configuration screenshots
- Documentation of any intentional exceptions with business justification
5. CloudTrail Logging
CloudTrail is your audit trail for all API activity in your AWS account. Without it, you have no visibility into who did what and when — and auditors have no evidence to review. This maps to CC7.1, CC7.2, and CC7.4 (system monitoring, anomaly detection, and incident analysis).
What auditors look for
- CloudTrail is enabled in all regions (not just your primary region)
- Management events are logged (read + write)
- Trail logs are stored in a dedicated S3 bucket with versioning and encryption
- Log file validation is enabled (to detect tampering)
- Trail has been active for the entire audit observation period (critical for Type 2)
How to fix it
Go to CloudTrail > Create trail. Enable it for all regions, log management events (both read and write), store logs in a dedicated S3 bucket with encryption enabled, and turn on log file validation. The entire setup takes about 10 minutes. The cost is minimal — most startups spend less than $5/month on CloudTrail for management events.
Evidence to collect
- Screenshot of CloudTrail configuration showing multi-region, log file validation, and encryption
- S3 bucket configuration for the CloudTrail log bucket
- AWS CLI output: aws cloudtrail describe-trails
- Sample log entries showing recent API activity
6. IAM Access Key Management
Long-lived IAM access keys are a significant security risk. Auditors check for stale keys, keys assigned to users who no longer need them, and the absence of a key rotation policy. This maps to CC6.1 and CC6.2.
What auditors look for
- No access keys older than 90 days without documented justification
- No access keys assigned to the root account
- Users with multiple active access keys have a documented reason
- Unused access keys (no activity in 90+ days) are deactivated or deleted
- A documented key rotation process exists
How to fix it
Generate an IAM Credential Report (IAM > Credential Report > Download). Review the access_key_1_last_used and access_key_2_last_used columns. Deactivate any key that has not been used in 90+ days. Rotate any key older than 90 days by creating a new key, updating your applications, and then deactivating the old one. Delete root account access keys immediately — there is no legitimate use case for them.
Evidence to collect
- IAM Credential Report showing key ages and last-used dates
- Documentation of your key rotation schedule and process
- Confirmation that no root account access keys exist
Putting It All Together
These six controls cover the core of what SOC 2 auditors examine in your AWS environment. The good news is that most of them are configuration changes — not engineering projects. A senior engineer can close all six gaps in a single focused day.
The key is to fix these before engaging an auditor. Remediating gaps during active fieldwork is expensive (auditors bill hourly for the extra time) and extends your timeline. Run a gap analysis first, fix everything, then kick off the audit with a clean environment.