Learn · SOC Reports
Subservice Organizations,
Carve-Out vs Inclusive
A subservice organization is a vendor your service provider relies on to deliver its own service — one whose controls are necessary, in combination with the provider's own, to meet commitments to customers. Think AWS beneath a SaaS. SOC reports handle them one of two ways: carve-out (exclude and disclose) or inclusive (include and test).
Not every vendor qualifies. The office-cleaning company and the sales CRM are vendors; the cloud host running production is a subservice organization. The test: if their controls fail, do your commitments to customers fail?
Plain-English explainer · Applies to SOC 1 & SOC 2 · Last reviewed July 2026
A subservice organization is a vendor your service provider relies on to deliver its own service — one whose controls are necessary, in combination with the provider’s own, for the provider to meet its commitments to customers. Think AWS beneath a SaaS platform. SOC reports handle them one of two ways: carve-out (exclude and disclose) or inclusive (include and test). The concept works identically in SOC 1 and SOC 2. Where a carved-out report assumes specific controls at the vendor, those assumptions are listed as CSOCs — and their customer-side mirror is the CUEC. Both of those lists get a full treatment in our CUECs & CSOCs explainer; this page goes deeper on the underlying concept — what makes a vendor a subservice organization in the first place, how the two methods actually work, and what report readers and service organizations each need to do about the dependency.
Definition
What Counts as a Subservice Organization
In the attestation standards behind SOC 1 and SOC 2, a subservice organization is an organization the service organization uses to perform services that are relevant to the service organization’s own system — meaning its controls are needed, together with the service organization’s, to achieve the principal service commitments and system requirements (in SOC 1 terms, the control objectives). That word necessary is what separates a subservice organization from an ordinary vendor.
Usually a subservice organization
- The cloud or hosting provider running your production environment — compute, storage, physical security, environmental controls.
- A managed SOC / MDR provider monitoring your security alerts, when detection and response are part of what you promise customers.
- A payment processor executing transactions inside your service’s delivery path.
- Sub-processors that store, process, or transmit customer data as part of delivering your service.
Usually just a vendor
- The office-cleaning company — no relationship to your service commitments.
- The CRM your sales team uses to track its own pipeline — it supports your business, not the audited system.
- Internal HR or expense tooling that never touches the in-scope system or customer data.
- A marketing analytics tool measuring your website traffic — outside the boundaries of the system description.
The one-question test
“If their controls fail, do your commitments to customers fail?” If AWS loses physical control of the data centre, the SaaS company’s availability and security commitments fail with it — subservice organization. If the cleaning contractor has a bad week, nothing in the SOC report is affected — vendor.
The classification matters because it changes the report. Vendors are handled by ordinary vendor-management controls. Subservice organizations must be identified in the system description, handled by one of exactly two methods, and — under carve-out — leave visible assumptions (CSOCs) that every reader of the report is expected to chase down.
The Two Methods
Carve-Out or Inclusive
Management chooses the treatment for each subservice organization — and the attestation standards allow exactly two. The choice decides whose controls the auditor tests, whose management signs an assertion, and how much homework is left for the reader.
Carve-out method
- The description excludes the subservice organization’s controls, and instead discloses the nature of the services it performs.
- The report identifies the CSOCs — complementary subservice organization controls — that the system assumes the subservice organization performs.
- The service organization’s own monitoring controls over the vendor — reviewing its SOC reports, SLAs, and incident notifications — stay in scope and are typically tested.
- The overwhelming majority of SOC reports use carve-out: it requires nothing from the vendor beyond the assurance documents it already publishes for customers.
Inclusive method
- The subservice organization’s relevant controls are included in the system description and tested by the service auditor.
- The subservice organization’s management must provide its own written assertion and its own written representations to the auditor.
- Demands deep cooperation between both organizations and both managements — audit planning, evidence access, and legal comfort on each side.
- Rare in practice: realistic mainly when the subservice organization is small, captive, or contractually intertwined — an affiliated data-centre operator, for example.
Why does carve-out dominate? Because the typical subservice organization is a hyperscale cloud provider that will not join a customer’s audit — it publishes its own SOC reports instead, and expects you to rely on those. Inclusive only becomes realistic when the relationship runs deeper than a standard customer contract: an affiliate, a captive data-centre operator, a partner whose operations are effectively an extension of yours. For what the resulting CSOC lists mean — and how they mirror the CUECs your report places on your own customers — see CUECs & CSOCs.
Reader Mechanics
How It Looks Inside the Report
Section 3 — management’s description of the system — names each subservice organization, the services it performs, and the method used; the auditor’s opinion also flags the method. In a carve-out report, the language runs along these lines:
“The description excludes the controls of AWS. The trust services criteria can be achieved only if the controls expected to be implemented at AWS, described herein as complementary subservice organization controls, are suitably designed and operating effectively.”
Read that carefully: the opinion on the service organization is conditional on a set of controls nobody in this report tested. Closing that loop is the reader’s job — and it is the step most vendor reviews skip. When you assess a report, work through the subservice organizations the same way you work through the rest of the report’s structure:
- Find the subservice-organization list in Section 3 and note the method used for each one.
- For every carved-out vendor, obtain its own SOC report — for the hyperscalers, these are published for customers to download and review.
- Check that vendor’s report period overlaps the period you care about, and read its opinion and exceptions against the specific CSOCs your service organization relies on.
- Note what the vendor’s report carves out in turn — for critical chains, this is your fourth-party risk, and it can run several layers deep.
- Confirm the service organization’s monitoring controls over its subservice organizations were tested, and read any exceptions against them closely.
If the subservice organization’s own report carries a qualified opinion or exceptions touching the CSOCs in question, treat it exactly as you would exceptions in the primary report: ask what failed, what compensates for it, and whether it touches the services you consume.
Playbook
Getting It Right as a Service Organization
If you are the one being audited, the subservice-organization work happens in scoping and in your vendor-monitoring controls — long before the auditor arrives.
- Identify your subservice organizations during scoping: hosting, managed SOC/MDR, payment processors, and sub-processors that handle customer data in your delivery path.
- Choose the method for each — in practice, almost always carve-out.
- Implement and evidence monitoring controls: an annual review of each subservice organization’s SOC report (its opinion, its exceptions, the CUECs it places on you, and its period coverage), SLA reviews, and incident-notification clauses in the contract.
- Map their CUECs into your control set. It is a chain: their CUECs become your controls, and your CUECs become your customers’ controls.
- Disclose accurately in your system description — name each subservice organization, the services it performs, and the method used.
Common pitfalls
- Treating every vendor as a subservice organization — it bloats the report and buries the dependencies that actually matter.
- Missing a real one — the report understates your dependency, and a reader who knows your architecture will notice.
- Ignoring period misalignment — a subservice organization’s report that ends months before yours leaves an unexamined gap in the chain.
- Relying on a subservice organization with a qualified opinion without documenting compensating controls on your side.
- Assuming carve-out means “not my problem” — the monitoring is your problem by design; that is the trade the method makes.
A note on that period point: your own customers manage the gap between your report period and their fiscal year with a bridge letter — and you should expect to manage your subservice organizations’ gaps the same way. In SOC 2 and SOC 1 readiness engagements, Tranquility Cybersecurity builds the subservice-organization inventory, the method decisions, and the monitoring evidence before the examination begins — the examination itself is performed by empanelled, independent licensed CPA firms.
Subservice Organizations — Common Questions
Which vendors qualify, how the two methods differ, and how far down the chain to look.
What is a subservice organization?
A subservice organization is a vendor a service organization uses to perform services that are relevant to the service organization’s own system — meaning its controls are necessary, in combination with the service organization’s controls, to achieve the service organization’s principal service commitments and system requirements (in SOC 1, the control objectives). The classic example is the cloud provider hosting a SaaS company’s production environment. The concept applies identically in SOC 1 and SOC 2.
What is the difference between the carve-out and inclusive methods?
Under the carve-out method, the subservice organization’s controls are excluded from the description; the report discloses the services it performs and lists the CSOCs the system assumes it operates, and readers close the gap with the vendor’s own SOC report. Under the inclusive method, the vendor’s relevant controls are included in the description and tested, and the vendor’s management must provide its own written assertion and representations. Carve-out is by far the more common method.
Is AWS a subservice organization?
For an organization hosting its production system on AWS, yes — AWS performs services (infrastructure, physical security, environmental controls) whose functioning is necessary to meet that organization’s commitments, so it is disclosed as a subservice organization, virtually always under the carve-out method. AWS publishes its own SOC reports for customers to review, which is how readers close the carve-out gap. The same logic applies to Azure, Google Cloud, and other hosting providers.
Is every vendor a subservice organization?
No. Only vendors whose controls are necessary — together with the service organization’s own — to meet the service commitments qualify. The office-cleaning company and the sales CRM are vendors, handled through ordinary vendor management; the cloud host running production is a subservice organization. A useful test: if their controls fail, do your commitments to customers fail? Listing every vendor bloats the report; missing a real subservice organization understates your dependency.
What are CSOCs?
CSOCs — complementary subservice organization controls — are the controls a carved-out report assumes the subservice organization performs. They appear in the system description, and the auditor’s conclusions hold only if those controls are actually in place at the vendor, which is why readers obtain the vendor’s own SOC report. They mirror CUECs, the controls the report assumes customers operate. Our CUECs & CSOCs explainer covers both in depth.
Do I need to review my vendor’s subservice organizations’ reports too?
For critical dependencies, look one layer down. Your vendor’s SOC report will name its own carved-out subservice organizations — that chain is your fourth-party risk. In practice, you rely primarily on your vendor’s tested monitoring controls over its subservice organizations, and go deeper yourself where the dependency is material: if your vendor’s entire service sits on one hosting provider, it is reasonable to confirm that provider holds a clean, current SOC report as well.
Why would anyone use the inclusive method?
Because it gives readers single-document coverage: the subservice organization’s controls are described and tested in the same report, with no separate vendor report to chase. The price is cooperation — the vendor’s management must sign its own assertion, provide representations, and open itself to testing — which is why inclusive is realistic mainly for small, captive, or affiliated subservice organizations, such as a data-centre operator under common ownership, and effectively impossible with hyperscale cloud providers.
Related reading: the Learn hub, CUECs & CSOCs, how to read a SOC 2 report, opinions and exceptions, what SOC 2 is, and our SOC 2 and SOC 1 services. More terms — including Carve-out Method, Inclusive Method, and CSOC — in the compliance glossary.
Written By Expert Auditors
Get in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours