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.
End users of the reports 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 customers that rely on the report. Thus, the scope is informed by what those clients expect and what they are relying on the service organisation to provide to them. That's usually centered on the software system(s) they use, and where their data is processed and stored.
Client services agreements are often the best starting point for this information about their reliance on the organisation. 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, the infrastructure that hosts it, and the people and processes that support it. That's often the whole company of people for simplicity (although this can be segregated in some cases). The processes are largely informed by the criteria of the SOC 2 standard, but include software development, customer success and product management for a software company, that may not be relevant for another type of services, for example.
Other sections of the report give further detail on the scope including the material sub-service providers (like AWS, GCP or Azure that host the infrastructure), and complementary user entity controls that highlight key responsibilities of the end users of the services.
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 may undermine the ability to meet the criteria.
Eg. If the service organisation provides a system, it might be the responsibility of end users to ensure their system access is maintained appropriately. If that is not managed effectively by the end user, it may mean data breaches occur even if the organisation manages everything effectively on their end.
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.
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 (SOC 1, HIPAA, ISO 27001, GDPR, CSA STAR, Consumer Data Right and more!). In a ~60 minute assessment it guides you through everything involved with an output report to guide you to compliance.
