.svg)
During a recent SOC 2 engagement, the question came up: the company runs its production systems in a colocation facility. Physical security, power, cooling, and facility access are all managed by the data center provider. The company doesn't control those systems. But its SOC 2 audit covers security controls that depend on physical security being effective. So whose controls are those, and how do they show up in the report?
The answer involves Complementary Subservice Organization Controls, or CSOCs, and the choice between two methods for addressing them: carve-out and inclusive. Getting this wrong doesn't just create audit complications. It creates confusion for the enterprise buyers reading your SOC 2 report, which is the audience that matters most.
What Are CSOCs?
CSOCs (Complementary Subservice Organization Controls) are controls operated by a third-party vendor, a subservice organization, that your system depends on to meet its Trust Services Criteria commitments. These are controls your organization assumes are in place but doesn't directly operate.
The most common example: a SaaS company running in a colocation facility relies on the data center provider for physical security controls, environmental controls (power, cooling, fire suppression), and physical access management. Those controls are necessary for the SaaS company to meet SOC 2 security requirements, but the SaaS company doesn't run them. The data center does.
CSOCs exist because modern service delivery is layered. Almost every service organization depends on other organizations to deliver parts of its service. Your SOC 2 report needs to acknowledge those dependencies and explain how they're managed, either by including the subservice organization's controls in your audit scope or by carving them out and referencing the subservice organization's own SOC 2 report.
How to Identify Your Subservice Organizations
Before deciding on carve-out vs inclusive, you need to know which vendors qualify as subservice organizations. Not every vendor is one. A subservice organization is a third party whose services are part of your system, meaning they directly affect your ability to meet your Trust Services Criteria commitments.
In a recent engagement, we helped a company identify four subservice organizations for their SOC 2 scope:
Colocation data center provider
Handles physical security, power, cooling, and facility access for the company's production servers.
Endpoint protection vendor
Provides antivirus and endpoint security across all company devices.
Microsoft
Provides core business productivity (Microsoft 365) and cloud services.
Each of these vendors operates controls that the company's system depends on. The data center controls physical security. The endpoint vendor controls malware detection. Microsoft controls email and identity infrastructure.
Vendors that don't touch your system or its data, such as your office cleaning service, your accountant, or your marketing tools, are not subservice organizations. The test is the same impact test used for people scoping: does this vendor's service directly or indirectly affect your ability to meet your Trust Services Criteria commitments?
Carve-Out Method (Most Common)
The carve-out method excludes the subservice organization's controls from your SOC 2 audit scope. Your system description identifies the subservice organization and describes the services it provides, but your auditor does not test the subservice organization's controls directly. Instead, the report references the subservice organization and notes that its controls were "carved out."
How it works in practice:
The company running in a colocation facility carves out physical security controls. The system description says something like: Physical security controls, including facility access, environmental controls, and physical monitoring, are the responsibility of [data center provider]. These controls are excluded from the scope of this examination. [Data center provider] issues its own SOC 2 report, which is reviewed annually by management.
The company then implements complementary controls on its side: reviewing the data center's SOC 2 report annually, monitoring for any bridge letter gaps, and documenting the review. Enterprise customers reviewing the SOC 2 report can request the data center's SOC 2 report separately for additional assurance.
When to use carve-out:
- The subservice organization has its own SOC 2 report (most major data centers, cloud providers, and SaaS vendors do)
- The subservice organization's controls are well-established and independently audited
- You want to keep your audit scope manageable and cost-effective
- Your enterprise customers are comfortable reviewing the subservice organization's SOC 2 report separately
Carve-out is the standard approach for colocation facilities, major cloud providers (AWS, GCP, Azure), and established SaaS vendors. In our experience, auditors are comfortable with this method when the subservice organization is well-known and has a current SOC 2 report available.
What your enterprise customers expect to see:
Sophisticated buyers, particularly in financial services and insurance, will look for three things when they see a carve-out:
- That the subservice organization is named and its services are clearly described
- That your company reviews the subservice organization's SOC 2 report annually
- That any change of subservice organization triggers notifications, with notice period
Inclusive Method
The inclusive method brings the subservice organization's controls into your SOC 2 audit scope. Your auditor directly tests those controls, and the results appear in your SOC 2 report alongside your own controls.
How it works in practice:
The system description includes the subservice organization's infrastructure, people, processes, and data relevant to the service. The subservice organization provides a formal assertion and a representation letter covering their controls. Your auditor tests those controls as part of your examination.
When to use inclusive:
- The subservice organization does not have its own SOC 2 report
- You want to provide a single, consolidated report to your customers (reducing the number of reports they need to review)
- The subservice organization's controls are deeply intertwined with your own (hard to separate cleanly)
- Your customers explicitly require it
Cost consideration: The inclusive method significantly expands the audit scope, increases cost, and requires the subservice organization's active cooperation (providing assertions, making personnel available for testing, granting auditor access). Most subservice organizations with their own SOC 2 reports prefer that customers use the carve-out method.
| Carve-Out | Inclusive | |
| Subservice controls tested? | No, referenced only | Yes, by your auditor |
| Audit scope | Narrower, lower cost | Expanded, higher cost |
| Subservice cooperation needed? | SOC 2 report sharing only | Assertions, representation letter, auditor access |
| Best when | Subservice org has its own SOC 2 | No independent SOC 2 available, or customer requires it |
| How common? | Standard practice | Less common |
How This Affects Your Enterprise Buyers
CSOCs matter because the enterprise buyers reading your SOC 2 report are evaluating whether your entire service delivery chain is adequately controlled, not just the parts you directly operate.
A company positioning itself as a data custodian for regulated industries (insurance, financial services, healthcare) needs its SOC 2 report to clearly communicate how it manages the services it depends on. A well-documented carve-out with annual SOC 2 report review gives buyers confidence. A vague reference to third-party services without naming the subservice organizations or describing the oversight process creates questions.
The companies that handle this well treat subservice organization management as an ongoing operating function: annual SOC 2 report reviews, documented in the vendor risk management program, with clear change notification procedures for critical subservice organizations. The ones that struggle treat it as a one-time documentation exercise during audit prep.
Not sure how to scope your subservice organizations?
We help companies build effective security programs where CSOCs, vendor management, and audit scope are designed from the start, not patched together before the auditor arrives.
Book Your Strategy CallFrequently Asked Questions
What does CSOCs stand for in SOC 2?
CSOCs stands for Complementary Subservice Organization Controls. These are controls operated by a third-party vendor (a subservice organization) that your system depends on to meet its Trust Services Criteria commitments. Common examples include physical security controls at a colocation data center, infrastructure controls at a cloud provider like AWS or Azure, and endpoint protection controls from a security vendor.
What is the difference between the carve-out and inclusive method in SOC 2?
The carve-out method excludes the subservice organization's controls from your audit scope. Your report identifies the subservice organization and its services, but your auditor doesn't test their controls directly. The inclusive method brings the subservice organization's controls into your audit scope, meaning your auditor tests them and the results appear in your report. Carve-out is far more common because it keeps the audit scope manageable and works well when the subservice organization has its own SOC 2 report.
What is a CSOCs example in a SOC 2 report?
A typical example: a SaaS company hosts its production servers in a colocation facility. Physical security, facility access, power, cooling, and fire suppression are all managed by the data center provider. These are CSOCs because the SaaS company's security commitments depend on physical security being effective, but the SaaS company doesn't operate those controls. The SOC 2 report would identify the data center as a subservice organization and describe how its controls are addressed (usually via carve-out with annual SOC 2 report review).
How do I identify subservice organizations for my SOC 2 audit?
A subservice organization is any third-party vendor whose services are part of your system and directly affect your ability to meet Trust Services Criteria commitments. Common subservice organizations include colocation or cloud infrastructure providers, endpoint protection vendors, identity providers, and business productivity platforms. Vendors that don't touch your system or data (office supplies, marketing tools, cleaning services) are not subservice organizations.
Do enterprise customers care about how CSOCs are handled?
Yes, particularly in regulated industries like financial services, insurance, and healthcare. Sophisticated buyers will check whether subservice organizations are named in your system description, whether you review their SOC 2 reports annually, and whether you have change notification procedures in place. Some enterprise contracts require advance notice (6 months or more) with right of refusal before changing critical subservice organizations like data center providers.
About the Author
Ali Aleali, CISSP, CCSP
Co-Founder & Principal Consultant, Truvo Cyber
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.