Define your SOC 2 Audit Scope
Audit scope definition is always part of any audit. The scope sets the boundaries of the audit and identifies the object in focus.
The object can include the people, data, system, or product in review. The scope definition allows the auditors to focus on an aspect of the organization rather than the whole. This is why it is important to clearly define the scope in review for your given audit.
Determining your SOC 2 audit scope requires your organization to specify the product, the data, the systems, vendors, Trust Service Criteria (TSC), and type in scope.
Read below for guidance on how to determine each scope item. A table listing each item is provided down below to use as a template for this exercise.
Product(s) in scope
This should be relatively easy. For a Software as a Service (SaaS) provider, the scope is typically the software application(s) offered to clients. Some organizations have multiple products, and it is important to define for your SOC 2 what product is in focus and what product isn’t.
Data in scope
In order to identify the data in scope, the ideal step is to focus on the type of data and people that flow through the product or service identified. For a (SaaS) provider, it’s typically all the data held in it (i.e., customer data, etc.) and the people that support it, such as vendors and employees.
Systems in scope
To identify all your systems in scope, take an inventory of all the various systems and internal controls that are critical to delivering your service or product in scope. This could include email and Slack; the key is the focus on the systems and tools that are essential in delivering your service/product. Production systems have a direct impact on your product or service in lieu of non-production systems.
For HR systems, focus on systems that manage employee onboarding and training processes. Everything else, such as time off requests and benefits, are out of scope since they are not critical to delivering service or product.
For a (SaaS) provider, it’s typically all the infrastructure that hosts it and the procedures that support it, such as AWS, Github, JIRA, etc.
Vendors in scope
In order to identify the vendors in scope, focus on the critical vendors such as cloud hosting production-related companies used to support the product or service in scope
Trust Service Criteria (TSC) in scope
In order to identify which of the TSCs to include, it is important to understand what they are. As a reminder (and previously described in the SOC 2 Overview guide), SOC 2 is composed of five TSCs for evaluating and reporting on the robustness of an organization’s systems and policies.
The five TSCs are:
- Security (Required): Demonstrates to an auditor that your systems are protected against unauthorized access and other risks that could impact your organization’s ability to provide services to your clients.
- Availability (Optional): Applicable when organizations need to demonstrate that their systems meet a certain standard of high availability.
- Confidentiality (Optional): Applicable to organizations that need to demonstrate that data classified as confidential is protected.
- Processing integrity (Optional): Applicable to organizations that must demonstrate that system processing is occurring accurately and in a timely manner.
- Privacy (Optional): Included when a service organization is in possession of personal information to demonstrate this information is protected and handled appropriately.
Only the SOC 2 Security TSC is required. The remaining four are optional and depend on the type of commitments made to your customers in contracts or policies.
- If your organization makes any commitment regarding service availability (i.e., uptime of 90%), then the availability of TSC is a good one to add
- If your organization makes any commitments regarding the level of data encryption in place and keeping your customer’s data confidential, then the confidentiality TSC is a good one to add
- If your organization makes any commitments regarding data or financial processing, the processing integrity will likely need to be added to your scope
- If your organization creates, collects, transmits, uses, or stores personal information, you should consider adding criteria from the Privacy criteria
The decision to add the optional TSC is up to each organization and really depends on any commitments made to customers in contracts or policies.
Type 1 or Type 2?
As part of your audit, you will need to let the auditor know whether a type 1 or type 2 will be conducted.
The rule of thumb is, if this is your first SOC 2, start with a type 1, then do a type 2.
Type 1 is good for first-timers. That is because type 1 is only assessing the ‘design’ of a control and generally requires only sample documentation of one (1) for each control. A type 1 is faster to complete than a type 2.
Type 2 is assessing the effectiveness of the controls across a period of time. Expect to provide a random sample of documentation per control during a specific period.
A SOC 2 observation period is the specific duration during which the auditor is assessing your controls against the SOC 2 criteria.
This effectively means that the evidence that would be provided to your auditor would need to be within the months and year specified in your observation period.
For a SOC 2, the most common observation period are:
- 3 months
- 6 months
- 12 months
Scoping guidance template
|Provide a detailed description of your organization’s products or services.
Focus on the product or service under review
|Provide the type of data and people that flows through the product or service under review|
|Please provide the list of systems / tools that flow through or support the product or service under review|
|Please provide the list of critical vendors being used to support the product or service under review|
|Confirm your SOC 2 audit Trust Service Criteria (TSC) scope.
□ (Mandatory) Security
□ (Optional) Availability
□ (Optional) Confidentiality
□ (Optional) Processing integrity
□ (Optional) Privacy
|Confirm your SOC 2 objective:
□ Type 1 – At a point of time. Test of design only
□ Type 2 – During a review period. Test of design and operating effectiveness
|Confirm your observation period
□ 3 months (MONTH/YEAR – MONTH/YEAR)
□ 6 months (MONTH/YEAR – MONTH/YEAR)
□ 12 months (MONTH/YEAR – MONTH/YEAR)
Join the conversation