Complementary User Entity Controls: The Part Buyers Miss
When a vendor hands you a clean SOC 2 opinion, there's a section most buyers skip that determines whether that assurance actually applies to your use of the service.
You've just received a vendor's SOC 2 Type 2 report. You scan to the auditor's opinion: clean, no exceptions, favorable. You add it to the vendor file and move on. What most buyers skip is a list, somewhere in the system description, that outlines controls you are supposed to have in place for the vendor's security program to hold together. If those are news to you, the assurance you just filed is thinner than you think.
That list is the Complementary User Entity Controls, and ignoring it is one of the most common gaps in vendor due diligence.
What CUECs actually are
A SOC 2 report documents what a service organization (the vendor) does to protect your data. But most security outcomes require both parties to act. A cloud vendor can't control whether your users have weak passwords. A payroll platform can't force you to deprovision a terminated employee's access. The auditor can only test what the vendor controls, and your side of the equation is explicitly carved out.
CUECs are how the auditor documents that carve-out. They're a list of assumptions the service organization's controls rely on. The vendor's controls are designed to work alongside those customer-side controls. If you're not implementing them, the auditor's positive opinion on the vendor's controls doesn't extend to cover the gap.
The AICPA's Trust Services Criteria framework, which governs SOC 2 audits, builds this concept in deliberately. It recognizes that a service organization operates within a larger system that includes its customers, and that the system description in the report has to be honest about which parts of that system live on the customer side.
Where they appear in the report
SOC 2 reports follow a consistent structure. After the management assertion and auditor's report, the bulk of the document is the system description: a detailed account of the vendor's environment, controls, and scope. The CUECs appear within that description, sometimes under a heading with that exact name, sometimes embedded in the section describing how the system achieves its control objectives.
The length varies a lot. A simple SaaS product might list five controls. A complex platform with deeper integration into a customer's infrastructure might list twenty or more. The number isn't a quality signal; it reflects the nature of the service and how much of the security picture depends on customer behavior.
Worth being clear about: the auditor doesn't test CUECs during the vendor's audit. They test the vendor's controls. The CUEC list is the auditor's documentation that certain responsibilities rest with you — not a verification that you've actually met them.
What the list typically includes
The specifics vary by service, but patterns appear repeatedly across almost every SOC 2 report:
- Access provisioning and deprovisioning. The vendor expects you to grant access only to users who need it and revoke it promptly when someone leaves or changes roles. The vendor often has no reliable way to know when an employee quits.
- Authentication standards. Many vendors require you to enforce multi-factor authentication for your own users, especially for admin-level accounts, even if the vendor doesn't mandate it at the platform level.
- Periodic access reviews. You're expected to review who has access to the service on a regular schedule. The vendor keeps logs; acting on them is your job.
- Secure data handling on your end. If you're transmitting data to the vendor, you're responsible for handling it securely on your side before it arrives. Encrypted transit is often assumed, not optional.
- Incident notification. Some reports include a control requiring you to notify the vendor if you suspect a breach or incident on your end that could affect shared data or the service environment.
- Configuration and permission management. Role assignments, API key scoping, integration permissions; these typically live in the customer's hands, and the report reflects that explicitly.
Reading CUECs as a buyer
When a vendor's SOC 2 report arrives, the CUEC list deserves a pass against your own environment. For each control, the question is simple: are we actually doing this?
If the answer is yes across the board, you've confirmed that the report's assurance extends to your use of the service. That's worth documenting. It's the information most vendor reviews never capture.
If the answer is no, or uncertain, that's a finding — not a vendor finding, but a gap in your own posture. The right response isn't to ding the vendor's score; it's to document the gap and either close it or accept the residual risk formally. If the control involves prompt deprovisioning or MFA enforcement and you're not doing it, you have a real exposure regardless of how strong the vendor's own controls are.
Some security teams have started treating the CUEC review as a standing step in vendor onboarding. It takes fifteen minutes per report and it's one of the few steps in vendor due diligence that produces action items for your program rather than just a stack of the vendor's paperwork. The vendor risk assessment checklist includes a step for this if you're building a structured process.
What vendors should know about writing them
If you're the service organization, the CUECs in your report define where your responsibility ends and your customer's begins. That boundary matters for the audit and for your own security posture.
Be specific. Vague CUECs ("customers should maintain appropriate security controls") give your customers no real guidance and are harder to audit around. A statement like "customers are responsible for revoking user access within 24 hours of termination" sets a clear expectation and is far more useful to the people actually trying to implement it.
Your customer-facing security documentation should reflect them too. If the report says customers are responsible for timely deprovisioning, that guidance should appear somewhere customers actually read, not only in a PDF that most never open.
CUECs can also drift over time. When you add features, introduce new integration points, or change how authentication is handled, the customer responsibilities can shift. Review the list when you re-scope or expand your audit, not just at renewal.
For an overview of how the SOC 2 audit process works and what goes into a system description, the SOC 2 guide covers the structure, timeline, and what the whole thing costs. The Type 1 vs Type 2 breakdown goes into what the auditor is actually attesting to in each report type, which matters when you're evaluating what a clean opinion means for a specific audit period.
The review habit worth building
The standard SOC 2 review at most companies goes like this: receive report, check opinion, file. The CUEC section is a casualty of that habit, and it's the section that actually implicates your own security controls.
A better version: when a vendor's SOC 2 lands, note the CUECs alongside the audit period and opinion. Walk through them against your current implementation. Document any gaps. That one extra step converts a file-and-forget process into something that reduces real risk.
The audit covered the vendor's side. The CUECs are telling you to cover yours.