Leveraging AWS SOC 2 Reports: Building a SOC 2 Compliant SaaS

Many of our clients have built a Software-as-a-Service (SaaS) application on top of AWS and are leveraging AWS controls as part of their systems environment. One reason our clients do this is to leverage the AWS SOC 2-compliant infrastructure. Service organizations like AWS have their own SOC 2 report to provide assurance to stakeholders that the AWS infrastructure is secure and available.

Occasionally, we get asked by our clients, “AWS already has a SOC 2, do we need our own SOC 2 as well?”

The Benefits of Leveraging an AWS SOC 2 Report

Using AWS can provide a solid, compliant foundation, but it doesn’t automatically grant your organization SOC 2 compliance. Think of it like renting a well-secured office space: the building comes with top-notch physical security and environmental controls, but you’re still responsible for how you run your business inside that space.

For example, one company I worked with was overwhelmed by the daunting checklist of security controls. They discovered that AWS’s pre-certified infrastructure acted like a solid foundation—almost as if they were inheriting a house that was already built to code. With AWS taking care of physical security and network safeguards, they could shift their focus to customizing controls around their own applications.

Another practical benefit is the suite of automated tools that AWS provides. Tools such as AWS CloudTrail and Amazon GuardDuty work in the background, continuously monitoring and logging activities. Almost like having an automated assistant that never sleeps, keeping meticulous records for a SOC 2 audit. Read more about these AWS tools:

• How to Simplify SOC 2 Compliance with AWS Security Tools
• Key AWS Monitoring Tools for Security & Audit Compliance – An Auditor’s Perspective

Companies can also access a repository of AWS compliance reports on-demand called AWS Artifact and build their control frameworks on top of the AWS controls.

In short, by leveraging AWS, many companies have found that meeting SOC 2 requirements becomes less about reinventing the wheel and more about fine-tuning their specific needs on top of a robust, already-compliant platform. This human-centered approach—where technology simplifies the complexity—really makes a difference in reducing stress and focusing on what matters most: serving their customers securely.

 

What is a Shared Responsibility Model?

AWS handles the security of the cloud—infrastructure, physical security, and network maintenance. However, you’re responsible for the security of what you put in the cloud. That means if your applications or data aren’t configured properly, or if you haven’t implemented the necessary policies and procedures, you could still fall short of SOC 2 requirements.

Customer and Regulatory Requirements

Even if you rely on AWS’s secure environment, your customers or industry regulations might still require your company to demonstrate its own SOC 2 compliance. It’s about showing that you’ve got the right controls in place across the board, not just trusting the underlying infrastructure.

Tailoring Controls to Your Operations

Many companies share the experience that leveraging AWS is like having a head start—but you still need to finish the race. You need to integrate AWS’s built-in tools (like CloudTrail or GuardDuty) with your own security practices and policies. One company I spoke with mentioned that while AWS took care of a lot of the heavy lifting, they had to “add the human touch” by tailoring the controls to fit their unique operations and customer requirements.

Audit Trail and Documentation

AWS Artifact provides great documentation for AWS’s controls, but during a SOC 2 audit, auditors will also look at your internal processes. They’ll want to see how you manage access, how you handle data, and how you continuously monitor and improve your security posture. This means that even though you benefit from AWS’s SOC 2-compliant infrastructure, your company’s own practices still need to be robust and well-documented.

 

What SOC 2 Controls is AWS Responsible For?

AWS is responsible for a significant portion of the security controls that support SOC 2 compliance, operating under the “security of the cloud” side of the shared responsibility model.

Here’s a breakdown of the main areas where AWS is responsible.

Physical and Environmental Security

AWS manages the physical security of its data centers. This includes facility access controls, environmental safeguards (like fire suppression and climate control), and hardware maintenance. This layer of security ensures that the underlying infrastructure meets rigorous standards, which is a key component of SOC 2 compliance.

Network and Infrastructure Security

AWS is in charge of securing the network infrastructure, including the hardware, routers, switches, and firewalls that form the backbone of their cloud services. They also maintain the virtualization layer (the hypervisor) that supports various cloud services, ensuring that the underlying infrastructure remains secure from unauthorized access and threats. AWS is not responsible for configuring the inbound and outbound security rules associated with virtual machines in their environment.

Operational Security Controls

AWS handles many operational aspects such as patch management, system monitoring, and incident response for the infrastructure. They continuously monitor their systems and perform regular updates and security patches. These practices help ensure that the foundational systems comply with security best practices and standards.

Shared Responsibility Between AWS & SOC 2

While AWS covers these critical areas, your organization remains responsible for securing what you deploy within the AWS environment. This means that while AWS secures the “cloud,” you must secure the “in the cloud”—including managing data, configuring identity and access management (IAM), and implementing your own application-level security measures.

If you build your application on top of AWS, your company’s SOC 2 will not include the controls that are AWS’s responsibility. Those are carved out of the report and the report only covers the controls your SaaS company has in place to meet the applicable SOC 2 Trust Services Criteria.

Over the years we have come across a few SaaS companies that have gotten SOC 2 audits before clients insisted, but those are usually when the company is in an industry that is highly regulated, such as the financial industry. Most of our clients are contractually bound or required to have a SOC 2 report.

In short, you can try giving the AWS SOC 2, where requested, in lieu of your own. If it makes the security-related questions stop, then great. If not, then consider getting your own SOC 2 report.

 

Do We Save on SOC 2 Compliance With AWS?

AWS is compliant with just about every standard and regulation you can think of. Using AWS or another provider for your IaaS is a great way to leverage another service organization’s controls to build a SOC 2-compliant application. Because you have utilized AWS, the number of applicable SOC 2 controls covered in your report will be less than if you were responsible for those controls yourself. A good audit firm will pass along the time savings associated with testing fewer controls and you should receive a savings on fees for your SOC 2 report.

If you have other subservice providers that are required to meet some of the SOC 2 criteria as they relate to your SaaS, then those may be carved out of the report as well so that the only controls that are included, are those that are your own SaaS company’s responsibility as they relate to the applicable SOC 2 criteria.

AWS SOC 2 Report Related FAQs

The following are questions we commonly get from clients when preparing for their AWS SOC 2 engagements.

What is a Service Organization vs. a Subservice Organization?

What is a Service Organization?

The AICPA published a white paper describing service organizations as the following: “Entities often use business relationships with other entities to further their objectives. Network-based information technology has enabled, and telecommunications systems have substantially increased, the economic benefits derived from these relationships. For example, some entities (user entities) can function more efficiently and effectively by outsourcing tasks or entire functions to another organization (service organization). A service organization is organized and operated to provide user entities with the benefits of the services of its personnel, expertise, equipment and technology…”

What is a Subservice Organization?

ISACA published a blog describing subservice organizations, “When an enterprise selects a subservice organization, it needs to understand how the subservice organization’s operations can or will affect the enterprise and how it processes, stores and maintains any shared sensitive information. A subservice organization is a vendor whose controls and operational health affect the client organization’s operations. All subservice organizations are vendors; however, all vendors are not subservice organizations. An understanding of this relationship is typically gained through an assessment—specifically, a third-party risk analysis.” You could also think of subservice organizations as the entities that service organizations outsource some of their operations to.

An example is a company that offers its clients a SaaS solution that is hosted by an infrastructure-as-a-service (IaaS) provider, which provides physical security, environmental control, and monitoring services for the SaaS company. In this case, the SaaS company is the service organization and the IaaS is the subservice organization.

What is a Carve-Out Report?

The carve-out audit method allows a service organization to describe services performed by a subservice organization within its system description, but excludes the subservice organization’s controls within the service organization’s SOC 2 report. While this approach excludes subservice organizations’ controls, the service organization is required to note (within its description of its “system”) the controls used to effectively monitor the subservice organization.

How Do You Monitor Subservice Organizations?

One of the recent updates provided within the AICPA’s SSAE 18 omnibus guidance includes additional monitoring of subservice organizations.

Service organizations should ensure they have monitoring controls for subservice organizations in place. The monitoring should include obtaining SOC 1 reports and SOC 2 reports from subservice organizations and reviewing the controls and results of control testing in the reports.

If a SOC report is not available from a subservice organization, reviews could include reviewing and reconciling output reports, holding discussions with the subservice organization, site visits to the subservice organization, and testing controls at the subservice organization by members of the service organization’s internal audit function, etc.

Navigating AWS SOC 2 Requirements for Your SaaS Compliance

It is customary for SaaS companies to use subservice organizations such as Amazon AWS as an IaaS provider. In these cases, the SaaS company has outsourced the performance of certain controls to a subservice provider. The controls outsourced to AWS may also address some of the SOC 2 criteria. In that case, the service organization (SaaS company) should monitor the subservice organization to ensure that they are performing the controls related to SOC 2 requirements consistently. This can be accomplished by reviewing AWS’s SOC 2 report and the relevant areas to your SaaS service.

The controls needed to meet the SOC 2 requirements that are your company’s responsibility should be included within a separate SOC 2 report. Please contact us at Linford & Company if you would like to discuss your adoption of a subservice organization and the impact that might have on the scope and fees associated with your SOC 2 audit.

This article was originally published on 8/15/2018 and was updated on 3/26/25.