SOC 2 Carve-Out vs Inclusive Method: How to Treat Providers
Choose how a SOC 2 report treats a subservice organization. Compare carve-out and inclusive methods, required disclosures, provider controls, and your own oversight.
In a SOC 2 report, the carve-out method leaves a subservice organization’s controls outside your CPA firm’s examination while describing the service and controls your company depends on. The inclusive method brings the provider’s relevant system components and controls into the description and examination. Neither method removes your own controls or provider oversight. Management should propose a method for each relevant provider and confirm it with the CPA firm before relying on the report scope.
When is a vendor a SOC 2 subservice organization?
Start with the service boundary, not the vendor list. The AICPA’s SOC 2 Description Criteria call a provider a subservice organization when its controls are necessary, together with yours, to meet the service commitments and system requirements in the report. That is a narrower question than whether you buy software from the provider or send it data.
For a hosted API, a cloud provider may operate physical and platform controls on which the service depends. Your team may still configure access, deploy the application, review changes, respond to incidents, and manage backups. Trace the actual service and control dependency before classifying the provider. Not every vendor belongs in the report as a subservice organization.
Write down the provider’s service, the part of your system that uses it, the commitment it supports, and the controls each party operates. The cloud-provider report guide explains why a provider’s own SOC 2 report covers its system, not your SaaS by default.
What changes under carve-out or inclusive treatment?
The AICPA’s Description Criteria, especially DC7 describe both methods. Use this as the scope test:
- With carve-out, your description names the nature of the provider’s service, each applicable criterion intended to be met by controls there, and the types of controls management assumes the provider operates. The provider’s system components and controls stay outside your description and the CPA firm’s examination. Your own controls for monitoring that provider remain in the description. Explain that the related commitments and system requirements depend on those assumed controls being suitably designed and operating effectively during the period the description addresses.
- With inclusive treatment, your description includes the relevant provider infrastructure, software, people, procedures, data, and controls. It identifies which parts belong to the provider. The CPA firm examines the included provider controls, so management must plan with the provider and CPA firm for access to the people and evidence needed.
Carve-out changes which controls the CPA firm tests in your engagement. It does not make a criterion irrelevant merely because a provider performs the related work. The AICPA’s DC8 guidance says an outsourced system component does not, by itself, justify omitting a relevant criterion. Ask the CPA firm how the provider dependency and any excluded criteria should appear in the final description.
If your service uses several subservice organizations, the AICPA permits carve-out for some and inclusive treatment for others. Make a separate decision for each provider. One blanket setting hides where the assurance boundary actually sits.
What must the team do after a carve-out decision?
Write the assumed provider controls as complementary subservice organization controls, or CSOCs. These are the controls you depend on the provider to operate, together with your own controls, to meet the scoped commitments. Use descriptions tied to the service you buy. “Provider handles security” does not tell a report reader which dependency matters.
For the hosted API example, management might assume the cloud provider restricts access to its facilities and protects the underlying infrastructure. Your team might review the provider’s assurance material, assess exceptions, track changes to the service it uses, and keep its own access and deployment controls operating. These are example responsibilities to investigate, not a ready-made control set for every cloud service.
The AICPA’s DC7 guidance says the description should also disclose controls your company uses to monitor the provider, regardless of the method selected. That can include reviewing the provider’s report, reconciling service output, or evaluating service performance. A provider report may support your review, but check its covered service, period, opinion, exceptions, and your responsibilities before relying on it. Keep a record of the review and any follow-up. The vendor review guide walks through that work.
Do not mix a CSOC with a complementary user entity control, or CUEC. A CUEC belongs to your customer only when a scoped control depends on that action to meet a service commitment or system requirement. A customer’s routine approval of its own users is not automatically a CUEC. A cloud provider’s facility controls belong to a different party. The CUEC guide shows how to test and record the dependency.
How should a startup decide and record the method?
Take a short proposal to the CPA firm before the engagement’s scope is set:
- Trace the dependency. Name the provider, supplied capability, system boundary, service commitment, and relevant criteria.
- Identify the controls. Separate your controls, provider controls, and customer controls. Name the source evidence and owner for your side.
- Test inclusive access. If you propose inclusive treatment, ask whether the provider can support the description, walkthroughs, evidence requests, and CPA examination for the relevant controls. Record unresolved access or contract limits rather than assuming cooperation.
- Test carve-out disclosures. If you propose carve-out, list the provider service, applicable criteria, assumed CSOCs, and your monitoring controls. State which commitments and system requirements depend on the assumed controls being suitably designed and operating through the covered period. Check that those statements match the service and agreement you actually have.
- Review the proposal. Record the method and reason for each provider, take the set to the CPA firm, and update the system description and control mapping when the engagement scope is agreed.
In FileGRC’s Git-native GRC workspace, an Audit can record each subservice treatment by linking a Vendor to the Components it supplies in a selected System, with a carve-out or inclusive method and rationale. Inclusive treatments also need selected Controls linked to those Components. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. Starter records are proposals, not compliance claims. Your source systems still operate controls and produce evidence; the independent CPA firm performs the examination and decides whether that evidence is sufficient.
Run your SOC 2 program as files in Git.
Keep policies, controls, work, and evidence indexes in a repository your team and agents can inspect. Add optional hosted email and Slack reminders to keep work moving.
Frequently asked questions
What is the carve-out method in SOC 2?
The carve-out method excludes a subservice organization's system components and controls from the service organization's system description and CPA examination. The description still identifies the provider's service, the applicable criteria its controls help meet, the assumed complementary subservice organization controls, and the service organization's own monitoring controls.
What is the inclusive method in SOC 2?
The inclusive method includes the relevant parts of a subservice organization's system and controls in the service organization's description. The CPA firm examines those included controls. Management and the CPA firm must plan access to the provider's people, records, and control evidence for that scope.
Is every SOC 2 vendor a subservice organization?
No. A vendor is a subservice organization for the report when its controls are needed, together with your controls, to meet the scoped service commitments and system requirements. Review the actual provider function with the CPA firm rather than labeling every vendor the same way.
Does carving out a cloud provider remove our SOC 2 responsibilities?
No. Carve-out leaves the provider's own controls outside your CPA firm's testing, but your report still describes the dependency and assumed controls. Your team must operate its own controls, monitor the provider, and address the criteria and commitments that remain relevant to the scoped service.
Can one SOC 2 report use carve-out for one provider and inclusive for another?
Yes. The AICPA's Description Criteria allow different treatment for different subservice organizations. Record and explain the method for each provider, then confirm the proposed treatment with the CPA firm before relying on the engagement scope.
What is the difference between a CSOC and a CUEC?
A complementary subservice organization control, or CSOC, is a control management assumes a carved-out provider operates. A complementary user entity control, or CUEC, is a control management assumes a customer operates. Name the responsible party and the service commitment that depends on the action.