AWS SOC 2 Compliance: What Auditors Actually Look For

SOC 2 auditors will ask about your AWS controls. Most teams scramble because they don't know what auditors actually test, or what evidence satisfies their requirements.

Here's the uncomfortable truth about AWS SOC 2 compliance: using AWS does NOT automatically make you compliant. AWS being SOC 2 compliant means their infrastructure is compliant, not your applications running on it. Your auditor will want to see YOUR controls, using AWS SOC reports only as evidence of infrastructure compliance.

This guide shows you exactly what to prepare. By the end, you'll know which controls are your responsibility versus AWS's, what evidence auditors expect for each Trust Service Criteria, common failure patterns to avoid, and a 90-day plan to get audit-ready.

With 185 AWS services now in scope for SOC 2 (as of the Fall 2025 reports), the toolkit is comprehensive. The challenge isn't capability. It's knowing where to focus. Let's start with what auditors actually care about.

What SOC 2 Auditors Expect from Your AWS Environment

SOC 2 auditors evaluate controls across five Trust Service Criteria, with Security being mandatory for all engagements. They want evidence, not promises. Documentation and logs that prove compliance matter far more than verbal assurances about your security posture.

AWS publishes their own SOC 2 reports quarterly, covering 185 services as of the Fall 2025 report. Your job is implementing Complementary User Entity Controls (CUECs) that AWS doesn't cover. These are the specific controls you must implement to complement AWS's infrastructure controls.

Understanding this division is the first step. Let's clarify the most common misconception before diving into the details.

The #1 Misconception: AWS Compliance vs. Your Compliance

The shared responsibility model determines everything. AWS secures "of" the cloud (physical infrastructure, hypervisor, networking). You secure "in" the cloud (IAM, data encryption, application configuration, firewall rules).

When your auditor asks about data encryption, they're asking about YOUR KMS key policies, YOUR S3 bucket configurations, YOUR encryption choices. AWS's infrastructure encryption is documented in their SOC reports, but that's a foundation you build on, not a substitute for your own controls.

This distinction matters because many teams assume "we're on AWS, so we're compliant." That assumption leads to audit failures.

How to Access AWS SOC Reports via AWS Artifact

AWS Artifact is the self-service portal for accessing compliance reports at no cost. Your auditor will expect you to have reviewed these reports to understand which controls AWS handles.

To access AWS SOC reports:

1. Navigate to AWS Artifact in the console (available in US East N. Virginia and GovCloud US-West)
2. Accept the NDA if you haven't already
3. Download the relevant SOC 2 report for your audit period

Required IAM permissions: Your IAM user or role needs artifact:ListReportVersions permission. The AWSArtifactReportsReadOnlyAccess managed policy includes this.

As of December 2025, AWS Artifact now provides access to previous versions of compliance reports, helpful when auditors need historical evidence.

The Shared Responsibility Model for SOC 2

Understanding which SOC 2 controls are AWS's responsibility versus yours is critical. Misunderstanding this split leads to gaps that auditors will find.

The AICPA SOC 2 Compliance Guide on AWS whitepaper (released July 2025) provides official guidance on this mapping. I recommend downloading it as a reference alongside this guide.

What AWS Handles (Security of the Cloud)

AWS manages and secures the infrastructure from the host operating system and virtualization layer down to physical security. This includes:

• Physical and environmental controls of data centers
• Hardware, software, networking, and facilities that run AWS services
• Compute, storage, database, and networking infrastructure
• AWS-managed security controls documented in their SOC reports

Your auditor will reference AWS SOC reports as evidence for these controls. You don't need to demonstrate these, just show you're aware of and relying on them appropriately.

What You Must Implement (Security in the Cloud)

You're responsible for everything built on top of AWS infrastructure:

• Guest operating system (including updates and security patches)
• Application software and utilities you install
• Configuration of AWS-provided security groups (firewall rules)
• IAM policies and access controls
• Data encryption (at rest and in transit choices)
• Network traffic protection

These are where auditors focus their attention. Every control discussed in this guide falls into your responsibility domain.

Complementary User Entity Controls (CUECs)

CUECs are the specific controls you implement to complement AWS's controls. The AICPA whitepaper provides detailed CUEC guidance mapped to each Trust Service Criteria.

Your auditor will specifically evaluate CUEC implementation. They're looking for evidence that you understood which controls AWS provides and consciously designed your controls to complement them, not duplicate or miss gaps.

SOC 2 Trust Service Criteria and AWS Mapping

The SOC 2 framework consists of five Trust Service Categories. Security (Common Criteria CC 1-9) is mandatory for all engagements. The other four categories are optional based on your business needs and customer commitments.

Understanding how each category maps to AWS services helps you plan both implementation and evidence collection.

Security (Common Criteria)

Security is mandatory for all SOC 2 engagements. It covers access control, system operations, change management, and risk mitigation. These are the controls auditors spend the most time examining.

What auditors look for:

• IAM policies demonstrating least privilege
• CloudTrail logs showing all API activity
• Evidence of regular access reviews
• MFA enforcement for privileged accounts
• Change management procedures with approval workflows

Availability

If you've committed to uptime SLAs with customers, you'll include Availability criteria. This covers system accessibility for operation and use as committed.

What auditors look for:

• Multi-AZ deployment evidence
• Auto Scaling configurations
• CloudWatch monitoring and alerting
• Incident response documentation
• Backup and recovery test results

Processing Integrity (The Gap AWS Doesn't Cover)

This is critical: AWS explicitly does NOT include Processing Integrity in their SOC 2 scope. You are fully responsible for proving that system processing is complete, valid, accurate, and timely.

No AWS service automatically provides Processing Integrity compliance. You must design and document:

• Input validation procedures
• Transaction logging and audit trails
• Data reconciliation processes
• Error handling and correction procedures

AWS services that help (even without explicit coverage): Step Functions for workflow orchestration, EventBridge for event tracking, CloudWatch Logs for processing evidence.

Confidentiality

Confidentiality protects information designated as confidential. If you handle customer data with confidentiality requirements, you'll include this category.

What auditors look for:

• KMS key policies with least privilege
• S3 bucket encryption configurations
• RDS encryption enabled
• Secrets Manager for credential storage
• Evidence of data classification

Privacy

Privacy addresses personal information handling per your privacy notice. This often overlaps with GDPR or CCPA requirements. If you collect personal data from end users, you likely need this category.

What auditors look for:

• Data inventory and classification
• Retention policies and enforcement
• Consent mechanisms
• Data access logs
• Deletion procedures

Required AWS Security Controls

Now let's get specific about what you need to implement. Each control section includes what auditors expect to see and the evidence you should collect.

For implementation details on these controls, see our AWS security best practices guide which covers the configurations in depth.

Identity and Access Management (IAM)

IAM misconfigurations cause more audit findings than any other category. Auditors scrutinize access controls closely because they're fundamental to every other Trust Service Criteria.

Required controls:

1. Least privilege - Grant minimum permissions needed. Use IAM Access Analyzer to generate policies based on actual CloudTrail activity.

2. No root user operations - Eliminate day-to-day root usage. Enable hardware MFA. Never create access keys for root.

3. MFA enforcement - Required for all privileged accounts and console access.

4. Temporary credentials - Use IAM roles instead of long-term access keys wherever possible.

5. Regular access reviews - Remove unused permissions, users, and roles. Document review cadence.

6. Conditions in policies - Use conditions like PrincipalOrgID and CalledVia to scope access appropriately.

What auditors look for: IAM Credential Reports showing MFA enabled, CloudTrail logs demonstrating no root activity, sample IAM policies showing least privilege implementation, documentation of access review procedures.

Logging and Monitoring

Without comprehensive logging, you can't prove what happened or didn't happen in your environment. Auditors will verify logging is enabled, protected, and retained appropriately.

Required controls:

1. CloudTrail multi-region trail - Create a trail that captures events in ALL regions. Single-region trails leave blind spots. Follow CloudTrail security best practices.

2. Log file validation enabled - This provides integrity checking. Without it, you can't prove logs weren't tampered with.

3. Log encryption with KMS - Encrypt CloudTrail logs using AWS KMS.

4. Protected S3 bucket - Enable MFA delete, object lock, and strict access controls on your log bucket.

5. CloudWatch integration - Integrate CloudTrail with CloudWatch Logs for real-time alerting on security events.

6. Appropriate retention - Minimum 1 year recommended. Note that CloudTrail console history only shows 90 days.

What auditors look for: Trail configuration showing multi-region enabled, validation status, encryption key ARN, S3 bucket policy restricting access, sample CloudWatch alarms for security events.

Data Protection and Encryption

Encryption at rest and in transit protects data even if other controls fail. Auditors want to see encryption enabled by default with proper key management.

Required controls:

1. Encryption at rest - Enable default encryption for EBS, S3, RDS using AWS KMS. KMS keys are protected by FIPS 140-3 Level 3 validated HSMs.

2. Encryption in transit - TLS 1.2+ for all connections. Use AWS Certificate Manager for certificate management.

3. Customer-managed KMS keys - For fine-grained control and audit trails. Enable automatic key rotation.

4. Least privilege key policies - Keys should only be accessible by services and users that need them.

5. Separate keys for different data - Use different keys for different data classifications.

What auditors look for: KMS key policies demonstrating least privilege, encryption configuration screenshots for S3/EBS/RDS, TLS certificate evidence, CloudTrail events showing key usage.

Threat Detection and Response

Detection capabilities demonstrate security maturity. Auditors want to see that you can identify and respond to threats, not just prevent them.

Required controls:

1. GuardDuty enabled - Enable in all regions. GuardDuty continuously monitors for malicious activity using machine learning and threat intelligence.

2. Security Hub aggregation - Aggregates findings from GuardDuty, Inspector, Macie, and Config. Provides security posture dashboard.

3. Amazon Inspector - Vulnerability scanning for EC2, Lambda, and container images. Continuous scanning without standalone agents.

4. Documented incident response plan - IR plan with AWS-specific runbooks, tested regularly.

5. Automated response - EventBridge rules to trigger containment actions for critical findings.

What auditors look for: GuardDuty enabled confirmation across accounts/regions, Security Hub dashboard showing compliance scores, IR plan documentation, evidence of IR testing.

Network Security

Network controls determine what can communicate with what. Misconfigured security groups are a leading cause of breaches and audit findings.

Required controls:

1. VPC isolation - Workloads in dedicated VPCs with proper subnet segmentation (public, private, isolated).

2. Security group best practices - Stateful firewall rules. Avoid 0.0.0.0/0 on sensitive ports. Create purpose-specific groups.

3. Network ACLs - Stateless subnet-level protection as additional defense layer.

4. VPC Flow Logs enabled - Required for network traffic monitoring and forensic capability.

5. WAF protection - Protect web applications from common exploits using managed rule sets.

What auditors look for: Security group configurations showing restricted access, VPC architecture diagrams, Flow Log configuration evidence, WAF rules documentation.

Multi-Account Governance

For organizations using multiple AWS accounts (recommended), governance controls ensure consistent security across the environment. See AWS multi-account best practices for detailed implementation guidance.

Required controls:

1. AWS Organizations - Centralized management with OU hierarchy.

2. Service Control Policies (SCPs) - Define maximum available permissions at organization, OU, or account level. See AWS Organizations best practices for SCP patterns.

3. Control Tower - Automated landing zone with preventive and detective guardrails.

4. Centralized logging - Aggregate CloudTrail, Config, and Security Hub findings across all accounts to a dedicated log archive account.

What auditors look for: Organizational structure documentation, SCP examples showing guardrails, centralized logging architecture, Control Tower dashboard.

Evidence Collection Strategy

Knowing what controls you need is step one. Proving them to auditors requires systematic evidence collection. This is where many organizations struggle because they implement controls but don't collect evidence proving they work.

AWS Audit Manager automates much of this process. The prebuilt SOC 2 framework includes 15 automated controls and 46 manual controls across 20 control sets. Understanding what evidence you need helps you configure Audit Manager effectively.

AWS Audit Manager for SOC 2

AWS Audit Manager provides a prebuilt SSAE-18 SOC 2 framework. The framework includes 20 control sets aligned to SOC 2 requirements.

Setting up Audit Manager for SOC 2:

1. Enable Security Hub with all standards enabled (prerequisite)
2. Enable necessary AWS Config rules
3. Create assessment using the SOC 2 framework
4. Configure evidence sources for automated collection
5. Set up manual evidence upload procedures for non-AWS controls

Important clarification: Audit Manager controls don't verify compliance or guarantee you'll pass an audit. They organize evidence collection. You still need to ensure your controls are properly implemented and operating effectively.

Evidence collection should begin 3-6 months before your audit to demonstrate controls operating over time. SOC 2 Type 2 audits examine operating effectiveness over a period (typically 6-12 months), not just point-in-time design.

Evidence Types and Data Sources

AWS Audit Manager collects evidence from four data source types:

1. User activity (CloudTrail) - Continuous API call tracking. Select specific event names for targeted evidence.

2. Compliance checks (AWS Config) - Event-driven based on Config rule triggers. Shows resource compliance status.

3. Security findings (Security Hub) - Scheduled per Security Hub check schedule. Aggregated security posture.

4. Configuration data (API calls) - Snapshots at daily, weekly, or monthly frequency. Point-in-time resource state.

Manual evidence is still required for:

• Physical security documentation (if applicable)
• Vendor risk assessments
• Policy documents and procedures
• Training records
• Evidence from non-AWS systems

You can import manual evidence from S3, upload from browser, or enter as text directly in Audit Manager.

Automating Evidence Collection with AWS Config

AWS Config conformance packs bundle multiple Config rules for deployment. AWS provides an "Operational Best Practices for SOC 2" conformance pack template.

Benefits of conformance packs:

• Deploy standard rule sets across accounts and regions
• Compliance score showing percentage of compliant rule-resource combinations
• Automated remediation with Systems Manager Automation
• Configuration aggregators for multi-account visibility

Deploy the SOC 2 conformance pack in all accounts within your audit scope. Configure automated remediation where appropriate, but test remediation actions in non-production first.

5 Common SOC 2 Failures on AWS (And How to Avoid Them)

Learning from others' failures is cheaper than learning from your own. These patterns cause consistent audit findings. Most stem from basic misconfigurations that automated tools can detect.

Failure #1: Root User Misuse and Access Key Sprawl

TSC Mapping: Security (CC6.1 - Logical Access)

The failure: Using root user for daily operations. Root account without MFA. Sharing root credentials. Long-term access keys not rotated. Unused access keys accumulating.

Why auditors care: Root access is unlimited. No IAM policy or SCP can restrict it. Poor root controls indicate poor security culture overall.

The fix:

• Eliminate root user for all operations (use IAM users/roles)
• Enable hardware MFA on root account immediately
• Replace long-term access keys with temporary credentials via IAM roles
• Regular access key rotation (90 days maximum) and cleanup of unused keys

Evidence to collect: IAM Credential Report, CloudTrail logs showing no root activity over audit period, MFA device configuration for root.

Failure #2: CloudTrail Gaps and Missing Log Validation

TSC Mapping: Security (CC7.2 - System Monitoring)

The failure: CloudTrail not multi-region. Log validation disabled. Logs not encrypted. S3 bucket publicly accessible or with weak policies.

Why auditors care: Without integrity-validated logs, you can't prove what happened. Gaps in logging mean gaps in accountability.

The fix:

• Create multi-region trail capturing events in ALL regions
• Enable log file validation (integrity checking)
• Encrypt logs with KMS
• Protect S3 bucket with MFA delete and object lock
• Integrate with CloudWatch for real-time alerting

Evidence to collect: Trail configuration showing multi-region enabled, validation status, encryption key ARN, bucket policy with access restrictions.

Failure #3: Unencrypted Data and Weak Key Management

TSC Mapping: Confidentiality (C1.1 - Confidential Information Protection)

The failure: Data stored unencrypted. Same encryption key for all data. Overly permissive key policies. No key rotation.

Why auditors care: Encryption without proper key management provides false security. Anyone with key access has data access.

The fix:

• Enable default encryption for EBS, S3, RDS
• Use customer-managed KMS keys (not AWS-managed) for control
• Apply least privilege to key policies
• Separate keys for different data classifications
• Enable automatic key rotation

Evidence to collect: Encryption configuration for all storage services, KMS key policies showing restricted access, CloudTrail key usage events.

Failure #4: Security Group Misconfigurations

TSC Mapping: Security (CC6.6 - Logical Access Security)

The failure: Security groups allowing 0.0.0.0/0 on sensitive ports. Default security groups used without modification. Overly permissive rules for unused ports.

Why auditors care: Overly permissive network access is a leading breach vector. It indicates lack of defense-in-depth.

The fix:

• Restrict inbound rules to specific CIDR ranges
• Remove rules for unused ports
• Never use default security groups without modification
• Enable VPC Flow Logs for network monitoring
• Regular security group audits (at least quarterly)

Evidence to collect: Security group configurations showing restricted access, VPC Flow Log configuration, documentation of security group review process.

Failure #5: Missing Incident Response Capabilities

TSC Mapping: Security (CC7.3 - Security Incident Management)

The failure: No documented IR plan. GuardDuty not enabled. No automated response capabilities. Team not trained on cloud IR procedures.

Why auditors care: Incidents are inevitable. Response capability demonstrates security maturity and operational readiness.

The fix:

• Document incident response plan with AWS-specific runbooks
• Enable GuardDuty in all accounts and regions
• Configure automated containment actions via EventBridge
• Train team on cloud IR procedures
• Retain logs for forensic analysis (minimum 1 year)

Evidence to collect: IR plan documentation, GuardDuty enabled confirmation, EventBridge automation rules, training records.

Your 90-Day SOC 2 Readiness Plan

Ninety days is aggressive but achievable for organizations with an existing AWS presence and some security maturity. For organizations starting from scratch, plan 6-12 months instead.

Critical context: SOC 2 Type 2 audits examine controls operating over a period (typically 6-12 months). Even after implementing controls, you need evidence of them working consistently. Start evidence collection as early as possible.

Days 1-30: Assessment and Foundation

Week 1: Determine applicable Trust Service Categories. Review AWS SOC reports via Artifact to understand AWS's control coverage.

Week 2: Conduct gap analysis. Identify which CUECs need implementation. Use our security review checklist as a starting point.

Week 3: Define scope (AWS services and accounts). Establish multi-account strategy using AWS Organizations if not already in place.

Week 4: Enable foundational logging: CloudTrail (multi-region), AWS Config (all regions), VPC Flow Logs everywhere.

Deliverables: Scoping document, gap analysis report, multi-account architecture diagram.

Days 31-60: Control Implementation

Weeks 5-6: IAM hardening. Eliminate root usage. Enforce MFA everywhere. Implement least privilege policies. Set up regular access reviews.

Weeks 7-8: Encryption implementation. Deploy KMS keys for each data classification. Enable default encryption for all storage services.

Weeks 9-10: Threat detection deployment. Enable GuardDuty in all accounts and regions. Configure Security Hub with all relevant standards. Deploy Inspector for vulnerability scanning.

Weeks 11-12: Deploy AWS Config conformance packs for SOC 2. Configure automated remediation where appropriate. Set up configuration aggregators for multi-account visibility.

Deliverables: Implemented controls documentation, conformance pack deployment, Security Hub baseline scores.

Days 61-90: Evidence Collection and Pre-Audit

Week 13: Create AWS Audit Manager assessment using SOC 2 framework. Configure all evidence sources.

Weeks 14-15: Verify automated evidence collection is working. Gather manual evidence: policies, procedures, training records, vendor assessments.

Week 16: Control testing. Validate controls are operating effectively, not just designed correctly.

Weeks 17-18: Remediate any identified gaps. Finalize documentation. Prepare for auditor walkthrough.

Deliverables: Audit Manager assessment with collected evidence, complete documentation package, remediation log.

Preparing for the Audit

With controls implemented and evidence collected, you're approaching audit readiness. Understanding what happens during the audit helps you prepare the right materials and people.

SOC 2 audits come in two types:

• Type 1 tests control design at a point in time
• Type 2 tests operating effectiveness over a period (typically 6-12 months)

Most customers require Type 2 reports because they demonstrate controls actually work, not just that they exist on paper.

What Auditors Will Test

Auditors evaluate controls across three dimensions:

1. Control design - Is the control designed to meet the Trust Service Criteria requirements?

2. Control implementation - Is the control actually in place and configured correctly?

3. Operating effectiveness (Type 2 only) - Has the control been working consistently throughout the audit period?

They'll sample transactions and configurations across the audit period. Prepare walkthroughs for key controls and have subject matter experts available for questions.

Sample Audit Questions by TSC

Security questions:

• "Show me your access review process. Walk me through how an employee gets access and how it's revoked."
• "Demonstrate how you enforce least privilege. Show me a sample policy."
• "How do you detect unauthorized access attempts?"

Availability questions:

• "What's your uptime over the audit period? Show me incident tickets."
• "Walk me through your backup and recovery procedures. When did you last test recovery?"

Confidentiality questions:

• "How is confidential data classified and encrypted? Who has access to encryption keys?"
• "Show me your key management procedures."

Privacy questions:

• "Show me your data retention policies. How do you handle deletion requests?"
• "Where is personal data stored and who has access?"

Processing Integrity questions:

• "How do you validate data accuracy? Show me reconciliation reports."
• "What happens when processing errors occur? Walk me through an example."

When to Get Professional Help

Consider external assistance if:

• First SOC 2 audit - A readiness assessment from a qualified firm identifies gaps before the real audit
• Limited internal expertise - Your team excels at development and operations but security compliance isn't their specialty
• Tight timelines - Less than 90 days to audit with significant gaps
• Complex environments - Multi-account architectures with sophisticated compliance requirements

AWS Security Assurance Services provides compliance advisory. When selecting AWS security partners for compliance work, use our partner evaluation framework to verify their SOC 2 experience and AWS competencies. To understand what a security review engagement entails, see our AWS security review process guide. Third-party GRC platforms (Vanta, Drata, Secureframe) can accelerate evidence collection. Independent consultancies like ours provide hands-on implementation alongside guidance. See how we helped Accolade achieve SOC 2 compliance with a properly governed AWS foundation.

Conclusion: Your SOC 2 Readiness Checklist

AWS SOC 2 compliance requires understanding two things: which controls AWS provides versus which you must implement, and what evidence proves your controls work.

Key takeaways:

1. Shared responsibility is critical - AWS handles infrastructure security. You handle everything built on it. Auditors evaluate YOUR controls.

2. Processing Integrity is entirely your responsibility - AWS explicitly excludes this TSC. Plan accordingly.

3. Evidence collection takes time - Start AWS Audit Manager 3-6 months before audit to demonstrate controls operating over time.

4. Common failures are preventable - Root user controls, CloudTrail validation, encryption, security groups, IR capabilities. Address these first.

5. 90 days is achievable - With focused effort, proper tooling, and clear priorities.

Your immediate next step: Access AWS Artifact today to download AWS's SOC reports. Understand their control coverage. Identify gaps in your environment using Security Hub. That baseline tells you exactly where to focus.

For organizations wanting expert guidance, a security review identifies gaps quickly and provides a prioritized remediation roadmap. We've helped teams get audit-ready in weeks instead of months.

Frequently Asked Questions