Define your SOC 2 audit scope

Overview

Defining the scope of a SOC 2 audit is a critical step in ensuring the process is both efficient and effective. It requires careful thought, planning, and collaboration among stakeholders, and lays the groundwork for securing your organization’s data, systems, and trust. In this article, we will explore the ins and outs of defining a SOC 2 audit scope, including the details, considerations, and best practices to help you and your team get started and remain on track.

What is SOC 2 audit scope?

SOC 2 audit scope refers to the specific systems, processes, controls, and organizational boundaries that will be evaluated during a SOC 2 examination. Instead of covering an entire company, the audit focuses on the areas that directly support how customer data is stored, processed, or transmitted. Defining the scope clearly is critical because it determines the time, cost, evidence requirements, and audit outcome. A well-defined scope ensures the audit is meaningful, aligned with business objectives, and does not become unnecessarily broad or complex.

Read below for guidance on how to determine each scope item. A table listing each item is provided below to use as a template for this exercise.

Determining the audit objectives

The first step in defining the audit scope is to articulate your audit objectives. As a compliance expert, you must consider the purpose of the SOC 2 audit, the specific requirements of your industry, and the expectations of your clients. Your audit objectives could include, for instance, solidifying security controls, improving risk mitigation strategies, or showcasing your commitment to data privacy and integrity. Additionally, the objectives may highlight areas for remediation; this proactive identification of gaps can save your organization time and resources in the long run.

Clearly stating the objectives creates a roadmap and sets boundaries that are crucial for evaluating which systems, processes, and departments need to be included in the audit. It also supports informed discussions with internal stakeholders and external auditors about the depth and breadth of the evaluation.

Product(s) in scope

In addition to defining the overall scope of the audit, it is also important to identify the specific products that are within the scope. This will help in ensuring that all aspects of these products are thoroughly assessed for compliance. For example, if a company offers multiple software applications, each application should be clearly identified as part of the audit scope. This allows for a comprehensive evaluation of the controls and processes associated with each product.

By defining the SOC 2 audit scope and identifying the products in scope, organizations can effectively plan and conduct their audits. This helps in ensuring that all relevant systems and processes are assessed for compliance with the SOC 2 standards. It also provides a clear framework for evaluating and improving security, availability, processing integrity, confidentiality, and privacy controls. Ultimately, a well-defined audit scope helps organizations demonstrate their commitment to protecting customer data and maintaining high standards of information security.

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

Data in scope for SOC 2 includes any information that impacts the trust service criteria being evaluated, such as security, availability, processing integrity, confidentiality, and privacy. This typically covers sensitive customer data, internal business data, and system-related data processed or stored by your organization. The scope also extends to third-party interactions and any data that supports your operational and compliance processes. Clearly defining the in-scope data is crucial to ensuring that your SOC 2 report addresses all relevant aspects of your organization’s information security and compliance practices.

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 to focus on the systems and tools that are essential to 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, is out of scope since it is not critical to delivering a service or product.

For a SaaS provider, all the infrastructure that hosts it and the procedures that support it, such as AWS, Github, JIRA, etc.

Vendors in scope

When conducting a SOC 2 audit, it is important to identify the vendors that are in scope for the assessment. Vendors that are in scope are those that have access to or store sensitive data or provide services that directly impact the security and availability of the systems being audited. These vendors may include cloud service providers, data centers, software-as-a-service providers, and managed service providers.

It is crucial to thoroughly assess and evaluate the security controls and practices of these vendors to ensure they meet the necessary requirements outlined in the SOC 2 framework. This helps organizations maintain a strong security posture and protect their sensitive information from potential threats and breaches.

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 and guides), SOC 2 is composed of five TSCs for evaluating and reporting on the robustness of an organization’s systems and policies.

The Trust Service Criteria (TSC) are the foundation of SOC 2 audits and provide the framework for evaluating these controls. Let’s delve into each of the Trust Service Criteria in scope:

1. Security (Required)
   This criterion assesses whether the system is protected against unauthorized access (both physical and logical), ensuring that data is safeguarded against potential breaches, theft, or damage. It includes controls related to network security, user authentication, data encryption, and incident response.
2. Availability (Optional)
   Availability measures the system’s uptime and accessibility, ensuring that it remains operational and accessible to users as agreed upon in service level agreements (SLAs). This criterion evaluates controls related to system resilience, redundancy, failover mechanisms, and disaster recovery planning.
3. Processing Integrity (Optional)
   Processing integrity ensures the accuracy, completeness, and validity of data processing, as well as the integrity of system outputs. This criterion focuses on controls related to data validation, error handling, processing accuracy, and reconciliation processes.
4. Confidentiality (Optional)
   Confidentiality addresses the protection of sensitive information from unauthorized access or disclosure. It includes controls related to data classification, access controls, encryption, data masking, and confidentiality agreements.
5. Privacy (Optional)
   Privacy assesses whether personal information is collected, used, disclosed, and disposed of in accordance with applicable privacy laws, regulations, and contractual obligations. This criterion evaluates controls related to data privacy policies, consent mechanisms, data retention practices, and individual rights management.

Each Trust Service Criterion is evaluated against predefined criteria and control objectives, with the goal of providing assurance to stakeholders regarding the effectiveness of a service organization’s controls related to security, availability, processing integrity, confidentiality, and privacy. 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.

Read TrustCloud’s SOC 2 Overview and Guides to learn more!

By undergoing SOC 2 audits and achieving compliance with the Trust Service Criteria, service organizations can demonstrate their commitment to protecting customer data and meeting the highest standards of trust and security.

For example,

1. 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
2. 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
3. If your organization makes any commitments regarding data or financial processing, processing integrity needs to be added to your scope
4. 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 need to let the auditor know whether a Type 1 or Type 2 audit will be conducted.

The rule of thumb is that if this is your first SOC 2, start with a Type 1 audit, then do a Type 2 audit.

Type 1 is good for first-timers. 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 over a period of time. Auditors expect to provide a random sample of documentation per control during a specific period.

Observation period

The observation period for SOC 2 is an essential part of the audit process. It involves the auditor observing the controls and processes in place within an organization to ensure they are operating effectively. This period allows the auditor to gather evidence and assess the design and implementation of the controls. The length of the observation period can vary depending on the complexity and size of the organization.

It is important for the organization to provide access to relevant personnel and documentation during this time to facilitate a thorough assessment. Ultimately, the observation period helps to validate the accuracy and reliability of the SOC 2 report. This effectively means that the evidence that is provided to your auditor needs to be within the months and years specified in your observation period.

For a SOC 2, the most common observation periods are:

1. 3 months
2. 6 months
3. 12 months

Scoping guidance template

Defining boundaries and exclusions

Not every system or process within an organization may be relevant to your SOC 2 audit. Defining clear boundaries ensures that your audit is manageable and focused on what truly matters. Deciding on exclusions involves risk assessment and an honest appraisal of internal controls. For instance, legacy systems that have minimal interaction with sensitive data might be reasonably excluded from the audit if they are adequately segregated.

Nevertheless, careful documentation of these exclusions is critical. The rationale should be transparent for stakeholders and auditors alike, and it should be reassessed periodically as systems evolve. This allows organizations to recalibrate their scope according to emerging risks or new operational realities.

Summing it up

Defining your SOC 2 audit scope is much more than ticking regulatory boxes; it is a strategic initiative that drives your organization toward higher standards in data security and operational excellence. By understanding your objectives, identifying relevant systems, weighing the trust service criteria, and engaging in thoughtful risk assessment, you can craft an audit scope that is both comprehensive and alarmingly aligned with practical business needs.

Collaboration across internal departments and with external auditors ensures that the scope reflects real-world priorities and that every risk is appropriately considered. Documenting the audit plan and reviewing it on an ongoing basis reinforces best practices and fortifies your compliance program, setting a robust foundation for future audits.

Ultimately, a thorough and well-defined SOC 2 audit scope not only safeguards your organization but also builds trust with customers and partners. By taking a structured, thoughtful approach to your audit planning, you position your organization at the forefront of data security and governance, an essential advantage in today’s fast-evolving digital landscape.

Are you a startup looking to get SOC 2 quickly? It’s free!

Sign up here