A subservice organization is a vendor that a service organization uses to perform part of the services it provides to its customers, where that vendor's controls are likely to be relevant to the customers' internal control or to the criteria in the service organization's SOC report.
The term comes from AICPA guidance for SOC examinations. In a SOC 2 report, common subservice organizations include cloud hosting providers, managed data centers, and other vendors that run part of the in-scope system.
In simple terms, identifying subservice organizations answers:
- Which outside companies perform part of the system your SOC 2 report describes?
- Are their controls covered in your report, or excluded from it?
- What does your company still need to do to monitor them?
Why Subservice Organizations Matter
Your SOC 2 report describes a system and the controls that support it. If part of that system runs on another company's infrastructure or services, some of the controls that matter are performed by that company, not by your team.
Subservice organizations matter because:
- They define the boundary of what your report covers and what it does not.
- Customers reading your report need to know which vendors they should also review.
- Auditors expect you to monitor the vendors you rely on, even when their controls are excluded from your report.
Subservice Organization vs Ordinary Vendor
Not every vendor is a subservice organization. A vendor is usually treated as a subservice organization when it performs part of the in-scope service and its controls are relevant to the criteria in your report.
| Vendor type | Typical example | Usually a subservice organization? |
|---|---|---|
| Cloud infrastructure that hosts the in-scope system | Public cloud provider | Often yes |
| Vendor that processes customer data as part of your service | Managed database or payment processor | Often yes |
| General business software not part of the system | Office productivity or expense tool | Usually no |
Your system description and your auditor decide where the line falls for your report. This table is a general illustration, not a rule.
Carve-Out Method vs Inclusive Method
AICPA guidance describes two ways a SOC report can present a subservice organization.
Carve-out method
The subservice organization's services are described, but its controls are excluded from the scope of the examination. This is the most common approach for large cloud providers. The report usually lists the controls the service organization expects the subservice organization to perform. These are called complementary subservice organization controls (CSOCs).
Inclusive method
The subservice organization's relevant controls are included in the description and the examination. This requires cooperation from the subservice organization and is less common.
Subservice Organizations and CUECs
Subservice organizations are related to, but different from, complementary user entity controls. CSOCs are controls your report assumes your vendors perform. CUECs are controls your report assumes your customers perform. Both describe responsibilities that sit outside your own control set. For a deeper walkthrough, see Subservice Organizations and CUECs in SOC 2.
How Teams Monitor Subservice Organizations
Under the carve-out method, the subservice organization's controls are not tested in your report, but auditors commonly expect you to show how you monitor them. Common practices include:
- Obtaining and reviewing the vendor's own SOC report each year
- Checking that the vendor's report covers the services and period you rely on
- Reviewing the vendor's CUECs and mapping them to your own controls
- Following up on exceptions noted in the vendor's report
- Recording the review in your vendor management or third-party risk management process
Common Mistakes
- Leaving a vendor that runs part of the system out of the system description
- Collecting a vendor's SOC report but never reviewing it
- Ignoring the vendor's CUECs, which then become gaps in your own controls
- Assuming a carved-out vendor needs no monitoring
- Failing to update the list when the system moves to a new provider
Evidence for Audits
Evidence commonly includes the list of subservice organizations, the vendor SOC reports you obtained, dated review notes, CUEC mappings, and follow-up on any exceptions. Keep these records for the full audit period.
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
That history can make vendor review records easier to find when an auditor asks for them. AuditFlo.co does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
A subservice organization is a vendor that performs part of your in-scope service and whose controls matter to your SOC report. Know which vendors qualify, understand whether your report uses the carve-out or inclusive method, and keep records showing you monitor them.