SOC 2 Scope: How It’s Defined

When preparing for a SOC 2 audit, defining the scope is one of the most critical and often-misunderstood elements. Clients frequently ask what “scope” means in this context, and why it matters.

Understanding scope is essential for delivering a meaningful SOC 2 report that meets stakeholder expectations and provides assurance around the systems and services in use. 

Earlier standards like SAS 70 and FRAG 21 were criticized for giving organizations too much flexibility in setting the boundaries of their reports. Companies could highlight what they did well while omitting areas that raised concerns—without having to disclose what was left out or why.

SOC 2 tightened these rules, but the definition of scope remains a key limitation and area of discretion. Ultimately, a SOC 2 report is only as useful as the scope it covers.

At its core, the SOC 2 scope should include the systems and services your customers rely on. That typically means:

Client agreements often offer helpful insight into what customers depend on, but because SOC 2 reports are designed for a broad audience, they usually exclude highly customized or client-specific services. They also omit anything deemed immaterial to users.

Once the service boundaries are defined, the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and/or Privacy) must be applied to the relevant systems.

If your service depends on third-party vendors, such as AWS, Google Cloud, or Microsoft Azure, they are considered sub-service organizations. These vendors often provide infrastructure, backup, and other key functions.

You must identify whether these sub-service organizations are included in your report using either the “carve-in” or “carve-out” method. Most SOC 2 reports use the carve-out approach, meaning the third party’s controls are excluded from your report, even though your system depends on them.

For example, suppose your SaaS platform is hosted on AWS. In that case, their infrastructure controls are critical to your service delivery but are likely not included in your SOC 2 audit unless you explicitly choose to “carve them in.”

Complementary User Entity Controls (CUECs) outline the responsibilities of your customers. Even if a system is fully within the report’s scope, some control objectives may depend on end users taking specific actions.

For instance, if your system provides access controls, users are still responsible for managing access rights within their organization. If they fail to do so, it could lead to security breaches—even if your controls are functioning as designed

Ultimately, management defines the scope of a SOC 2 report. That flexibility allows organizations to align the report with their service offerings and risk profile, but they must disclose the boundaries clearly and fairly. The service auditor then evaluates whether the scope is appropriate and accurately presented.

While organizations can choose to include only some of their services, they cannot “cherry-pick” within a selected service. Once a service is in scope, all relevant components must be included.

Want help defining or optimizing your SOC 2 scope? Contact us to speak with our compliance experts and ensure your SOC 2 report meets the needs of your customers and stakeholders.