10 AWS Misconfigurations That Fail SOC 2 Audits (And How to Fix Them)
The most common AWS security misconfigurations that auditors flag during SOC 2 reviews — with remediation steps for each.
Why AWS Misconfigurations Are the #1 SOC 2 Audit Finding
Most SOC 2 audit failures aren't policy failures — they're configuration failures. An organization has a written policy that says "MFA is required for all IAM users" but hasn't actually enforced it for a service account created two years ago. The auditor checks. The control fails.
Here are the 10 most common AWS misconfigurations that auditors find — and how to fix each one.
1. MFA Not Enforced for All IAM Users
What auditors check: Are there any IAM users with console access that don't have MFA enabled?
Why it fails: Most organizations enable MFA for their main admin accounts but forget about service accounts, legacy users, or accounts created during onboarding that never got MFA configured.
Fix: Run aws iam list-users combined with aws iam list-mfa-devices to find users without MFA. For new users, enforce MFA via an IAM policy that denies all actions if MFA is not present. Use SecureSpect's aws.iam.mfa_privileged_users check to monitor continuously.
2. Active Root Account Access Keys
What auditors check: Does the root account have active access keys?
Why it fails: Access keys for the root account give programmatic access to everything in the account with no MFA gate. Even if they've never been used, they're a critical risk.
Fix: Go to IAM → Security credentials (logged in as root) and delete all access keys. There is no legitimate use case for root access keys. SecureSpect check: aws.iam.root_mfa.
3. Access Keys Not Rotated Within 90 Days
What auditors check: Are there any active IAM access keys older than 90 days?
Why it fails: Access keys are permanent credentials that don't expire by default. Old keys may belong to users who've left the organization, or to applications that haven't been audited recently.
Fix: Run aws iam list-users and aws iam list-access-keys to find stale keys. Rotate or disable keys older than 90 days. For long-running applications, migrate from access keys to IAM roles. Monitor with SecureSpect check: aws.iam.access_key_rotation.
4. S3 Buckets Without Public Access Block
What auditors check: Are there S3 buckets that could be made public?
Why it fails: Even if a bucket is currently private, without the S3 Public Access Block setting enabled at the account level, a misconfiguration could expose it. Auditors flag the absence of this control even if no bucket is currently public.
Fix: Enable S3 Block Public Access at the account level: AWS Console → S3 → Block Public Access Settings (account level). Also enable it on individual buckets. SecureSpect check: aws.s3.public_access_block.
5. CloudTrail Disabled or Misconfigured
What auditors check: Is CloudTrail enabled in all regions? Is log file validation enabled? Are logs stored in a protected bucket?
Why it fails: CloudTrail is often enabled in the primary region but not in all regions. Log file validation (which uses SHA-256 hashing to detect log tampering) is frequently not enabled.
Fix: Ensure a multi-region trail is enabled with log file validation on. Store logs in a separate S3 bucket with access logging enabled and bucket policies that prevent log deletion. SecureSpect check: aws.cloudtrail.enabled.
6. GuardDuty Not Enabled
What auditors check: Is AWS GuardDuty enabled in all accounts and regions?
Why it fails: GuardDuty requires explicit activation per account per region. In multi-account organizations, it's common for it to be enabled in the primary account but not in member accounts.
Fix: Enable GuardDuty in all accounts and regions. Use AWS Organizations with delegated admin to manage GuardDuty centrally. SecureSpect check: aws.guardduty.enabled.
7. KMS Key Rotation Not Enabled
What auditors check: Are KMS customer-managed keys configured with automatic rotation?
Why it fails: KMS key rotation is not enabled by default for customer-managed keys. Without rotation, a key compromise exposes all data encrypted with that key forever.
Fix: For each customer-managed KMS key, enable automatic rotation (rotates annually). Note: automatic rotation is not available for asymmetric keys. SecureSpect check: aws.kms.key_rotation.
8. EKS Secrets Not Encrypted
What auditors check: Are EKS cluster secrets encrypted at rest using KMS?
Why it fails: EKS clusters don't encrypt Kubernetes secrets at rest by default. Kubernetes secrets often contain database passwords, API keys, and other sensitive credentials.
Fix: For existing clusters, enable envelope encryption for secrets using a KMS key: aws eks associate-encryption-config. For new clusters, configure it during creation. SecureSpect check: aws.eks.secrets_encryption.
9. Security Groups Allowing Unrestricted Inbound
What auditors check: Are there security groups with inbound rules open to 0.0.0.0/0 on sensitive ports?
Why it fails: Overly permissive security groups are extremely common in development environments that make it to production, or in security groups created for one-time troubleshooting that never get cleaned up.
Fix: Audit security groups with aws ec2 describe-security-groups. Flag any group with 0.0.0.0/0 inbound rules on ports other than 80/443. Enforce least-privilege network access. SecureSpect check: aws.ec2.security_group_ingress.
10. WAF Not Attached to CloudFront / ALB
What auditors check: Is AWS WAF deployed in front of public-facing web applications?
Why it fails: WAF isn't required for all workloads, but for public-facing SaaS applications processing customer data, auditors increasingly expect it. Its absence can be flagged as a control gap.
Fix: Deploy AWS WAF with an appropriate managed rule group (at minimum the AWS Managed Rules Core Rule Set) in front of your CloudFront distribution or Application Load Balancer. SecureSpect check: aws.waf.web_acl_exists.
Running All 10 Checks Automatically
SecureSpect runs all 10 of these checks automatically — plus 90+ more — every time you trigger a scan or on your configured schedule. The run-all-tests endpoint can be called from your CI/CD pipeline, and failing controls generate Jira tickets automatically.
The goal: find these issues before your auditor does.