SOC 2 Complementary User Entity Controls (CUECs), Explained

By Editorial team · Published 2026-04-22 · Last updated 2026-04-22

CUECs define what a buyer is responsible for implementing when using a vendor's SOC 2-covered service. Most buyers ignore them. They shouldn't.

Complementary User Entity Controls (CUECs) are one of the most consistently misunderstood elements in a SOC 2 report. They appear in Section 4 of the report and describe controls that the service organization's system assumes its customers (user entities) are implementing. If the user entity hasn't implemented them, the service organization's controls may not achieve their stated objectives — and the auditor's opinion doesn't cover that gap. Buyers who don't read the CUEC section are missing half the picture.

Where CUECs come from — the AICPA framework

Under the AICPA's SOC 2 reporting framework (SSAE 18, AT-C §205), a service organization's description of its system must include the relevant aspects of controls that user entities are expected to implement. The AICPA defines CUECs as 'controls that management of the service organization assumes, in the design of the service, will be implemented by user entities and which, if not implemented, are likely to prevent the achievement of the service organization's control objectives.'

In plain terms: the service vendor designed their controls assuming you're doing certain things on your end. CUECs document what those things are. If you're not doing them, the vendor's SOC 2 controls don't protect you as fully as the report implies.

Common CUEC examples across SaaS product categories

• Identity and access management: 'User entities are responsible for managing user provisioning and deprovisioning in the service provider's platform.' If you don't have a documented offboarding process that includes deprovisioning the vendor's system, this CUEC is unmet.
• API key and credential security: 'User entities are responsible for maintaining the confidentiality of API keys issued by the service organization.' Shared or unrotated API keys in your codebase are a CUEC failure.
• Data classification before transmission: 'User entities should not transmit data classified above [level] to the service.' This is common in multi-tenant SaaS where the vendor limits what data types are covered by the SOC 2 scope.
• Incident reporting: 'User entities are responsible for reporting suspected security incidents to the service organization within 24 hours.' Many buyers have no defined incident reporting procedure for vendor systems.
• Network-level controls: 'User entities are responsible for controlling access to the service from their network environment.' This assumes the buyer has firewall rules, VPN requirements, or IP allowlisting in place.

How buyers should review the CUEC section

1. Locate Section 4 of the SOC 2 report: CUECs are typically documented in the service organization's description of its system, often in a dedicated subsection. They may also appear in management's response or in specific control activity descriptions.
2. Inventory each CUEC against your current controls: For each stated CUEC, determine whether your organization has a control that satisfies it. Document the mapping.
3. Identify unmet CUECs: Any CUEC without a corresponding internal control represents a shared-responsibility gap. This isn't the vendor's fault — it's a scoping decision the buyer needs to address.
4. Include CUEC compliance in vendor onboarding: Your vendor onboarding process should include a CUEC review step. The team that owns the vendor relationship (often IT security or procurement) should confirm CUEC satisfaction before production integration.
5. Track CUEC changes across audit cycles: CUECs can change between a vendor's annual reports. When reviewing a new SOC 2 report from an existing vendor, compare the CUEC section to the prior year's report and identify any new assumptions.

CUECs vs. Complementary Subservice Organization Controls (CSOCs)

CUECs are sometimes confused with Complementary Subservice Organization Controls (CSOCs), which appear when a service organization uses a carve-out method for a subservice provider (e.g., AWS). CSOCs describe controls that the subservice organization is expected to have. CUECs describe controls that the customer (user entity) is expected to have. They operate at different levels of the service chain and require different review responses.

For service organizations writing CUECs

If you're a vendor writing your SOC 2 system description, the CUEC section should be specific and honest, not a generic disclaimer list. Auditors including those at Schellman, Prescient Assurance, and BARR Advisory will push back on CUECs that are so broad they become meaningless. A CUEC that says 'user entities are responsible for all data they transmit' is not a control assumption — it's a liability shift. Write CUECs that reflect your actual system design dependencies, and your customers will take them seriously.

CUECs and shared responsibility in multi-tenant SaaS

Multi-tenant SaaS products have an inherent shared responsibility model: the vendor controls the platform; the customer controls how they configure and use it. CUECs formalize the customer side of this model. In practice, a well-written CUEC section in a multi-tenant SaaS SOC 2 report will specify: which access configurations are the customer's responsibility (e.g., which user roles have export capability), which data types the service assumes the customer has classified before uploading, and which notification obligations fall on the customer in the event of a suspected account compromise. Customers who read and implement the CUEC section are better protected — and better positioned to pass their own vendor security reviews when they list the SaaS vendor as a subservice provider.

From a vendor perspective, CUECs that are specific and implementable by the customer create a more defensible SOC 2 program. If a security incident occurs and it traces back to a configuration the customer was responsible for maintaining (per the CUEC section), the CUECs provide documented evidence of where the responsibility boundary was defined. This matters in both contractual disputes and in post-incident regulatory reviews.