Menu
Quick Answer: A subservice organization is a vendor whose controls are necessary, in combination with your own, to meet your SOC 2 commitments (a cloud host’s data-center security, a payroll processor’s handling of pay data). Your auditor has two ways to deal with one: carve-out, where the report names the vendor and lists the controls you’re relying on it for but doesn’t test them, or inclusive, where the vendor’s controls are tested directly and its management provides its own assertion. Almost every startup uses carve-out, because the vendors that matter most (AWS, GCP, Azure, and most enterprise SaaS) already publish their own SOC 2 reports.
What Is a Subservice Organization?
A subservice organization is a third-party vendor whose controls are necessary, in combination with your own, to achieve your SOC 2 service commitments or the Trust Services Criteria in scope. This is different from an ordinary vendor, whose controls are not structurally required for you to meet those commitments, assuming you have adequate vendor-monitoring controls in place.
Every SOC 2 report has to draw a line between two kinds of third parties. Ordinary vendors are ones you oversee: you review them, you monitor them, and if they disappeared tomorrow you could still meet your service commitments some other way. Subservice organizations are different. Your ability to meet a specific control objective structurally depends on that vendor doing something you cannot do yourself, and cannot fully verify through oversight alone.
The practical test is simple: could you achieve your stated control objectives using your own controls plus ordinary vendor oversight, or does the objective only hold because a specific vendor is performing a specific control? If it’s the latter, that vendor is a subservice organization for that control.
A few concrete examples make this test easier to apply:
- Cloud infrastructure providers (AWS, GCP, Azure) hosting your production systems are almost always subservice organizations for physical and data-center security. You cannot walk into their data centers and test badge access yourself, and you depend entirely on them for it.
- Payroll processors handling employee pay data are typically subservice organizations for the controls relevant to your in-scope systems, because they perform specific processing steps you have delegated entirely.
- A marketing SaaS tool that never touches in-scope systems or customer data usually stays an ordinary vendor. You monitor it like any vendor, but no control objective depends on it performing a specific function on your behalf.
Deciding which vendors clear this bar is part of scope determination, not an afterthought bolted on later. Our SOC 2 scope determination guide covers how to draw that boundary before you engage an auditor, and our SOC 2 vendor management requirements guide covers the broader third-party oversight process that subservice organizations sit inside.
Carve-Out vs. Inclusive: Two Ways to Handle a Subservice Organization
Once a vendor qualifies as a subservice organization, your auditor has two ways to address it in the report. The carve-out method names the vendor and lists the controls your management assumes it has in place, without testing those controls directly. The inclusive method brings the vendor’s controls into the engagement itself, tested alongside your own, with the vendor’s management providing a separate written assertion.
The Carve-Out Method
Under carve-out, your system description identifies the subservice organization and describes the types of controls your management assumes it has implemented. These are often called Complementary Subservice Organization Controls (CSOCs), a term worth knowing because you will see it in your system description and in any subservice organization’s own report. The auditor does not test whether those specific controls actually operated effectively during the period. Instead, the auditor tests your own controls, which include how you monitor that subservice organization.
Carve-out is the method used in the overwhelming majority of SOC 2 engagements, and it’s the right choice whenever either of these is true:
- The subservice organization already has its own independent SOC 1 or SOC 2 report (or an ISO 27001 certification) that you and your report’s readers can obtain and review directly.
- The subservice organization won’t provide the level of contractual cooperation an inclusive engagement requires, which is common with large platform vendors serving thousands of customers who cannot each run a separate examination.
The Inclusive Method
Under inclusive, the subservice organization’s relevant controls become part of your system description, and they are tested as part of your engagement, alongside your own. This requires the subservice organization’s own management to provide a separate written assertion and to actively participate: interviews, evidence requests, and walkthroughs, on the same schedule as yours.
That participation requirement is exactly why inclusive is rare. It substantially expands audit scope, time, and cost, and it only works when the subservice organization is willing and able to open its own controls to your specific audit. Most companies, especially startups relying on hyperscale cloud providers, cannot realistically obtain that level of cooperation from a vendor serving a huge customer base.
What Changes in the Report Either Way
| Carve-Out | Inclusive | |
|---|---|---|
| Vendor named in system description | Yes | Yes |
| Vendor’s controls tested by your auditor | No | Yes |
| Vendor management provides its own assertion | No | Yes |
| Auditor’s opinion covers vendor’s controls | No, opinion covers only your own controls | Yes, opinion extends to the tested vendor controls |
| How a report reader gets assurance on the vendor | Separately obtains and reviews the vendor’s own SOC report | Reads it directly in your report |
| Typical use case | Vendor already has its own current SOC report (AWS, GCP, Azure, most SaaS) | Vendor has no independent report and will actively participate |
The practical consequence: under carve-out, a customer or prospect who wants assurance that your cloud provider’s physical security actually operated effectively during the period has to go get that provider’s own SOC 2 report separately. Your report tells them which controls you’re relying on the vendor for; it doesn’t vouch for whether the vendor executed them. Under inclusive, your auditor’s opinion literally covers those tested vendor controls, so the reader gets everything in one document.
Which Method Do Nearly All Startups Use?
Carve-out, by a wide margin. Virtually every major infrastructure and platform vendor a startup depends on, AWS, GCP, Azure, and most enterprise SaaS tools, already publishes its own independent SOC 2 or ISO 27001 report. That makes it unnecessary, and often prohibitively expensive and impractical, to pull those vendors into an inclusive examination of your own audit.
It also isn’t realistic in the other direction. A hyperscale cloud provider serving hundreds of thousands of customers is not going to participate directly in any single customer’s individual audit; that’s precisely why they publish their own reports for customers to rely on instead. If your auditor tells you a core infrastructure vendor needs to be handled inclusively, that’s worth a direct conversation about why, since it’s the exception rather than the rule.
Where this can shift is with smaller, more specialized vendors: a boutique managed-services provider or a niche processor that hasn’t gone through its own SOC 2 yet, but that performs a control your service commitments depend on. In that narrower case, inclusive treatment (or, more often, a push to get that vendor its own SOC 2 report before your next cycle) becomes a real option worth discussing with your auditor.
CSOC vs. CUEC: Don’t Confuse These Two
Complementary Subservice Organization Controls (CSOCs) and Complementary User Entity Controls (CUECs) sound alike and are easy to conflate, but they point in opposite directions.
A CSOC is a control your management assumes a subservice organization (a vendor you depend on) has implemented. It’s what carve-out is built around: the report lists these so a reader knows what you’re relying on the vendor for.
A CUEC is a completely different, distinct concept: a control your own customers (user entities) are assumed to implement, because your service commitments depend on your customers doing something on their end. If you sell software, your customer’s obligation to manage their own user access within your platform is a typical CUEC.
CSOCs describe what you need from your vendors going up the chain. CUECs describe what your customers need to do coming down the chain from you. Our complementary user entity controls guide covers CUECs in full; this page focuses on the subservice-organization side.
Monitoring a Carved-Out Subservice Organization
Carving out a vendor removes it from direct testing. It does not remove your responsibility for it. Auditors still expect you to demonstrate an active, documented vendor-monitoring process, and this is one of your own controls that gets tested even though the vendor’s controls themselves don’t.
At minimum, that means:
- Obtaining the vendor’s current SOC report annually and keeping a record that you did.
- Reviewing the opinion, not just filing the report. A qualified opinion or a section with exceptions relevant to the controls you’re relying on is something you need to evaluate and, if necessary, respond to.
- Checking the report’s coverage period. A SOC 2 report that expired eight months ago doesn’t tell you anything about the vendor’s current control environment. Auditors will ask when you last reviewed the report and whether its period is still current relative to your own audit window.
- Maintaining a documented vendor-risk process for that relationship, tying back to your broader third-party risk program rather than existing as a one-off checklist item for this one vendor.
This monitoring obligation is exactly why physical and data-center security controls at CC6.4 usually read as “inherited from the cloud provider, documented, and reviewed” rather than absent from your control set entirely. Our SOC 2 Common Criteria explained guide walks through how CC6.4 and the rest of the access-control criteria treat that inheritance in practice.
FAQ
What is a subservice organization in a SOC 2 report?
A subservice organization is a vendor whose controls are necessary, in combination with your own, to meet your SOC 2 service commitments or Trust Services Criteria. Cloud infrastructure providers are the most common example: you rely on them for physical data-center security you cannot test yourself. A vendor that never touches in-scope systems or data stays an ordinary vendor, not a subservice organization.
What is the difference between the carve-out and inclusive method?
Under carve-out, your system description names the subservice organization and lists the controls you assume it has in place, but the auditor doesn’t test those controls directly; your own controls, including how you monitor the vendor, get tested instead. Under inclusive, the subservice organization’s controls are tested as part of your engagement, and its management has to provide its own written assertion and participate directly.
Which method should a startup use for SOC 2?
Carve-out, in almost every case. Startups depend on hyperscale cloud providers and established SaaS vendors that already publish their own independent SOC 2 or ISO 27001 reports, which makes it unnecessary and impractical to pull them into an inclusive examination. Inclusive is realistic only when the subservice organization has no such report of its own and is willing and able to participate directly in your audit.
What is a Complementary Subservice Organization Control (CSOC)?
A CSOC is a control your management assumes a subservice organization has implemented, listed in your system description under the carve-out method. It’s the mirror image of a Complementary User Entity Control (CUEC), which is a control your own customers are assumed to implement. CSOCs describe what you need from vendors; CUECs describe what your customers need from you.
Do we still have to monitor a subservice organization we carved out?
Yes. Carving out a vendor removes it from direct testing, not from your responsibility. You still need a documented process for obtaining and reviewing that vendor’s own SOC report annually, checking the opinion and any exceptions relevant to you, and confirming the report’s coverage period is current. Auditors test this monitoring process as one of your own controls.
Can we use carve-out for some vendors and inclusive for others?
Yes. The method is chosen per subservice organization, not once for the whole engagement. Most companies carve out every vendor with its own current SOC 2 or ISO 27001 report, and only consider inclusive treatment for a subservice organization that has no such report and is small enough to participate directly in the audit.
Figuring out which of your vendors count as subservice organizations, and whether carve-out actually covers you, is exactly the kind of scoping question that shapes what an auditor quotes and how long fieldwork takes. SOC2Auditors matches you with verified SOC 2 audit firms based on your stack, vendor dependencies, and timeline, no sales calls required. Find your SOC 2 auditor to get a shortlist, or read our SOC 2 scope determination guide to work through the rest of your scoping decisions first.