SOC 2 Carve-Out vs Inclusive Method: Subservice Orgs

By Editorial team · Published 2026-04-22 · Last updated 2026-04-22

When your SOC 2 system includes AWS, Stripe, or another subservice provider, you must choose carve-out or inclusive method. Here's how to decide.

Most SaaS companies rely on cloud infrastructure, payment processors, or other third-party services that are material to the controls covered in a SOC 2 report. Under SSAE 18, when a service organization uses another service organization (a subservice organization) to perform services that are relevant to the SOC 2 system, the service organization must choose one of two methods for handling it in the report: carve-out or inclusive. This choice affects audit scope, evidence requirements, and how buyers read the resulting report.

Definitions: carve-out vs. inclusive

Under the carve-out method, the service organization's system description identifies the subservice organization and the services it provides, but explicitly excludes the subservice organization's controls from the scope of the SOC 2 examination. The auditor's opinion covers only the service organization's controls. The service organization should describe what controls it has in place to monitor the subservice organization (vendor management controls).

Under the inclusive method, the subservice organization's relevant controls are included within the scope of the SOC 2 examination. The auditor tests the subservice organization's controls as part of the engagement and includes them in the opinion. This requires the service organization to obtain the subservice organization's cooperation during fieldwork and is significantly more complex.

When to use each method

• Carve-out for major cloud providers (AWS, GCP, Azure): Use carve-out. AWS, GCP, and Azure publish their own SOC 2 Type II reports. The accepted industry practice is to carve them out and reference their reports, combined with your vendor management controls for monitoring them. No enterprise buyer expects your auditor to independently test AWS infrastructure.
• Carve-out for large SaaS subservice providers (Stripe, Okta, Salesforce): Use carve-out if the provider has their own SOC 2 or equivalent. Include a description of your vendor management controls and the complementary subservice organization controls (CSOCs) you expect them to have.
• Inclusive for proprietary or custom subservice arrangements: If you have a material operational dependency on a smaller provider that doesn't publish their own SOC 2 — a custom data center, a proprietary data processing partner, a white-label API provider — inclusive method may be appropriate. This requires their cooperation.
• Inclusive when required by customer contract: Some enterprise customers contractually require inclusive treatment of specific subservice providers. This is uncommon but not unheard of in regulated industries.

Practical implications for your audit

1. Inventory your subservice organizations before scoping: Identify every third-party service that processes your customers' data, performs security functions (authentication, logging, infrastructure), or is relevant to the TSCs in scope. This list is the starting point for the carve-out/inclusive decision.
2. Obtain SOC 2 reports for carve-out subservice providers: If you carve out AWS, Stripe, or Okta, your auditor will expect you to have obtained and reviewed their SOC 2 reports. Document this as part of your vendor management process. Keep copies on file.
3. Document vendor management controls: For each carve-out subservice organization, describe what controls you have over the relationship — annual SOC 2 review, contractual security requirements, incident notification clauses. These become the complementary controls that make the carve-out defensible.
4. Prepare the system description subservice section: The system description in your SOC 2 report must describe each subservice organization, the method used, and (for carve-out) the CSOCs. Work with your auditor to draft this section early — it shapes the overall audit scope.
5. For inclusive method: obtain the subservice organization's written consent to be included in your audit scope, and coordinate access for your auditor. This often requires contractual provisions negotiated at the time of the vendor agreement.

How buyers read the subservice organization section

Enterprise security teams reviewing your SOC 2 report look at the subservice organization section to identify two things: whether the carve-out choices are reasonable, and whether the complementary controls you describe are substantive. A carve-out with no CSOCs described, or with CSOCs so generic they're meaningless ('user entities should review vendor SOC 2 reports'), signals a weak vendor management program.

When assessing an auditor for your program, ask how they've handled subservice organizations for clients with similar technology stacks. Auditors at Schellman, A-LIGN, BARR Advisory, and Prescient Assurance have extensive experience with AWS-hosted SaaS products and standard carve-out structures. A first-time auditor unfamiliar with cloud-native architectures may request evidence for subservice providers that you've reasonably carved out, adding unnecessary scope to the engagement.

Updating subservice organization handling across audit cycles

Subservice organization lists change. Adding a new cloud region, switching payment processors, or onboarding a new AI API provider creates new subservice relationships that need to be scoped in the next cycle's system description. Maintain a running list of material subservice organizations as part of your vendor management program, and review it with your auditor at the start of each engagement. Discovering an undisclosed material subservice organization during fieldwork extends the audit and raises questions about your system description accuracy.

How buyers evaluate the subservice organization section

Enterprise security teams reviewing your SOC 2 report will check three things in the subservice organization section: (1) whether the carve-out choices are reasonable given your technical architecture, (2) whether the CSOCs described are substantive rather than generic, and (3) whether the subservice providers listed match what you disclose in your security questionnaire responses and DPA. Inconsistency between your SOC 2 report and your security questionnaire answers is a red flag that triggers follow-up. If your SOC 2 carves out AWS but your security questionnaire says 'we manage our own hardware,' that contradiction will be noticed by a thorough reviewer.

If you use a GRC platform for evidence collection, the subservice organization list in your SOC 2 should align with the vendor inventory maintained in the platform. Platforms like Vanta, Hyperproof, and Drata support vendor risk tracking as a feature alongside the compliance program — keeping the lists synchronized avoids the situation where your SOC 2 carves out a vendor your compliance platform lists as 'unreviewed.'