Three Steps for Defining the Scope of a SOC 2 Audit
“The beginning is the most important part of the work.”
Plato said that. There’s a reason he is still one of the best-known and most widely read philosophers in history. The man knew what he was talking about, even when it comes to audit compliance, which he predates by centuries.
When you’re tackling an audit, preparation beforehand is critical. If you’re undergoing a SOC 2 examination, part of that is defining your scope. This is the “beginning” that is “the most important part.”
But how do you do that? It’s such a key component of your project lifecycle but it depends largely on your organization’s compliance needs.
You need some direction on this critical part of your audit. Schellman has performed over 800 SOC 2 audits in just the last year. In that time, we’ve been through this with various organizations facing the same problem of what to include.
So in this article, we will outline a 3-step process to help you shape your SOC 2 scope.
Maybe your customer base is growing and you need to demonstrate compliance against a well-known cybersecurity framework. Or perhaps you’d just like to gain a better understanding of your security posture for internal purposes.
SOC 2 can help with both of those and more. But regardless of your objective, there are a few things you should consider when scoping your independent assessment. Read on to learn what they are and to ensure you’re set up for success.
1. Identify and Document System Boundaries and Components of the System.
First things first, you have to decide what service offering(s) you’ll include for the audit. When you do that, you’ll need to describe it thoroughly for inclusion in your eventual SOC 2 report. But that report will also require information on the following five components used to provide your in-scope service:
- Infrastructure: Describe the physical and hardware components of the in-scope system, including servers, databases, network devices, corresponding operating systems, hosting providers, and the location of these components.
- What about on-premise deployments?
- They would be considered within the boundaries of the in-scope system, if they are necessary to deliver the service or achieve your service commitments and system requirements.
- If they are not necessary to do those things, they would be considered outside the boundaries of the system (or out of scope).
- Whether the on-premise deployments are managed by your organization, or a separate organization, if they are necessary to deliver the in-scope service or achieve the service commitments, they must be described in your audit. They are considered in-scope and either need to be audited as part of your system (described and tested), or can optionally be carved-out of scope, if they are managed by a third-party (described only).
- What about on-premise deployments?
- Software: Describe the business function of the in-scope application(s) and software as well as monitoring software, ticketing systems, logging tools, intrusion detection systems (IDS), and security information and event management (SIEM) tools, etc. that are necessary to deliver the services.
- People: Describe the personnel involved in the operation and use of the in-scope services. That could include executive management/key stakeholders, product support and product management personnel, developers, engineers, etc.
- Procedures: Describe the procedures in place to support the operation of your implemented controls, also known as “process narratives.”
- Data: Describe the information used and supported by the in-scope services, as well as the process utilized to capture, prepare, and provide the information.
As is the case with most compliance initiatives, documentation is the name of the game, so make sure to identify and put pen to paper on these elements when defining your scope.
2. Select the In-Scope Trust Services Categories.
If you know what services you’ll be having audited and you have an understanding of the various boundaries, your next step for scoping is determining what criteria your assessors will use to audit them.
With SOC 2, that starts with the five Trust Services Categories (TSCs). Each has a unique set of criteria associated with them that you can elect to include in your assessment. We wrote extensively about each of the categories and their criteria in our article here to help you choose those that are right for your organization. But here’s a quick rundown you don’t have to click to get—you have these 5 options:
- Security (comprised of the Common Criteria)
- Processing Integrity
Your selection of what criteria to measure your scope against should be influenced by factors such as:
- Function of your in-scope service(s);
- Components of your information security program that are most important to your customers; and
- Principal service commitments made by your organization to the customers related to the in-scope service.
You must include the common criteria (security category) by default, but you should determine the inclusion of any of the others by those factors.
3. Decide on a Type 1 or Type 2 Audit.
You have your services defined, you know what criteria they should be evaluated against. Now, you need to decide the depth of that evaluation.
You do that by selecting either a Type 1 or Type 2 examination. Again, we wrote in detail about the two types of SOC reports and their advantages, but here’s a quick summation of their differences:
- A Type 1 SOC 2 audit examines the design and implementation of controls as of a point in time. You’ll need evidence to support that your controls are suitably designed and implemented to meet your chosen criteria as of the report date. If you use controls that have an established frequency or multiple occurrences (e.g. new hire security awareness training), your auditor will require evidence of an example recent occurrence.
- A Type 2 SOC 2 audit, on the other hand, also examines the operating effectiveness of controls throughout a period of time. So not only do your controls need to be well-designed and implemented, but your auditor will test evidence for all control occurrences during the decided audit period—not just a singular, recent occurrence—to ensure they are proven to function over time.
It's a different kind of lift in terms of your internal labor commitment, and each type provides a different level of assurance to your customers as well. In finalizing your scope, you’ll need to choose the report type that suits both of those factors.
You should also ensure that if you do choose a Type 2 SOC 2, the processes associated with the in-scope controls have been operationalized for the entire period of coverage—meaning, you’ll be able to provide sufficient evidence for all samples that your auditor may select.
Additional Considerations for Your SOC 2 Scope
Once you do finalize your scope, that doesn’t mean you can’t make changes after the fact. If you determine that there needs to be a modification to the scope of the audit, the best path forward is to notify your assessor immediately to determine how or if they can accommodate the change. Certain changes are not allowed by the authoritative audit guidance, so the earlier the notification the better.
But until then, understanding what you want in terms of these three facets should largely shape the scope of your SOC 2 examination. By determining your systems/services to be evaluated, the criteria they’ll be validated against, and the type of report, you’ll have done well in what Plato would have called the most important part of the work.
As you continue making these critical decisions so that you maximize your opportunities with your SOC 2, check out our other content that will help you set expectations and goals for your process:
- Which SOC Opinion Do You Want? (article)
- SOC 2 vs SOC 3 - Either, Neither, or Both? (video)
- How Long Will Your SOC Examination Take? (article)
Having gone through everything we’ve published on our staple service, you may find you have lingering questions we didn’t answer (yet). If so, please reach out to us—we would love to set up a conversation so that we can offer an auditor’s perspective to alleviate any particular concerns you may have.
About Fred Hood
Fred Hood is a Senior Associate at Schellman based in Raleigh, NC. Prior to joining Schellman in 2019, Fred worked as a Senior Internal Auditor at Brighthouse Financial, specializing in IT SOX and pre-implementation reviews, and a Risk Advisory Associate at KPMG, specializing in IT internal and external audits. Fred has over three years of experience comprised of serving clients in various industries, including financial services, manufacturing, and retail. Fred is now focused primarily on SOC 1 and SOC 2 audits at Schellman. Fred currently holds the following certifications: Certified Public Accountant (CPA) and Certificate of Cloud Security Knowledge (CCSK), Advanced SOC for Service Organizations certificate.