This new guidance document represents a significant evolution in how AWS frames SOC 2 compliance expectations. It provides clear mappings between Trust Services Criteria and AWS services, offers practical implementation guidance, and reinforces the critical distinction between AWS infrastructure controls and customer responsibilities. We strongly recommend that anyone involved in SOC 2 audits or implementations—auditors, assessors, GRC professionals, and AWS practitioners—read this whitepaper in full. It sets the foundation for evidence-based SOC 2 assurance in AWS environments and clarifies expectations that will shape audit programs throughout 2026 and beyond.
Download the AWS SOC 2 Compliance Guide (July 2025):
https://aws.amazon.com/blogs/security/new-whitepaper-available-aicpa-soc-2-compliance-guide-on-aws/
While AWS continues to provide strong infrastructure-level assurances, the guidance reinforces a reality auditors already know well: SOC 2 in AWS is fundamentally about customer responsibility. AWS secures the cloud. Customers must secure, configure, monitor, and prove what happens inside it.
This guide focuses on how auditors and assessors can evaluate those customer-owned responsibilities using structured, point-in-time evidence.
AWS SOC 2 in 2026: What Changed and Why It Matters
The new AWS guidance reframes SOC 2 away from checkbox compliance and toward risk-based, evidence-driven assurance. It maps SOC 2 Trust Services Criteria to AWS-native services while emphasizing that:
- AWS SOC reports cover security of the cloud
- SOC 2 audits evaluate security in the cloud, which is customer-owned
The guidance also reinforces the importance of Complementary User Entity Controls (CUECs). If customers fail to implement them, inherited AWS controls do not stand on their own.
AWS Shared Responsibility Model (Audit Context)
The AWS Shared Responsibility Model defines the boundary between AWS-managed and customer-managed controls:
- AWS responsibilities: Physical data centers, infrastructure, hypervisor isolation
- Customer responsibilities: IAM, encryption, logging, monitoring, configuration, governance
For SOC 2 purposes, nearly all Common Criteria (CC1–CC9) require customer-side evidence.
AWS Shared Responsibility Model:
https://aws.amazon.com/compliance/shared-responsibility-model/
The AWS Shared Responsibility Model clearly delineates where AWS controls end and customer obligations begin for SOC 2 audit purposes.
Key Customer-Owned SOC 2 Responsibilities in AWS
IAM Security (CC6.1, CC6.2, CC6.3)
Customers are responsible for:
- Role-based access control using AWS IAM
- Least privilege enforcement
- Cross-account trust relationships
- Credential lifecycle management
BlackBox Auditor supports point-in-time extraction and reporting of IAM users, roles, policies, permission boundaries, and trust relationships to support audit validation.
Logging and Monitoring (CC7.x)
Customers must configure and monitor:
- AWS CloudTrail
- Configuration changes
- Security events and anomalies
BlackBox Auditor provides audit-ready snapshots confirming logging scope and identifying gaps without reliance on screenshots.
Configuration and Change Management (CC5, CC8)
Customers must demonstrate:
- Change governance
- Configuration baselines
- Control enforcement consistency
BlackBox Auditor produces repeatable point-in-time configuration evidence suitable for workpapers.
SOC 2 Control-to-Evidence Mapping (AWS Focus)
The following table maps SOC 2 Common Criteria to customer responsibilities in AWS and identifies typical audit evidence requirements:
| SOC 2 Control | Customer Responsibility in AWS | Typical Audit Evidence | BlackBox Auditor Evidence |
|---|---|---|---|
| CC6.1 Logical Access | IAM roles, least privilege, segmentation | IAM screenshots, policy exports | IAM user/role inventory, effective permissions, trust relationships |
| CC6.2 User Provisioning | User lifecycle management | Access review docs, screenshots | IAM user status and credential state |
| CC6.3 Access Changes | Role modifications and approvals | Change tickets, screenshots | Point-in-time IAM configuration reports |
| CC7.1 System Monitoring | Logging and anomaly detection | CloudTrail screenshots | Logging enablement and scope reports (CloudTrail, AWS Config) |
| CC7.2 Security Events | Detection and alerting | Incident logs | Security configuration and monitoring summaries |
| CC5.1 Control Activities | Segregation of duties | Policy narratives | IAM role separation and access boundaries |
| CC8.1 Change Management | Infrastructure change control | IaC samples, screenshots | Configuration state and change evidence |
| CC9.1 Risk Mitigation | Resilience and recovery | DR plans | AWS configuration supporting resiliency |
Why AWS Native Reports Are Not Enough
AWS SOC 2 reports provide valuable assurance over AWS-managed infrastructure controls. However, they do not demonstrate:
- How IAM is implemented by the customer
- Whether customer logging is complete
- How access aligns to least privilege
Auditors must independently validate customer controls. Relying solely on AWS SOC reports creates a gap in evidence that must be closed through customer-provided documentation.
How BlackBox Auditor Supports AWS SOC 2 Audits
BlackBox Auditor is intentionally designed for point-in-time, audit-grade evidence, not continuous monitoring. It reduces ambiguity and minimizes reliance on screenshots and manual exports, producing structured outputs aligned to SOC 2 expectations.
Key capabilities:
- IAM Evidence — Complete inventory of users, roles, policies, trust relationships, and effective permissions
- Logging Validation — Confirmation of CloudTrail enablement, scope, and configuration
- Audit-Ready Format — Timestamped, reproducible evidence suitable for SOC 2 workpapers
By automating evidence collection and normalization, BlackBox Auditor allows auditors to focus on control evaluation rather than data gathering.
Final Thought
SOC 2 in AWS is no longer about explaining shared responsibility. It is about proving customer responsibility with defensible evidence.
The 2025 AWS SOC 2 guidance makes clear that customer controls must be implemented, monitored, and evidenced with the same rigor as AWS infrastructure controls. Auditors evaluating AWS environments must validate customer-owned configurations using structured, point-in-time evidence.