SOC 2 Scope: How It’s Defined

Updated: Sep 20

One of the most controversial and arguably most important aspects of a SOC 2 Report is the scope.

Earlier controls reporting standards (like SAS 70 and FRAG 21) were criticised for the flexibility they allowed the company when determining the scope.

 

Many end users believed it was the content that ended up excluded from the reports that was of the most interest. The report itself was merely a description of what the company did well (and therefore wanted to showcase to its readers). No disclosure or justification was required for what was excluded, which made it hard for end users to understand why or understand what may be missing.

 

As the standards have evolved, they’ve become more stringent with scope. However, many still consider scope a limitation of controls reports.

 

Defining the Scope of a SOC2 Report

 

A SOC 2 Report should always cover the systems and services that are being used by the clients requiring assurance. Thus, the scope is informed by what those clients expect and what they are relying on the service organisation to provide.

 

Client services agreements are usually the best starting point for this information. However, since reports are usually prepared for a broad audience that has unique individual requirements, they often exclude bespoke client-specific services. The reports will also usually exclude anything considered immaterial to the end users.

 

Based on the scope of services, the SOC 2 Trust Services Criteria is required to focus on the relevant system components that support those services in line with the disclosed scope.

 

Disclosing the Scope

 

Here, I’ll focus heavily on how the scope SHOULD be disclosed in the report, rather than how it actually is. (There’s a lot of variation in the reports out there!)

 

The Introduction, Overview and/or Scope sections of a report should succinctly note the key components of the scope. This includes the Trust Service Principles of Security, Availability, Processing Integrity, Confidentiality and/or Privacy. The standard requires the report to detail the type(s) of services provided and details of the Infrastructure, Software, People, Policies and Procedures and Data relevant to those services.

 

A simple example is for a Software as a Service (SaaS) provider. The scope is typically their software application(s) offered to clients, including all the data held in it, infrastructure that hosts it and the people and procedures that support it.

 

Other sections giving further detail on the scope are the sub-service providers and complementary user entity control areas by noting the boundaries of the report coverage.

 

SOC 2 Sub-service Organisations

 

Vendors or outsourced service providers that support some of the services in the scope of the report, are classified as Sub-service Organisations. These are required to be detailed in the report so end users can determine which organisations are responsible for which components.

 

The carve-in or carve-out methods of determining scope identify whether the report includes the areas of scope performed by the Sub-service Providers. Carve-out is far more common, which is where all the Sub-service Organisation controls are excluded.

 

Eg. For many SaaS providers, other organisations like Amazon Web Services (AWS) or Microsoft Azure provide the infrastructure, backups and recovery and other support functions and without their controls supporting the infrastructure the SOC 2 criteria would not be met, however these are not included in the report.

 

SOC 2 Complementary User Entity Controls

 

Statements that clarify what is expected from users to complement the services provided by the organisation. These statements are like caveats: although an area is in scope, it may be reliant on the end user. If the end user isn't performing their part, it undermines the assurance of the report accordingly.

 

Eg. If the service organisation provides a system, it might be the responsibility of end users to ensure their system access is maintained appropriately.

 

Scope: The Bottom Line

 

When it comes down to it, the scope of a SOC 2 Report is up to management to determine. There is flexibility, but it must be clearly defined and disclosed in the report. Ultimately, management is responsible for ensuring the report meets the requirements of their end users. A benefit of the SOC 2 standard, it's quite prescriptive in the scope of Trust Services Criteria and disclosing the systems components.

 

Then, the Service Auditor is responsible for assessing whether this is fairly presented. If the auditor doesn’t believe this to be the case, they would qualify the report with a note to end readers — although in practice, that would more likely mean management would update the SOC 2 report accordingly to make its presentation fairer.

 

It is also up to the service organisation to determine what and who are covered by a report, as long as it’s not “cherry-picking”. For example, an organisation may have a range of service types; they could pick all of them, or include only a subset of these. After this choice is made, though, the organisation cannot exclude any sub-components: that would be cherry-picking the scope.

 

Looking to understand your scope?

Want to see how that works for SOC 2 and other standards?

 

Our free Readiness Assessment software identifies your scope as it relates to SOC 2 and other standards (HIPAA, ISO 27001, GDPR Consumer Data Right). In a ~60 minute assessment it guides you through everything involved with an output report to guide you to compliance.

Readiness Assessment

SOC Reporting

Have you been asked what your SOC 2 scope is? Our clients are often confused by this question. We explore what it means and how it works.