Complementary user entity controls (CUECs)
A complementary user entity control is something your customer has to do for your control to work. They sit in your report, they get read, and badly written ones shift blame without reducing risk.
A complementary user entity control, or CUEC, is a control that your customer must operate for one of your controls to achieve its criterion. Configuring single sign-on, removing their own departed users from your application, and protecting the API keys you issue are the three that appear in nearly every SaaS company's SOC 2 report. They are listed in the system description, they are not tested by your auditor, and a security reviewer will read the list to work out what your report is quietly making their problem.
5 to 15 CUECs in a typical SaaS company's SOC 2 report
Not tested By your auditor. The customer performs them
Why they exist
Multi-tenant software gives the customer a share of the control. You can enforce password complexity, but you cannot stop an administrator at a customer creating a shared login. You can log every administrative action, but you cannot make anyone read the log. Where the criterion can only be met by the two of you acting together, the report says so, and the half you do not control becomes a CUEC.
The list is a statement about the product's security model, not a legal formality. A report with twenty CUECs is describing software that pushes a lot of responsibility onto the buyer. A report with four is describing software with more secure defaults. Reviewers who know what they are doing count them.
CUECs a SaaS company normally lists
| CUEC | Supports | What goes wrong without it |
|---|---|---|
| Provision and deprovision their own users promptly | Logical access | Departed employees at the customer keep access to their data |
| Configure single sign-on and multi-factor authentication where offered | Logical access | Credential stuffing against local accounts |
| Protect API keys and rotate them | Logical access, confidentiality | A leaked key in a public repository reads their tenant |
| Assign the least privileged role to each user | Logical access | Every user is an administrator |
| Review their own audit logs and administrative reports | Monitoring | Misuse inside their own tenant goes unnoticed |
| Validate the accuracy of data they submit | Processing integrity | Garbage in, processed faithfully, garbage out |
| Notify you of a suspected security incident | Incident response | Your response clock starts late |
| Maintain their own copies of exported data where they need retention | Availability | Deletion inside your retention policy is irreversible |
Writing CUECs your customers will accept
The temptation is a long list, since everything on it is something you are not responsible for. Resist it. A reviewer reading fourteen CUECs on a product with three configuration options concludes the list was written defensively, and asks the questions you were avoiding.
- Write one CUEC for each place where the customer genuinely holds half of a control, and no more.
- Say what the customer must do, not what they must generally maintain. "Remove users within one business day of departure" is a control. "Maintain appropriate security" is not.
- Check that your product actually lets them do it. A CUEC that requires a capability you do not ship is a finding waiting to happen.
- Match the CUEC list to your documentation. If the report tells a customer to rotate keys and your docs never mention rotation, the gap gets noticed.
- Review the list every year. Features that shipped secure by default should come off it.
The counter-argument, honestly
Sales teams sometimes push for a short CUEC list because it reads better. Under-listing is the worse error. If a customer's data is exposed by a configuration you never told them to set, the absence of the CUEC is the first thing their counsel finds. List what is real, keep it specific, and put the same guidance in your product documentation, where somebody might read it before an incident.
Reading a supplier's CUEC list
The other half of this is your job as a customer. When you collect a vendor's SOC 2 report, the CUEC list is a task list handed to you, and most companies file the report without reading it. Every CUEC in it is a control you now own, and your own auditor can ask for evidence that you perform it.
0 of 0 done ยท
That checklist is stored in your own browser and nowhere else. The wider process it belongs to is on the vendor management page, and the mechanics of reading the rest of a report are on how to read a SOC 2 report.
CUECs against subservice organizations
Both acknowledge controls sitting outside the audited entity, and they point in opposite directions. CUECs point at your customer. Subservice organizations point at your suppliers. A report with neither is either a very simple system or a description nobody thought through. The subservice organizations page covers the other direction, including the carve-out method that nearly everyone uses.
Get your system description reviewed
The CUEC list is written during readiness, not during fieldwork. Have someone who reads these for a living look at yours.
Get matchedCommon questions
What does CUEC stand for?
Complementary user entity control. The user entity is your customer, the organization using your service. It is a control they must perform for one of your controls to meet its criterion, and it is listed in your SOC 2 system description rather than tested by your auditor.
Does the auditor test our CUECs?
No. Your auditor tests your controls. CUECs are performed by your customers, who are not part of your engagement, so the report discloses them and stops there. Your customer's own auditor may test them as part of that customer's audit.
How many CUECs should a SOC 2 report have?
Five to fifteen is the usual band for a business to business SaaS product. Fewer suggests either a very locked-down product or an incomplete list. Many more suggests a product that leaves a lot of security decisions to the customer, which is a real finding about the product rather than about the report.
What do we do with the CUECs in a vendor's report?
Treat each one as a control you now own. Assign it to a named person, confirm you actually perform it, keep evidence, and log the ones you do not perform as accepted risks. Your own auditor can and does ask whether you read the CUEC lists in the reports you collect.
Are CUECs the same as the shared responsibility model?
They are the audit expression of the same idea. A shared responsibility model is a marketing and documentation artifact describing where your duties end. CUECs are the specific, testable version of that boundary, written into a report a CPA firm signed. When the two disagree, the report is the one your customer's reviewer will quote back at you.