SOC 2 on AWS: controls and evidence
SOC 2 on AWS is mostly CC6, CC7 and CC8: logical access, system operations and change management. Those are the criteria your AWS configuration answers. The rest of the report is about people and process.
A SOC 2 on AWS needs six things done before the observation window opens: production in its own account, people signing in through IAM Identity Center with MFA, an organization CloudTrail trail in a separate log archive account, AWS Config and Security Hub recording, KMS encryption enforced on data stores, and infrastructure changes flowing only through a reviewed pipeline. With those in place, the AWS side of the audit is mostly exporting evidence.
3 of 9 Common Criteria sections where AWS configuration carries most of the evidence: CC6, CC7, CC8
Which SOC 2 criteria does AWS configuration answer?
AWS configuration answers most of CC6 (logical and physical access), CC7 (system operations) and CC8 (change management), and part of A1 if you include Availability. CC1 to CC5, CC9 and the vendor and HR controls come from policies, people and records outside AWS. That split is why a company with a perfect AWS account can still fail a SOC 2.
| Criterion | What it asks | AWS services involved |
|---|---|---|
| CC6.1 | Logical access restricted to authorized users, encryption of data | IAM Identity Center, IAM, SCPs, KMS |
| CC6.2, CC6.3 | Access granted, changed and removed through a process | Identity provider groups mapped to permission sets |
| CC6.6 | Boundary protection against external threats | Security groups, WAF, private subnets, VPC endpoints |
| CC6.7 | Data protected in transmission | ACM certificates, TLS policies on load balancers and CloudFront |
| CC6.8 | Malicious software prevented or detected | GuardDuty, Inspector, ECR image scanning |
| CC7.1 | Configuration and vulnerability monitoring | AWS Config, Security Hub, Inspector |
| CC7.2, CC7.3 | Anomalies detected and evaluated | GuardDuty, CloudTrail, CloudWatch alarms |
| CC7.4, CC7.5 | Incidents responded to and recovered from | Runbooks, AWS Backup, snapshots |
| CC8.1 | Changes authorized, tested and approved | CodePipeline or GitHub Actions deploy roles, CloudTrail for out-of-band changes |
| A1.2, A1.3 | Capacity, backups and recovery tested | Multi-AZ deployments, AWS Backup, restore tests |
The criteria text itself is on SOC2Prep's Common Criteria guide. This page covers only the AWS side.
CC6: access on AWS
Auditors sample access in three ways: who can reach production today, how a new starter got access, and how a leaver lost it. On AWS the clean answer is federation. People exist only in your identity provider, groups map to permission sets in IAM Identity Center, and removing someone from the identity provider removes their AWS access in the same action.
- Root account. Hardware or passkey MFA on every root user, no root access keys, and an alarm on root sign-in. The IAM credential report proves the first two.
- IAM users. None for people. Service users with access keys only where a workload cannot use a role, rotated and inventoried.
- Permission sets. One per job function, with production write access held by a small group. Admin access through a separate permission set that is logged when used.
- Access review. Quarterly, exporting permission set assignments per account, signed off by a named owner. Keep the export and the sign-off together.
The general version of this, across providers, is in IAM and least privilege.
CC7: monitoring and detection on AWS
CC7 wants evidence that you watch for problems and act on them. Turning on GuardDuty and Security Hub is the easy half. The half auditors test is triage: they pick findings from the period and ask what happened to each. A Security Hub account with 400 open findings and no tickets is evidence that the control did not operate.
- Enable GuardDuty and Security Hub organization-wide from a delegated security account.
- Pick one or two standards in Security Hub, usually AWS Foundational Security Best Practices, and suppress controls that do not apply, with a written reason.
- Route high and critical findings to a ticket queue with an owner.
- Set a remediation target by severity, for example critical in 7 days and high in 30, and write it in the vulnerability management policy.
- Keep the ticket history. That is the evidence.
CC8: change management on AWS
The auditor samples production changes from the period and asks for the approval behind each one. If changes go through infrastructure as code and a pipeline, every change has a pull request with a reviewer, and the deploy role is the only principal allowed to modify production. CloudTrail then shows any change made outside the pipeline, which is exactly what the auditor looks for next.
Break-glass changes
Emergency console changes will happen. Write down how they are allowed, log them, and raise a ticket after the fact with a retrospective approval. An auditor accepts a documented exception. They do not accept a silent one.
The AWS evidence request list
These are the AWS items that appear on a typical SOC 2 request list, with where each comes from.
| Request | Source |
|---|---|
| List of AWS accounts and their purpose | AWS Organizations account list |
| Users with production access | IAM Identity Center account assignments export |
| MFA enforcement | Identity provider policy, IAM credential report for root |
| Audit log configuration | Organization trail settings, log bucket policy, retention |
| Encryption at rest | Config rules for S3, EBS, RDS encryption, with results |
| Security monitoring | Security Hub and GuardDuty enabled status, sample finding with ticket |
| Vulnerability scanning | Inspector coverage and finding history |
| Backups and restore test | AWS Backup plan, job history, restore test record |
| Change samples | Pull requests and pipeline runs for sampled deploys |
| Network diagram | Your diagram, matching VPC and security group configuration |
Evidence collection covers how to gather these without screenshots every month, and Config, Security Hub and Audit Manager covers what the native tools collect for you.
Using the AWS SOC 2 report
Download the current AWS SOC 2 Type 2 from AWS Artifact and give it to your auditor. Most auditors use the carve-out method: your report says AWS is a subservice organization and excludes its controls. Read the complementary user entity controls section. It lists what AWS expects you to do, and your auditor may ask for evidence that you do it. AWS reports are issued twice a year, so the period usually overlaps yours without a bridge letter.
Can a startup get SOC 2 on AWS without a compliance platform?
Yes. AWS Config, Security Hub, CloudTrail and a disciplined evidence folder cover the AWS controls. The work a platform saves is chasing people for access reviews, training and policy acknowledgements, which a small team can manage by hand for a first audit.
Does SOC 2 require CloudTrail in every region?
SOC 2 does not name CloudTrail. Your auditor will ask for evidence that administrative activity is logged everywhere it can happen. An organization trail covering all regions is the simplest way to show that, including regions you do not use, since an attacker might.
Should AWS be carved out or included in our SOC 2?
Carved out, in almost every case. The inclusive method would require AWS to participate in your audit, which it does not do. Your system description names AWS as a subservice organization and your auditor relies on the AWS report for its controls.
How long should we keep CloudTrail logs for SOC 2?
At least the length of the audit period plus the time to fieldwork, so twelve to fifteen months for a twelve-month Type 2. Many companies keep one year in S3 Standard and longer in a cheaper storage class with object lock.
Get quotes for SOC 2 on AWS
Readiness, account hardening or an AWS review before the audit.
Get matched