What are complementary user entity controls (CUECs)?
Updated
Complementary user entity controls (CUECs) are controls that a service organization assumes its customers will put in place. Listed inside a SOC 1 or SOC 2 report, they close the gap between the provider's controls and the customer's own environment. Without them, the provider's controls may not achieve their stated objectives.
CUECs are the practical expression of shared responsibility: a SOC report can only cover what the service organization controls, so it names the controls the user entity must operate on its side. Reading, mapping, and evidencing those CUECs is a standard part of any vendor-reliance review.
What a CUEC is and where it appears
A complementary user entity control is a control the service organization expects its customers to implement in order for the combined system of controls to meet the control objectives (SOC 1) or the applicable Trust Services Criteria (SOC 2). CUECs are disclosed in a dedicated section of the service organization's SOC report, typically alongside the description of the system.
The concept exists because a SOC examination has a boundary. The service auditor can test only the controls the service organization operates. Many control objectives, however, can be met only if the customer also does something on its side — restricting who can log in, reviewing output, or configuring the service securely. CUECs make those customer-side dependencies explicit rather than leaving them implied.
How CUECs fit into shared responsibility
Think of a control objective as a chain: the service organization owns some links, the customer owns others. A CUEC is a link the report hands to the customer. If the customer never implements it, the objective is not actually met end-to-end, regardless of how clean the service organization's own testing looks.
This is distinct from a complementary subservice organization control (CSOC), which is a control the report expects a downstream vendor (a subservice organization) to operate — for example, the cloud data center a SaaS provider runs on. CUECs point at the customer; CSOCs point at the provider's own vendors. Both are carve-outs of responsibility that the reader must track separately.
- Restricting and reviewing which of your own employees are granted access to the service.
- Configuring the service's security options (encryption, session settings, IP restrictions) per your policy.
- Reviewing reports or output the service produces before relying on them for a decision.
- Notifying the provider promptly of terminated users or suspected security events.
- Reconciling data transmitted to and from the service for completeness and accuracy.
Handling CUECs as a user entity
When you receive a vendor's SOC report, the CUEC section is not boilerplate to skip — it is a task list. Each CUEC describes something you are expected to be doing. The standard workflow is to extract every CUEC, map it to a control you actually operate (or flag it as a gap), and keep evidence that the control is running, so your own auditor can see the vendor relationship is covered on both sides.
Unmapped CUECs are a common finding. A vendor can hand you a clean SOC 2, but if the report assumes you review access quarterly and you do not, the control objective is not met in your environment. Treating the CUEC list as inherited requirements — owned, mapped, and evidenced like any other control — is what closes that loop.
Frequently asked questions
What is the difference between a CUEC and a CSOC?
A complementary user entity control (CUEC) is a control the SOC report expects the customer (user entity) to implement. A complementary subservice organization control (CSOC) is a control the report expects a downstream vendor — a subservice organization such as a hosting provider — to implement. CUECs point at you; CSOCs point at the provider's own vendors.
Who is responsible for implementing CUECs?
The customer — the user entity relying on the service. The service organization identifies the CUECs in its SOC report, but it does not operate them. Responsibility for implementing, running, and evidencing each CUEC sits with the customer that consumes the service.
What happens if we don't implement a listed CUEC?
The related control objective or Trust Services Criterion may not be met in your environment, even if the vendor's own controls tested cleanly. Unimplemented CUECs are a frequent source of findings in vendor-reliance and SOX reviews, because the auditor evaluates the combined system of controls, not just the provider's half.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.