Carve-Out vs Inclusive Subservice Organization Treatment in SOC 2

A SOC 2 report has to account for every vendor that touches the systems inside its scope, and the audit forces a binary choice on each one: carve it out of testing, or fold it in. That choice, formalized under AT-C Section 320 (the standard that replaced SSAE 16 and SAS 70), determines what gets tested, what gets disclosed, and what a buyer or regulator actually sees when they open the report. Get it wrong at scoping, and the fix later in the engagement is expensive. Get it right, and the report does the job it's supposed to do: tell a sophisticated reader exactly where the service organization's controls end and someone else's begin.

The governing test is simple to state and harder to apply consistently: does this vendor's service directly or indirectly affect the organization's ability to meet its Trust Services Criteria commitments? Office cleaners, outside counsel, and marketing tools that don't touch production systems clear the bar easily, because they are not subservice organizations. Cloud infrastructure providers, data centers hosting production systems, payroll processors with access to production data, managed service providers doing patching and vulnerability scanning, disaster recovery vendors, and subcontractors processing transactions on the organization's behalf don't get that pass. They're in scope, and the only remaining question is how.

Misclassifying a vendor at scoping is, by most accounts, the single most common error in SOC 2 readiness work, and it's also the most expensive one to unwind mid-engagement. One practitioner account published on fieldguide.io describes a hyperscaler that got missed in a system description entirely, and became visible only two weeks into fieldwork. The result: a rewritten system description, a scramble to obtain the upstream provider's own SOC report, and a bridge letter to cover the gap. None of that is catastrophic on its own. All of it is avoidable if classification gets asked about early and answered correctly.

How the carve-out method works

Under the carve-out method, the system description names the subservice organization, describes the nature of what it does, and then explicitly excludes its control objectives and controls from the audit's scope. The auditor doesn't test the subservice organization's environment. What the description has to include instead is a set of Complementary Subservice Organization Controls, usually shortened to CSOCs, along with the service organization's own process for monitoring whether the subservice organization is holding up its end.

CSOCs are a disclosure. The service organization is saying, in effect, that it has a reasonable basis to expect these controls exist at the vendor. The auditor doesn't verify them. Weak reports fall apart later exactly at that distinction.

Carve-out is the dominant approach, and the numbers back that up. A SOC benchmark study from Konfirmity and CBIZ found that 89.6% of SOC 2 reports include subservice providers, up from 82% the year before, with an average of roughly 10 CSOCs per report. Auditors are comfortable signing off on carve-out treatment when the subservice organization already has a current SOC 2 report of its own. That's why it's the standard approach for major cloud providers, established SaaS vendors, and colocation facilities. The opinion language is explicit about the boundary: it does not extend to the subservice organization's controls, full stop.

Sophisticated buyers reading a carve-out report know what to look for. In practice, this means the subservice organization is named and its services described, there's evidence the service organization reviews the subservice SOC report annually, and there's a documented process for notification if that vendor ever changes. The limitation built into carve-out is that it shifts the assurance burden downstream: if a user entity's own risk assessment depends on those excluded controls, its auditor has to go get the subservice organization's report independently. Carve-out relocates that work rather than making it disappear. It just relocates it.

How the inclusive method works, and what it costs to execute

Inclusive treatment does the opposite. The system description covers the subservice organization's services and its relevant controls, the auditor tests both, and the resulting opinion is a single, genuinely consolidated statement covering two organizations instead of one.

That consolidation isn't free, and it isn't just a matter of the audit firm doing more work. Inclusive treatment requires the subservice organization to participate directly: a written management assertion that gets included in section two of the report right after the service organization's own assertion, a written management representation letter, auditor access to personnel and systems, and a willingness to coordinate scheduling and evidence collection across two separate organizations' calendars. If the subservice organization won't provide that written assertion, inclusive is off the table before the engagement even starts. No amount of preference or planning changes that. Carve-out becomes the only option left.

Even when cooperation is available, inclusive expands the audit's footprint substantially. Scope now covers two environments instead of one, scheduling coordination across two organizations can stretch the engagement timeline well past what a single-entity audit would take, and audit firms themselves carry more risk under inclusive treatment. Fieldguide notes that peer review exposure drafts flag engagements where a significant subservice organization is named in the opinion for extra scrutiny. All of that combines to make inclusive the minority approach, and it's a minority approach for structural reasons, not because auditors or clients don't understand it.

Where it works: an affiliated data center, or a managed service tightly integrated into the service organization's own operations (per OneUptime). Where it doesn't: a hyperscale public cloud provider serving thousands of customers, where getting the level of participation inclusive treatment demands is, practically speaking, not going to happen. Linford & Company documents a case in which a tech company assumed its outsourced payroll platform would support inclusive treatment, only to find the provider could not support inclusive treatment as expected. The engagement ended in extra testing, reporting delays, and a hard lesson about confirming cooperation before committing to a method.

The three questions that determine which method fits

None of this is a matter of taste. Three questions, asked in sequence, determine which method is even available, let alone which one is better.

Will the subservice organization cooperate? If there's no written assertion on offer, inclusive is eliminated, regardless of what the service organization or its user entities might prefer. Cooperation means the assertion letter, the representation letter, auditor access, and scheduling alignment, all four, and large infrastructure vendors routinely decline all of it because their own SOC programs already serve that purpose for their entire customer base.

Does the subservice organization already have a current SOC report of its own? If yes, carve-out is defensible and auditors accept it without friction. If no, carve-out leaves user entities with no downstream assurance to go find. Inclusive becomes the only path to giving report users meaningful coverage. The absence of a subservice SOC report is widely recognized as one of the primary conditions that makes inclusive treatment appropriate.

What level of assurance do the user entities actually need? Enterprise buyers in regulated industries sometimes want one consolidated report rather than a stack of vendor reports to cross-reference on their own. And if the subservice organization's controls are woven too tightly into the service organization's own environment to describe separately, carve-out's description may simply not give user entities enough to work with, Truvo Cyber notes. A CPA Journal study surveyed CFOs, chief audit executives, and audit committee members at public companies and found that 51% didn't know whether SOC 1 reports for subservice organizations had even been obtained, and only 26% had made any inquiry of the service organization. That's a sobering number: it means the user-entity burden that carve-out assumes will get picked up downstream frequently isn't picked up.

None of this has to resolve the same way across an entire vendor portfolio. A service organization with multiple subservice organizations can carve out some and include others within the same report, and this is a recognized option under AT-C Section 320, not an exception. Most organizations end up at carve-out because the cooperation prerequisite for inclusive simply can't be met. That's not a shortcut. Auditors accept it as a legitimate outcome because, in most cases, it is one.

What CSOCs must say, and where most carve-out reports fall short

CSOCs aren't optional decoration on a carve-out report. AT-C Section 320 governs their use, and a well-built CSOC does three specific things: it names the control the subservice organization is expected to operate, it ties that control to the specific Trust Services Criterion it supports, and it gives a user entity's auditor enough specificity to know what to look for in the subservice organization's own report.

Weak CSOCs fail at all three. Generic language that doesn't specify which controls are actually expected, no mapping back to the relevant Trust Services Criteria, and ambiguity about what the user entity is supposed to verify on its own, all of it adds up to a disclosure that reads as compliant but doesn't function as one. The point is plain: vague or incomplete CSOC disclosure creates confusion for user entities trying to piece together the full control environment, which is precisely the opposite of what the disclosure exists to do.

The monitoring obligation doesn't stop once the CSOCs are written down, either. Regardless of which method a service organization chose, it has to review the subservice organization's SOC report on a regular basis, address any gap between the subservice organization's audit period and its own period-end, and keep a documented process for handling vendor changes when they happen.

The bar for what CSOCs need to cover is also moving. The same 2024 Konfirmity and CBIZ benchmark found confidentiality now appears in 64.4% of SOC 2 reports, up from 34% in 2023, and as Trust Services Criteria scope broadens, CSOC coverage has to broaden with it. A CSOC disclosure written for a security-only audit can end up materially incomplete the moment confidentiality or availability criteria get added to scope. Incomplete CSOCs don't just create technical audit headaches, either. They create confusion for the enterprise buyers reading the report, and those buyers are the audience actually driving renewals and sales cycles.

How the method choice affects what enterprise buyers and regulators see in the report

Enterprise buyers, particularly in fintech, healthcare, and regulated SaaS, read SOC 2 reports with real sophistication at this point. What they find depends entirely on which method got chosen and how well it got executed.

An inclusive report gives them a single audited opinion covering the full control environment, no separate chase for a subservice organization's SOC report, and a lighter review burden for their own audit teams. A well-executed carve-out gives them nearly the same confidence at lower cost: a named subservice organization, clear CSOCs, and documented evidence of annual review, which is enough for sophisticated buyers when the vendor in question is a known provider with a current SOC 2 of its own. A poorly executed carve-out gives them none of that: an unnamed or vaguely described vendor, generic CSOCs, no visible evidence of review, and a report that raises more questions than it answers. That's the version that slows down or kills an enterprise sales cycle. A verified Type II report removes a common objection in these deals, while a shaky carve-out reintroduces it.

Regulators are raising the stakes on this same question. The UK FCA's Critical Third Parties regime (PS24/16), in force since January 2025, requires designated critical third parties to provide regular assurance, information, and notifications to regulators, and SOC 2 Type II is among the most commonly accepted evidence formats for meeting that obligation. Under the EU's Digital Operational Resilience Act, organizations populating their ICT third-party Register of Information under DORA Article 28 may use SOC 2 reports as evidence of independent verification, and a current Type II can support clients who are themselves subject to DORA oversight requirements. In both regimes, the substance of how a subservice organization was treated (carved out with adequate CSOCs and documented oversight, or included with fully tested controls) affects whether the report actually satisfies what regulators expect to see.

Inclusive audits can shorten sales cycles in regulated industries by handing the buyer one consolidated assurance artifact instead of two reports to reconcile. But that only holds if the cooperation and cost requirements are actually met. For most organizations, a clean carve-out backed by strong CSOCs gets to the same commercial outcome with a lot less friction.

Maintaining the chosen method over time, vendor changes, bridge letters, and audit continuity

A carve-out isn't a document that gets written once and filed away. It requires active upkeep between audit cycles, and the obligations are specific: obtain and review the subservice organization's current SOC report every year, assess whether any exceptions or qualifications in that report touch the service organization's own control environment, and request a bridge letter when gaps in the subservice organization's audit period ends before the service organization's period-end. All of that has to be documented, because enterprise buyers and their auditors will ask to see it, not just hear that it happened.

Vendor change protocol matters just as much. If a subservice organization gets replaced or a new one gets added mid-period, the system description has to be updated, and the choice between carve-out and inclusive treatment reopens from scratch for that new vendor. The same three-question framework applies again, every time.

Inclusive treatment carries its own version of ongoing cost: sustained access for the audit firm and continued coordination across both organizations' timelines, cycle after cycle. The cooperation requirement that made inclusive possible in the first place doesn't end after the first report goes out the door.

The real risk, and it's a quiet one, is drift. Organizations that made the right call at scoping sometimes let the monitoring lapse afterward, no annual review, no bridge letter, no documented process, and the carve-out that was perfectly defensible at audit time turns indefensible by the next engagement or the next enterprise review. The method choice itself gets made once per cycle. The oversight that keeps it credible is continuous, and that oversight, documented properly, is what sophisticated buyers and their auditors are actually evaluating when they open the report.