Your SOC 2 covers a system that runs on someone else's infrastructure. Your cloud provider operates the data centers, the physical security, and the hardware. Some of the criteria in your report depend on controls you do not operate and cannot test.
SOC 2 handles that with two methods for treating subservice organizations: carve-out and inclusive. The choice decides what your report covers, what your auditor tests, and what you have to do to stay on top of vendors whose controls your opinion relies on.
This article explains both methods, when each one fits, and the monitoring work that a carve-out creates. That last part is where first reports often come up short.
Which vendors are subservice organizations
Not every vendor is a subservice organization. The term covers vendors whose services are likely to be relevant to your customers, because their controls are needed, alongside yours, to meet your service commitments and system requirements.
A hosting provider is the usual example. If its physical access controls failed, your commitments to protect customer data would fail with them. A managed database service or an outsourced operations team can be another.
Most vendors do not reach that bar. Your payroll provider, your design tools, and your email marketing service are vendors you manage through your vendor risk process. They are not part of the system the report describes. The test is whether the report's criteria could be met without them.
Identify subservice organizations during scoping, so your system description can name them. How to scope your first SOC 2 report covers where this decision sits among the others.
The carve-out method
Under the carve-out method, the subservice organization's controls are excluded from your system description and from the scope of your auditor's examination. The description still has to say quite a lot about it:
Who it is, and the nature of the services it provides.
Which criteria it supports, so a reader can see which parts of the report depend on it.
The controls you assume it operates. These are complementary subservice organization controls, the vendor-facing counterpart of complementary user entity controls.
The auditor's opinion then states that its conclusions assume those complementary subservice organization controls operated effectively.
Carve-out is the common treatment for large cloud providers. They publish their own SOC reports, and they do not take part in their customers' audits. A reader of your report who needs assurance about the provider's controls reads the provider's report alongside yours.
The inclusive method
Under the inclusive method, the subservice organization's relevant controls are included in your system description and tested by your auditor. The report then covers both organizations' controls for the services in scope.
That has real requirements:
The subservice organization has to take part. It provides access for testing, and its management provides a written assertion about its part of the description and its controls.
The auditor needs enough access to test those controls to the same standard as yours, across the same period for a Type II report.
The description has to separate the two. A reader should be able to tell which controls are yours and which are the subservice organization's.
Inclusive treatment is uncommon for that reason. It fits where the subservice organization is closely tied to you: an affiliate within the same group, a managed service provider that operates part of your system under contract and agrees to the examination, or a provider that has no report of its own and is willing to be tested.
Choosing between them
The practical comparison:
| Carve-out | Inclusive | |
|---|---|---|
| Subservice organization's controls | Excluded from scope, assumed in the opinion | Included and tested by your auditor |
| Its participation | Not required | Required, including a written assertion |
| What a reader needs | Your report and the vendor's own report | Your report |
| Your ongoing work | Monitoring the vendor's controls, usually through its SOC report | Coordinating the vendor's part of each examination |
| Typical use | Large cloud and platform providers | Affiliates, closely managed providers |
For most SaaS companies the answer is carve-out for the cloud provider, and the question is only whether any other vendor qualifies as a subservice organization at all. You can use different methods for different subservice organizations in the same report, which is worth knowing if one closely managed provider would rather be included.
The monitoring work a carve-out creates
When you carve out a subservice organization, you still need controls over your oversight of it. The common criteria expect you to assess and manage vendor risk, under CC9.2, and the auditor will test that you did so for the vendors your opinion depends on. For a cloud provider, the annual cycle usually looks like this:
Obtain its current SOC report, through its compliance portal or under its terms for access.
Check the scope. Confirm the services and regions you use are covered, and the period overlaps yours.
Read the opinion and the exceptions. Note any modified opinion, and any exceptions in controls your system relies on.
Map its user entity controls to yours. The provider's report lists its own CUECs. They are now controls you are expected to operate, such as configuring access to your cloud accounts correctly.
Cover the gap. If its period ends well before yours does, ask for a bridge letter or the next report, and record what you received.
Record the conclusion. Who reviewed it, when, what they found, and what follow-up was decided.
Step 4 is the one teams tend to miss. Every large provider has a shared responsibility model, and its CUECs are that model in audit form. Your auditor will expect your own controls to cover them.
Steps 2 and 5 matter more than they look. A provider's report that does not cover the services you use, or that covers a period ending many months before yours, gives you less assurance than it appears to. A vendor due diligence checklist covers how this fits into your wider vendor review.
Mistakes that come up in first reports
The same handful of problems recur:
A missing subservice organization. The cloud provider is listed, but a managed database or queue service run by a second provider is not, though customer data lives there.
Every vendor listed. The opposite error. Naming vendors that do not meet the definition makes the description harder to read and implies controls the report does not need.
Assuming the provider covers your configuration. The provider's report covers its controls. How you configure its services, such as storage access policies and network rules, is your control, tested in your report.
Assumed controls that do not match. The controls you list as assumed of the provider should be ones its own report actually describes. Check them against its report, not against memory.
What buyers see
A buyer reading your report will find the carve-out stated in the description and referenced in the opinion. A careful one will look for your subservice organizations, check whether the vendors they care about are listed, and ask for the providers' own reports if they need them.
Make that easy. Name subservice organizations clearly, list the controls you assume of them in plain terms, and be ready to say how you monitor them. The glossary entry for subservice organizations and the SOC 2 framework page cover the related terms.
How TrustLynce helps
TrustLynce's third-party risk module keeps each subservice organization in your vendor inventory, with its risk tier, its current SOC report, the review record, and the date it is next due. That gives your auditor the monitoring evidence a carve-out depends on, in one place.