Search “AWS SOC 2 compliance” and you hit an immediate confusion: AWS already has its own SOC 2 report. So are you done? No — and this is the single most expensive misunderstanding in a SOC 2 audit. AWS’s SOC 2 covers AWS’s own data centers, hardware, and managed-service operations. It says nothing about how your organization has configured AWS. Under the shared responsibility model, everything you build in your account — IAM policies, S3 bucket settings, encryption, and logging is entirely on you, and that is exactly what your auditor samples.
So “AWS SOC 2 compliance” really means two things: (1) configuring AWS so its security controls satisfy the relevant Trust Services Criteria, and (2) continuously proving they stayed configured across your audit window. This guide covers both — the exact settings, and how to generate the evidence automatically instead of screenshotting it the week before fieldwork. For the platform landscape, see our SOC 2 compliance software guide; for the control list, the SOC 2 controls breakdown.
AWS is responsible for security of the cloud; you are responsible for security in the cloud. Your SOC 2 auditor only tests the second half. AWS’s SOC 2 report (downloadable from AWS Artifact) is evidence you can inherit for the physical and infrastructure layer — include it as a sub-service organization report. Everything above the hypervisor is yours to configure and prove.
Work these in order. Each is a control your auditor will sample evidence for across the whole observation window — not just on audit day.
.webp)
*:* grants.0.0.0.0/0 on sensitive ports (22, 3389, database ports).
Below is what Strac Comply continuously checks in your AWS account. The difference from a checklist tool: Strac Comply doesn’t ask you to attest that a control exists — it runs the test against your live AWS environment every day, and the pass/fail result is the audit evidence. The connection that proves the control is the connection that catches it drifting.
And because Strac Comply runs on Strac’s data security platform, the data-protection control (CC6.7) isn’t just attested — sensitive data in AWS is discovered, classified, and protected, and that enforcement is the evidence. The same edge makes Generative AI DLP and MCP security evidence continuous. See the full platform in the SOC 2 compliance software guide.
Strac Comply runs the AWS tests above every day and turns each result into live SOC 2 evidence — plus DSPM that finds sensitive data across S3 and RDS. Stop screenshotting the console.
Related integration SOC 2 guides: GitHub SOC 2, Google Workspace SOC 2, Microsoft 365 SOC 2.
Yes — AWS maintains its own SOC 1, SOC 2, and SOC 3 reports for its infrastructure and managed services, available through AWS Artifact. But that does not make your AWS account SOC 2 compliant. Under the shared responsibility model, your IAM, S3, encryption, and logging configuration is yours to secure and prove.
Partially. You include AWS’s report as a sub-service organization (carve-out/inclusive) report to cover the infrastructure layer your auditor doesn’t directly test. You still must demonstrate your own controls for everything you configure in the account.
AWS Audit Manager (prebuilt SOC 2 framework), AWS Config (drift detection), CloudTrail (activity logging), GuardDuty (threat detection), and KMS (encryption). These cover detection; they don’t protect your data or auto-generate the continuous evidence — a platform like Strac Comply does that.
Configuration is days to a few weeks; the SOC 2 Type II observation window is then 3–12 months of continuous evidence. See the SOC 2 Type II checklist for the full timeline.
Publicly accessible S3 buckets and over-permissioned IAM. Enable account-level S3 Block Public Access and enforce least-privilege IAM with MFA to close the two most-cited findings.
.avif){kind=icon}
.gif)
