Short answer: The carve-out and inclusive methods are two ways a SOC 2 report can treat a subservice organization, such as your cloud host. With carve-out, the report describes the provider’s services but excludes its controls from testing. With the inclusive method, the provider’s controls are described and tested as part of your examination. Most companies use carve-out.
Almost no modern service organization runs everything itself. You host on a public cloud, process payments through a gateway, send email through a platform and answer support tickets in a SaaS tool. Some of those providers do work that your SOC 2 controls depend on. The way your report treats them has a large effect on what the auditor tests, what the report says and what your customers conclude.
This article explains the two methods, when each is used, what complementary subservice organization controls are and how to manage providers so that your report holds up.
What is a subservice organization?
A subservice organization is a third party that performs a service which is part of your system and whose controls are needed to meet the criteria in your report. Think hosting, data storage, a managed security provider, or an outsourced operations team that runs part of your production environment.
Not every vendor qualifies. Your office coffee supplier is a vendor, not a subservice organization. A project management tool that holds no customer data and plays no part in delivering the service is a vendor too. The test is whether the provider’s controls are relevant to your service commitments. Vendors that fail the test still need managing, but they are described differently. Our guide to third-party risk management for SOC 2 covers vendor oversight in general.
The carve-out method
Under carve-out, the system description names the subservice organization, explains what it does for you and says that its controls are excluded from the examination. The auditor does not test them. The description also lists the controls the provider is expected to operate, known as complementary subservice organization controls (CSOCs), and states that your criteria can only be met if those controls work.
This is the most common treatment for large cloud providers. They publish their own SOC reports, run audits at a scale no single customer could influence, and would not allow each customer’s auditor into their data centers.
What carve-out means for you
- Your auditor tests your controls, not the provider’s.
- You still must monitor the provider. Reviewing its report each year and mapping its stated customer responsibilities to your own controls is a standard expectation.
- Your report clearly says which provider controls you depend on, so readers know the dependency exists.
The inclusive method
Under the inclusive method, the subservice organization’s relevant controls are included in your system description and tested as part of your examination. The provider must agree to participate, provide a written assertion and give the auditor access to evidence. The report then speaks directly to the provider’s controls, as well as yours.
This is far less common because it needs the provider’s cooperation and adds scope, cost and coordination. It tends to appear when the provider is small, closely tied to you or effectively an extension of your team, for example an outsourced operations or support function that runs key controls on your behalf.
Carve-out vs inclusive at a glance
| Carve-out | Inclusive | |
|---|---|---|
| Provider’s controls tested in your report | No | Yes |
| Provider must participate | No | Yes, including a written assertion |
| Typical providers | Large cloud, payment and infrastructure vendors | Small or closely integrated providers |
| Effort and cost | Lower | Higher |
| What the reader sees | A dependency and its CSOCs | Tested provider controls in the report |
| Your ongoing duty | Monitor the provider and review its report | Coordinate evidence and scope with the provider |
Complementary subservice organization controls
CSOCs are the controls your report assumes the provider operates. Examples include physical security of data centers, hypervisor patching, network infrastructure monitoring and encryption of storage at rest by the platform. Your description should state them plainly so readers can see the dependency.
A related idea works in the other direction. Your cloud provider’s own report lists controls it expects you to implement, called complementary user entity controls. These are your side of the shared responsibility model: configuring identity and access, encrypting your data, setting network rules and so on. This is why you cannot treat a provider’s SOC report as proof that your own environment is secure. We explain that trap in subservice providers and your SOC 2. For readers on the receiving side, how to read a SOC 2 report shows where CUECs and carve-outs appear.
How to manage subservice organizations step by step
- Inventory your providers. List every third party that touches the in-scope system, even indirectly.
- Classify them. Mark which are subservice organizations because their controls are needed to meet your criteria, and which are ordinary vendors.
- Choose the method. Carve-out is the default for large providers. Discuss inclusive with your auditor only if a provider performs key controls for you.
- Obtain the provider’s report. Major cloud platforms offer their SOC reports through customer portals, such as AWS Artifact. Read the report period, scope, exceptions and the customer responsibilities section.
- Map responsibilities. For each provider control you rely on, note how you confirm it, and for each customer responsibility in their report, note which of your controls covers it.
- Document the dependency. Describe each provider and the CSOCs in the system description.
- Review annually. Refresh the provider’s report, check for exceptions affecting you, and record the review as evidence.
For cloud-specific mapping, see our guides to cloud security and SOC 2 and AWS security controls for SOC 2.
Common mistakes
- Assuming the cloud provider’s report covers you. It covers their platform, not your configuration.
- Not collecting the report. Without the provider’s SOC report and your review of it, the carve-out has no support.
- Listing a vendor as a subservice organization when it is not one, or the reverse. Misclassification confuses scope and weakens credibility.
- Ignoring bridge periods. The provider’s report period may not line up with yours. Check the dates and request updates or letters when needed.
- Letting an outsourced team run key controls without evidence. If a contractor performs access reviews or backups for you, your auditor will ask for proof that those controls operate.
- Forgetting scope. Provider treatment belongs in the scope decision. Our article on defining SOC 2 scope explains where it fits.
Business implications
Customers read your treatment of subservice organizations to judge how much of their risk you are really carrying. A report that clearly states dependencies and shows annual provider reviews builds trust. One that hides behind a provider’s reputation raises questions. For companies planning a first report, getting this right early avoids rework during fieldwork. SOC2.in’s SOC 2 Type I and Type II audit support includes help documenting these dependencies.
A practical guide to choosing between the two methods
The choice between carve-out and inclusive is made with your auditor, but you can prepare by thinking through a few questions. The answers usually point clearly in one direction.
| Question | Leans toward carve-out | Leans toward inclusive |
|---|---|---|
| Does the vendor publish its own SOC report? | Yes, and customers can request it | No report is available |
| How central is the vendor to your service? | Supporting infrastructure | Core to delivering a commitment you make |
| Will the vendor cooperate with your auditor? | Not needed | Yes, willing to provide evidence and a written assertion |
| What do your customers expect? | Accept a list of subservice organizations | Ask for end-to-end coverage |
What you still own under carve-out
Carving out a vendor does not remove your responsibility to manage it. You still need to review its report each year, check the period and scope, read its exceptions, and confirm that you operate the complementary controls it expects from you. Record that review with a date and a reviewer. Missing vendor-review evidence is one of the most common findings in this area. Our guide on subservice providers walks through the cloud-provider version of this.
Frequently asked questions
What is the carve-out method in SOC 2?
It is a way of presenting a subservice organization in which the description includes the provider’s services but its controls are excluded from testing, and the dependency is stated as a complementary subservice organization control.
What is the inclusive method in SOC 2?
It is the alternative, where the provider’s relevant controls are described and tested as part of your examination, with the provider’s participation and written assertion.
Is AWS a subservice organization in my SOC 2?
If you host the in-scope system on it and rely on its controls, such as physical security, it is typically treated as a subservice organization under the carve-out method.
What are CSOCs?
Complementary subservice organization controls are controls your report assumes the provider operates in order for your criteria to be met.
Do I still need to review the provider’s SOC report if it is carved out?
Yes. Carve-out means the auditor does not test the provider, so you are expected to monitor it yourself, including reading its report each year.
Which method should I use?
Most companies use carve-out for large cloud and infrastructure providers. Consider the inclusive method only when a smaller provider performs key controls for you and agrees to participate.
Conclusion
Treat subservice organizations as a deliberate part of your SOC 2 design. Classify providers correctly, usually choose carve-out, collect and read their reports, map responsibilities in both directions and document the dependency clearly. Do that, and your report shows maturity instead of leaving buyers to guess what you outsource.
