Complementary user entity controls: writing ones that hold up
A CUEC is a condition on your own report. Written vaguely it transfers nothing, and written well it reads like a contract term.
Complementary user entity controls, or CUECs, are the tasks your customer must perform so your controls can do what your SOC 2 report says they do. The auditor tests your side and never the customer’s. So you write the dependency down, and each written dependency is a CUEC.
CSOCs use the same idea in reverse, pointed at vendors below you. You write one list and inherit the other.
Where CUECs sit in the report
Your SOC 2 covers your system and stops at its edge. Along that edge sit controls only the customer can run. Take access provisioning. You built the roles, but the customer decides who gets admin. If they hand it to everyone, your access control no longer does what you described.
You have no way to test that, since you have no access to their records and no authority to ask. So you disclose it instead. The disclosure goes in Section 3, inside the system description management wrote and asserted,1 and the auditor reads it as a condition on your claims.
- What a CUEC is not
- A tip, a hardening guide or a best practice list. Those belong in product docs. A CUEC limits what your own description claims.
- Who owns the words
- You do. It is management language inside a document management asserts, not text the auditor drafts.
- Who reads it
- The security reviewer at every company that receives your report, and later their own auditor. It is one of the few report sections that creates work for the reader.
CSOCs point the other way
Now look down instead of up. You run on a cloud host, send email through a delivery service and take payments through a processor. Those are subservice organizations, and some of their controls hold yours up. Each one you rely on is a complementary subservice organization control.
Physical security is the easy example. You say production data sits in a facility with controlled entry. You have never visited it. The control belongs to the host, so you name it as theirs. Your customers work through your CUEC list, and you work through your vendors’ lists in the same way.
Carve-out or inclusive for your vendors
A subservice organization can be handled two ways in your description, and the choice shapes what gets tested and what a buyer sees.2 The labels sound procedural. The real deciding factor is how much influence you have over the vendor.
| Carve-out | Inclusive | |
|---|---|---|
| Scope of the description | Only your controls. The vendor is named, its controls excluded | Your controls and the vendor’s, described as one system |
| What gets tested | Your controls, including how you pick and monitor the vendor | Both sets, at both companies |
| What the vendor must agree to | Nothing beyond sharing its own report | Its own management assertion, plus testing alongside you |
| What your report shows | A CSOC list of controls you assume the vendor runs | The vendor’s controls and results inside your report |
Plan on carve-out. Inclusive needs someone at your cloud host to sign a management assertion and sit for testing next to you, and nobody there will. You do not need them to. Carve-out is the normal treatment for commodity infrastructure. It leaves one real duty: read the vendor’s report and act on its CUEC list.
It changes who runs the control, not whether it matters. Your auditor still checks that you chose the vendor deliberately, read its report, and noticed when that report expired. An unread PDF in a shared drive is a finding waiting for a sample.
Writing a CUEC that transfers something
Read every CUEC as a legal condition on your assertion. If the condition is vague, nothing is conditioned, and the sentence will not help you on the day a customer claims your product let their intern into production. A weak CUEC names a responsibility. A strong one names an action someone could check.
| Vague | Testable |
|---|---|
| Users are responsible for the security of their accounts | The user entity gives each of its users the least privileged role their job needs, and removes access within one business day of a departure |
| Customers should implement appropriate controls over their data | The user entity classifies data before upload and keeps cardholder and regulated health data out of the service, which sits outside this description’s boundary |
| User entities are responsible for monitoring their activity | The user entity reviews the administrator activity export at least quarterly and investigates any entry it does not recognize |
| Users must keep their credentials confidential | The user entity enrolls every administrator in multi factor authentication and connects its own identity provider where supported |
Four parts of a testable CUEC
Each strong version above names who, what and when, in one sentence. The vague versions are not shorter. They are only emptier. Use this checklist on every line you draft.
- A precise actor. The user entity, not users. An individual employee of your customer has no authority to act for the company.
- A verb the customer performs. Reviews, removes, enrolls, classifies, approves. “Is responsible for” cannot be tested.
- A frequency or trigger. Quarterly, or within one business day of a departure. With no clock there is nothing to sample.
- The control it protects. If you cannot say which of your controls breaks when the customer skips this, it belongs in your docs, not the CUEC list.
If a criterion in scope requires you to run a control, listing it as a CUEC does not move the duty.3 Auditors push back. A buyer who spots your encryption duties in the customer column will read the rest of your description far less kindly. cybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Keep your list short. It gets written once, during the system description, and then every customer quotes it back at you while the report circulates. Four to eight precise items do more than twenty vague ones. Our system description template shows where the list sits.
Working through a vendor’s CUEC list
The other half of this topic lands in your inbox. A vendor sends a report, you glance at Section 1, see a clean opinion, and file it. Section 1 is standard language. After the checks that tell you a report is real, the part that needs action is in Section 3.
- Find it. Near the end of the system description, often under a plain heading with no emphasis.
- Assign a named person to each item. A team owner means whoever notices, which in practice means nobody.
- Check you actually do it. Be honest. Expect at least one item you assumed the vendor handled.
- Keep the evidence reachable. Their CUECs become your controls, and your auditor can ask you to show them.
- Document what you cannot meet and what you do instead. A written compensating control is defensible. Silence is not.
While the report is open, check its period. A CUEC list from a report that lapsed a year and a half ago describes a system that may have changed. How long a SOC 2 report stays valid covers that. If Section 4 shows deviations, read what an exception actually means before you escalate. File the result in your vendor assessment.
What this costs, and what you can write yourself
CUECs are a writing task. A consultant drafting your system description would bill for this list along with everything else. For scale, here is one published estimate of the consultant route for full SOC 2 preparation.
- Comp AI states that a vCISO or compliance consultant might charge $150 to $400 an hour, which can total $20,000 to $50,000 for a full SOC 2 prep engagement. Source, checked 2026-07-30.
You can write good CUECs yourself with the four part checklist above and an hour of focus. Scope drives most of the content, and we scope Security only, which keeps the boundary tight and the list short. Our Trust Services Criteria guide explains each criterion if you want more depth.
The software is $199 a month, cancel any time. Audits go through our preferred pricing program, and we negotiate the fee on your behalf, and you see the price in your account before you book. The full SOC 2 cost breakdown covers the rest.
Your next step
Before you write a single CUEC, find out what your system description needs to cover. The free readiness assessment takes about 15 minutes and returns a score and a gap list, including the vendor and boundary questions that shape this list. When you want to see the plans, go to pricing.
Questions
What does a complementary user entity control mean?
How is a CSOC different from a CUEC?
Should a small company use the carve-out or inclusive method?
Who is responsible for the CUECs in a vendor SOC 2 report?
Can I list my own duties as CUECs to reduce my scope?
Sources
Get audit-ready without a compliance team
The readiness assessment is free, with no payment and no card. When you are ready, the software is $199 a month, cancel any time, and audits go through our preferred pricing program. You can be audit-ready starting at about a week.
Start with a free readiness assessmentcybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.