AWS Security Review Before SOC 2: What Your Auditor Will Test on Your Side

An AWS security review checks how your own AWS accounts are configured: who has access, what is exposed to the internet, whether activity is logged, and whether anyone would notice an attack. Before SOC 2 it matters because AWS's own SOC 2 report covers AWS's infrastructure, not your settings. Your auditor tests your side, so a review finds the gaps first.

Why AWS's SOC 2 report does not cover you

This is the most common misunderstanding we see in SOC 2 readiness for AWS-hosted companies. The team knows AWS has a SOC 2 report, so they assume the hosting side is handled.

Part of it is. AWS describes its shared responsibility model as AWS being responsible for "protecting the infrastructure that runs all of the services offered in the AWS Cloud." Physical data centres, hardware, the hypervisor and the network underneath your account are AWS's job, and AWS's report covers them.

Everything you configure is yours. Which IAM users exist, whether the root account has MFA, which buckets are public, which security groups allow traffic from anywhere, whether CloudTrail is on: none of that is in AWS's report, because AWS does not control it. As AWS puts it, customer responsibility "will be determined by the AWS Cloud services that a customer selects."

Your SOC 2 auditor will test your side. An AWS security review is how you find out what they will see before they see it.

How to get AWS's SOC 2 report and bridge letter

You will still need AWS's report, because AWS is almost always treated as a subservice organization in your SOC 2. According to the AWS SOC FAQ:

• AWS SOC 1 and SOC 2 reports are downloaded from AWS Artifact, the self-service compliance portal in the AWS console. The SOC 3 is public on the AWS website.
• AWS issues SOC 2 reports twice a year, with periods ending March 31 and September 30. Each report covers the previous twelve months.
• AWS publishes a SOC Continued Operations Letter, also called a bridge letter, updated monthly and available in Artifact. It covers the gap between the end of AWS's last report period and today.
• The AWS SOC 2 report covers the Security, Availability, Confidentiality and Privacy criteria.

Download the current report and bridge letter, read the section listing complementary user entity controls (the things AWS says customers must do), and file both with a dated note of who reviewed them. Your auditor will ask to see that review. Our explainer on what a SOC 2 bridge letter is covers how bridge letters fit into an audit period.

Carve-out: how AWS appears in your SOC 2

Most companies use the carve-out method for AWS. Your system description says AWS provides hosting, AWS's controls are excluded from your report, and you show that you monitor AWS by reviewing its report each year. The alternative, the inclusive method, would pull AWS's controls into your audit, which almost never happens with a provider that size.

Carve-out does not reduce what you have to prove about your own configuration. It only means you are not testing AWS's data centres. Our guide to SOC 2 subservice organizations goes through the wording and the evidence in detail.

What an AWS security review checks

An AWS security review for SOC 2 focuses on the areas auditors sample and attackers use. These are the areas we work through, with the SOC 2 concern each one maps to.

Area	What we look at	Why the auditor cares
Root account	MFA on root, no root access keys, root not used for daily work	Privileged access is restricted (CC6.1)
IAM users and roles	Long-lived access keys, unused users, admin policies attached broadly, MFA for console users	Access is granted by role and removed when no longer needed (CC6.2, CC6.3)
Single sign-on	Whether people sign in through your identity provider rather than separate IAM users	Leavers lose AWS access when their main account is disabled
Logging	CloudTrail on in every region, logs stored in a protected bucket, retention period	Activity is recorded and can be reviewed (CC7.2)
Threat detection	Whether GuardDuty is enabled and whether its findings reach a person	Anomalies are detected and acted on (CC7.2, CC7.3)
Public exposure	S3 Block Public Access, security groups open to 0.0.0.0/0, public snapshots, public IPs on databases	Systems are protected from unauthorized access (CC6.6)
Encryption	Encryption at rest on storage and databases, TLS on public endpoints, key management	Data is protected in storage and transit (CC6.1, CC6.7)
Configuration baseline	Results against the CIS AWS Foundations Benchmark in Security Hub CSPM	Configuration is monitored against a standard (CC7.1)
Backups and recovery	Backup schedules, cross-region or cross-account copies, evidence of a restore test	Recovery objectives can be met (A1.2, A1.3)
Account structure	Production separated from development, guardrails across accounts	Changes to production are controlled (CC8.1)

A few of these deserve a note.

S3 Block Public Access

Since April 2023, AWS turns on S3 Block Public Access and disables ACLs by default for new buckets. Buckets created before that change keep their old settings. Companies with older accounts often find public or ACL-based buckets nobody remembers creating.

CIS AWS Foundations Benchmark

AWS Security Hub CSPM can check your accounts against the CIS AWS Foundations Benchmark, with several versions supported. Turning it on gives you a scored baseline and a list of failing checks. It is a good starting point, not the whole review: a benchmark tells you a setting is off, not whether that setting matters in your environment.

Logging that nobody reads

CloudTrail and GuardDuty being enabled is the easy part. The question auditors increasingly ask is what happens next. Who receives a GuardDuty finding? Where is the record that someone looked at it? A detection service sending alerts to an unmonitored address does not satisfy CC7. Our post on logging and audit trails for compliance covers what a reviewable log trail looks like.

The findings we see most often

Across AWS environments at growing companies, the same issues come up again and again:

1. IAM users with access keys created years ago, still active, sometimes belonging to people who have left.
2. The AdministratorAccess policy attached to most of the engineering team.
3. CloudTrail on in the main region only, or logs written to a bucket the same admins can delete.
4. A database or cache with a public IP and a security group open to the internet, set up for a quick test.
5. Development and production in the same account, so a developer's broad permissions reach customer data.
6. Backups configured but never restored, so nobody knows if they work.
7. Secrets in environment variables or code rather than a secrets manager. See secrets management for startups for the fix.

None of these are unusual, and all of them are fixable. What matters for SOC 2 is that they are fixed before your observation window starts, because an auditor testing a Type II period will sample evidence from across the whole window.

When to run an AWS security review

The best time is early in SOC 2 readiness, during or right after the gap assessment. That gives engineering time to fix findings before evidence starts counting. Running it the month before fieldwork leaves you explaining issues rather than showing they were resolved.

Other good triggers: an enterprise buyer's security questionnaire asks detailed cloud questions, you are raising money and expect technical due diligence, the team has grown quickly and nobody owns the AWS setup, or you are merging accounts after an acquisition. If you want a self-guided first pass, see our post on how to pre-audit your cloud or run the free cloud security posture check.

What an AWS security review costs

Price depends mostly on the number of AWS accounts and regions in scope, how many services you run, and whether you want help fixing findings or only the report. One production account with a staging account is a very different scope from an organization with thirty accounts.

Our AWS security review starts from $2,500 per AWS environment, using read-only access, and ends with a findings list ranked by real risk and mapped to the SOC 2 criteria your auditor will test.

Common questions about AWS security reviews

What is an AWS security review?

An AWS security review is an assessment of how your AWS accounts are configured: identity and access, public exposure, logging, threat detection, encryption, backups and account structure. It produces a ranked list of misconfigurations and fixes. It is a configuration review, not a penetration test, and usually needs only read-only access to your accounts.

Does AWS being SOC 2 compliant make my company SOC 2 compliant?

No. AWS's SOC 2 report covers AWS's infrastructure: data centres, hardware and the services underneath your account. Your IAM, network rules, logging and data handling are your responsibility under the shared responsibility model, and your SOC 2 auditor tests them separately. You use AWS's report as evidence about AWS, not about you.

Where do I download the AWS SOC 2 report?

From AWS Artifact in the AWS Management Console. AWS issues SOC 2 reports twice a year, for twelve-month periods ending March 31 and September 30. A SOC Continued Operations Letter, also called a bridge letter, is updated monthly in Artifact and covers the time since the last report period ended.

Is an AWS security review the same as a Well-Architected review?

No. An AWS Well-Architected review covers several pillars at a high level, including reliability, cost and performance. An AWS security review goes deeper on security alone, with specific findings in IAM, exposure, logging and detection, and maps them to the controls a SOC 2 or ISO 27001 auditor will test.

Do I need a penetration test as well as an AWS security review?

Usually yes, if you are pursuing SOC 2 or selling to enterprise buyers. The AWS review checks configuration from the inside with read-only access. A penetration test attacks your application and exposed services from the outside to see what can actually be exploited. They find different things, and buyers often ask for both.