Every SOC 2 report for a multi-tenant service has a short list most readers skip: the complementary user entity controls, usually called CUECs. They look like small print. They are closer to a condition attached to the opinion.
A CUEC is a control your system design assumes your customers will operate. If they do not, some of your controls will not achieve what the report says they achieve. The auditor's opinion is written with that dependency in mind.
This article covers what CUECs are, how they fit into the report, how to write them as a service organization, and what to do with them as a customer.
What a CUEC is, and why the report needs them
SOC 2 reports describe a system, and the system usually extends into your customers' hands. Your product lets customers create their own users, set their own passwords or connect their own single sign-on, and generate API keys. Your controls cannot reach those decisions.
The AICPA's description criteria require the system description to identify the controls that management assumed, in designing the system, would be operated by user entities, where those controls are needed to meet your service commitments and system requirements. Those are the CUECs. The auditor's opinion then states that its conclusions assume those complementary controls operated effectively.
Two things follow from that definition:
A CUEC must be necessary. It belongs on the list only if your commitments depend on it. General security advice for customers does not qualify.
A CUEC is not tested by your auditor. Your auditor examines your controls. Whether each customer operates its CUECs is outside the examination, and is each customer's concern.
Where CUECs appear in the report
CUECs are listed in the system description, often as a table that ties each one to the criteria it supports. The auditor's report refers to them in the opinion. In a Type II report, the section that sets out criteria, controls, and tests may note them against the relevant criteria too.
They sit alongside a related list for vendors: complementary subservice organization controls. Those are controls your design assumes a carved-out subservice organization, such as your cloud provider, will operate. The logic is the same, pointed at your vendors instead of your customers.
What good CUECs look like
A useful CUEC names a responsibility a customer can act on, connected to a part of your service. Some common areas, with examples:
| Area | Example CUEC |
|---|---|
| User administration | Customers are responsible for provisioning and removing access for their own users, and for reviewing that access periodically. |
| Authentication | Customers that use single sign-on are responsible for configuring and securing their identity provider, including multi-factor authentication. |
| Credentials | Customers are responsible for protecting API keys and other credentials issued to them, and for revoking them when compromised. |
| Input data | Customers are responsible for the accuracy and completeness of data they submit to the service. |
| Notification | Customers are responsible for notifying the service organization promptly of suspected security incidents involving their accounts. |
| Configuration | Customers are responsible for configuring data retention and sharing settings in line with their own requirements. |
Each of these connects to a control on your side. Your access controls protect the boundary of a tenant. The customer decides who is inside it. Your product offers multi-factor authentication. The customer enforces it for their users, or through their own identity provider. If your product enforces it for every user, the CUEC for that is unnecessary.
That last point is worth taking seriously. A CUEC often marks a place where a product decision moved responsibility to the customer. Sometimes that is the right design. Sometimes a default you control would remove the CUEC entirely. Enforcing MFA for every user and SSO as a compliance control cover two places where that choice comes up.
Writing your own CUECs
Draft them during scoping, then refine them as you write the system description. A practical process:
Walk through your shared responsibility model. For each criterion series, ask where your control stops and the customer's decision begins.
Check your contracts and documentation. Your terms of service and admin guides already assign responsibilities to customers. CUECs should be consistent with them, not stricter or looser.
Test necessity. For each draft CUEC, ask whether your commitments could fail if the customer did not do it. If not, remove it.
Make each one specific. Name the action and the part of the service. "The customer is responsible for security" is not a control.
Map each one to a criterion. This keeps the list honest, and buyers reading it can see why it is there.
Review with your auditor. They will have a view on whether the list is complete and whether any item shifts your own responsibility onto customers.
What gets CUECs wrong
The kitchen sink. A long list of everything a customer should do for good security dilutes the ones that matter, and reads as defensive.
Shifting your own work. "Customers are responsible for backing up their data" in a service that promises backups is a contradiction a buyer will catch.
Drift from the product. A feature changes during the period, and the CUEC describing the old behavior stays in the description.
Missing ones. If your design genuinely depends on a customer action and the report does not say so, the description is incomplete.
What to do with a vendor's CUECs
When you receive a SOC 2 report from a vendor, its CUECs become your to-do list. The vendor's opinion assumed you would operate them. If you do not, the assurance you are relying on has a hole in it, and it is a hole you created.
For each vendor report you review:
Find the list. It is usually in the system description, sometimes in a separate section near the end.
Map each CUEC to one of your controls. Your access review covers user administration in that vendor's tool. Your identity provider enforces multi-factor authentication for it.
Record gaps and decide on them. A CUEC you do not operate is a risk to accept, treat, or raise with the vendor.
Keep the mapping with the review. It is evidence for your own vendor risk process, which your auditor will examine under CC9.2 of the trust services criteria.
Say your team adopts a hypothetical ticketing service whose report lists four CUECs: customers manage their own users, review their access periodically, protect their API tokens, and report suspected incidents promptly. Your mapping might read: user management through your identity provider and its provisioning rules; access review through your quarterly review, with the ticketing service added to its scope; API tokens held in your secrets manager and rotated under your key management procedure; incident reporting through your incident response plan, which names the vendor's security contact. If the service is not yet in your access review, that is the gap, and adding it is the fix.
Teams that skip this step often have the right controls already. What they lack is the record showing they checked. A short mapping table, attached to each annual vendor review, closes that gap.
The glossary entry for CUECs and the SOC 2 framework page cover the surrounding terms.
How TrustLynce helps
TrustLynce's third-party risk module keeps vendor reviews, including the CUEC mapping from each vendor's SOC report, with the vendor record and its reassessment date. Compliance automation maps your own controls to the criteria, so each vendor CUEC can be tied to the control that meets it.