Complementary User Entity Controls (CUECs) in SOC 2: What They Are and How to Evidence Them

Complementary user entity controls (CUECs) are the controls a vendor's SOC 2 report assumes its customers operate. A typical cloud arrangement: the provider's report covers its data centers, hardware and hypervisors, and assumes each customer controls who can sign in to its account, enforces MFA, and protects its API keys. Those customer-side controls are the CUECs, and a customer's own auditor and enterprise buyers expect each one mapped to a control with evidence.

What Are Complementary User Entity Controls in SOC 2?

Complementary user entity controls are controls that service organization management assumed its user entities would implement, and that are needed alongside its own controls to meet its service commitments and system requirements. Linford & Co describes CUECs as the controls the service organization expects the user entity to perform, documented in the system description.

The auditor's opinion states the condition. A publicly posted SOC 3 report from Signifyd uses the standard wording: management's assertion is fairly stated if complementary subservice organization controls and complementary user entity controls assumed in the design of Signifyd's controls operated effectively throughout that period. The same report states that the examination did not include those controls.

A SOC 2 report is an attestation report issued by an independent CPA firm, and the CUEC list marks its boundary: everything on the list is the customer's responsibility.

How CUECs Work in Two Directions for a B2B AI Company on a Neocloud

A B2B AI company meets complementary user entity controls from both sides. Take a company that sells an AI product to enterprises and moved its GPU workloads from a hyperscaler to a neocloud, a cloud provider built around GPU capacity.

• As a user entity, the AI company must operate the CUECs listed in the neocloud's SOC 2 report: managing its own console and API users, enforcing MFA, protecting API tokens, configuring tenant network rules, and the rest of the list.
• As a service organization, the AI company's own SOC 2 report lists CUECs its customers must operate: managing their own users in the product, protecting the API keys issued to them, and configuring SSO for their workspace.

The neocloud's report feeds the AI company's vendor management evidence, and the AI company's report feeds each customer's. The neocloud SOC 2 guide covers the responsibility split by service model.

Where to Find CUECs in a Vendor's SOC 2 Report

Complementary user entity controls appear in the system description, commonly Section III of a SOC 2 report, under a heading such as Complementary User Entity Controls. risk3sixty notes that anyone reviewing a vendor's system description should keep the CUECs in mind, because the reader will be responsible for performing them.

Layouts vary by audit firm, so read until every CUEC is captured.

How to Map a Neocloud's CUECs to Controls and Evidence

Mapping a neocloud's complementary user entity controls means giving each one a control the AI company operates, an artifact that proves it, and a frequency. The rows below are typical infrastructure CUEC categories; build the real register from the provider's report wording.

Most of these controls already exist for other systems; the register adds the neocloud to their scope. The on-prem evidence collection guide covers collecting artifacts when the GRC platform has no integration with the provider.

Which CUECs a B2B SaaS or AI Company Lists in Its Own SOC 2 Report

A B2B SaaS or AI company lists complementary user entity controls for every duty its product hands to the customer. If the product lets customers create users, issue API keys, or connect SSO, the company's access controls only work if customers manage those settings well.

Clear CUECs share four traits:

1. Specific to a product feature. Customers manage user access in the admin console can be tested; customers maintain appropriate security cannot.
2. Necessary. Each CUEC is a control the company's design depends on. General security advice belongs in customer documentation.
3. Communicated. CC2.3 in the AICPA Trust Services Criteria expects an entity to communicate with external parties, including customers, on matters affecting internal control. Publish the list in product documentation or the trust center too.
4. Stable. Rewording CUECs every year forces every customer to remap. Add new ones when a new feature hands customers a new duty.

A short, precise list also speeds enterprise procurement: a security reviewer can map six clear CUECs quickly, while twenty vague ones turn into follow-up questions.

Common CUECs by Vendor Type: Cloud, Colocation, Identity Provider, Payroll

Complementary user entity controls follow the service the vendor provides. The categories below are typical; each vendor's current report is the authoritative list.

Colocation CUECs come with their own physical access and contract mechanics. The SOC 2 vendor management guide for data centers covers the colocation case, including the carve-out treatment and what to request from the provider.

How CUECs Differ From CSOCs in a SOC 2 Report

Complementary user entity controls are duties assigned to the customer; complementary subservice organization controls (CSOCs) are duties assigned to the service organization's own vendors. When the neocloud carves out its data center provider, the data center's physical security controls are CSOCs in the neocloud's report, while the AI company's MFA and access management are CUECs. The CSOCs and carve-out vs inclusive guide covers how CSOCs are scoped and tested.

What Happens When a User Entity Does Not Operate a CUEC

When a user entity leaves a complementary user entity control unoperated, the vendor's SOC 2 report stays as issued, and the assurance it gives that user entity stops at the gap. The consequences come in two places:

• Security. A valid API token leaked from the AI company's repository gets through the neocloud's access controls, which worked as designed; the token protection CUEC was the missing part.
• The user entity's own audit. CC9.2 expects an entity to assess and manage vendor risks, and an auditor may ask how each critical vendor's CUECs are addressed. Treatment depends on the auditor's judgment: an unmapped CUEC may be a vendor management gap, or, where the underlying control is missing (no access review of the neocloud console, for example), an exception against the related access criterion.

The CC9.2 vendor risk management guide covers the full vendor assessment.

Steps to Build and Maintain a CUEC Register

A CUEC register maps every complementary user entity control, in both directions, to an owner, a control, and evidence. Keep it in the GRC platform or the Security Program Manual, with the rest of the control set.

1. List the critical vendors. Start with the neocloud, the identity provider, source control, and any service that stores customer data. The hybrid and on-prem scoping guide helps decide which systems are in scope.
2. Copy each vendor's CUECs verbatim, with the report period and section reference.
3. Map each CUEC to an existing control such as access reviews, MFA, secrets management, backups, or incident response. Create a new control only where nothing fits.
4. Assign an owner, an evidence artifact, and a frequency to every row.
5. Write the outbound CUECs for each duty the product hands to customers, and publish them where customers can find them.
6. Re-check annually. When a vendor issues a new SOC 2 report, compare its CUEC list against the register and remap changes. Review the company's own CUECs before each new report period.

For GPU workloads on bare metal, the SOC 2 for bare metal service covers scoping, evidence, and vendor reviews.

CUECs Turn a Vendor's SOC 2 Report Into Evidence the AI Company Can Use

A vendor's SOC 2 report supports the AI company's own audit once the CUEC list is mapped, owned, and evidenced. Written outward, the same discipline gives enterprise customers a short, testable list of their own duties, and one register for both directions gives procurement teams and the auditor a single place to look.

Frequently Asked Questions

What does CUEC stand for in SOC 2?

CUEC stands for complementary user entity control. In a SOC 2 report, CUECs are controls the service organization assumed its customers, the user entities, would operate when it designed its own controls. The auditor's opinion holds only if those customer-side controls also operate effectively, so each CUEC is a duty the customer carries.

Where do I find the CUECs in a vendor's SOC 2 report?

Look in the system description, usually Section III, under a heading such as Complementary User Entity Controls. Some reports also tie each CUEC to the Trust Services Criteria it supports. The auditor's opinion and management's assertion name CUECs as a condition, which confirms the list is part of what the report relies on.

How do we show evidence that we operate a vendor's CUECs?

Keep a CUEC register that maps each CUEC to one of your controls, an owner, an evidence artifact, and a frequency. Typical evidence includes access review exports, MFA enforcement settings, secrets rotation logs, backup and restore records, and an annual vendor review memo. Store the register with the vendor record in the GRC platform.

Should our own SOC 2 report list CUECs for our customers?

Yes, if any of your controls depend on customer action. A B2B SaaS or AI product that lets customers manage their own users, API keys, or SSO settings relies on those customers to do so. Listing those duties as CUECs in the system description states the boundary clearly for customers, their auditors, and procurement teams.

What happens if a user entity does not operate a CUEC?

The vendor's SOC 2 opinion stays as issued, but the assurance it gives that user entity no longer covers the area the CUEC protects. The user entity's own auditor may treat an unmapped CUEC as a vendor management gap under CC9.2, or as an exception in the related criterion, depending on the auditor's judgment.