What SOC 2 Auditors Actually Ask for From Your AWS IAM Configuration

Why IAM Is the Center of Gravity for SOC 2 Evidence

AWS IAM configuration touches more SOC 2 Trust Services Criteria than any other single component of a typical SaaS company's infrastructure. CC6.1 (logical access), CC6.2 (authentication), CC6.3 (least privilege), CC6.6 (network access), and CC7.2 (monitoring) all have IAM-specific evidence requirements. For companies running most of their infrastructure on AWS, a thorough IAM review satisfies a significant portion of the total evidence request list.

The flip side is that IAM evidence is also among the most time-consuming to gather manually. The IAM console does not export a single report that covers all of these criteria. Evidence collection requires multiple exports from different IAM features, cross-referencing across them, and sometimes augmenting with CloudTrail data to show historical context. Without automation, a competent engineer spends 6–10 hours assembling a complete IAM evidence package before an audit.

This article covers exactly what auditors ask for, which control it maps to, and the best way to gather it.

The Standard IAM Evidence Request List

1. IAM Credential Report (CC6.1, CC6.2)

The credential report is typically the first IAM request in any SOC 2 PBC list. It is generated directly from the IAM console (or via aws iam generate-credential-report) and shows every IAM user with: password status and age, access key ages, MFA device status, and last sign-in and access key usage dates.

Auditors use this report to verify CC6.2 (multi-factor authentication): every active user with console access should have MFA enabled. They also check for stale access keys (keys not used in 90+ days suggest credential hygiene issues) and accounts with access that should have been deprovisioned (last sign-in dates that predate recent terminations).

What takes the longest without automation: The credential report is a point-in-time snapshot. If an auditor asks for evidence covering the full observation period — not just the current state — a single report is insufficient. Demonstrating quarterly credential reviews requires either quarterly report exports stored with dates, or a platform that captures credential state on a regular schedule.

2. IAM User and Role Listing with Policy Attachments (CC6.1, CC6.3)

This request asks for a complete list of IAM users and roles with their attached policies and group memberships. The purpose is to evaluate least privilege (CC6.3): is each user and role scoped to the minimum permissions needed for their function? Auditors look for users or roles with AdministratorAccess or wildcarded (*) action policies that are not clearly justified by function.

Gathering this manually requires running aws iam list-users, aws iam list-roles, and for each entity, aws iam list-attached-user-policies / aws iam list-role-policies. Assembling it into a readable format takes time. Auditors typically want to see this as a cross-referenced table, not a series of JSON outputs.

3. IAM Access Analyzer Findings (CC6.3, CC6.6)

AWS IAM Access Analyzer identifies resources in your account that are accessible from outside your AWS organization or account — S3 buckets, IAM roles with external trust policies, Lambda functions with resource-based policies permitting external access, and similar configurations. Each finding represents a potential unintended external exposure.

Auditors use Access Analyzer findings for CC6.3 (is access scoped appropriately?) and CC6.6 (are network and logical access controls preventing unauthorized external access?). The evidence they want to see is not just the current finding list but evidence that findings are reviewed and resolved within a defined timeline — typically 30 days for findings classified as high risk.

4. Root Account MFA and Access Key Status (CC6.2)

The AWS root account is a special case. Best practice and SOC 2 CC6.2 requirements both specify that the root account should have MFA enabled and should not have active access keys. Auditors verify this specifically and separately from the credential report, because the root account is not included in the standard IAM credential report output.

Gathering this evidence requires checking the Security status section of the AWS console's IAM dashboard, or querying the Account Summary via the AWS CLI. The evidence is simple to gather — it is a screenshot or API response confirming MFA enabled and zero active access keys — but it is a specific request that needs to be prepared.

5. Password Policy Configuration (CC6.1, CC6.2)

The IAM account password policy specifies minimum length, complexity requirements, expiry period, and history requirements. Auditors check this against your documented password policy to confirm they match. Mismatches — a documented policy requiring 12-character passwords while the IAM policy only enforces 8 — are a finding.

aws iam get-account-password-policy returns the current policy in a format suitable for evidence. The evidence bundle should include both the IAM policy output and the relevant section of your access management policy for comparison.

6. CloudTrail Log Verification (CC7.2)

CC7.2 covers monitoring of security events. For AWS environments, this primarily means CloudTrail: auditors want to see that CloudTrail is enabled across all regions, that management events are logged, and that log integrity validation is enabled. They also check that CloudTrail logs are stored in a bucket with appropriate access controls (not publicly readable, with MFA delete enabled, and with server-side encryption).

aws cloudtrail describe-trails returns the trail configuration. aws cloudtrail get-trail-status confirms that logging is active and shows the last successful delivery to S3. Auditors typically ask for both, plus a sample of log file validation outputs showing that logs have not been tampered with.

7. GuardDuty Status and Findings Review (CC7.2, CC7.3)

Amazon GuardDuty provides continuous threat detection for CloudTrail events, VPC flow logs, and DNS logs. Auditors ask for evidence that GuardDuty is enabled in all active regions and that findings above a defined severity threshold are being reviewed. For CC7.2, the key evidence is that monitoring is active. For CC7.3, the key evidence is that detected threats are being evaluated and responded to.

The evidence bundle typically includes: confirmation of GuardDuty enablement per region, a findings summary for the audit period with severity distribution, and for any high-severity findings, evidence of the review and response action.

8. VPC Security Group Rules and Network ACLs (CC6.6)

CC6.6 covers logical and physical access controls at the network level. For AWS, this means VPC security groups and network ACLs. Auditors look for security groups with inbound access from 0.0.0.0/0 (unrestricted) on sensitive ports — particularly port 22 (SSH), port 3389 (RDP), database ports, or any port not clearly documented as intentionally public.

aws ec2 describe-security-groups exports all security groups with their inbound and outbound rules. For a large environment, this is a significant amount of data. Auditors typically ask you to identify which security groups have public inbound rules and provide a justification for each — not to review every rule individually.

As covered in detail in our article on configuration drift and SOC 2 compliance, security group rules are among the most commonly modified controls and the most frequently flagged for drift during audits.

9. S3 Bucket Access Policies and Public Access Block Settings (CC6.6)

For companies storing customer data or compliance evidence in S3, auditors check that buckets are not publicly accessible and that bucket policies do not grant unintended access. AWS provides account-level and bucket-level Public Access Block settings that prevent public ACLs and policies even if a bucket policy is misconfigured.

Evidence includes: the account-level Public Access Block status, a listing of buckets used for customer data or evidence with their ACL and policy status, and for any bucket with a resource-based policy, the policy reviewed for unintended access grants.

10. KMS Key Management and Rotation (CC6.7)

CC6.7 covers the protection of data in transit and at rest, including cryptographic key management. For AWS environments using KMS, auditors check that customer-managed keys (CMKs) exist for sensitive data stores, that key rotation is enabled, and that key access policies are appropriately scoped. Automatic key rotation should be enabled for CMKs managing customer data — AWS rotates these keys annually when enabled.

The Time Cost Without Automation

A realistic estimate for gathering all of the above evidence manually, for a moderately complex AWS environment (2–4 accounts, 20–50 IAM users, 50–100 security groups), is 6–10 hours per audit cycle. This includes pulling each export, formatting it for the evidence room, cross-referencing related items, and writing up the policy comparisons.

With continuous automated collection, the same evidence package is pre-assembled at the start of fieldwork. CompliRun pulls IAM credentials reports, Access Analyzer findings, CloudTrail configurations, GuardDuty status, security group rules, S3 public access settings, and KMS key rotation status on a daily schedule. By the time fieldwork begins, the evidence room contains a complete record — not just the current state, but the history of each control throughout the observation period.

What Auditors Actually Flag as Problems

Based on patterns across first-year SOC 2 engagements, the IAM issues most likely to become audit findings are:

• IAM users without MFA enabled (CC6.2) — common in older accounts where MFA was not enforced at creation
• Access keys not rotated in 90+ days (CC6.1) — especially for automated service accounts where rotation requires engineering work
• Roles with AdministratorAccess or other broad permissions not justified by documented function (CC6.3)
• Security groups with unrestricted inbound rules on non-HTTP ports (CC6.6) — particularly database ports or SSH open to 0.0.0.0/0
• CloudTrail not enabled in all regions, or log integrity validation disabled (CC7.2)
• Root account access keys active (CC6.2) — this is a hard requirement that produces a finding every time

None of these are difficult to remediate. The challenge is identifying them before fieldwork rather than during it. Daily automated collection ensures that changes creating any of these conditions are flagged within 24 hours — not discovered during a manual pre-audit review that may happen weeks before fieldwork begins.