August 6, 2026

Subservice organizations: how the scoping call sets your SOC engagement

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Key insights

A vendor is a subservice organization when its controls have to work for your client's system to meet its commitments. Make the call at scoping, not in fieldwork.
Carve-out isn't the easy option. It trades fieldwork for CSOC and CUEC mapping, upstream report review, and bridge-letter chasing, every engagement, every period.
Inclusive needs the subservice organization's written assertion, representations, and auditor access. Confirm cooperation before the description is drafted, or the choice gets made for you.

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.

What makes a vendor a subservice organization

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:

SOC 2: the AICPA's SOC 2 Description Criteria points to controls needed, together with the service organization's, to give reasonable assurance that service commitments and system requirements were met.
SOC 1: AT-C Section 320 frames it around services likely to be relevant to user entities' internal control over financial reporting.

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: what you exclude and what you still owe

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:

Reading the subservice organization's own SOC report
Evaluating the exceptions
Handling any gap periods
Documenting your conclusion

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.

Inclusive: more assurance, more logistics

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.

Where engagement teams lose the hours

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.

Upstream report review

An upstream SOC report only earns its place if it covers:

The exact services your client uses
The right period
The relevant controls
The exceptions that matter

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.

The CSOC and CUEC mapping cascade

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.

Bridge letters and gap periods

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.

How to pick the right method before scoping locks in

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:

Will the subservice organization give you a written assertion, representations, and auditor access? A no rules out inclusive on the spot.
Do the user entity contracts forbid carve-out? A commitment like "no carve-out of subservice controls" points you straight to inclusive.
Does the subservice organization have a current SOC report covering the exact services and period you need? If it does, carve-out monitoring is workable. If it doesn't, monitoring gets expensive fast, and the relationship might be worth a second look on its own.
Can your firm absorb the peer review exposure and three-party coordination inclusive demands?

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.

Run subservice organization evidence on one system with Fieldguide

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.