Subservice organizations: carve-out or inclusive
A subservice organization is a vendor whose controls your customers depend on. You either carve it out of your report and rely on its own SOC 2, or you include it, and one of those choices is realistic.
A subservice organization is a vendor that performs part of the service your customers receive, in a way that affects whether the Trust Services Criteria are met. Your cloud provider is the obvious one. In your report you either use the carve-out method, which excludes that vendor's controls from your scope and names them, or the inclusive method, which brings their controls into your report and has your auditor test them. Well over ninety percent of SOC 2 reports carve out, and for a company hosting on AWS, Azure or Google Cloud there is no realistic alternative.
- Carve-out method
- The subservice organization's controls are excluded from your description and from the auditor's opinion. You name the vendor, say what it does, and state which criteria depend on its controls. Your customer is expected to read that vendor's own report.
- Inclusive method
- The subservice organization's relevant controls are described in your system description and tested by your auditor. It requires the vendor's cooperation, its own management assertion, and access for your auditor.
Which method to use
| Carve-out | Inclusive | |
|---|---|---|
| Vendor cooperation needed | None | Full, including a signed assertion |
| Your auditor tests their controls | No | Yes |
| Effect on your audit fee | None | Adds materially, often 15 to 40 percent |
| What the customer must do | Read the vendor's own SOC 2 | Nothing extra |
| Works with AWS, Azure, GCP | Yes | No. Hyperscalers will not participate |
| Typical use | Almost every SOC 2 | A tightly held affiliate or an outsourcer you effectively control |
The decision is usually made for you. A hyperscaler will not sign a management assertion for your report, so cloud infrastructure is carved out without discussion. The inclusive method shows up where the subservice organization is a company you own, a long-standing outsourced operations partner, or a processor whose own report does not exist and whose work is too central to leave unexamined.
Which vendors count as subservice organizations
Not every vendor is one. The test is whether that vendor's controls are necessary for the criteria in your report to be met. Your payroll provider holds employee data and is not part of the service your customers buy, so it is a vendor you manage under your vendor management control rather than a subservice organization. Your cloud host is unavoidably one.
| Vendor | Usual treatment | Why |
|---|---|---|
| AWS, Azure, Google Cloud | Subservice, carved out | Physical and environmental security and infrastructure controls sit with them |
| Managed database or Kubernetes provider | Subservice, carved out | They operate part of your production stack |
| Managed security operations provider | Subservice, carved out | They perform your monitoring and response control |
| Outsourced development or support in another country | Often subservice, sometimes inclusive | They touch production or customer data as part of the service |
| Payment processor | Subservice if payments are part of your service | Otherwise a managed vendor |
| Email, CRM, HR and payroll tools | Vendors, not subservice | They support your business, not the audited service |
| Data centre colocation | Subservice, carved out | Physical security is theirs |
A Canadian wrinkle worth catching early
If a subservice organization stores personal information outside Canada, that fact belongs in your privacy disclosures whether or not it belongs in your SOC 2. Alberta's PIPA requires notifying individuals about service providers outside Canada, and Quebec's Law 25 requires a privacy impact assessment before communicating personal information outside Quebec. The audit does not discharge either duty. The data residency page works through what is actually required.
What carve-out looks like in the report
Three things change. Your system description gains a section naming each subservice organization, the functions it performs, and the criteria that depend on it. The auditor's opinion states that the description excludes those controls. And the report carries a list of the controls you expect the subservice organization to have, which is the part most first-time readers skip and most reviewers read.
That list has a name: complementary subservice organization controls, or CSOCs. They are the controls you are assuming the carved-out vendor operates. The similarly named complementary user entity controls point the other way, at your customers, and the two get mixed up constantly.
Carving out does not mean ignoring. You still need a control that says you obtain and review each subservice organization's SOC 2 report annually, and the auditor will test it by asking for evidence that you did. That control is where most first-year vendor exceptions come from. The vendor management page covers running it properly, and how to read a supplier's report covers what to look for when you do.
Subservice organizations and CUECs are different things
A subservice organization is a vendor below you in the chain whose controls you rely on. A complementary user entity control is a control your own customer must perform for your controls to work, such as configuring single sign-on or removing their own departed users. One points down the supply chain, the other points up at your customers. Both appear in the report and neither is optional. CUECs have their own page.
The three mistakes that cost time
- Listing every SaaS tool you buy as a subservice organization. It inflates the description, invites questions, and commits you to reviewing reports for vendors that do not affect the criteria.
- Naming a subservice organization and then having no evidence you reviewed its report. The control you wrote is the control you get tested on.
- Assuming your cloud provider's SOC 2 covers your configuration of their service. It covers their infrastructure. Your IAM policies, your security groups and your encryption settings are yours, and the shared responsibility boundary is exactly where reviewers probe.
Get your scope reviewed before you commit
Which vendors are subservice organizations is a scoping decision with a price attached. Have a firm price it against your real architecture.
Get matchedCommon questions
Is AWS a subservice organization in our SOC 2?
Yes, and it is carved out. AWS controls physical security, environmental protection and the underlying infrastructure, which your criteria depend on. AWS will not participate in an inclusive report, so your description names them, your opinion excludes their controls, and you keep evidence that you review their SOC 2 report annually.
Do our customers need to read our subservice organization's report?
Strictly, yes, that is what carve-out means. In practice most buyers accept that the hyperscaler's report exists and focus their questions on the boundary between their controls and yours. Sophisticated reviewers do ask for evidence that you obtained and reviewed the report yourself.
Does using the inclusive method make our report stronger?
For a reader, marginally, because fewer controls sit outside the opinion. For you it costs more, takes longer, and requires a vendor willing to sign an assertion and open its records to your auditor. It is worth it when the subservice organization does something central and has no report of its own, and rarely otherwise.
What if a subservice organization has no SOC 2 report?
You have three options: use the inclusive method and have your auditor test them, perform and document your own assessment of their controls and accept that reviewers will scrutinise it, or replace the vendor. Which one fits depends on how central they are and how replaceable.
Are subprocessors and subservice organizations the same thing?
No, though they overlap. Subprocessor is a privacy law term for anyone processing personal data on your behalf, and it comes from data protection agreements. Subservice organization is an audit term for a vendor whose controls your criteria depend on. A payroll provider is a subprocessor and usually not a subservice organization.