Complementary user entity controls, or CUECs, are controls your SOC 2 report assumes your customers operate on their side. If a customer does not run them, the report does not fully protect that customer. You list them in the report so readers know where your responsibility ends and theirs starts.
Why they exist
Your controls cover your system. They cannot cover how a customer manages its own users. If your product lets an admin invite users, your controls can make sure the invite works as designed. They cannot make the customer remove a leaver from their account.
CUECs state that boundary honestly. They also help customers during vendor reviews, because they map straight to a to do list.
CUECs versus subservice controls
Do not mix up two similar terms.
- CUECs are what you expect of your customers.
- Complementary subservice organization controls, or CSOCs, are what you expect of vendors whose controls are carved out of your report, such as a cloud host.
Both sit in the report. They point in opposite directions. See vendor management and carve out reports for the second.
How to find your CUECs
Walk through your product and ask who does what.
- Account and access: customers manage their own users, roles and offboarding.
- Authentication: customers enable MFA or SSO if you offer it as an option.
- Configuration: customers set retention, sharing and permission settings.
- Data: customers decide what data they upload and classify it.
- Integrations: customers review the API keys and apps they connect.
- Notification: customers keep contact details current so they receive security notices.
Each item where a customer can weaken their own security is a candidate.
How to word them
Short, specific and testable by the customer. For example: "User entities are responsible for removing access for their own personnel who no longer need it." Avoid legal sounding text and avoid vague phrases such as "customers should follow best practices".
Keep the list to controls that truly matter. A report with forty CUECs reads like an attempt to push blame, and customers will notice.
Tell your customers
Publish the CUECs in your documentation as a security responsibilities page, linked from onboarding. In sales, offer the list when someone asks about shared responsibility. A customer who knows the list before signing is less likely to be surprised later.
If you can make a CUEC easier to meet through product features, such as audit logs, SSO and role based access, say so. That is a real advantage.
Keep the list alive
Review the CUEC list whenever the product changes. A new admin feature, a new integration or a new data type can add a customer side duty. Compare the list in the report with the one in your documentation, because a mismatch confuses buyers and auditors alike. Ask support to flag recurring customer mistakes. If many customers forget the same step, either make the product enforce it or move it higher in the onboarding guide.
Quick check
Do CUECs get tested by our auditor?
No. The auditor tests your controls. CUECs are listed so readers know what they must cover themselves.
Who writes the CUEC list?
Your management, usually with input from product and support. Your auditor will review it for clarity.
Last reviewed: 19 October 2026.
