Carve-Out or Inclusive? Subservice Organizations in Your SOC 2

Carve out, almost certainly. Under the AICPA's description criteria for a SOC 2 system description (DC section 200) there are exactly two ways to handle a subservice organization, meaning a vendor whose services form part of the system you are reporting on: the carve-out method, which names the vendor and describes its services but excludes its controls from your auditor's testing, or the inclusive method, which pulls that vendor's controls inside your report and inside your auditor's examination procedures. The inclusive method needs the vendor's active cooperation, its own written assertion, and a period that lines up with yours, which is why practitioners describe carve-out as the default by necessity rather than preference (Linford & Company, a CPA firm that sells SOC audits, so read the framing accordingly). Carving out is not free, though. It obliges you to disclose complementary subservice organization controls, and it leaves you owning the monitoring.

The decision itself takes about five minutes for most companies. What takes longer, and what this piece is really about, is the disclosure and monitoring work that follows from it.

Key takeaways

• A subservice organization is a vendor whose services are part of the system you are reporting on, not merely a vendor you buy from. Your cloud host is one; your payroll provider usually is not.
• The carve-out method excludes the vendor's controls from your auditor's testing but still requires you to identify the vendor, describe its services, and disclose the complementary subservice organization controls you are relying on it to perform.
• The inclusive method requires the vendor to participate, assert, and align its period to yours. Large providers generally will not, which decides the question for most companies.
• Carving out does not transfer the risk. You still owe evidence that you selected, reviewed and monitored the vendor, and that evidence is tested.
• The expensive mistake is claiming a control your provider performs as though you performed it. That is the version of this that produces a revision cycle.

What a subservice organization actually is

The definition is narrower than most first-time teams assume, and getting it wrong in either direction costs you.

A subservice organization is a third-party provider whose services form part of the information system you are describing, and whose controls are necessary, in combination with your own, for your service commitments to be achieved. The test is whether the vendor's controls have to work for your commitments to hold. Your cloud infrastructure provider almost always passes that test, because physical security, environmental controls and hypervisor isolation are load-bearing for commitments you make about your service. A managed database or hosting provider usually passes. A payment processor often does.

Plenty of vendors do not pass. Your payroll system, your CRM, your expense tool: these are vendors, they belong in your vendor risk programme, and they are not part of the system in the SOC 2 sense unless they touch the commitments you are reporting on. Sweeping every vendor into the description does not make the report stronger; it makes the description longer, harder to defend in fieldwork, and confusing for the customer reading it.

Get the boundary wrong in the other direction and it is worse. A provider whose controls genuinely carry part of your commitments, omitted from the description entirely, is a completeness problem in Section 3, and it is exactly the sort of thing a careful reviewer at a large customer notices.

The two methods, and what each one asks of you

Carve-out. Your system description identifies the subservice organization, describes the nature of the services it provides, and states which controls you are relying on it to perform. Your auditor does not test those controls. The vendor's own report, if it has one, is a separate document that you obtain and review rather than something your auditor examines on your behalf.

Inclusive. The description covers the vendor's relevant system components and its controls as part of your system, and those controls become subject to your service auditor's examination procedures. That is a substantially bigger undertaking. It requires the vendor to provide detailed control information, to make evidence and personnel available, to align to your observation period, and to participate in your report rather than simply supply its own.

The asymmetry is obvious once stated: carve-out is a disclosure exercise you control, and inclusive is a joint engagement you can only run with a willing partner.

Why nearly everyone carves out

Because the inclusive method requires leverage you probably do not have.

A subservice organization has to agree to be included. It has to open its controls to an audit firm it did not hire, on a calendar set by a customer, and stand behind an assertion inside someone else's report. Providers operating at scale have a much cheaper way to serve the same need, which is to publish their own SOC report and hand it to every customer who asks. Doing the inclusive method for one customer creates an obligation they would then face from thousands.

So the practical position for a normal SaaS company is that inclusive is not really on the menu for infrastructure providers, and carve-out follows. That is not a compromise or a weaker report. It is the standard shape of nearly every SOC 2 report your customers have ever read, and no competent reviewer treats it as a deficiency.

Where inclusive genuinely comes up is a different relationship: a smaller vendor that depends on your business, a corporate affiliate, or a provider you effectively control. In those cases the leverage exists and the question becomes whether it is worth using.

What carving out actually obliges you to do

This is the part that surprises people, because "excluded from testing" sounds like "not my problem".

Disclose the complementary subservice organization controls. These are the controls you are relying on the vendor to perform for your criteria to be met, and they belong in the description. They are a disclosure, not a tested assertion: you are representing that you have a basis to expect those controls exist, and your auditor is not testing them at the vendor. Writing them well matters, because a customer reads this section to understand what your report does and does not cover.

Evidence that you monitor the vendor. The controls that remain squarely yours are the ones around the relationship: how you selected the provider, how you assess it on a defined cadence, what you do with its report, and what happens when its report contains exceptions. Those controls are yours, they are in scope, and they are tested. Obtaining the vendor's report annually and filing it unread is a control that fails the moment an auditor asks what you did with it. Our vendor risk management guide covers the programme this sits inside.

Read the vendor's report properly. Their report will contain its own complementary user entity controls, meaning the things they assume you are doing on your end. Those assumptions frequently become controls in your own description. Working through someone else's report is a skill in itself, and our walkthrough of how to read a SOC 2 report in twenty minutes is written for exactly this.

When the inclusive method is worth the trouble

Three situations, and they are narrower than vendors selling the idea suggest.

The vendor is effectively you. A corporate affiliate, a subsidiary, or an outsourced operations team that works exclusively for you. Coordination is cheap because it is internal, and including them produces a cleaner report for customers than a carve-out that describes a related party at arm's length.

A single vendor performs a control your customers care about most. If the thing your enterprise buyers ask about in every security review sits at a vendor and you can only answer with "we carve them out, here is their report", including them removes a recurring friction point in your sales cycle. Weigh that against the coordination cost honestly, because it recurs annually.

Your customer contract demands it. Rare, but it happens in regulated procurement. If a contract requires the vendor's controls to be covered by your report rather than by a separate one, the decision has been made for you and the work is to find out whether the vendor will play.

Outside those, the carve-out plus a good vendor monitoring programme is both cheaper and easier to defend.

The mistake that costs a revision cycle

One error accounts for most of the pain here: claiming a control your provider performs as though you performed it.

It usually shows up in physical and environmental security. A company lists data centre access controls, environmental monitoring and media disposal among its own controls, when in fact its cloud provider performs all three. In fieldwork the auditor asks for evidence, there is none, and the description has to be rewritten to move those controls into the complementary subservice organization disclosure. That rewrite lands late, it touches Section 3 which then needs re-review, and it is entirely avoidable.

The second-most-common version is subtler: describing the vendor accurately but never stating what you rely on it for. The description names the provider, says what it does in general terms, and stops. A customer reading it cannot tell where your responsibility ends and the vendor's begins, which is precisely the question the disclosure exists to answer.

Both are fixed the same way, and fixed early: for every control in your description, write down who physically performs it. Anything performed by someone outside your company moves to the disclosure, and anything you rely on but did not name gets named.

When this is not your problem

If you run entirely on your own hardware in your own facilities with no third party inside the system boundary, you have no subservice organizations and none of this applies. That is uncommon in 2026 but it is not extinct.

More usefully: if you are a normal SaaS company on one major cloud provider with no unusual dependencies, this decision does not need outside help. Carve out, obtain your provider's report, write the complementary subservice organization controls with care, and build a real annual review of that report into your calendar. That is a day of work for someone who has done it before and perhaps a week for someone who has not, and buying consulting for it is buying reassurance rather than expertise.

The case for help is a messy boundary: several providers whose relationship to your commitments is genuinely arguable, an affiliate relationship, an acquisition that brought its own stack, or an enterprise customer disputing your description. Ambiguity is what costs money here, not the mechanics.

Where Top Floor fits

Boundary decisions and the system description are a large share of what our audit and assurance work is: deciding which providers are inside the system, drafting the disclosures so they survive both fieldwork and customer review, and then handling the auditor's questions about them. We manage the examination around an independent CPA firm; we do not perform it and do not issue opinions.

If the gap is that nobody is actually reviewing vendor reports between audits, that is a programme problem and compliance as a service is the purchase. If you are still ahead of an examination and setting scope for the first time, start with SOC 2 readiness, where the boundary question belongs.

How to decide this week

Take your control list and put a name next to every control: which company performs it. Anything with a vendor's name is either a complementary subservice organization control or a control you have misattributed to yourself, and sorting that list is most of the work.

Then make a second list of every third party that touches the service you are reporting on, and against each write one sentence: does this vendor's control failure break a commitment we made to customers? Yes means subservice organization, no means ordinary vendor. Do not agonise over the middle cases alone; take them to your auditor early, because scope questions are cheap before fieldwork and expensive during it.

Finally, download your cloud provider's current report and check three things: the period it covers, whether it is current, and what its complementary user entity controls expect of you. If that last list contains anything you are not doing, you have found this week's actual work.

Frequently asked questions

What is a subservice organization in a SOC 2 report?

It is a third-party provider whose services form part of the system you are reporting on, and whose controls are necessary, together with yours, for your service commitments to be achieved. Your cloud infrastructure provider is the standard example, because physical security and environmental controls at their facilities are load-bearing for commitments you make about your service. The test is whether that vendor's control failure would break something you promised a customer. Vendors that fail the test, such as your payroll or CRM tools, belong in your vendor risk programme rather than in the system description.

Should we use the carve-out method or the inclusive method?

Carve out, in almost every case, and usually because the choice is not really yours. The inclusive method requires the subservice organization to open its controls to your auditor, provide its own assertion, and align to your observation period, and providers operating at scale decline because publishing their own report serves every customer at once. The inclusive method makes sense mainly for an affiliate, a subsidiary, or a vendor that depends on your business enough to participate. Carving out is the standard shape of nearly every SOC 2 report in circulation and no competent reviewer treats it as a weakness.

Do we still need our cloud provider's SOC 2 report if we carve them out?

Yes, and you need evidence that you read it. Carving a provider out excludes their controls from your auditor's testing; it does not remove your own controls around vendor selection, assessment and monitoring, and those controls are yours and are tested. An auditor asking about vendor management will want to see that you obtained the current report, reviewed it on a defined cadence, considered any exceptions in it, and acted on the complementary user entity controls it expects of you. Filing the report unread is a control that fails the first question.

What are complementary subservice organization controls?

They are the controls you are relying on your carved-out vendor to perform in order for your own criteria to be met, disclosed in your system description so a reader can see where your coverage ends. They are a disclosure rather than a tested assertion: you are representing that you have a reasonable basis to expect those controls exist at the vendor, and your service auditor is not testing them there. They are the mirror image of the complementary user entity controls in your provider's report, which are the things that provider assumes you are doing on your end.