Subservice Organizations in SOC Reports: Carve-Out vs. Inclusive Method

When a service organization relies on another vendor to perform part of its service, that vendor relationship doesn’t disappear from the SOC audit. Think of a payroll processor using a third-party data center, for example, or a SaaS company built on a major cloud infrastructure provider. If the vendor performs controls that the service organization relies upon to meet its control objectives (SOC 1) or service commitments (SOC 2), it must be accounted for. The question is: how?

The answer lies in one of the two methods defined under AT-C Section 320 (and the older SSAE 16 / SAS 70 frameworks before it): the carve-out method and the inclusive method. Choosing between them is not purely a technical auditing decision; it has real implications for how user entities and their auditors interpret the scope and reliability of your SOC 1 or SOC 2 report.

What Is a Subservice Organization?

A subservice organization is a third-party service provider whose services are part of the service organization’s information system and are relevant to user entities’ internal control over financial reporting (for SOC 1) or to the trust service criteria being reported on (for SOC 2).

Not every vendor qualifies. A subservice organization is specifically one whose controls are necessary for the service organization to achieve the control objectives or criteria it is representing in its SOC report. Generic vendors like office supply companies, non-integrated SaaS tools, and legal counsel are not subservice organizations. The distinction matters because identifying a vendor as a subservice organization changes the scope of the audit and the disclosures required in the report.

Common examples of subservice organizations include:

• Cloud infrastructure providers (AWS, Azure, Google Cloud) for SaaS companies

• Data centers used to host service organization systems

• Third-party payroll processors or benefit administrators

• Disaster recovery or business continuity vendors with access to production data

• Managed service providers (MSPs) that perform vulnerability scans, administer endpoint protection, manage monitoring, or perform patching and hardening

• Subcontractors who perform transaction processing on behalf of the service organization

The Carve-Out Method

Under the carve-out method, the service organization explicitly excludes the subservice organization from the scope of its SOC report. The subservice organization’s controls are carved out. The controls are described in the report, but they are not tested by the service auditor.

The service organization’s System Description must disclose the nature of the services performed by the subservice organization and the types of controls that are excluded from the scope of the engagement. The service auditor’s opinion then applies only to the service organization’s own controls, not to the subservice organization.

This is by far the more common approach. It allows the service organization to complete its SOC examination without requiring the cooperation or participation of the subservice organization. It also allows each party to maintain its own audit scope and timeline.

However, the carve-out method shifts responsibility to the user entity. If the carved-out controls are relevant to the user entity’s own risk assessment or financial statement audit, the user entity’s auditor must obtain assurance over those controls through other means. This is typically done by obtaining and reviewing the subservice organization’s own SOC report, if one exists.

The Inclusive Method

Under the inclusive method, the subservice organization is included within the scope of the service organization’s SOC report. The service auditor tests the controls at both the service organization and the subservice organization, and the resulting opinion covers both.

The inclusive method is significantly more complex to execute. It requires the subservice organization to agree to participate in the examination, grant the service auditor access to its personnel and systems, and accept joint responsibility for the accuracy of the combined system description. In practice, this level of cooperation is difficult to obtain, particularly with large infrastructure providers who serve thousands of customers and maintain their own separate SOC programs.

When the inclusive method is used, the System Description covers both organizations’ environments, and the service auditor’s testing and opinion extend to the subservice organization’s relevant controls. Although this produces a more comprehensive report, it is logistically demanding and rarely the default choice.

Carve-Out vs. Inclusive Method: Key Differences

What the Report Must Disclose Under Each Method

Regardless of which method is used, AT-C Section 320 requires specific disclosures in the System Description. The level of detail differs between the two approaches.

Carve-Out Disclosures

When the carve-out method is used, the System Description must identify the subservice organization by name, describe the nature of the services it provides, and specify the types of controls that have been excluded from the scope of the examination. The description must be sufficiently detailed so that user entities and their auditors understand what is and is not covered by the report.

The service auditor’s report will include language clarifying that the opinion does not extend to the subservice organization’s controls, as they were not in scope for the examination.

Inclusive Disclosures

When the inclusive method is used, the System Description must cover both organizations’ environments in an integrated way. Controls attributable to the subservice organization must be clearly identified and distinguished from the service organization’s own controls. The service auditor’s report will reflect that testing was performed at both entities and that the opinion covers both.

Complementary User Entity Controls and Complementary Subservice Organization Controls

Both subservice methods require the service organization to identify Complementary User Entity Controls (CUECs) — controls that user entities are expected to implement to achieve the stated control objectives or criteria. This has always been a standard element of SOC reports.

Under the carve-out method, service organizations must also identify Complementary Subservice Organization Controls (CSOCs) — controls that the subservice organization is expected to have in place for the service organization’s control objectives or criteria to be met. CSOCs are a disclosure requirement, not a tested assertion. The service organization is representing that it has a basis to expect these controls exist, but the service auditor is not testing them.

CSOCs are an area where many SOC reports are underdeveloped. A vague or incomplete CSOC disclosure creates ambiguity for user entities trying to understand the full control environment. Well-constructed CSOCs are specific, actionable, and tied to the relevant control objectives or criteria they support.

How User Entities and Their Auditors Should Respond

When a SOC 1 or SOC 2 report uses the carve-out method, user entities and their auditors cannot simply treat the carved-out controls as irrelevant. If those controls are part of the system that supports the user entity’s financial reporting or operational processes, assurance must be obtained through other means.

In practice, this means:

• Obtaining the subservice organization’s own SOC report and reviewing it for the relevant period and scope

• Reviewing the CSOCs in the service organization’s report and confirming the subservice organization’s report addresses them

• Performing bridge letter procedures if the subservice organization’s report does not cover the full period under review

• Escalating to direct testing if the subservice organization has no SOC report or if its report contains exceptions relevant to the user entity’s risk

This chain of assurance (service organization SOC report, subservice organization SOC report, gap analysis, and complementary controls) is the intended structure of the framework. It works when all parties maintain current, well-scoped reports. It breaks down when subservice organizations lack SOC coverage or when CSOCs are too vague to map against a subservice organization’s report.

Practical Considerations When Choosing a Method

The choice between the carve-out and inclusive method is rarely a close call in practice, but it deserves deliberate analysis. The following factors typically drive the decision:

• Subservice organization cooperation. If the subservice organization will not participate in the examination, the inclusive method is not available. Most large infrastructure providers like AWS, Azure, and Google Cloud maintain their own SOC programs and will not participate in a customer’s examination.

• User entity sophistication. If the service organization’s user entities are large, audit-intensive organizations with experienced internal audit functions, they will be equipped to obtain and review the subservice organization’s SOC report. Smaller user entities may struggle with this responsibility.

• Materiality of subservice controls. If the subservice organization performs a substantial portion of the processing that supports the service organization’s control objectives, the carve-out method distributes the assurance across multiple reports, requiring user entities to obtain and review the subservice organization's SOC report independently rather than relying on a single, consolidated opinion.

• Audit timeline and logistics. The inclusive method requires coordinating audit access across two organizations, which can significantly complicate scheduling and extend the engagement timeline.

How a SOC Readiness Engagement Addresses Subservice Organization Questions

One of the most common gaps identified during SOC readiness assessments is an incomplete or inaccurate treatment of subservice organizations. Service organizations sometimes fail to identify vendors that qualify as subservice organizations, leading to a System Description that misrepresents the scope of the control environment.

A structured readiness engagement will invent all third-party vendors, evaluate which meet the threshold for subservice organization status, determine the appropriate method for each, and help the service organization draft accurate and complete CSOCs. This work reduces the risk of surprises during the examination and produces a System Description that accurately reflects the environment auditors will test.

Whether your organization is preparing for its first SOC 2 examination or looking to strengthen an existing report, getting the subservice organization method right is a foundational step. It will affect the reliability of your report and the confidence of every user entity who relies on it.

Compass has guided organizations through every stage of their SOC journey, from readiness assessments and subservice organization scoping to examination support and report remediation. Our team understands how third-party vendor relationships interact with your control environment, and we help you determine the right method, document accurate CSOCs, and produce a System Description that stands up to auditor scrutiny. Contact us today to discuss your SOC questions and find out how we can help you build a report that user entities and their auditors can rely on.