A complementary user entity control, or CUEC, is a control that your service depends on the customer performing. Your control environment cannot be complete on its own, because some of what keeps the system secure happens on the customer's side of the boundary. DC Section 200 requires you to disclose exactly which controls those are, worded specifically enough that a knowledgeable reader could actually go implement them.
Most system descriptions treat this section as boilerplate. It is not. A vague CUEC list is one of the more common sources of system description findings, and it is also one of the sections enterprise security reviewers now read most carefully, because it tells them precisely what they are responsible for if they rely on your report.
CUEC vs user entity responsibility vs CSOC
These three terms get used interchangeably and they should not be. Each describes a different party's obligation, and mixing them up is itself a common drafting failure.
| Term | Whose obligation | Test for inclusion | Where it belongs |
|---|---|---|---|
| Complementary user entity control (CUEC) | The customer | Your control environment would not operate as described without it | DC 200.F, in the system description |
| User entity responsibility | The customer | Good practice for the customer, but your controls do not depend on it | Contract, documentation, or security guidance, not the CUEC list |
| Complementary subservice organization control (CSOC) | A vendor or subservice organization (cloud provider, identity platform, and similar) | Your control environment would not operate as described without it, and you use the carve-out method for that vendor | DC 200.G, in the system description |
The distinction that matters most is the test for inclusion, not the label. Ask whether removing the customer's action would break one of your own controls. If yes, it is a CUEC. If the action is simply good practice that your control environment does not actually rely on, it does not belong in the CUEC list, and padding the list with it weakens the section rather than strengthening it.
What DC 200.F requires
DC Section 200, the AICPA's description criteria for a SOC 2 system description, addresses complementary user entity controls under criterion DC 200.F. If your service has controls that rely on the customer doing something, you must disclose those CUECs in Section 3 of your report. The disclosure has to be specific enough that a knowledgeable reader could implement the control, not a general statement that customers should "maintain good security practices."
The auditor does not test your customers. What the auditor evaluates is whether the CUEC is described with enough specificity to be actionable, and whether it genuinely reflects a dependency your control environment has. A CUEC list copied from a template, listing generic obligations that do not map to anything your controls actually rely on, is itself a description criteria problem, because the description is supposed to reflect your actual system, not a standard list.
Five CUEC examples: weak wording vs defensible wording
The difference between a CUEC that survives scrutiny and one that generates a finding is almost always specificity. Here are five common CUECs, shown both ways, each mapped to the trust services criteria it typically supports.
| Control area | Weak wording | Defensible wording | Maps to |
|---|---|---|---|
| User account administration | "Customers are responsible for managing their own users." | "The customer is responsible for provisioning, modifying, and deprovisioning user accounts within its own tenant, including timely removal of access upon employee termination." | CC6.1–CC6.3 |
| Multi-factor authentication | "Customers should use strong authentication." | "The customer is responsible for enforcing multi-factor authentication for all users accessing the platform through its own identity provider configuration." | CC6.1 |
| API data accuracy | "Customers must ensure data quality." | "The customer is responsible for the accuracy and completeness of data submitted to the platform via API prior to transmission, as the service does not independently validate source data correctness." | Processing integrity, CC6.1 |
| Endpoint protection | "Customers are responsible for their own devices." | "The customer is responsible for maintaining endpoint protection controls, including patching and malware detection, on devices used to access the platform." | CC6.7, CC6.8 |
| Activity log review | "Customers should monitor their activity." | "The customer is responsible for reviewing the account activity logs made available through the platform and investigating anomalous activity within its own environment." | CC7.2, CC7.3 |
Notice what changes between the columns. The defensible version names the specific action, the mechanism by which it happens, and the boundary of the customer's responsibility relative to the service. The weak version could be true of almost any SaaS product on the market, which is exactly why it does not survive scrutiny.
A test to run on your own CUEC section
Before your auditor reads Section 3, run your own CUEC list through three questions.
- Would one of my controls actually fail to operate as described if the customer did not do this? If the honest answer is no, it is not a CUEC. Move it to documentation or remove it.
- Could a customer's security team read this line and know exactly what to configure? If the wording is generic enough to apply to any vendor, a knowledgeable reader cannot act on it, and neither can your auditor evaluate it as specific.
- Does this CUEC match what my controls narrative elsewhere in the description says? A CUEC that assumes a customer action your Section 3 controls narrative does not otherwise reference is an internal inconsistency, and inconsistencies inside a system description are exactly what auditors are trained to catch.
Carve-out vs inclusive method
CSOCs only exist under the carve-out method. Under the inclusive method, the subservice organization's controls are tested directly as part of your audit and folded into your own report, so there is nothing left to carve out or disclose separately.
| Carve-out method | Inclusive method | |
|---|---|---|
| Subservice organization's controls | Excluded from your audit scope | Tested as part of your audit |
| Disclosure | CSOCs listed under DC 200.G, reader must separately verify | Included directly in your report's control matrix |
| Practical fit | Standard for hyperscale providers (AWS, GCP, Azure) and large platforms (Stripe, Okta) | Feasible mainly for smaller vendors willing to grant audit access |
| Reader's burden | Higher: reader must obtain and review the subservice organization's own report | Lower: everything is in one report |
Most SaaS companies use carve-out for infrastructure providers, because obtaining inclusive-method audit access to a hyperscale cloud provider is not realistically available to an individual customer. The trade-off is that the reader now has two reports to reconcile instead of one, which is precisely why the CSOC disclosure needs to be specific enough to tell them what to go verify.
What actually goes wrong
The CUEC list is copied from a template and never adapted. It lists obligations that sound plausible for any SaaS company but do not map to anything the actual control environment depends on. This is the single most common failure, and it is visible immediately to anyone who reads the section carefully.
A CUEC is listed that contradicts the controls narrative. If Section 3 says the platform enforces MFA for all users, but the CUEC list also says the customer is responsible for enforcing MFA, the description is internally inconsistent. Only one of those statements can be accurate for a given control.
Real dependencies are missing. A control that genuinely depends on customer action, such as API-submitted data accuracy or customer-managed encryption keys, has no corresponding CUEC at all. The control environment description implies self-sufficiency it does not actually have.
User entity responsibilities are mislabeled as CUECs. Good security hygiene the customer should practice, but that no specific control depends on, gets listed alongside real CUECs. This dilutes the section and makes it harder for a reader to tell which items are load-bearing.
Why this section produces findings
Three patterns account for most of the CUEC-related findings auditors raise.
Vagueness that fails the "knowledgeable reader" test. DC 200 requires descriptions specific enough for a knowledgeable reader to understand and act on. "Customers should follow best practices" fails that test on its face.
Internal inconsistency with the rest of Section 3. A CUEC that assumes a customer action the controls narrative does not otherwise account for, or that contradicts a control described elsewhere, is flagged during the auditor's own consistency review of the description.
Drift from what the control environment actually became. Controls change over time. A platform that once required customers to manage their own MFA may have since built enforced MFA into the product. If the CUEC list was not updated, it now describes a dependency that no longer exists, which is a DC 200.H significant-changes problem layered on top of a DC 200.F problem.
What this looks like from the reader's sideIf you are evaluating a vendor's SOC 2 report rather than producing one, the CUEC section is your action list. It tells you specifically what you are responsible for configuring, monitoring, or maintaining for the vendor's control environment, and by extension your own risk posture, to hold. Skipping this section is the single most common way procurement teams miss a real gap.
What CUECs mean if you are reading someone else's report
If you are evaluating a vendor's SOC 2 report as a customer or prospective buyer, treat the CUEC section as a checklist, not a formality.
- Read every CUEC and confirm your own team is actually doing what it describes. A vendor's control is only as strong as your side of the dependency.
- Flag any CUEC worded too vaguely to act on, and ask the vendor directly what it means in practice, since a vague CUEC in their report is also a vague dependency in your risk model.
- If the vendor uses the carve-out method for a critical subservice organization, obtain and review that organization's own report, since the CSOC disclosure tells you which controls you still need to verify independently.
- Compare the CUEC list against the vendor's own controls narrative for internal consistency. A contradiction in their report is a signal worth raising in your vendor risk review, not just an editorial nitpick.
Primary source: the AICPA's 2018 SOC 2 Description Criteria (DC Section 200), with revised implementation guidance.
Frequently asked questions
Are complementary user entity controls required in a SOC 2 report?
Yes, whenever your control environment depends on the customer doing something. DC Section 200.F requires the system description to disclose CUECs your service relies on. Omitting a CUEC your controls actually depend on is a description criteria gap, not an optional courtesy to readers.
What is the difference between a CUEC and a user entity responsibility?
A CUEC is a control your control environment depends on the customer performing. A user entity responsibility is something customers should do for their own security but that your controls do not rely on. If removing the customer action would break one of your controls, it is a CUEC. If it would not, it is a responsibility, not a CUEC, and belongs elsewhere in the report or in your documentation, not in the CUEC list.
Does the auditor test complementary user entity controls?
No. The auditor tests your controls, not your customers' controls. What the auditor does test is whether the CUEC is worded specifically enough that a knowledgeable reader could actually implement it, and whether your control environment genuinely depends on it operating as described.
What are complementary subservice organization controls?
CSOCs are controls that a vendor or subservice organization, such as a cloud provider or identity platform, must perform for your controls to be effective, disclosed under the carve-out method. CUECs are the customer's obligations. CSOCs are the vendor's. They serve the same structural purpose in the report but describe two different parties.
What is the difference between the carve-out and inclusive method for subservice organizations?
Under the carve-out method, the subservice organization's controls are excluded from your audit scope and disclosed as CSOCs the reader must separately verify. Under the inclusive method, the subservice organization's controls are tested as part of your audit and included in the report. Most SaaS companies use carve-out for major infrastructure providers because obtaining inclusive-method access to a hyperscale cloud provider is impractical.
How many CUECs should a SOC 2 system description have?
There is no fixed number. The right count is however many controls in your environment genuinely depend on the customer doing something. A short, specific, accurate CUEC list is stronger than a long generic one copied from a template. Padding the list with responsibilities that are not real dependencies weakens the section rather than strengthening it.
Where do CUECs appear in a SOC 2 report?
In Section 3, the system description, typically in a dedicated subsection near the end that lists each control the service depends on the customer performing. A reader evaluating your report as a vendor should read this section as their own action list, because it describes what they must do for your controls to actually hold.
Related reading: DC Section 200: the AICPA description criteria that govern your SOC 2 system description, SOC 2 system description and control matrix, how to verify a SOC 2 report, and SOC 2 system description review.