One of the first questions an engineering team asks when starting a SOC 2 program is: "do we need to export everything from AWS?" The honest answer is no — but explaining which configurations matter, which don't, and why requires understanding what auditors are actually testing against Trust Service Criteria rather than what feels like a comprehensive security export.
This post maps the specific AWS (and GCP/Azure where relevant) configurations that generate SOC 2 evidence, organized by the Trust Service Criteria they support. We're not trying to be exhaustive — AWS has thousands of configurable settings. We're trying to be accurate about what auditors ask for and why.
Logical Access Controls (CC6.1 – CC6.3)
The CC6 criteria dominate cloud infrastructure evidence requests. Auditors are testing whether only authorized entities can access your systems, whether access is granted through a controlled process, and whether it's revoked when no longer needed.
IAM Policy Configurations
The specific IAM evidence auditors request:
- User access lists with attached policies: A list of IAM users (not roles) with their directly attached policies and group memberships. Auditors sample specific users and verify their access is consistent with their job function.
- Privileged access inventory: Which IAM principals have AdministratorAccess, PowerUserAccess, or equivalent privilege levels? For each, is there a documented business justification?
- IAM access key age reports: AWS provides an IAM credential report that includes access key age, last used date, and rotation status. Stale access keys (last rotated over 90 days, never used but still active) are a consistent finding.
- Role assumption logs: CloudTrail AssumeRole events for privileged roles. Auditors look for role assumptions outside business hours or by unexpected principals as anomaly indicators.
What doesn't generate useful evidence: IAM password policy configuration screenshots. Auditors will ask whether the policy is configured correctly, but a screenshot of the policy page doesn't prove it was enforced for the observation period. You need the IAM Credential Report (which is timestamped) rather than a point-in-time configuration screenshot.
VPC and Network Segmentation
SOC 2 Type II auditors want to verify that production environments are logically separated from non-production environments. The evidence they accept:
- VPC resource listing showing separate VPCs for production, staging, and development
- Security group rules for production resources — specifically that inbound rules don't permit broad access from 0.0.0.0/0 on sensitive ports
- Network ACLs for production subnets
What generally doesn't generate SOC 2-relevant evidence: Route table configurations, Transit Gateway settings, NAT gateway configurations. These matter for security architecture but auditors testing CC6.x controls focus on access boundary configurations, not routing.
Monitoring and Anomaly Detection (CC7.1 – CC7.2)
CC7.1 requires that you detect and respond to potential security threats. CC7.2 requires monitoring for anomalous activity. The cloud configurations that generate this evidence:
CloudTrail
CloudTrail is the most important logging service for SOC 2 evidence generation. The specific configuration items auditors check:
- Multi-region trail status: Is CloudTrail enabled for all regions in your account, not just the regions where production workloads run? A gap in CloudTrail coverage for any region creates a monitoring gap that auditors will note.
- Log file integrity validation: Is CloudTrail's log file validation enabled? This setting generates hash-based integrity evidence that logs haven't been tampered with — relevant for the chain-of-custody requirement in audit evidence.
- S3 bucket policy for CloudTrail logs: Is the bucket where CloudTrail logs are stored restricted from public access, and is access to the bucket itself logged?
- CloudWatch Alarms for critical events: Are there alarms configured for unauthorized API calls, root account usage, IAM policy changes, and CloudTrail configuration changes? The AICPA has published specific alarm configurations recommended for SOC 2 programs; auditors often use these as a reference.
AWS Config
AWS Config records the history of resource configurations over time. For SOC 2, it generates evidence that specific security configurations were maintained throughout the observation period — not just on the day you pull an export. If your system description says "production S3 buckets have server-side encryption enabled," an AWS Config rule checking that configuration daily generates timestamped evidence that the control was operating consistently, not just at the moment of export.
Encryption Controls (CC6.7)
CC6.7 addresses the protection of data at rest and in transit. Cloud infrastructure evidence for this criterion:
S3 Encryption
- Default encryption settings for production S3 buckets — AES-256 or SSE-KMS. The S3 console shows the encryption configuration; an export or screenshot confirms the setting.
- S3 Block Public Access settings for production buckets. All four Block Public Access settings should be enabled for buckets containing customer data. The AWS S3 console shows this per-bucket and at the account level.
RDS / Database Encryption
- Encryption at rest status for production RDS instances. This is set at creation and can't be changed without recreating the instance — a snapshot export confirming "Encrypted: Yes" is sufficient evidence.
- SSL/TLS enforcement for database connections. RDS parameter group settings for `rds.force_ssl` (PostgreSQL) or `require_secure_transport` (MySQL) confirm that client connections must use TLS.
What Doesn't Usually Come Up
We're not saying KMS key rotation settings or ACM certificate configurations don't matter for security — they do. But auditors testing CC6.7 typically focus on storage encryption and transport encryption. KMS key rotation rates, HSM configurations, and envelope encryption architecture are more likely to come up in a specialized financial services audit than a standard B2B SaaS SOC 2.
Change Management Evidence (CC8.1)
Cloud infrastructure generates two types of change management evidence:
CloudTrail API Call History for Infrastructure Changes
When an auditor selects a sample production change — say, a security group rule modification — they may ask to see the CloudTrail record of who made the change, when, and from which API call context. This is your cloud-side change management evidence: it proves that the change happened at the stated time by the stated actor, which can be cross-referenced against your change control ticket.
Infrastructure-as-Code Change History
For teams using Terraform or CloudFormation, the VCS commit history for infrastructure configuration files is change management evidence. An auditor asking about a specific production change can trace it through: Jira ticket (approved by manager) → pull request (code review by peer) → merge commit → Terraform apply log (deployed by CI/CD pipeline). This chain is clean evidence for CC8.1 without requiring manual change log maintenance.
A Note on Evidence Export Frequency
A point-in-time export of AWS configurations on the day before your auditor arrives isn't equivalent to evidence that those configurations were maintained throughout the observation period. An IAM policy summary exported on October 14th tells you the state on October 14th. It tells you nothing about whether the same policy was in effect on April 3rd when an auditor asks about access on that date.
Continuous monitoring addresses this by generating daily or hourly configuration snapshots that are timestamped and retained for the observation period. When the auditor asks "was production S3 encryption enabled on May 18th?" the answer is retrievable from a retained configuration snapshot, not inferred from the current state. This is the specific gap between "we have good security configurations" and "we have SOC 2 evidence that those configurations were maintained continuously." The configurations may be identical — the evidence of their persistence is what makes them audit-ready.