How to Define the Scope of Your First SOC 2 Audit

The first time a team goes through a SOC 2 audit, they often define their scope in the wrong order. They incorrectly start by making a list of servers, devices, hosted tools, and third parties. These are important inputs, but they aren't the beginning. The scoping question that comes first is, "What data and systems do you use that support the trust services criteria you're claiming to meet?"

Scope follows criteria, not org charts

It is common to define the scope of a SOC 2 audit based on how the company is organized or how the product is discussed in a sales deck. However, this is not the right approach to take.

The scope of the audit should be derived from the trust services criteria you are asserting: security, availability, processing integrity, confidentiality, privacy - and nothing more. There are 34 criteria in total across those five categories in the AICPA framework. Only the categories you choose are in scope, and only the systems that support those criteria belong inside the boundary.

For example, if you are only asserting security, you are not required to include your disaster recovery infrastructure in scope simply because it exists. That's not prudence, that's scope creep, and it results in a longer and more expensive audit with no added assurance.

Subservice organizations force a real decision

The first SOC 2 audit you face will always intersect with a bunch of subservice organizations - the cloud hosting provider, the payment processor, the identity management vendor. For each you decide whether to carve them out or bring them in.

Pushing them out means you don't evaluate the controls the vendor is relying on. Unfortunately, you still have to list the complementary subservice organization controls your system relies on in your description of the system. Pulling them in means taking the whole set of controls the vendor is applying and including them in your report. That's usually the right approach, but doing so means giving auditors the necessary evidence about the vendor's environment and perhaps paying for the vendor to get a new SOC 2.

People usually carve out a major cloud provider or payment processor. They already publish their own audit reports, and it'd just be duplicated effort. Smaller or less mature vendors tend to get the inclusive treatment because they don't have their own attestation to point to. This is exactly the point where a lot of first-timers stumble, and it's worth keeping a soc 2 requirements checklist on hand while you work through which vendors are in and which are out, along with the rest of the boundary decisions covered above.

The system description is where scope actually gets decided

Auditors do not examine your infrastructure diagram. They examine your system description, the AICPA-mandated document that defines your infrastructure, software, people, procedures, and data that fall within the scope of the examination.

Write this before the engagement, not as a responsive task. Enumerate all components that come into contact with in-scope data: production environments, admin tools, ticketing systems if they contain in-scope data, the people and processes supported by these tools, etc. Then, use this list to properly scope the test. Anything on your list should be examined. Anything not on the list should require a suitable written justification.

This is what is truly meant by scoping. It's a writing assignment before it's an engineering one.

Document your exclusions, not just your inclusions

Teams often focus excessively on what's in scope, and relegate what's out of scope to a footnote. But the order of importance should really be reversed if you want your exclusions to hold up over time. People reading a SOC 2 report - including auditors - are far more concerned with why certain systems, people, data flows or risks were left out than with why you had to split a complex system into two trust boundaries.

If you think a reader will find an exclusion controversial or disagree with it, treat that as a signal that you haven't yet made your case prominently enough for why the shortcut was necessary. This doesn't mean you make an exclusion incredibly verbose just to hype its importance. Just remember that even a last-minute boundary decision due to changing facts on the ground should be documented and clearly communicated in the report.

Type I and Type II change how much scope has to hold up

A Type I report evaluates control design at a specific point in time. A Type II report evaluates operating effectiveness over a period, typically ranging from three to twelve months. This fundamental difference affects how tightly you need to set your scope.

What looks like a reasonable scope on a particular day can unravel over a six-month period if, for example, the underlying system changes, a vendor relationship is altered, or a control is quietly eliminated. If you are going directly into a Type II with your first audit, perform a readiness or gap assessment beforehand. It's a relatively low-cost method for discovering scope issues before they start appearing as exceptions in a report that your clients will read.

Map every criterion to a system, or explain why not

Prepare a matrix connecting each relevant trust services criterion to a given system or control, and identifying why specific criteria are not relevant, if that is the case. This single artifact likely does more to keep the audit on track and find the holes you need than any other in the whole process. It costs you essentially nothing to prepare and share, but it gives your auditor something concrete to actually test you against, instead of a blurry description they have to mentally turn into a check.

Scoping isn't a formality you rush through to get to the "real" audit. It's the decision that determines whether the real audit produces a report anyone can trust.