Subservice Organizations in SOC Reports

A subservice organization is any third party whose controls a service organization depends on to meet its own commitments, and how a SOC report treats that relationship, whether by carve-out or inclusive method, determines exactly what the report proves and what someone else has to go verify. That distinction is technical, but it also decides whether a financial statement auditor, a HUD 232 lender, or a bank relying on a payroll processor can actually trust the piece of paper in front of them, or whether that paper is quietly pointing somewhere else entirely.

Not every vendor clears the bar. Working through the AICPA's language on this took some untangling, but it comes down to three things that all have to hold at once: the vendor's controls have to be necessary for the service organization to meet its service commitments, the vendor's role has to be something customers need described to understand the system, and there has to be a contract obligating the vendor to run specific controls addressing specific risks. Miss any one of those three and the entity is just a vendor, full stop, not a subservice organization. The practical dividing line runs through control, not size or brand recognition. A contractor operates inside the service organization's own systems, under its direct supervision, while a subservice organization runs its own controls independently, with the service organization simply relying on the outcome. How much money changes hands or how big the company is has little bearing on which category applies.

The 2023 AICPA SOC 1 Guide actually removed the defined term "vendor" altogether, which forces the binary: an entity either is a subservice organization or it isn't, no fuzzy middle category to hide in. Cloud infrastructure providers, payroll processors, loan servicing platforms, third-party property managers: these routinely clear the threshold. Getting the classification wrong at the system description stage doesn't stay hidden. Auditors find the gap, user entities find the gap, and by then the examination is already scoped incorrectly.

How the standards governing subservice organizations evolved to where they stand today

SAS 70 got there first, introducing the carve-out and inclusive concepts as the original framework for describing how a service organization's report should handle third-party reliance. It was a reasonable starting point but thin on detail. SSAE 16 filled in a lot of that thinness, codifying explicit guidance on subservice organizations and bringing complementary user entity controls, or CUECs, into the formal framework in a more structured way.

SSAE 18 is where things tightened considerably, and it remains the governing standard today under AT-C Section 320. It raised the bar on what service organization management has to do to monitor its subservice organizations on an ongoing basis, and it demanded more from the system description itself: vague characterizations of subservice relationships no longer pass muster. SSAE 18 replaced SSAE 16 outright.

Then came the February 2023 AICPA SOC 1 Guide revision, which added new examples for identifying and evaluating subservice organizations, clarified that system descriptions must address monitoring controls specifically, and eliminated "vendor" as a defined term to close the ambiguity discussed above. Each revision has continued to address how subservice organizations interact with evolving service delivery models and control frameworks. Each revision has moved in the same direction: more scrutiny over what counts as a subservice organization and what a service organization has to demonstrate about monitoring it.

Why subservice organizations now appear in nearly every SOC report

The CBIZ 2024 SOC Benchmark Study reviewed 193 SOC reports, up from 154 the year before, and found that 89.6% of them included subservice organizations, up from 82% the prior year. Nearly every report in the study addressed the issue in some form.

Why the jump? Cloud computing and API-driven architecture are the mechanical drivers. A single SaaS platform might sit on top of a hyperscale cloud provider, which itself depends on physical data center operators several layers removed from the end customer. Each link in that chain can independently qualify as a subservice organization under the three-condition test. So the practical question facing a service organization today isn't whether to address subservice organizations in its SOC report. It's which method to use, and how much detail that method demands.

What the carve-out method covers and what it leaves for others to verify

Carve-out means the system description names the subservice organization, describes what it does, and then explicitly excludes its controls from the scope of testing. The service auditor tests the service organization's own controls only; the subservice organization's control design and operating effectiveness sit outside the engagement entirely.

According to the CBIZ 2024 benchmark data, 96% of reports that include subservice organizations use carve-out. That dominance isn't an accident. Carve-out works cleanly when the subservice organization already has its own SOC report covering the relevant services, and it avoids forcing a service auditor to independently test an environment it doesn't control or have direct access to. There's also no written assertion required from the subservice organization, which simplifies coordination considerably.

But carve-out shifts the burden somewhere. If the carved-out controls matter to a user entity's financial reporting or risk assessment, that user entity's auditor has to get assurance some other way, typically by obtaining the subservice organization's own SOC report and checking that it actually covers what's needed. That check has two parts: does the report cover the right services, and does the report's coverage period line up with the period in question? A carve-out is a deliberate structural choice, and it depends entirely on the chain of assurance behind it, the subservice organization's own report, actually existing and actually getting checked. If nobody follows through on that verification, the carve-out becomes a hole in practice even though it wasn't designed as one.

When the inclusive method is the better choice and what it requires to execute

Inclusive flips the structure: the subservice organization's controls come inside the scope, the service auditor tests their design and operating effectiveness directly, and the results show up in the report itself. The main reason to choose inclusive over carve-out is straightforward. If the subservice organization doesn't have its own SOC report covering the relevant services, carve-out leaves a real gap, one that user entities have no other document to fill.

Inclusive requires something carve-out doesn't: a written statement of assertion from the subservice organization, which means that organization has to agree to cooperate and put its name on the line. That's a coordination step, and it takes lead time. There's also a coverage period consideration worth flagging here: when carve-out is on the table and a subservice organization's own report exists, that report should cover at least 9 months of a 12-month examination period to actually be useful. Anything shorter starts to strain what the carve-out approach can responsibly claim.

Inclusive costs more to execute. It requires deeper access, more testing, more coordination. But it produces a report that stands on its own, which matters most when a subservice organization's controls are woven so tightly into the service organization's system that carving them out would leave the report incoherent, or leave user entities with no clean way to evaluate that piece independently.

How complementary subservice organization controls and user entity controls define the outer edges of the assurance provided

Complementary subservice organization controls, or CSOCs, are controls that service organization management assumed the subservice organization would have in place when it designed its own system, controls necessary in combination with its own to meet its service commitments. Here's the catch, and it's easy to miss on a first pass: CSOCs are not tested as part of the examination. They're disclosed assumptions. If the subservice organization doesn't actually operate the control the service organization assumed it would, the assurance the report seems to offer has a quiet crack running through it.

A vague CSOC disclosure, something generic like "the subservice organization maintains appropriate security controls," doesn't tell a user entity anything actionable. A well-built CSOC ties directly to a specific control objective or trust service criterion and says, concretely, what the subservice organization is assumed to be doing.

Complementary user entity controls, CUECs, work the same logic in the other direction: these are controls the service organization has determined must exist at the user entity itself for the whole system to function as intended. User entities need to identify which CUECs actually apply to the services they use, and then check whether those controls are both implemented and operating. If a user entity skips this step and a required CUEC isn't in place, that gap belongs to the user entity's own control environment, not to the service organization's report.

Updated AICPA SOC 1 guidance has tightened expectations around monitoring: the system description now has to address what the service organization does to monitor its subservice organizations, both the ongoing kind, regular status reporting and periodic meetings, and the separate, periodic evaluations that go deeper. Taken together, CSOCs and CUECs mark the actual boundary of what any single SOC report proves. Read the report without reading these two categories of disclosure, and the picture that forms is more confident than the facts support.

How financial statement auditors use SOC reports when a client relies on service organizations

SOC 1 reports exist, in large part, to give financial statement auditors structured, third-party-verified evidence about controls at service organizations that touch a user entity's internal control over financial reporting. Without one, the auditor has to find another way in: direct testing, management representations, alternative procedures. All of those options exist. None of them are as efficient or as standardized as a properly scoped SOC 1.

For public companies, this ties directly into SOX ICFR assessments. When a company outsources a function, the controls performed at the service organization become part of that company's own ICFR scope, whether the company likes it or not. A SOC 1 Type II report gives audited evidence the auditor can plug directly into SOX documentation and testing, rather than reconstructing that evidence from scratch.

Where a carve-out is in play, the auditor's job gets more specific. First, identify whether the carved-out controls actually carry financial reporting risk. If they do, go get the subservice organization's own SOC 1 report, or some other sufficient evidence. Then verify, carefully, that the report covers the right services, the right time period, and the right scope. A subservice organization's report that covers different services, or a shorter period than the engagement requires, does not close the gap just because it exists.

Modern financial reporting chains make this a layered problem. A payroll processor, a cloud billing platform, and a data storage provider might each independently qualify as a subservice organization across different reports the auditor has to trace through. And the quality of the original system description, how clearly and specifically it names each subservice organization and characterizes its role, determines how fast and how reliably that chain can actually be followed.

How subservice organization structure plays out in mortgage banking SOC engagements

Mortgage banking is dense with exactly the kind of financially consequential functions that get outsourced: loan servicing, pricing, hedging, valuation, general ledger processing, payment processing. Each of those routinely runs through third-party platforms that meet the subservice organization test. Mortgage servicers themselves are prime candidates for SOC 1 reporting precisely because they process financial transactions and hold records that user entities' own financial statements depend on.

The carve-out pattern shows up constantly in this space. Escrow processors, title insurance vendors, credit reporting agencies: all get described in the system description, all get excluded from testing scope, with user entity auditors pointed toward those vendors' own SOC reports instead. A typical mortgage servicer SOC 1 Type II report follows this exact structure: it covers the servicer's own control objectives and controls, carves out the subservice organizations it relies on, and leaves user entities and their auditors to independently confirm assurance over those carved-out functions.

That confirmation step matters more than it might sound. For a user entity relying on a mortgage servicer, the auditor has to check that each carved-out vendor, the escrow processor, the credit bureau, whichever entities show up in the description, has a current SOC report that actually covers the services in question and lines up with the examination period. Firms with real depth in mortgage banking audits, like Pease Bell, a Cleveland-based CPA firm that conducts mortgage banking audits, understand how these layered relationships map onto financial reporting risk, and that understanding shapes how servicers should structure their system descriptions and CSOC disclosures in the first place, so the chain can actually be followed without gaps opening up along the way.

Subservice organizations in HUD 232 and multifamily housing contexts

HUD 232-insured properties, skilled nursing facilities, assisted living, memory care, lean heavily on third-party management companies, billing agents, and therapy service providers to run daily operations. When a third-party management company controls the books and records of an HUD 232 borrower, as is common, that management company is a subservice organization for purposes of any SOC 1 examination on the operator. Its controls over financial reporting can't just get waved off or omitted from the picture.

Annual audited financial statements for HUD 232 properties have to be prepared under the HUD Consolidated Audit Guide and Government Auditing Standards, and the control environment behind those statements is directly shaped by how well management company controls get documented and monitored. This isn't an abstract compliance concern. Oversight bodies have raised concerns about financial controls and compliance risks among HUD-insured Section 232 borrowers, exactly the kind of breakdown that proper subservice organization disclosure and monitoring exists to catch before it compounds.

Compounding the pressure, HUD ORCF has faced reported staffing pressures in recent periods, meaning individual staff are now managing far more properties each. Federal oversight capacity is stretched thinner than it was. That makes auditor-level scrutiny of the control chain more important, because the safety net above it has fewer hands holding it up. Auditors working in this space need more than general SOC fluency. They need familiarity with HUD's REAC and FASS submission requirements, surplus-cash calculation schedules, and how management company arrangements interact with borrower certification obligations, because those pieces don't show up in a generic SOC 1 training.

What service organizations should do before and during a SOC examination to handle subservice organizations correctly

Start with a complete inventory, and mean complete. Every third party whose controls are necessary to meet service commitments needs to go on the list, evaluated against the full three-condition AICPA test, not a loose approximation of it. Skipping this step, or applying the test casually, is where scope gaps originate.

For each entity that clears the bar, the method decision needs to happen before scoping begins, not partway through the engagement. Does the subservice organization already have a current SOC report covering the exact services in use? If so, carve-out is likely the right call. If no such report exists, or if the coverage that does exist is thin or misaligned, inclusive method deserves serious consideration, and that means starting coordination with the subservice organization early enough to actually secure a written assertion before the examination window closes.

Coverage period deserves its own check, separate from the method decision itself. If carve-out is the plan, confirm the subservice organization's report actually spans enough of the examination period, that 9-month threshold against a 12-month window, to be useful rather than symbolic. A carve-out resting on a report that barely overlaps the period in question isn't really providing the assurance it appears to provide on paper. Sitting with this long enough, the pattern becomes clear: this is probably the single most overlooked step in the entire process. The method gets chosen correctly, the CSOCs get drafted carefully, and then nobody checks whether the underlying report's dates actually line up. That's the kind of gap that surfaces during an audit, at the worst possible time, when there's no runway left to fix it.