If your company runs critical systems or stores customer data on Amazon Web Services (AWS), understanding the AWS SOC 2 report is essential. This third-party audit document is a valuable compliance asset, but can also be a source of confusion.

Many organizations assume that using AWS, or any SOC 2 compliant cloud service provider (CSP), means they’re already covered for their own SOC 2 compliance. In reality, AWS’s SOC 2 report can support and help meet your compliance efforts, but not replace them.

In this article, we’ll unpack what the AWS SOC 2 report covers, how to use it to streamline your own audit, and the broader topic of shared responsibility in cloud compliance so you can leverage CSPs while still meeting security and compliance requirements.

What does the AWS SOC 2 report include?

The AWS SOC 2 report includes detailed descriptions of the:

• System architecture and services covered
• AWS control environment, including:
• Logical and physical access controls
• Change management processes
• Incident response procedures
• Data protection measures
• Complementary user entity controls
• Auditor’s test results over the evaluation period
• Auditor’s opinion

It’s important to note that AWS’s SOC 2 report only applies to AWS-managed services, not customer-deployed applications or configurations. 

Does this mean AWS customers are automatically SOC 2 compliant?

No, and this is a common misconception.

Using a SOC 2 compliant cloud provider like AWS does not make your organization SOC 2 compliant. 

The AWS SOC 2 report shows that AWS has implemented strong security and availability controls for the infrastructure and services it manages. But your own organization is still responsible for:

• Securing your applications and workloads hosted in AWS
• Managing user access and permissions
• Implementing encryption, logging, and monitoring at the application level
• Defining and enforcing security policies
• Responding to security incidents

In short, AWS can help you meet some SOC 2 requirements, but you’ll still need to implement your own internal controls, policies, and procedures to meet the framework’s full criteria.

What is shared responsibility in cloud compliance?

Cloud providers like AWS follow a shared responsibility model, which outlines what the provider manages versus what you—the customer—are responsible for managing.

Here’s the high-level overview of AWS’s shared responsibility model:

• AWS is responsible for the security “of” the cloud, including the physical infrastructure that runs all of the services offered in the AWS cloud.
• The customer is responsible for security “in” the cloud, such as access controls, encryption settings, application security, and customer data protection of their AWS environment.

While the exact responsibilities of each customer will be determined by the AWS Cloud services they select, the integration of those services into their IT environment, and applicable laws and regulations, the table below shows a basic breakdown in responsibilities between AWS and the customer across services.

Note that some controls which apply to both the infrastructure layer and customer layers are shared by AWS and the customer. For a shared control, AWS provides the control implementation for the infrastructure while the customer provides their own control implementation within their use of AWS services. Take patch management for example. While AWS is responsible for patching and fixing flaws within the infrastructure, customers are responsible for patching their guest OS and applications.

Bottom line: While AWS provides a secure foundation, you’re responsible for how that foundation is used, including how securely your systems are configured and operated.

That means that the AWS SOC 2 report helps validate part of your environment, but you’re still responsible for implementing and demonstrating the controls within your scope during a SOC 2 audit, such as logging, monitoring, vulnerability management, and user access.

This is true no matter what CSP you’re using. Your responsibility may vary based on the provider, the product you’re using, the type of deployment of your tech stack, and your regulatory and customer requirements, among other factors — but if at least some of your data and workloads are in the cloud, then you’ll share responsibility with the CSP. That’s why it’s essential to find and review each CSP’s shared responsibility model, including:

• Microsoft Azure
• Google Cloud
• Digital Ocean

Why you may need the AWS SOC 2 report

Now that we understand that the AWS SOC 2 report can help, but not replace, your compliance efforts, you might be wondering what is the purpose of the report then. 

Here’s why this report matters:

• Required by your auditors: If you’re pursuing SOC 2 compliance, your auditors will want to see the AWS SOC 2 report to verify that your cloud service provider meets baseline requirements.
• Inherits security controls: As an AWS customer, you benefit from the physical and environmental security controls validated in the AWS SOC 2 report. This reduces the burden of proving certain infrastructure controls in your own audit.
• Reduces testing scope: Your SOC 2 auditor won’t need to re-evaluate AWS’s infrastructure controls already covered in the AWS SOC 2 report.
• Spells out CUECs: The AWS SOC 2 report includes a section titled Complementary User Entity Controls, which can help you determine what policies, procedures, and controls you may need to implement to satisfy the service commitments and system requirements for specific use cases.
• Supports risk assessments: Leveraging the security policies and test results detailed in the AWS SOC 2 report can help support your own control evaluations and streamline the SOC 2 readiness process.
• Builds customer trust: While this request is more common from auditors, your customers may request the AWS SOC 2 report to validate the security of your hosting provider, especially if they are in highly regulated industries like finance or healthcare. While you may not be able to share the SOC 2 report, you can share AWS’s SOC 3 report, a publicly available summary of the AWS SOC 2 report.
• Supports vendor diligence and risk management requirements: SOC 2 includes several requirements related to vendor risk in its privacy and security TSC (or the Common Criteria). For example, CC9.2 requires that the entity assesses and manages risks associated with vendors and business partners. So being able to access and review the AWS SOC 2 report can help you meet these requirements more efficiently. 
• Supports reviews of new AWS services or regions or other CSPs: Your internal team may review AWS’s SOC 2 report when evaluating new AWS services or regions, or when comparing AWS with other cloud providers.

Now that we understand the legitimate use cases for the AWS SOC 2 report, let’s walk through the steps to access it. 

How to get AWS SOC 2 Report

Getting access to the most recent AWS SOC 2 report is simple. Here are the steps to access the report:

1. Log into the AWS Management Console
2. Navigate to AWS Artifact
3. Search for “SOC 2 Type II Report”
4. Accept the NDA terms
5. Download the report for use in your SOC 2 audit prep or due diligence

Please note that you must have an active AWS account with appropriate admin permissions to access this report and any Artifact documentation.

Don’t have an active AWS account with appropriate permissions? Download our illustrative SOC 2 report example to get a sense of what this type of report covers and how long it is.