When SaaS Vendors Must Be Treated as Subservice Organizations Under SOC 2

A SaaS company preparing for a SOC 2 audit discovers that its cloud infrastructure provider, email delivery service, or payment processor handles customer data in ways that directly affect the security commitments in the service organization's own report. The auditor asks whether these vendors are subservice organizations. Leadership needs to know what that means, when it applies, and what evidence satisfies the requirement.

1What Is a Subservice Organization

The SOC 2 framework, promulgated by the American Institute of CPAs, addresses situations where a service organization relies on another entity to perform functions that are part of the services provided to user entities. When a vendor performs tasks that affect the controls described in your SOC 2 report, that vendor may meet the definition of a subservice organization.

The AICPA describes this structure plainly: entities often use business relationships with other organizations to further their objectives, and some entities can function more efficiently by outsourcing tasks or entire functions to another organization. In the SOC 2 context, if the outsourced function is relevant to the trust services criteria you are reporting on, the vendor is a subservice organization, not merely a supplier.

The distinction matters because subservice organizations must be disclosed in your SOC 2 report and their controls must be addressed, either through inclusion in your own report or by reference to their independent SOC 2 report.

2When a Vendor Must Be Treated as a Subservice Organization

Not every vendor qualifies. The test is whether the vendor performs a function that is necessary to achieve the control objectives in your SOC 2 report. If a vendor processes, stores or transmits customer data in a way that directly affects security, availability, processing integrity, confidentiality or privacy, and that function is part of the service you provide to your customers, the vendor is likely a subservice organization.

Examples include cloud infrastructure providers that host production environments, email service providers that send transactional messages containing customer data, payment processors that handle credit card information on your behalf, and identity providers that authenticate your users. Office productivity software used only by internal staff, or a vendor that provides a service unrelated to the commitments in your report, would not meet the definition.

The determination is made jointly by service organization management and the auditor, based on the nature of the services provided and the control objectives in scope.

3The Two Reporting Methods and What Evidence Each Requires

SOC 2 reports can handle subservice organizations in two ways: the carve-out method and the inclusive method. Each has different implications for your audit and your customers' reliance on your report.

Carve-Out Method

Under the carve-out method, your report describes the subservice organization's functions and states that your controls assume the subservice organization has effective controls in place. The subservice organization's controls are not tested by your auditor. Instead, your customers are expected to obtain and review the subservice organization's own SOC 2 report and evaluate whether those controls are sufficient.

This method requires you to name the subservice organization in your report, describe what services they perform, and document your complementary user entity controls. Your auditor will review your vendor management processes but will not test the vendor's controls directly. You must maintain a current SOC 2 report from each carved-out subservice organization and make it available to your auditor and, when requested, to your customers.

Inclusive Method

Under the inclusive method, the subservice organization's relevant controls are included in your SOC 2 report as if they were your own. Your auditor tests those controls, either by performing procedures at the subservice organization or by relying on that organization's SOC 2 report under specific auditing standards.

This method provides a more complete picture to your customers, who do not need to obtain separate reports from your subservice organizations. However, it requires either direct access for your auditor to test the vendor's controls or a SOC 2 report from the vendor that covers the same period and criteria as your own report. Your auditor must evaluate whether the vendor's report is suitable for reliance.

4Business Consequences of the Choice

The reporting method affects your customers' audit requirements. If you use the carve-out method, your customers must obtain and review each subservice organization's SOC 2 report to complete their own assessments. Larger customers with mature compliance programs expect this, but smaller customers may find the requirement burdensome or may not understand it. Sales prospects evaluating your report will notice the carve-outs and may request additional documentation.

The inclusive method simplifies due diligence for your customers but adds complexity and cost to your audit. Your auditor must test additional controls, coordinate with subservice organization auditors, or obtain and evaluate vendor SOC 2 reports. If a critical vendor does not have a SOC 2 report covering the required period, your audit may be delayed or your scope may need to change.

From a risk perspective, both methods place accountability on your organization. Even under the carve-out method, you remain responsible for selecting and monitoring subservice organizations. A control failure at a vendor affects your service regardless of how the vendor is treated in your report.

5Who Inside the Organization Is Accountable

This is a governance question before it is an operational one. Determining which vendors are subservice organizations, selecting the reporting method, obtaining and reviewing vendor SOC 2 reports, and establishing complementary controls are security and risk decisions that require executive judgment.

In practice, the CTO or VP of Engineering often coordinates with the compliance or legal team, but neither role typically has the mandate to make binding risk acceptance decisions on behalf of the organization. The CEO or board expects these decisions to be made with a clear understanding of business impact, regulatory position, and customer expectations.

Adequate ownership includes a documented vendor risk management program that identifies which vendors handle customer data, evaluates their security posture, collects and reviews SOC 2 reports on a defined schedule, tracks report expiration dates, and escalates gaps to leadership. It also includes defined complementary user entity controls, meaning the specific actions your organization takes to mitigate risks that the vendor's controls do not fully address.

This work requires sustained attention. Vendor SOC 2 reports expire annually. New vendors are added as the business grows. Existing vendors change their scope, retire services, or fail audits. Someone must own the process continuously, not only in the weeks before your own audit.

6The Relationship to Vendor and Third-Party Oversight

Subservice organization management is a specialized subset of vendor risk management. Not every vendor requires a SOC 2 report, but every vendor that meets the subservice organization definition does. The broader vendor risk program should include security questionnaires, contract review, access controls, and ongoing monitoring. For subservice organizations specifically, the program must ensure that current SOC 2 reports are on file, that the reports cover the necessary trust services criteria and time periods, and that any exceptions or qualifications in those reports are evaluated and addressed.

Managed service providers are often subservice organizations if they manage infrastructure, monitor security controls, or handle incident response for systems that process customer data. The distinction between a vendor, a subservice organization, and an MSP is functional, not contractual. If an MSP performs tasks that affect your control environment, it is a subservice organization for SOC 2 purposes.

Leadership should expect the vendor risk program to produce a clear answer to the question: which of our vendors are subservice organizations, do we have current SOC 2 reports from each of them, and have we addressed any gaps or exceptions in those reports?

7What Leadership Should Do Next

First, work with your auditor to confirm which vendors meet the definition of a subservice organization. This requires a joint review of your vendor list, your service commitments, and the control objectives in your SOC 2 scope. Do not wait until audit fieldwork begins.

Second, for each identified subservice organization, obtain a current SOC 2 report. Confirm that the report covers the trust services criteria relevant to your own report and that the reporting period aligns with or overlaps your audit period. If a vendor does not have a SOC 2 report, evaluate whether an alternative attestation is acceptable or whether the vendor must be removed from critical data paths.

Third, decide whether to use the carve-out or inclusive method for each vendor. This decision should be informed by customer expectations, audit complexity, and the availability of vendor reports. Document the rationale.

Fourth, document your complementary user entity controls. These are the controls your organization implements to address risks that the subservice organization's controls do not fully cover. Examples include monitoring vendor uptime, reviewing access logs, encrypting data before transmission to the vendor, or maintaining backup systems. Your auditor will test these controls.

Fifth, assign ongoing ownership. Someone must track vendor SOC 2 report expiration dates, request updated reports, review new reports for exceptions, and escalate issues to leadership. This role requires access to vendor relationships, understanding of the SOC 2 framework, and authority to raise concerns.

If your organization does not have a senior security leader with the mandate and capacity to own this process, that is the gap to address first. A virtual CISO engagement provides the executive ownership, regulatory expertise, and governance structure needed to manage subservice organizations as part of a complete vendor risk program. The role includes identifying subservice organizations, establishing the evidence collection process, making and documenting risk decisions, and reporting to leadership on vendor compliance status.

Subservice organization management is not a one-time project. It is a continuous governance function that directly affects your ability to maintain a clean SOC 2 report and meet customer commitments. The absence of clear ownership creates audit risk, customer friction, and unmanaged third-party exposure. The presence of disciplined, executive-level oversight turns vendor compliance into a repeatable process that supports rather than impedes business growth.