Introduction
Subservice organizations and complementary user entity controls (CUECs) are how a SOC 2 report draws the line between what your company does, what your critical vendors do for you, and what your customers must do themselves. If your product runs on a cloud provider, sends data through a payment processor, or relies on a managed database, your report has to say how those providers are handled. If your controls only work when customers do certain things on their side, your report has to say that too.
This guide is written for the company being audited, the service organization. It explains the carve-out and inclusive methods for subservice organizations, what complementary subservice organization controls (CSOCs) and CUECs are, and what evidence you keep so your system description and your auditor's testing line up.
Here is a labeled hypothetical. A SaaS company hosts production on a large cloud provider and uses a third-party email delivery service for customer notifications. Its SOC 2 report uses the carve-out method for the cloud provider, lists the types of controls it expects the provider to run (physical security of data centers, hardware disposal, environmental protections), and describes how it monitors the provider each year by reviewing the provider's SOC 2 Type 2 report. The report also lists CUECs, such as customers enabling single sign-on for their own users and protecting the API keys they generate. When the auditor asks for evidence, the company can show the dated vendor report review, the CSOC mapping, and where customers are told about their responsibilities.
In plain language: this page explains how your own SOC 2 report treats your subservice organizations and your customers' responsibilities, and what to keep to prove it. It is not the playbook for reviewing a vendor's SOC report as a customer. That is covered in Third-Party Due Diligence Evidence for SOC 2.
Key Terms in One Place
- Service organization: the company whose system is described and examined in the SOC 2 report. If you are pursuing SOC 2, this is you.
- User entity: a customer that uses the service organization's system.
- Subservice organization: a vendor used by the service organization that performs controls necessary, in combination with the service organization's controls, to achieve its service commitments and system requirements. A cloud hosting provider running your production environment is a common example.
- Carve-out method: the subservice organization's relevant system components are excluded from your description and from the scope of the examination, but your description identifies the nature of its services, the types of controls you expect it to run, and the controls you use to monitor it.
- Inclusive method: the relevant parts of the subservice organization's system, including its controls, are included in your description and are subject to your auditor's examination procedures.
- Complementary subservice organization controls (CSOCs): controls you assumed, in designing your system, would be implemented by a subservice organization and that are necessary, together with your controls, to meet your commitments. These are disclosed when you use the carve-out method.
- Complementary user entity controls (CUECs): controls you assumed, in designing your system, would be implemented by your customers and that are necessary, together with your controls, to meet your commitments.
These definitions follow the AICPA 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022), often called DC 200.
How This Guide Differs From Related Pages
| Page | Primary job | Use it when |
|---|---|---|
| Third-Party Due Diligence Evidence for SOC 2 | Building a vendor diligence file, including reading a vendor's SOC report and mapping its CUECs to your controls | You are the customer reviewing someone else's report |
| Vendor Management for SOC 2 | Running the vendor risk program: inventory, tiers, reviews | You need the overall vendor program, not report scoping |
| What Is Third-Party Risk Management? | Defines the discipline | You need the concept, not the evidence playbook |
| What Is a System Description? | Defines the narrative that frames your report | You need the overall description, of which subservice and CUEC disclosures are a part |
| This guide | How your report treats subservice organizations (carve-out vs inclusive), CSOCs, CUECs, and the evidence behind them | You are the service organization writing and defending those disclosures |
What SOC 2 Requires vs Common Practice
Keep the criteria and your chosen practices apart.
What the criteria address. The description criteria in DC 200 call for disclosures in this area:
- CUECs: if management assumed in the design of the system that certain controls would be implemented by user entities, and those controls are necessary in combination with the service organization's controls, the description identifies those CUECs.
- Subservice organizations: if the service organization uses a subservice organization whose controls are necessary in combination with its own, the description addresses it. Under the inclusive method, that includes the nature of the service, the necessary subservice organization controls, relevant aspects of its infrastructure, software, people, procedures, and data, and the portions of the system attributable to it. Under the carve-out method, that includes the nature of the service, each applicable trust services criterion intended to be met by controls at the subservice organization, and the types of controls assumed to be implemented there (the CSOCs).
- Monitoring: the implementation guidance says that regardless of the method, the description discloses the controls the service organization uses to monitor the services provided by the subservice organization. Examples it gives include inspecting Type 2 SOC 2 reports on the subservice organization's system, reviewing and reconciling output reports, periodic discussions and service level reviews, site visits, internal audit testing, and monitoring external communications such as complaints.
The AICPA 2017 Trust Services Criteria with revised points of focus (2022) also connect here. CC9.2 addresses assessing and managing risks associated with vendors and business partners, and CC2.3 addresses communicating with external parties about matters affecting the functioning of internal control, which is how CUECs and other customer responsibilities reach your customers. See SOC 2 Trust Services Criteria Explained.
The guidance also makes a useful distinction. CUECs are only the customer controls your system actually depends on to meet your commitments. Other things customers must do to get value from the service are user entity responsibilities. DC 200 gives the example that a customer identifying its own authorized users and telling the service organization who they are is not considered a CUEC. User entity responsibilities are often communicated in user manuals or contracts, and the description usually identifies the types of communications used rather than listing every responsibility.
What is common practice, not a fixed SOC 2 rule:
- Using the carve-out method for large cloud providers that publish their own SOC reports
- Reviewing each carved-out subservice organization's SOC report at least annually with a dated, signed review note
- Keeping a CSOC mapping table that ties each assumed control type to the criteria it supports
- Publishing CUECs in a customer-facing security or trust page as well as in the report
- Re-checking CUECs and subservice organizations whenever architecture or the product changes
SOC 2 does not name a review template, a review cadence, or a specific monitoring tool. Your description states what you do, and your auditor tests that.
Carve-Out vs Inclusive at a Glance
| Dimension | Carve-out method | Inclusive method |
|---|---|---|
| Subservice organization's system components | Excluded from your description and from the scope of the examination | Included in your description and in the scope of the examination |
| Subservice organization's controls | Not tested by your auditor; described as the types of controls you assume it runs (CSOCs) | Described and subject to your auditor's examination procedures |
| What your description must identify | Nature of the service, applicable criteria met by controls at the subservice organization, CSOCs | Nature of the service, necessary subservice controls, relevant system aspects, portions attributable to the subservice organization |
| Your monitoring controls | Disclosed and commonly tested | Disclosed and commonly tested |
| Cooperation needed from the subservice organization | Usually limited to providing its own report or other information | Significant, because its controls are examined as part of your engagement |
| Where customers get assurance on the subservice organization | Usually from the subservice organization's own report | From your report |
A service organization that uses several subservice organizations can use carve-out for some and inclusive for others. The choice is made per subservice organization and stated in the description.
Is This Vendor a Subservice Organization?
Not every vendor is a subservice organization. DC 200 notes that a vendor might also be a subservice organization depending on the services it provides, specifically when it operates controls that are necessary, together with yours, to meet your service commitments and system requirements.
Questions that help you decide:
- Does the vendor store, process, or transmit customer data as part of the system in scope?
- Do any of your commitments to customers (availability, security, confidentiality) depend on controls the vendor operates?
- If the vendor's controls failed, would your controls alone still meet your commitments?
- Does the vendor operate infrastructure or processing that your system description treats as part of how the service is delivered?
A cloud provider hosting production usually answers yes. An internal chat tool or an expense app usually answers no and belongs in your normal vendor management program instead. Write down your reasoning for borderline cases, because auditors ask why a vendor was or was not treated as a subservice organization.
The Subservice and CUEC File at a Glance
| Area | What to keep | Stronger evidence | Weaker evidence |
|---|---|---|---|
| Subservice inventory | List of subservice organizations, services provided, method used | Dated list tied to the system description and vendor inventory | Method decided informally by the auditor with no internal record |
| Classification rationale | Why each critical vendor is or is not a subservice organization | Short written rationale per vendor | "We always carve out everything" |
| CSOC mapping | Assumed control types per subservice organization and the criteria they support | Table mapping CSOCs to criteria and to the subservice organization's report sections | CSOCs copied from another company's report |
| Monitoring | How you monitor each subservice organization | Dated SOC report reviews, exception follow-up, bridge letters, service level reviews | A downloaded PDF with no review notes |
| Report coverage | Whether the subservice report covers your services, regions, and period | Review note recording scope, period, opinion, exceptions, and gaps | Report from two years ago for a different service |
| CUEC list | Customer controls your system depends on | Current list in the description, reviewed when the product changes | Generic list unrelated to your product |
| Customer communication | Where customers learn their CUECs and responsibilities | Trust page, onboarding docs, contract terms, or help center with dates | "Customers should know" with nothing published |
| Change control | Updates when vendors, architecture, or features change | Tickets that update the description, CSOCs, or CUECs | Description unchanged for years despite new vendors |
Building the Evidence Step by Step
1. Inventory vendors and identify subservice organizations
Start from your vendor inventory and your system description. For each vendor that touches the in-scope system, apply the questions above and record the outcome. Keep the result as a short list: vendor, service provided, subservice organization yes or no, rationale, and owner. This list should match the boundary in your system description.
2. Choose and document the method for each
For each subservice organization, record whether you use carve-out or inclusive, who decided, and why. Many teams carve out large cloud providers because those providers publish their own SOC reports and an inclusive approach would require the provider to participate in your examination. Inclusive is more common where a closely related provider, such as an affiliate or a dedicated outsourced operations partner, agrees to be examined with you. Discuss the method with your auditor early, since it affects scope and fieldwork.
3. Define CSOCs for carved-out subservice organizations
List the types of controls you assume each carved-out subservice organization performs, written specifically for the services it provides to you. For a cloud host, that often includes physical access to data centers, environmental protections, hardware maintenance and disposal, and the underlying infrastructure availability you rely on. Map each CSOC to the trust services criteria it supports. DC 200 says only CSOCs specific to the services provided by the system should be described, so avoid boilerplate lists.
4. Decide how you will monitor each subservice organization
Pick monitoring activities you can actually perform and evidence. The most common is an annual review of the subservice organization's SOC 2 Type 2 report. A useful review note records:
- Report type, period, and issue date
- Services, products, and regions covered, and whether they match what you use
- The opinion and any qualifications
- Exceptions noted in testing and whether they affect you
- CUECs the subservice organization lists for its customers, and which of your controls address them
- Its own subservice organizations and the method it uses
- Whether a bridge letter is needed to cover the gap between its period end and yours
- Conclusion, follow-up actions, reviewer, and date
Add other monitoring where it matters: service level and status page reviews, incident notifications from the provider, or quarterly calls with a key partner.
5. Address the subservice organization's own CUECs
Your subservice organization's report lists controls it expects you to run as its customer. Those become your responsibilities. Map each relevant one to a control you operate, such as managing access to the cloud console, enabling logging, or configuring encryption settings. This is where your work as a service organization meets the customer-side work described in Third-Party Due Diligence Evidence for SOC 2.
6. Write your own CUECs carefully
List only the customer controls your system truly depends on to meet your commitments. Common examples for SaaS products include customers managing who in their organization has access to their account, enabling available security features such as single sign-on or multi-factor authentication for their users, protecting credentials and API keys they generate, and promptly removing access for their own departing users. Test each one by asking whether your commitments would still hold if the customer did not perform it. If they would, it may be a user entity responsibility rather than a CUEC.
Do not use CUECs to push your own responsibilities onto customers. A CUEC list that shifts core security work to users can raise questions from auditors and from customers reading your report.
7. Communicate CUECs and responsibilities to customers
Your description identifies CUECs, and CC2.3 covers communication with external parties. Keep a record of where customers learn about their side: the SOC 2 report itself, a trust or security page, onboarding materials, product documentation, or contract terms. Date those sources and keep prior versions so you can show what customers were told during the audit period.
8. Keep the description current through change
New vendors, migrations, regional expansions, and new product features can all change your subservice organizations, CSOCs, or CUECs. Route those updates through change management so a ticket shows who updated the description and when. Silent drift between the real architecture and the description is a common control drift pattern.
9. Handle problems at a subservice organization
If a subservice organization's report has a qualified opinion, relevant exceptions, a scope gap, or a significant incident, record your assessment, any compensating control you rely on, and follow-up actions with owners and dates. Track open items through Exception Management and Audit Findings Remediation. A documented response shows the monitoring control worked. An unread report with a known exception does not.
10. Dry-run the auditor's questions before fieldwork
Before fieldwork, check that you can produce: the subservice organization list with methods, the CSOC mapping, dated monitoring evidence for each subservice organization, the mapping of subservice CUECs to your controls, your own CUEC list, and dated customer communication sources. For broader readiness, see how to prepare for a SOC 2 audit.
Type 1 vs Type 2 Considerations
For a Type 1 report, auditors evaluate whether the description is fairly presented and controls are suitably designed and implemented at a point in time. A current subservice list with methods, CSOC disclosures, designed monitoring controls, a CUEC list, and evidence of customer communication usually support that.
For a Type 2 report, auditors test whether controls operated across the period. Expect requests such as:
- Monitoring evidence dated within the period, such as SOC report review notes for each carved-out subservice organization
- Bridge letters or other information covering gaps between the subservice report period and your period, where relevant
- Follow-up records for exceptions or incidents at subservice organizations
- Evidence that subservice CUECs mapped to your controls actually operated, tested through those controls
- Change tickets for vendor additions or architecture changes during the period, and matching description updates
- Customer communication sources that were in place during the period
See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Evidence Examples by Scenario
| Scenario | Stronger evidence | Weaker evidence |
|---|---|---|
| Auditor asks how the cloud host is monitored | Dated annual review of its Type 2 report with scope, exceptions, CUEC mapping, and sign-off | Report PDF in a shared drive with no notes |
| Subservice report period ends months before yours | Bridge letter obtained and reviewed, or documented gap assessment | No coverage for the gap and no record of considering it |
| Subservice report shows a relevant exception | Assessment of impact, compensating controls, and follow-up ticket | Exception never noticed |
| New payment processor added mid-period | Change ticket, subservice classification decision, description updated | Vendor live in production but absent from the description |
| Customer asks what they must do | Trust page and onboarding docs listing CUECs, dated | Sales engineer explains verbally |
| Auditor questions a CUEC | Rationale showing the system depends on that customer control | CUEC that is really your own responsibility |
| Product adds single sign-on | CUEC list reviewed and updated through a ticket | CUEC list unchanged since the first report |
Common Mistakes
- Treating every vendor as a subservice organization, or none of them
- Copying CSOCs from another company's report instead of describing the services you actually use
- Downloading a subservice organization's SOC report without reviewing or signing off on it
- Ignoring the subservice organization's own CUECs, which become your responsibilities
- Missing that the subservice report does not cover the services or regions you use
- No plan for the gap between the subservice report period and yours
- CUEC lists that shift your core security duties onto customers
- Calling every customer responsibility a CUEC, even when your commitments do not depend on it
- CUECs that exist only inside the report, with no customer-facing communication
- Adding vendors or features without updating the description
When you find one, record it and track the fix through Exception Management and Audit Findings Remediation and remediation.
Operating Model: Make Subservice and CUEC Evidence Routine
- Name owners. Assign a control owner for subservice monitoring and one for the CUEC list and customer communications.
- Keep one list. Maintain a single subservice organization list with method, CSOCs, monitoring activity, and next review date.
- Review on a calendar. Schedule SOC report reviews when providers publish new reports, and track bridge letters.
- Tie changes to the description. Vendor onboarding, migrations, and new features trigger a check of subservice status, CSOCs, and CUECs.
- Publish and date customer guidance. Keep CUECs and responsibilities in a dated customer-facing location.
- Dry-run before fieldwork. Pull the full file quarterly, not only in audit week.
Linking Subservice and CUEC Evidence to Neighboring Controls
- System description. Subservice and CUEC disclosures are part of your system description.
- Vendor management and due diligence. Subservice organizations are a subset of vendors; see Vendor Management for SOC 2 and Third-Party Due Diligence Evidence for SOC 2.
- Risk assessment. Vendor dependency risks belong in your risk assessment and risk register.
- Asset inventory. Cloud accounts and SaaS systems hosted by subservice organizations should appear in Asset Inventory Evidence for SOC 2.
- Access control. Many subservice CUECs are about your access to their consoles; see access control and How to Run a SOC 2 User Access Review.
- Incident response. Provider incidents and notifications connect to Incident Response Evidence for SOC 2.
- Disaster recovery. Availability commitments often rely on provider infrastructure; see Disaster Recovery Evidence for SOC 2.
- Control mapping. CSOCs and CUECs should appear in your control mapping so gaps are visible.
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For subservice organizations and CUECs, that can mean dated history for vendor review tickets, SOC report review tasks, exception follow-ups, and change tickets that update the system description, so you can show the work across the period without rebuilding it from email. Your vendor contracts, provider reports, and customer documentation remain the systems of record. AuditFlo.co does not review vendor reports for you, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Subservice organizations and CUECs are where your SOC 2 report admits that you do not operate alone. The carve-out method keeps a provider's system out of your examination but requires you to name the controls you rely on and prove you monitor them. The inclusive method brings the provider's controls into your examination and needs its cooperation. CUECs tell customers which of their controls your system depends on, and they only work if customers can find them. Keep a clear list, write CSOCs and CUECs that match your real architecture, review provider reports with dated notes, and update everything when your system changes.
If you are building the broader readiness path, start with What Is a System Description?, Third-Party Due Diligence Evidence for SOC 2, Vendor Management for SOC 2, SOC 2 Trust Services Criteria Explained, and how to prepare for a SOC 2 audit.
FAQ
What is the difference between the carve-out and inclusive methods?
Under the carve-out method, the subservice organization's relevant system components are excluded from your description and from the scope of your examination, and your description identifies the services it provides, the controls you assume it runs (CSOCs), and how you monitor it. Under the inclusive method, its relevant system components and controls are included in your description and are subject to your auditor's examination procedures.
Is every vendor a subservice organization?
No. A vendor is a subservice organization when it performs controls that are necessary, together with yours, to achieve your service commitments and system requirements. A production cloud host usually qualifies. Many internal business tools do not, and are handled through normal vendor management.
What are CSOCs?
Complementary subservice organization controls are controls you assumed, in designing your system, would be implemented by a carved-out subservice organization and that are necessary together with your controls. Your description identifies them, and your report readers rely on the subservice organization actually operating them.
What is the difference between a CUEC and a user entity responsibility?
A CUEC is a customer control your system depends on to meet your commitments. A user entity responsibility is something customers must do to get the intended benefit of the service but that your commitments do not depend on. The AICPA description criteria give identifying a customer's own authorized users as an example that is not considered a CUEC.
Do we still need to monitor a carved-out subservice organization?
Yes. The description criteria guidance says that regardless of method, your description discloses the controls you use to monitor the services provided by the subservice organization. Reviewing its Type 2 SOC 2 report with dated notes is a common example.
How is this guide different from third-party due diligence?
This guide covers your role as the service organization: how your report treats your subservice organizations and what your customers must do. Third-Party Due Diligence Evidence for SOC 2 covers your role as a customer reviewing a vendor's report and mapping that vendor's CUECs to your controls.
Does AuditFlo.co review our vendors' SOC reports?
No. AuditFlo.co helps organize dated evidence such as review tickets, tasks, and workflow history from systems you already use. Your team performs the reviews, and AuditFlo.co does not replace your auditor.