If your platform runs on a cloud provider, uses a managed data centre, or hands part of the service to a specialist partner, your SOC report has to say something about them. You have two options for how. The carve-out method names the vendor, describes what you rely on them for, and excludes their controls from your description and from the auditor’s testing. The inclusive method brings their relevant controls inside your report and has your service auditor test them.
Carve-out is the far more common choice, mostly for practical reasons rather than technical ones. But the decision has real consequences for what your buyers can conclude from the report, and it is worth making deliberately rather than by default.
First: which vendors are actually subservice organizations
Not every vendor is one, and over-identifying them creates work you do not need.
A subservice organization is a vendor used to perform some of the services you provide to your customers, whose controls are necessary — in combination with your own — for the applicable trust services criteria or control objectives to be achieved. The test is whether their controls have to work for your commitments to be met.
Your cloud infrastructure provider almost certainly qualifies: their physical security and hardware controls are genuinely part of how your service protects customer data. A BPO that processes transactions on your behalf qualifies. A managed SOC provider running your detection and response may qualify.
Your payroll platform, your CRM, your expense tool and your marketing automation vendor generally do not. They are vendors you manage under your vendor risk programme, but they are not part of delivering the service your report covers. The distinction is worth getting right because subservice organizations carry disclosure obligations that ordinary vendors do not.
What the carve-out method does
Under the carve-out method, your system description identifies each subservice organization, describes the services they provide and states which types of controls you assume they operate. Those assumed controls are the complementary subservice organization controls, usually presented as a list similar in form to complementary user entity controls.
Their controls are then excluded from your description, from the auditor’s testing procedures, and from the opinion. Your service auditor examines your controls; the subservice organization’s controls are outside the boundary.
Critically, this does not remove your responsibility for them. The trust services criteria include vendor and business partner risk management, and your monitoring of the subservice organization is itself a control inside your report that will be tested. In practice that means: obtaining and reviewing their SOC report each year, reading the exceptions and the complementary subservice organization controls, tracking that review with a date and a reviewer, and escalating anything relevant. If your auditor asks how you monitor your cloud provider and the honest answer is “we assume they are fine”, that is a testable control failing.
Carve-out is the default for a reason. Large infrastructure providers do not participate in individual customers’ examinations, publish their own reports at scale, and would not coordinate assertions with thousands of service organizations. The method exists precisely so that reliance on a well-audited vendor can be disclosed without pretending you can test them.
What the inclusive method does
Under the inclusive method, the subservice organization’s relevant controls are described in your system description alongside yours and are tested by your service auditor. Their controls appear in the test results section. The opinion covers them.
The requirements are heavier than most people expect:
- The subservice organization has to agree. They must be willing to have their controls described, examined and reported on inside someone else’s report.
- They provide their own written assertion. Management at the subservice organization asserts on the portion of the description relating to them.
- Periods have to align. Their controls need to be examined over the same period your report covers.
- Their exceptions land in your report. If a control at their end failed during the period, that exception appears in your document and your buyers read it.
- Contracts need to support it. Access for the auditor, cooperation on evidence, and timing commitments should be written down, not assumed.
That last point is where inclusive engagements most often stall. The commercial relationship has to be close enough that the subservice organization will accept audit obligations on your schedule.
Choosing between them
The carve out method and the inclusive method are not equally weighted options in practice — the first is the default and the second is the exception you make deliberately.
| Carve-out | Inclusive | |
|---|---|---|
| Vendor’s controls described | Types only, as assumptions | Yes, in detail |
| Vendor’s controls tested by your auditor | No | Yes |
| Vendor assertion required | No | Yes |
| Vendor cooperation required | Minimal | Substantial |
| Reader must obtain vendor’s own report | Yes | No |
| Typical fit | Large cloud and infrastructure providers | Affiliates, dedicated partners, vendors without their own report |
The inclusive method is worth considering in a few specific situations.
The subservice organization is closely held. A subsidiary, an affiliate under common ownership, or an offshore delivery entity that is effectively part of your operation. Cooperation is not a negotiation, and buyers get a single coherent picture instead of being sent to look at a related party’s separate report.
They have no report of their own. If a critical partner cannot produce a SOC report and never will, carving them out leaves a hole your buyers cannot fill. Including them may be the only way to give a reader assurance over that part of the service.
Buyers keep asking about that specific dependency. If every security review stalls on the same partner, folding them in may be cheaper than answering the question forty times a year.
For most service organizations, none of those apply and carve-out is correct. Carving out is not a weaker choice; it is the accurate one when you genuinely do not control or test the vendor’s environment.
You can mix methods in one report
This surprises people. There is no requirement to treat every subservice organization the same way. A report can carve out a hyperscale cloud provider while including a dedicated processing partner. The description simply has to be clear about which method applies to which organization, so a reader knows what the opinion covers.
Where the description gets vague — a subservice organization mentioned in passing without stating the method, or complementary subservice organization controls that are missing entirely — a careful reader cannot tell where your boundary is. That is a description quality problem your auditor will raise before the report issues, and it is easier to solve while you are drafting than during fieldwork.
What buyers do with this section
Reviewers reading your report use the subservice organization disclosure to build a picture of the whole chain. If you carve out, a diligent reviewer will go and get that provider’s report, read its complementary subservice organization controls, and check that the things you assumed they do are things they actually claim to do.
That check occasionally fails. A service organization assumes its provider handles something the provider’s own report explicitly pushes back to customers, and the responsibility falls into the gap between the two documents. Reading your subservice organizations’ reports against your own assumptions once a year is the cheapest way to catch that.
What to do next
List every vendor involved in delivering the service your report covers and mark each one as a subservice organization or not, using the criteria test rather than instinct. For each one you mark yes, decide the method and write down why.
Then take your largest carved-out provider, open their latest report, and check whether the controls you assume they operate are the controls they say they operate. Assurion works through subservice organization scoping with clients during readiness, because it is much cheaper to settle the boundary before the description is written than after.