What are examples of CUECs?

Secureframe gives examples such as configuring MFA for your users, disabling former employees' accounts in a timely manner, keeping endpoint protection current and reviewing permissions regularly. ZenGRC adds logical and physical access controls and routine patching. The exact wording differs in every report, so copy the list from the vendor's report rather than from an example.

What is the difference between CUECs and CSOCs?

A CUEC is a control the vendor expects you, its customer, to operate. A complementary subservice organization control (CSOC) is a control the vendor relies on one of its own vendors, such as a cloud provider, to operate. ZenGRC describes CSOCs as controls the service provider outsources, performed by another entity while the provider remains responsible for their effectiveness. For your vendor review, CUECs go on your to-do list and CSOCs tell you who sits behind the vendor.

What happens if we do not operate a CUEC?

The vendor's report may stop covering that risk for you. ZenGRC notes that if a customer does not perform its CUECs consistently, the service organization's controls can fail to achieve their purpose. In practice you would show an auditor a gap in your vendor review: a control the vendor assumed you ran and you did not. Fix it or record an approved exception with a date, and keep the evidence.

Do I need to operate every CUEC in the report?

No, only the ones that apply to how you use the service. A vendor report covers every customer, and some CUECs concern features you may not use. For each one, record whether it applies and why. If it applies, name the control you operate, the owner and where the evidence lives. If it does not, write the reason down, because an unexplained blank looks the same as a missed control.

Where are CUECs in the report?

Usually in a sub-section of the system description, or in the section describing the tested controls. Secureframe says the section is typically titled Complementary User Entity Controls or something similar, so scan the table of contents for those words and for headings such as user control considerations. If you cannot find a section, ask the vendor where the report lists them.

Do we need CUECs in our own report too?

If you are the service organization, yes where your controls depend on customers. Your system description lists the controls customers are expected to operate, such as managing their own users and protecting their API keys, so a customer's auditor knows what the customer is responsible for. List only what your product genuinely relies on, and do not copy another vendor's list.

Complementary user entity controls (CUECs) in a SOC 2 report

Updated 25 October 2026

Complementary user entity controls (CUECs) are the controls a service organization's SOC 2 report says its customers must operate for the vendor's controls to work as described. Examples are managing your own users' access, turning on MFA for your accounts and reviewing the logs the vendor provides. You find them in the vendor's report, usually in the system description. Your auditor expects you to map the ones that apply to you to controls you actually run, and to keep evidence that they operated. This guide shows where to look, how to tell CUECs from subservice controls, a step-by-step way to map them, and how to write your own.

What a CUEC is

A SOC 2 report is written by a licensed CPA firm after it examines the vendor's controls against the Trust Services Criteria. Some of those controls cannot work unless the customer does its part. A cloud provider can secure its platform, but it cannot decide who in your company holds an administrator login. The report states that split of duties as a list of controls the customer is expected to perform, which is what makes them "complementary".

Secureframe defines a CUEC as a control that a service provider expects its customers to implement. Scytale describes them as a shared responsibility: the customer has to perform certain controls for the service organization's control criteria to be met. ZenGRC adds that a CUEC's implementation depends on the user entity, not on the service provider. You may also see them under headings such as user control considerations.

CUECs and CSOCs are different lists

A second acronym appears in the same part of a report and is easy to mix up. ZenGRC warns that CUECs should not be confused with Complementary Sub-Service Organization Controls, which it describes as controls the service provider outsources to its own vendors.

CUEC	CSOC
Operated by you, the vendor's customer	Operated by the vendor's own vendor, such as its cloud provider
Listed so you know what you must do	Listed so you know whom the vendor depends on
Goes into your control set and evidence	Goes into your vendor inventory as a fourth party

The third row is a recommendation for how to record them, not a rule from the criteria. The vendor stays responsible for the controls it outsources; you are responsible for the ones the report assigns to you.

Where to find them in a vendor's report

Secureframe says the section is typically titled Complementary User Entity Controls or something similar. Scytale places CUECs in the system description, where the auditor evaluates whether they are fairly presented, and ZenGRC says they sit in a sub-section of the service description or in the tested controls section. Practical steps:

Open the table of contents and search the PDF for "user entity", "complementary" and "user control".
Read the section on subservice organizations next to it. That is where the CSOCs and carve-outs are listed.
Check that the report covers the product you use. A CUEC list for another product line does not describe your duties.
If you do not have the report yet, see where to get your vendors' SOC 2 reports.

Typical CUECs by kind of vendor

Every report words its CUECs differently, and this page does not claim what any particular vendor's report says. Policyseed's vendor review records use the starting points below as prompts for the kinds of vendor most startups have. Replace them with the list in the report you actually read.

Kind of vendor	Controls to look for
Cloud hosting	Manage users, roles and keys in your account. MFA on console access. Encryption, network rules, logging and backups for what you build.
Source control	Manage members and permissions. Require MFA or single sign-on. Branch protection. Rotate tokens and deploy keys.
Identity provider	Provision and remove users. Set MFA and password policy. Review administrators and sign-in logs.
Other SaaS tools	Manage accounts and roles in your workspace. Decide what data you send. Tell the vendor about incidents involving its service.

How to map CUECs from your vendors' reports

Pick the vendors. Start with the Tier 1 vendors in your inventory: the ones that store or process customer data or hold production access. The vendor policy sets the tiers.
Get the current report. Note the report type and period, and confirm it covers the service you use.
Copy the CUEC list word for word. One row per control. Do not paraphrase, because the auditor can compare your list with the report.
Decide if each one applies. It applies if you use the feature or hold the responsibility described. If it does not, write why.
Map it to a control you already run. Name the policy section, the owner and the evidence. Many CUECs are your ordinary controls seen from the vendor's side: user access reviews, MFA, offboarding and log review.
Close the gaps. If a CUEC applies and nothing in your set covers it, add the control or record an approved exception with an owner and an expiry date.
Record it in the vendor review. Put the list, the owners and the evidence locations in the review record, with the date and the reviewer.
Repeat when the report changes. New reports can add or reword CUECs. Secureframe suggests revisiting them before renewals and security reviews. Operate them consistently across the whole period, as ZenGRC points out, not only at review time.

A mapped row looks like this. The wording is illustrative, not taken from any vendor's report:

CUEC (as written in the report)	Your control and evidence
Customers disable accounts of former employees in a timely manner.	Offboarding checklist closes the account. Evidence: the completed checklist and a quarterly access review.
Customers configure MFA for their users.	MFA enforced in the identity provider. Evidence: the setting, with a date.
Customers review the logs the service provides.	Weekly alert review in the ticket queue. Evidence: the review log.
Customers restrict access by IP address.	Not applicable: we do not use the feature. Reason recorded in the vendor review.

What the generated vendor policy says about CUECs

The Vendor and Third-Party Risk Management Policy asks the Security Owner to record the CUECs when reviewing a Tier 1 vendor. The two statements below are rendered from the policy template for the Northwind Cloud Inc sample intake, so they change when the template does.

Section 4.3: For Tier 1 vendors, the Security Owner reviews an independent assurance report covering the service used, records exceptions and the complementary user entity controls Northwind Cloud Inc must operate, and documents the data flow and sub-processors.

Section 5.2: Due diligence. For Tier 1 vendors, the Security Owner obtains the current SOC 2 Type II report or ISO 27001 certificate, reviews scope, opinion, exceptions and complementary user entity controls, sends the Northwind Cloud Inc questionnaire where gaps remain and documents the data flow with Engineering; Tier 2 vendors need an assurance report or completed questionnaire. Findings and the final tier are recorded.

That is the link to the criteria. SOC 2 criterion CC9.2 asks how you assess and manage risk from vendors and business partners, and CUECs are the part of a vendor's report where that risk lands back on you. The free vendor review template builds one draft record per vendor you name, with a CUEC line for each and a place for the owner and the evidence. The vendor reports guide covers what else to check in each report.

Writing CUECs for your own customers

If you are the service organization, the same list runs the other way. Your system description names the controls your customers are expected to operate, so a customer's auditor knows what the customer is responsible for. Your auditor then evaluates whether that list is fairly presented, as Scytale notes. The system description template includes a CUEC section drafted with examples such as these:

Customers manage their own users' access to the service and remove people who no longer need it.
Customers protect their account credentials and use the sign-in protections the service offers.
Customers keep API keys and tokens secret and rotate them if they may have been exposed.
Customers report suspected security incidents to you promptly.

Check each against how your product really works and delete what does not apply. Only list controls your own controls depend on, and write them from your product, not from your hosting provider's report. Telling customers where the list is helps: Secureframe suggests explaining the section, adding reminders to onboarding material and revisiting it before renewals, and Scytale recommends discussing CUECs with customers before the SOC 2 process starts.

The Audit Kit ($59, one time) includes both sides as editable drafts: the vendor review records with typical CUECs per vendor, and a first draft of the system description with its CUEC section. Every fact the intake does not supply is left as a placeholder for you to fill in.

Frequently asked questions

What are complementary user entity controls (CUECs) in a SOC 2 report?: Controls that the service organization's report says its customers (the user entities) must operate for the service organization's own controls to work as described. Typical examples are managing your own users' access, turning on multi-factor authentication for your accounts and reviewing the logs the vendor gives you. They are listed in the report, normally inside the system description, and your auditor expects you to operate the ones that apply to how you use the service.
What are examples of CUECs?: Secureframe gives examples such as configuring MFA for your users, disabling former employees' accounts in a timely manner, keeping endpoint protection current and reviewing permissions regularly. ZenGRC adds logical and physical access controls and routine patching. The exact wording differs in every report, so copy the list from the vendor's report rather than from an example.
What is the difference between CUECs and CSOCs?: A CUEC is a control the vendor expects you, its customer, to operate. A complementary subservice organization control (CSOC) is a control the vendor relies on one of its own vendors, such as a cloud provider, to operate. ZenGRC describes CSOCs as controls the service provider outsources, performed by another entity while the provider remains responsible for their effectiveness. For your vendor review, CUECs go on your to-do list and CSOCs tell you who sits behind the vendor.
What happens if we do not operate a CUEC?: The vendor's report may stop covering that risk for you. ZenGRC notes that if a customer does not perform its CUECs consistently, the service organization's controls can fail to achieve their purpose. In practice you would show an auditor a gap in your vendor review: a control the vendor assumed you ran and you did not. Fix it or record an approved exception with a date, and keep the evidence.
Do I need to operate every CUEC in the report?: No, only the ones that apply to how you use the service. A vendor report covers every customer, and some CUECs concern features you may not use. For each one, record whether it applies and why. If it applies, name the control you operate, the owner and where the evidence lives. If it does not, write the reason down, because an unexplained blank looks the same as a missed control.
Where are CUECs in the report?: Usually in a sub-section of the system description, or in the section describing the tested controls. Secureframe says the section is typically titled Complementary User Entity Controls or something similar, so scan the table of contents for those words and for headings such as user control considerations. If you cannot find a section, ask the vendor where the report lists them.
Do we need CUECs in our own report too?: If you are the service organization, yes where your controls depend on customers. Your system description lists the controls customers are expected to operate, such as managing their own users and protecting their API keys, so a customer's auditor knows what the customer is responsible for. List only what your product genuinely relies on, and do not copy another vendor's list.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.