Key insights
Two weeks into fieldwork, a senior flags that the client's payroll SaaS runs on a hyperscaler that wasn't named in the system description. The carve-out versus inclusive question reopens, the description gets rewritten, and someone starts chasing an upstream SOC report and a bridge letter to cover the gap. Every hour of that came from misclassifying one vendor at the scoping stage.
The call turns on control dependency: whether the third party's controls have to operate for the client's system to meet its commitments. This article covers how to make that call, what carve-out and inclusive each cost you after issuance, and where the hours actually go once the method is set.
A vendor becomes a subservice organization when its controls have to work, alongside your client's own, for your client's system to meet its commitments. That's the whole test. The standards put it two ways:
Same idea, different report.
That dependency test answers most calls. One more question catches the rest: do report users need the third party's services described to understand the system? A yes to either takes it out of ordinary vendor treatment.
This call turns on control dependency, not contract size or how big the vendor looms. A payroll SaaS running on AWS depends on AWS's physical security, environmental, and infrastructure controls to meet its own availability and security commitments, so AWS is a subservice organization. A background-check provider your client's HR team uses at onboarding is not, however large the contract, because its controls don't have to operate for the client's system to hold up. The call gets missed most often on the IaaS and PaaS providers sitting under SaaS platforms. Make the call before anything else in scoping.
Carve-out is the method most firms reach for, and it's easy to read as the light option. It leaves the subservice organization's control objectives and controls out of both the system description and the examination scope, so your auditor never tests them. But you don't walk away clean. Management still has to identify complementary subservice organization controls (CSOCs): the controls it assumed would be running at the subservice organization when it designed the system.
The description has to make that relationship clear to report users, too: what the subservice organization does, which of its controls fall outside the examination scope, and which CSOCs your client is relying on.
And the monitoring never stops. Your client owns the risk of the services it uses, and in a SOC 2 that maps to criterion CC9.2 on vendor and business-partner risk. In practice, it means:
You test those monitoring controls and evaluate how they're presented, even with the subservice organization carved out. One more thing: carve-out and inclusive aren't all-or-nothing. You can carve out one subservice organization and present another inclusively in the same report.
The inclusive method does the opposite: it pulls the subservice organization's services and controls into the description and into the service auditor's testing. It's the strongest presentation a report user can get, and the hardest to pull off. It only happens if the subservice organization cooperates. Without its written management assertion and written representations, inclusive is off the table before you start.
The testing widens, too. Your auditor runs comparable procedures over the subservice organization's work, and PCAOB interpretation says that can mean testing controls at the subservice organization itself. Someone has to arrange that access, so now you're coordinating three parties before a single sample gets pulled.
And your firm carries more risk. For peer review, inclusive rates higher-risk than carve-out. A peer review exposure draft flags engagements with significant subservice organizations identified in the opinion for extra scrutiny. That's why most firms default to carve-out.
Carve-out doesn't make the work disappear. It moves into your evidence file, and the data says it's getting shortchanged. A CPA Journal study surveyed the people who lean on these reports: CFOs, chief audit executives, and audit committee members at public companies. Even there, 51% didn't know whether SOC 1 reports of subservice organizations had even been obtained, and only 26% had made inquiries of the service organization. That's the user side, not service auditors, but the same steps sit inside your carve-out engagements, and every one has its own friction.
An upstream SOC report only earns its place if it covers:
A hyperscaler report can run several hundred pages across storage, compute, networking, identity, and managed database services, and your client touches only a slice of it. So the reviewer's first job is filtering down to that slice. An exception in a service your client never uses is noise. An exception in one it depends on might mean adding a compensating control on your side. Then there's the cross-check: confirming the subservice organization's controls actually cover the CSOCs the primary report claims, line by line, across two documents.
Mapping is the cross-check that ties the two reports together: every control one side counts on has to actually exist and operate on the other. It runs in both directions. Every CSOC in the service organization's report has to trace to a real control in the subservice organization's report. And every complementary user entity control (CUEC), a control the subservice organization expects its customers to run, has to trace back to a control the service organization actually operates.
The gaps are specific. Say a CSOC assumes the cloud provider restricts physical access to its data centers, but the upstream report only covers logical access. Nothing backs the CSOC, and the description has a hole the reviewer will find. It happens the other way too: if the cloud provider's report tells customers to configure encryption at rest and manage their own keys, the service organization has to name a real operating control for key management, not a policy that says the box is checked. Either way, it usually surfaces after the description is signed off, when your options are narrow.
It can go deeper. When the subservice organization leans on its own subservice organizations, the chain extends another layer, and you have to decide how far down your procedures reach. Report users only see the top line. You walk the whole chain, and a gap two layers down still lands on the engagement partner.
A SOC report covers a set period, and it rarely lines up with your examination window. The stretch it doesn't reach is the gap period. To cover it, somebody ends up chasing a bridge letter: management's written statement that nothing material changed in its controls after the report closed.
It's thinner evidence than most clients think. A bridge letter carries no service auditor opinion, and if the gap runs too long, you're back to testing as though no SOC report existed at all.
So treat it as calendar management: ask early, chase the follow-ups, log what comes back, weigh what changed during the gap, and write down why the coverage still holds. Then do it again for every carved-out subservice organization on every engagement you're running.
Pervasiveness can settle it before you start. The more the subservice organization's services and controls drive the system, the harder carve-out is to defend: excluding them can leave the description short of a fair presentation and put the opinion at risk. Weigh that first. Everything after it is a more open call.
When both methods are open, four questions sort it out before scoping:
Get this wrong and you're rewriting the description and reversing the method mid-engagement, so decide before the description is drafted. It's also the work agentic AI is reaching first: chasing bridge letters, reviewing monitoring reports, and flagging carve-out gaps.
Strip it back and the subservice organization workload is really evidence logistics: pulling upstream reports, mapping CSOCs and CUECs, logging bridge letters, and documenting monitoring conclusions, usually spread across files and inboxes. Fieldguide puts all of it on one system, with pre-built SOC 2 frameworks, request tracking, and a central document repository that keeps the evidence trail out of email.
Field Agents execute the evidence review the moment documents land and flag gaps and inconsistencies. Practitioners review and approve every output before it goes anywhere. The engagement math follows: BerryDunn reported 30–50% efficiency gains and more than doubled its engagement capacity on its SOC practice. If subservice evidence is eating your engagement hours, see how Fieldguide handles the whole lifecycle in one place and request a demo.