Navigating SOC 2 Scope for a Successful Audit – Professional Insights

When discussing the SOC audit process with clients, one of the first questions we are often asked is what the scope of a SOC 2 audit is. The answer is almost always, “It depends.” This answer can often be a point of frustration for many, as there is no quick answer. This is due to several factors that must be considered when scoping a SOC 2 audit, such as the different SOC 2 Trust Services Criteria (TSCs) that can be included, the services being covered, supporting systems and processes, as well as the existing internal control environment at the service organization. In the following sections, I will answer some of the common questions asked by clients and their service auditors when scoping a SOC 2 audit.

What Is The Scope of a SOC 2 Audit?

Service organizations come in many different variations, therefore the scope of a SOC 2 audit varies as well. That being said, defining the high-level scope of a SOC 2 audit can typically be done by a service auditor after having management answer a few questions. Detailed scoping of a SOC 2 audit, on the other hand, requires more input from management, and oftentimes their service auditor, including a SOC readiness assessment in order to narrow down the scope of the audit and controls that will be tested.

The scope of the SOC 2 audit will mainly be driven by the services being covered in the report, the TSCs in scope, and the period of time being covered. Defining the services being covered in the SOC 2 report is typically the first question asked when scoping an engagement and the easiest to answer, as this is the system or service being offered by the service organization. User entities often request a SOC 2 report from the service organization over a particular system or service they offer and this is typically what kicks off the process of undergoing a SOC 2 audit.

Once the service/system has been determined, the applicable TSCs can be considered. There are five TSCs that can be included in the scope of a SOC 2, which are:

• Security (Common Criteria)
• Availability
• Confidentiality
• Processing Integrity
• Privacy

The only criteria that must be included in the scope of a SOC 2 is the security criteria, which is also referred to as the common criteria. The other criteria in scope can be determined based on the service organization’s service commitments and system requirements, as well as any specific criteria requested by user entities.

Lastly, the period of time being covered by the report (Type II) or point in time (Type I) is defined. In most cases, this decision hinges on how quickly management requires the SOC 2 report to be issued or if a customer has specific requirements that need to be met.

 

How to Determine the Scope of a SOC 2 Audit

Once the services and criteria in scope for the SOC 2 have been defined, management, with the help of their service auditor, can set forth the task of detailing specifics. This will include considering the policies, processes, systems (including subservice organizations), and people that should be included in the scope of the audit. Usually, this is done by taking a risk-based approach in order to focus on the key controls in place supporting the applicable audit criteria.

In my experience with first-time SOC 2 audits, the process of determining the detailed scope of the audit is developed throughout the initial phase of the audit when a readiness assessment is performed. During this time, the service auditor meets with management to gain an understanding of the following:

• How the in-scope system/services work.
• The policies and procedures in place.
• The systems supporting the services.
• Key vendors and subservice organizations used.
• The people/process owners involved.

By the end of a readiness assessment, the service auditor should be able to identify the controls in scope for the SOC 2 audit, including any potential gaps that should be addressed prior to the beginning of the period (Type II) or as of date (Type I) of the SOC 2 report. For more information, see our article on the differences between Type I and Type II SOC reports.

During What Phase of the Audit Is Scoping Done?

The initial scoping of a SOC 2 audit should be done in the first phase of the audit. As I stated previously, when undergoing a SOC 2 audit for the first time, defining the detailed scope of an audit is typically done as part of the readiness assessment. However, the initial scope of a SOC 2 audit can change based on changes to the service organization’s IT environment, operations, and/or services. The scope can also change based on user entity requests/requirements.

It is not uncommon for the scope of a SOC 2 audit to change after it is initially defined. Changes to scope that occur after the planning phase of the audit should be discussed with the service auditor in order to avoid any confusion around the scope of the audit or evidence needed to satisfy audit requests. The service auditor can also assist management with considering any risks or gaps that may arise due to the change in scope.

 

Other SOC 2 Audit Scope Considerations

In addition to what I have previously mentioned, there are several other scope considerations I have found helpful to discuss with clients when scoping a SOC 2 audit. One is the supporting systems and what should be considered for the SOC 2 audit scope. Oftentimes not every single system or tool used by the service organization needs to be in scope.

In my experience, the type of data stored by the system, what it does, and how integral the system is to the operation of the in-scope service/system should be considered to help define the in-scope systems. Another thing to consider is how users gain access to key internal systems and if a password management tool is used or SSO which will potentially bring another supporting system/tool into the scope of the audit.

Management of the service organization should also define whether the scope of the SOC 2 audit includes all company personnel or just a portion of them. For example, are only employees considered in scope, or are there contractors that should also be considered? Are there specific controls in scope that are applicable to only employees and others that apply to only contractors?

Lastly, determining what vendors should be included in the scope of the SOC 2 audit as a subservice organization. Typically, the service auditor can help management determine which vendors should be considered a subservice organization and how they are treated in the report (carve out vs. inclusive method).

SOC 2 Audit Scope In Summary

Though you may not have gained a straightforward answer to what the scope of a SOC 2 audit is, in this article I covered key considerations for the audit scoping process. Determining the high-level scope includes defining the in-scope services/system, TSCs, and period. Once those things are decided, the scope can be further defined by management, with a service auditor’s help, typically during a readiness assessment. Changes to the scope of a SOC 2 audit can occur after the initial planning phase of the audit based on changes in the service organization’s environment and a service auditor can assist management with navigating the definition of a SOC 2 audit scope.

For further information regarding our SOC 2 audit services, including the process we follow for scoping and completing a SOC 2 audit, contact us at the Linford & Co. website.

To learn more about the different criteria for SOC 2 audits, check out these related articles:

• SOC 2 and the Control Environment: Understanding the Criteria
• Understanding Information & Communication: Controls & Criteria for SOC 2
• The SOC 2 Risk Assessment Criteria: Through the Eyes of an Auditor
• SOC Incident Reporting: What are SOC 2 Security Reporting Requirements?
• What are Description Criteria for a SOC 2 Report?
• The SOC 2 Criteria for Monitoring Activities – Insights from an Auditor