SOC 2 on AWS: The Controls That Actually Matter

SOC 2 doesn’t dictate a control list — but if you run on AWS, the auditor’s questions map to a very predictable set of AWS capabilities. The good news: AWS gives you almost everything you need natively, and a compliance automation platform can pull most of the evidence straight from your account. The bad news: teams waste weeks reinventing controls or buying tools for things IAM, CloudTrail, and Config already do. Here’s what actually matters, mapped to the Trust Services Criteria an auditor will test.

IAM and least privilege

This is the control auditors probe hardest, because access is where breaches happen.

Enforce MFA everywhere — root, all human users, and privileged roles. Lock the root account away entirely and don’t use it for daily work.
No long-lived IAM users for humans. Use federated SSO (IAM Identity Center / your IdP) so access is centrally granted and revoked. Workloads use IAM roles, not access keys.
Least privilege in practice — scope policies to what a role needs, not *. Use permission boundaries and SCPs in AWS Organizations to cap blast radius.
Evidence the auditor wants: a current list of who has access to what, proof MFA is enforced, and that offboarded employees lost access promptly.

Logging and monitoring

You can’t attest to security you can’t see. Three services do most of the work:

CloudTrail — enable across all regions, log to a dedicated, locked-down S3 bucket, and turn on log file validation. This is your audit trail of who did what.
AWS Config — records resource configuration and change history, and evaluates it against rules (e.g., “no public S3 buckets,” “encryption enabled”). This is gold for continuous-compliance evidence.
GuardDuty (threat detection) and Security Hub (aggregated findings against CIS/AWS best-practice benchmarks) — turn both on. Security Hub’s benchmark scores double as evidence of ongoing monitoring.
Route alerts somewhere a human sees them — CloudWatch alarms and findings into your incident channel, not a dashboard nobody opens.

Encryption

Straightforward on AWS, and auditors expect it by default:

At rest: enable encryption on S3, EBS, RDS, and backups — use KMS with sensible key policies. Default-encrypt new resources via account settings and Config rules.
In transit: enforce TLS. Terminate at ALB/CloudFront, redirect HTTP→HTTPS, and use ACM for certificate management and rotation.
The control the auditor tests isn’t “do you encrypt” but “can you prove encryption is enforced everywhere” — which is exactly what a Config rule gives you.

Backups and availability

Relevant especially if you scope the Availability criterion:

Automated, tested backups — RDS automated backups/snapshots, AWS Backup for centralized policy, versioning on critical S3 buckets.
Prove restores work. A backup you’ve never restored is a hope, not a control. Periodic restore tests are the evidence.
Disaster recovery appropriate to your SLAs — multi-AZ at minimum, documented RTO/RPO. Don’t over-engineer multi-region if you don’t promise it.

Change management

Auditors want assurance that code reaching production is reviewed and traceable.

Everything through version control and CI/CD. No console cowboy-deploys to production.
Pull requests with required review and branch protection — this is your change-management control, and the PR/merge history is the evidence.
Infrastructure as code (Terraform/CloudFormation/CDK) so infra changes are reviewed the same way and drift is detectable via Config.
Separate environments with restricted production access.

Vulnerability management

Amazon Inspector for automated scanning of EC2, container images (ECR), and Lambda against known CVEs.
Scan images in the pipeline before they ship, and patch on a defined cadence.
Dependency scanning (Dependabot/your SCA tool) for application-layer vulns.
The control is having a documented process — how findings are triaged, prioritized, and remediated within a target window — not zero vulnerabilities.

Access reviews

The recurring control teams forget until the auditor asks:

Periodic access reviews — typically quarterly — where an owner confirms each person’s access is still appropriate, and stale access is revoked.
Onboarding/offboarding tied to your IdP so access grants and revocations are consistent and logged.
This is a Type II favorite: the auditor wants to see reviews happened every period, not once before the audit.

The pragmatic play

You don’t need a security vendor for most of this — you need to turn on and configure what AWS already offers, then wire evidence collection to a compliance platform (Vanta, Drata, Secureframe, and similar) that reads your AWS account, GitHub, and IdP directly. That combination covers the majority of a Security-scoped SOC 2 with minimal custom work.

Prioritize in this order: IAM/MFA and offboarding first (highest risk, most-tested), then logging (CloudTrail + Config + Security Hub), then encryption enforcement, then the recurring processes — access reviews, change management, vuln scanning, backup tests. Get those solid and the auditor’s checklist mostly answers itself.

Which AWS services map to which SOC 2 controls?

If it helps to see the mapping directly, this is how the auditor’s questions line up with AWS capabilities:

Access control & least privilege → IAM, IAM Identity Center (SSO), permission boundaries, Service Control Policies, AWS Organizations.
Logging & audit trail → CloudTrail (who did what), AWS Config (resource state and change history), VPC Flow Logs (network visibility).
Monitoring & threat detection → GuardDuty, Security Hub (CIS/AWS benchmark scoring), CloudWatch alarms.
Encryption → KMS for at-rest, ACM + ALB/CloudFront for TLS in transit, Config rules to prove enforcement.
Change management → CodePipeline/CI/CD, source control with required PR review, CloudFormation/Terraform/CDK for infrastructure as code.
Vulnerability management → Amazon Inspector (EC2, ECR images, Lambda), plus dependency scanning in your pipeline.
Backup & availability → AWS Backup, RDS automated snapshots, S3 versioning, multi-AZ deployments.

Notice that almost every row is a service you already have access to. SOC 2 on AWS is far more about configuring and evidencing native services than about buying new tools.

The AWS SOC 2 evidence you’ll actually be asked for

An auditor doesn’t accept “we enforce MFA” — they want an artifact. Knowing what evidence looks like up front saves weeks of scramble. Expect to produce:

A current access list — who has access to what, exported from IAM Identity Center or your IdP, with proof MFA is enforced.
Offboarding proof — tickets or logs showing that departed employees lost access promptly.
CloudTrail configuration — showing it’s on across all regions, delivering to a locked-down bucket with log file validation.
Config rule results — e.g., “no public S3 buckets” and “encryption enabled” evaluating as compliant over time. This is gold because it’s continuous evidence, not a one-time screenshot.
PR/merge history — demonstrating that production changes went through review.
Access review records — signed-off quarterly reviews, not a single pre-audit cleanup.
Inspector findings and remediation tickets — showing your triage process runs on a cadence.
Restore-test evidence — proof a backup was actually restored, not just taken.

The teams that pass smoothly are the ones whose compliance platform (Vanta, Drata, Secureframe, and similar) reads these directly from AWS, GitHub, and their IdP — so evidence accrues automatically instead of being reconstructed under deadline.

Does AWS being SOC 2 compliant make my startup compliant?

No — and this is the single most common misconception. AWS’s own SOC 2 report covers the security of the cloud: their data centers, hardware, and the managed services themselves. Under the shared responsibility model, you are responsible for the security in the cloud — how you configure IAM, whether you enforce encryption, how you manage change, whether you run access reviews. Your auditor examines your controls, not Amazon’s. You can inherit and reference AWS’s compliance for the underlying infrastructure (their reports are available through AWS Artifact), but that inheritance covers only the physical and infrastructure layer. Everything above it — your account configuration, your code pipeline, your people processes — is yours to control and evidence.

Frequently asked questions

Does running on AWS make me SOC 2 compliant? No. AWS’s SOC 2 covers the security of the cloud — their infrastructure and managed services. Under the shared responsibility model, your SOC 2 audit examines the controls you configure in the cloud: IAM, encryption, logging, change management, and access reviews. AWS gives you a compliant foundation, not a compliant company.

What are the most important AWS controls for SOC 2? In priority order: IAM with MFA everywhere and prompt offboarding (highest risk and most heavily tested), then logging with CloudTrail, AWS Config, and Security Hub, then enforced encryption via KMS and TLS, then the recurring processes — quarterly access reviews, change management, vulnerability scanning, and tested backups.

Do I need extra security tools for SOC 2 on AWS? Usually not. Most of what an auditor asks for is native to AWS — IAM, CloudTrail, Config, GuardDuty, Security Hub, KMS, and Inspector already cover the bulk of a Security-scoped SOC 2. The one addition worth it for a small team is a compliance automation platform to collect evidence from AWS, GitHub, and your IdP automatically.

Can I use AWS’s compliance reports as evidence for my own audit? You can reference AWS’s SOC 2 (available through AWS Artifact) to cover the underlying infrastructure layer under the shared responsibility model. But it only covers Amazon’s responsibilities — your auditor still tests and requires evidence for every control you own on top of AWS.

Is AWS Config required for SOC 2? It’s not strictly mandated — SOC 2 prescribes no specific tools — but Config is close to indispensable in practice because it produces continuous evidence that resources stay compliant (encryption on, no public buckets) over time, which is exactly what a Type II auditor samples across the observation window.

If you’re running on AWS and staring down a SOC 2 request, my fixed-scope SOC 2 Readiness Sprint turns your existing AWS account into audit-ready evidence — so you implement the controls that matter and skip the ones that don’t.