Vendors inside the system
Subservice organizations: the vendors your report must name.
Not every vendor belongs in your SOC 2 description. A subservice organization is one whose services are part of the system you deliver and whose controls your criteria depend on. This page shows how to tell them apart from ordinary vendors, how to name them, and how to monitor them in a way your auditor can test.
Back to SOC 2 services01 · Who counts
The test: is the vendor performing part of your service?
Two questions separate a subservice organization from an ordinary vendor.
- Does the vendor perform part of the service your customers receive, such as hosting, storing, processing or transmitting their data?
- Are controls at the vendor needed, together with yours, to meet the criteria in your report?
If both answers are yes, the vendor is a subservice organization and must be named in your description. If the vendor supplies a tool you use to run the business, such as payroll software for your own staff or a design tool, it is an ordinary vendor: you still manage its risk under your vendor programme, but it does not appear as part of the system.
02 · Typical treatment
Vendor types and how they are typically treated
Illustrative; the answer depends on what the vendor does for your system.
| Illustrative vendor | Usually | Typical method |
|---|---|---|
| Cloud infrastructure host | Subservice organization | Carve-out |
| Managed database or object storage provider | Subservice organization | Carve-out |
| Payment processor handling customer transactions | Subservice organization | Carve-out |
| Outsourced support desk with access to customer data | Subservice organization | Carve-out, or inclusive if closely related |
| Parent company running shared IT operations | Subservice organization | Inclusive is common |
| Error-tracking tool receiving production data | Depends on the data it receives | Carve-out if in scope |
| HR and payroll software for your own employees | Ordinary vendor | Not in the description |
| Office productivity and email suite | Usually an ordinary vendor | Not in the description unless the service relies on it |
03 · In the description
How the description names them
Name, role, method and the controls you assume.
- Identity. The vendor's name, or a clear description of the type of vendor.
- Nature of the service. What it does for your system, in a sentence or two.
- Method. Whether the carve-out or inclusive method applies.
- Complementary controls. Under carve-out, the CSOCs your system assumes the vendor operates.
- Your monitoring. How you oversee the vendor, described as one of your own controls.
04 · Monitoring
The controls you perform to monitor them
Monitoring is your control, and it is tested.
- Keep an inventory of subservice organizations with owner, method and data handled.
- Assess risk at onboarding and again on a set cadence.
- Obtain and review their SOC reports, or other evidence where none exists.
- Put security terms in contracts: notification of incidents, right to audit or evidence, data return and deletion.
- Track incidents and service failures that involve the vendor.
- Record every review with a date, reviewer and conclusion.
Scale the effort to the vendor's reach. A host that stores all customer data deserves a full report review each cycle and a named owner. A vendor that receives a narrow slice of data may need only a lighter check. Write the tiering down, because the auditor tests whether you follow your own rule, and an unwritten rule cannot be followed consistently.
05 · Reviewing their reports
How to review a subservice organization's report
Four things to check, every time.
- PeriodDoes the vendor's period cover enough of yours? If a gap remains, ask for a bridge letter and note it.
- ScopeAre the services and locations you use inside its boundary, and are the relevant categories included?
- Exceptions and opinionRead the opinion and every exception. Decide and record whether each one affects you.
- Complementary controlsList the CUECs the vendor assigns to you, and confirm you operate each one. Confirm its own subservice organizations do not hide a gap.
Your auditor will usually sample these reviews under CC9.2. A review form with the four headings above, signed and dated, is easy to evidence.
Sources: AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization (subservice organizations); AICPA description criteria DC section 200; AICPA Trust Services Criteria TSP section 100, CC9.2.
Questions about subservice organizations
Our error-tracking tool sometimes receives customer data. Is it a subservice organization?
Possibly. Look at what it receives and why.
If customer data reaches it as part of running the service and your controls rely on it protecting that data, treat it as one. Reducing what you send it is often the cleaner fix.
What if a key vendor has no SOC report?
Use other evidence, and record why it is enough.
Options include an ISO/IEC 27001 certificate with a matching scope, a completed questionnaire, contract terms or a review of its controls. Your reasoning is part of the evidence.
Do our vendors' vendors appear in our report?
Generally not by name.
Your vendor's own report deals with its subservice organizations. When you review it, check that its carve-outs do not leave a gap in something you rely on.
How many subservice organizations is normal?
There is no normal number.
It depends on your architecture. What matters is that every vendor performing part of the service is named and monitored, and none is missing.
Name every vendor that matters, and show you watch them.
We build your subservice inventory, write the description entries and set up a report review your auditor can sample.