Defining SOC 2 scope: systems, criteria, and boundaries
Scope is the first and most consequential decision in a SOC 2 engagement, because it determines what gets tested, what the report can claim, and most of what the audit will cost. Getting it right means drawing an honest boundary around the system that actually matters to customers.
Scope is the decision everything else hangs on
SOC 2 is not a company-wide certification; it is an examination of a defined system. Scope answers which products, environments, data flows, locations, and people are in bounds, and which Trust Services Criteria the report will address. That single set of choices drives the size of your control set, the volume of evidence you collect, the length of fieldwork, and ultimately the price. It also dictates what the report can honestly say to a buyer, since a customer can only rely on the report for the system that was actually examined. Because every downstream effort follows from it, scope deserves more upfront deliberation than most teams give it.
Choosing the Trust Services Criteria
The AICPA defines five Trust Services Criteria categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, often called the Common Criteria, is mandatory and is the only category required in every SOC 2 report. The other four are optional and should be selected based on the commitments you actually make to customers and the nature of your service. Availability fits services with uptime obligations, Confidentiality fits those handling sensitive non-personal data under NDAs or contracts, Processing Integrity fits systems where accurate and complete processing is the product, and Privacy applies when you collect personal information directly from individuals. Adding categories you do not need inflates the work without strengthening the report, while omitting one a buyer expects can stall a deal.
Drawing the system boundary
Before settling on criteria, you and your auditor should define the system and its boundaries relative to the services you provide. A system boundary encompasses more than servers: it includes the infrastructure, software, data, people, and procedures that support the in-scope service. In practice this means deciding which applications, cloud accounts, code repositories, supporting tools, and physical or virtual locations are inside the line, and which corporate functions or unrelated products are outside it. The boundary should map to what customers rely on, not to your entire organization. A well-drawn boundary is defensible and clear in the system description, so a reader understands exactly what was and was not examined.
The risks of over- and under-scoping
Over-scoping is the more common and quieter mistake: teams sweep in products, environments, and staff that customers never ask about, then pay for the extra evidence collection and testing for years. Under-scoping is riskier in a different way; if you exclude a system that customers genuinely depend on, the report looks complete but does not actually cover what matters, and a sharp procurement reviewer will notice the gap and lose trust. There is also a credibility cost to a boundary that seems gerrymandered to avoid testing a weak area. The goal is an honest line that covers the customer-facing service in full without dragging in unrelated parts of the business. Revisit scope at each annual cycle, since new products and environments can quietly drift in or out of relevance.
Subservice organizations and the carve-out decision
Most service organizations rely on subservice organizations, vendors like cloud infrastructure providers whose controls contribute to meeting the criteria. SOC 2 handles them two ways. The carve-out method discloses the subservice provider and the controls you expect it to perform but excludes those controls from your auditor's testing, typically leaning on the vendor's own SOC 2 report; this is by far the more common approach for providers built on major cloud platforms. The inclusive method folds the subservice organization's relevant controls into your examination and tests them directly, which is heavier but leaves no visibility gap. Either way, the system description must name the subservice organizations, describe the controls they are responsible for, and state the complementary controls your customers must operate on their end. Buyers reviewing your report will read these carve-outs closely, because a critical function handled by an untested vendor is a gap they have to chase down separately.