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-outInclusive
Scope of the descriptionOnly your controls. The vendor is named, its controls excludedYour controls and the vendor’s, described as one system
What gets testedYour controls, including how you pick and monitor the vendorBoth sets, at both companies
What the vendor must agree toNothing beyond sharing its own reportIts own management assertion, plus testing alongside you
What your report showsA CSOC list of controls you assume the vendor runsThe 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.

Carving out still leaves you on the hook

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.

VagueTestable
Users are responsible for the security of their accountsThe 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 dataThe 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 activityThe user entity reviews the administrator activity export at least quarterly and investigates any entry it does not recognize
Users must keep their credentials confidentialThe 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.

  1. A precise actor. The user entity, not users. An individual employee of your customer has no authority to act for the company.
  2. A verb the customer performs. Reviews, removes, enrolls, classifies, approves. “Is responsible for” cannot be tested.
  3. A frequency or trigger. Quarterly, or within one business day of a departure. With no clock there is nothing to sample.
  4. 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.
Do not park your own work here

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.

In someone else’s report, the CUEC list is your to-do list.
  1. Find it. Near the end of the system description, often under a plain heading with no emphasis.
  2. Assign a named person to each item. A team owner means whoever notices, which in practice means nobody.
  3. Check you actually do it. Be honest. Expect at least one item you assumed the vendor handled.
  4. Keep the evidence reachable. Their CUECs become your controls, and your auditor can ask you to show them.
  5. 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?
It is something your customer has to do so that your controls achieve what your SOC 2 system description says they achieve. The list sits in Section 3 of the report, inside the description management wrote. Your auditor never tests the customer, so the dependency has to be written down as a condition.
How is a CSOC different from a CUEC?
The direction. A CUEC points up at your customers. A CSOC, or complementary subservice organization control, points down at vendors you depend on, such as a cloud host or payment processor. Both describe a control you rely on and cannot test yourself.
Should a small company use the carve-out or inclusive method?
Carve-out, in nearly every case. The inclusive method needs the vendor to supply its own management assertion and be tested alongside you, which a large cloud provider will not agree to for a small customer. With carve-out you name the vendor, list the controls you assume it runs, and your own vendor management gets tested.
Who is responsible for the CUECs in a vendor SOC 2 report?
You are, as the customer reading it. Treat the list as tasks addressed to your company. Give each one a named owner, confirm you actually do it, and keep evidence your own auditor can reach.
Can I list my own duties as CUECs to reduce my scope?
No. If a criterion in scope requires you to run a control, putting it in the CUEC list does not move the obligation. Auditors will object, and a buyer reviewing the list will read the rest of your description with more suspicion.

Sources

  1. SOC 2 Report AICPA. What a SOC 2 report is and who may issue one. Checked 1 August 2026.
  2. Statements on Standards for Attestation Engagements AICPA. The attestation standards a SOC 2 examination is performed under. Checked 1 August 2026.
  3. TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers. Checked 1 August 2026.

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 assessment

cybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.