SOC 225 April 2026 6 min read

Complementary User Entity Controls in SOC 2 Reports

SOC 2 reports include CUECs — controls your customers must implement. Learn what CUECs are, how to document them, and what they mean for both service providers and report users.

Key Takeaways

CUECs are controls in a SOC 2 report that the service organization assumes its customer (the "user entity") will implement for the overall system to be secure.
As a service provider, you define CUECs in your system description to communicate the control environment assumptions underlying your audit.
As a customer of a vendor, you must implement the CUECs listed in that vendor's SOC 2 report — your auditor will check this.
Common CUECs include: configure strong authentication, restrict API key permissions, implement access reviews for the service, and review the vendor's SOC 2 report annually.
CUECs should be practical and specific — abstract statements like "implement appropriate controls" are less useful than "configure MFA on all user accounts accessing the platform."

In this guide

What Are CUECs
Writing CUECs as a Service Provider
Implementing CUECs as a Customer
CUEC Examples by Category
How CUECs Are Tested in an Audit
CUECs vs CSCECs

What Are CUECs

Complementary User Entity Controls (CUECs) are documented in Section 2 of a SOC 2 report (the service organization's system description) and represent the controls that the service organization assumes its customers — referred to as "user entities" — will implement as part of the overall system of internal control. Without these customer-side controls in place, the service organization cannot fully meet all Trust Service Criteria commitments.

The concept reflects the shared responsibility model of cloud computing. AWS can implement all the physical security and network controls in the world, but if a customer configures their IAM roles to be publicly accessible, the overall security of that customer's environment is compromised. CUECs make this shared responsibility explicit and auditable.

CUECs do not transfer responsibility from the service provider to the customer — both parties retain responsibility for their respective controls. Rather, CUECs document the assumptions that the service provider's audit relies on. An enterprise customer reviewing a vendor's SOC 2 report is expected to read Section 2, identify the CUECs, and verify their own compliance with them.

Writing CUECs as a Service Provider

When writing your own SOC 2 system description, you define CUECs that describe the controls your customers must implement for your shared security model to work. The scope of your CUECs depends on your product architecture and the access your customers have to your system. For a multi-tenant SaaS product, relevant CUECs typically include: customers must configure strong passwords and MFA for all user accounts; customers must grant access only to personnel with a legitimate need; customers must review user account access regularly and revoke access for departed personnel; and customers must report suspected security incidents to the service provider promptly.

CUECs should be written at a level of specificity that allows a customer's auditor to test whether they have been implemented. "Implement appropriate security measures" is too vague. "Configure multi-factor authentication on all administrator accounts in the platform" is testable. Review each Trust Service Criterion and ask: what actions by the customer could undermine our ability to meet this criterion? Those customer actions become your CUECs.

Work with your auditor to finalize the CUEC language. Auditors have seen hundreds of CUEC sections and can identify whether your list is complete and appropriately specific. Adding relevant CUECs is not in your interest commercially — customers may be annoyed by a long list — but they are a legal and professional necessity for an accurate system description.

Implementing CUECs as a Customer

As a customer of a vendor who has a SOC 2 report, you are expected to read that report's CUEC section and verify that your organization has implemented each listed control. Your own SOC 2 auditor will test whether you have implemented the CUECs of your significant subservice organizations — this is how CC9.2 (subservice organization management) is operationalized at the customer level.

Create a CUEC implementation register: for each significant vendor, list the CUECs from their SOC 2 report, identify which controls you have implemented, and link to the evidence. For AWS, this might look like: "CUEC: Configure IAM roles with least-privilege permissions — Implemented via IAM policies reviewed quarterly, linked to access review records." For Okta: "CUEC: Configure MFA for all user accounts — Implemented via global authentication policy requiring MFA, screenshot evidence in evidence library."

Review your CUEC implementation status annually when you renew your vendor SOC 2 report review. Vendors update their CUEC sections over time as their product evolves, and new CUECs may be added that require action on your part. A CUEC that was not relevant in year one may become relevant after a vendor product update.

CUEC Examples by Category

Authentication CUECs (common from identity providers and SaaS platforms): "User entities must require MFA for all accounts accessing the platform." "User entities must configure session timeout policies not exceeding [n] minutes of inactivity." "User entities are responsible for promptly revoking access for personnel no longer requiring access." These CUECs reflect the shared responsibility for authentication strength.

Access management CUECs (common from cloud infrastructure and data platforms): "User entities must configure IAM roles and policies in accordance with least-privilege principles." "User entities must conduct periodic reviews of user access and API key assignments." "User entities are responsible for managing their own encryption keys when using customer-managed key options." These reflect the customer's responsibility for their own configuration within the provider's platform.

Operational CUECs (common from monitoring and infrastructure providers): "User entities must configure alert notifications to security personnel for events detected by the service." "User entities are responsible for conducting application-layer security testing of their implementations." "User entities must obtain and review this SOC 2 report as part of their vendor risk management program." These reflect the expectation that customers are active participants in the security model, not passive recipients.

How CUECs Are Tested in an Audit

In your own SOC 2 audit (as the service provider), your auditor is not responsible for testing whether your customers have implemented your CUECs. The CUECs are noted in the report and the responsibility for implementation passes to the customer. However, your auditor will verify that your CUEC language is consistent with your system description — CUECs that describe customer controls that contradict or overlap with your own controls will be questioned.

In your customer's SOC 2 audit (when your product is a subservice organization to your customer), your customer's auditor tests whether the CUECs have been implemented. They do this by requesting evidence of implementation for each CUEC listed in your report. This is why CUECs must be testable — vague CUECs create ambiguity about what evidence is required.

When you are both a service provider (with CUECs for your customers) and a customer (with CUECs to implement from your vendors), you have a dual role in the CUEC ecosystem. Your compliance program must address both: publishing appropriate CUECs in your own report and maintaining evidence that you have implemented your vendors' CUECs.

CUECs vs CSCECs

In addition to CUECs (Complementary User Entity Controls — customer controls), SOC 2 reports may include CSCECs — Complementary Subservice Organization Entity Controls. CSCECs are controls that the service organization assumes its subservice organizations (vendors like AWS) have implemented. Where CUECs describe what customers must do, CSCECs describe what vendors must do.

For example, a SaaS company's SOC 2 report might include a CSCEC stating: "AWS, as a subservice organization, is assumed to maintain the physical security, environmental controls, and infrastructure availability described in their SOC 2 report." The existence of this CSCEC means that the carve-out method is applied to AWS, and customers must obtain the AWS SOC 2 report to assess those controls.

Auditors will verify that your CSCECs are consistent with the controls actually provided by your subservice organizations — you cannot assert CSCECs that your vendors have not documented in their own reports. Review your subservice organization's control descriptions when drafting your CSCECs to ensure alignment.

Frequently Asked Questions

Do our customers need to implement our CUECs to maintain their SOC 2 compliance?

Yes. If your customer has a SOC 2 report and you are listed as a subservice organization in it, their auditor will test whether they have implemented your CUECs. Customers who have not implemented your CUECs may receive exceptions in their own audit reports for the control areas covered by the unimplemented CUECs. This is a meaningful business consideration — some customers may ask you to minimize your CUEC list so as not to create additional compliance obligations for them.

Can we have zero CUECs in our SOC 2 report?

It is theoretically possible but practically unusual for a SaaS product to have zero CUECs. Almost all SaaS products rely on customers to configure access controls, manage their own user accounts, and report security incidents. Zero CUECs might suggest that the service organization is claiming full responsibility for controls that inherently require customer action — auditors will scrutinize this claim carefully.

How do we communicate our CUECs to our customers?

Your SOC 2 report (specifically Section 2) is the primary vehicle. Enterprise customers who request your report will read Section 2. Additionally, you can reference your CUECs in your security documentation, implementation guides, or customer trust center. Some companies publish a one-page CUEC summary as part of their customer-facing security documentation so customers don't need to read the full report to understand their responsibilities.

What happens if a customer doesn't implement our CUECs and there is a breach?

This is a contractual and legal question, not a SOC 2 question. Your SOC 2 report documents the control environment assumption; whether a customer's failure to implement CUECs limits your liability in a breach scenario depends on your terms of service, data processing agreement, and applicable law. Many service providers explicitly reference their SOC 2 report's CUECs in their security addendums to establish that customer configuration errors are outside their control perimeter.

Our vendor updated their CUECs and added new requirements. What should we do?

Obtain the updated SOC 2 report, read the CUEC section, identify new or modified CUECs, and assess whether you have already implemented them or need to take action. Update your CUEC implementation register and assign owners for any gaps. Document the review date and the assessment outcome. This process is part of your annual vendor review under CC9.2.