Category: Audit & Attestation
Complementary User Entity Controls
Also known as: CUECs, CUEC, Complementary User Entity Control, User Entity Controls
Simply put
Complementary User Entity Controls (CUECs) are security and operational controls that a service provider expects its customers to put in place on their own side so that the overall service works as intended. In other words, a vendor's controls only fully protect the customer if the customer also implements certain controls at their end. These are commonly identified in SOC reports to clarify which security responsibilities belong to the customer rather than the service provider.
Formal definition
CUECs are control activities that reside at the user entity level and are identified by a service organization as necessary complements to its own controls in order to achieve stated control objectives or applicable trust services criteria. They are typically enumerated within SOC 1 or SOC 2 reports, signaling that the effectiveness of the service organization's control environment depends in part on the user entity implementing and operating specified controls (for example, access provisioning, review of output, or configuration on the customer side). CUECs delineate the shared-responsibility boundary between provider and customer; a user entity reviewing a SOC report should map each CUEC to its own internal controls, since failure to implement them may create gaps that the service organization's controls do not address. Note that CUECs describe expected customer-side controls and do not, by themselves, guarantee compliance or transfer accountability to the service provider.
Why it matters
CUECs matter because they define the shared-responsibility boundary between a service provider and its customers. When an organization relies on a vendor's SOC 1 or SOC 2 report as assurance, it is easy to assume the vendor's controls cover the full risk surface. In reality, the service organization's control objectives are only achieved if the customer implements the complementary controls the provider expects on the customer side, such as access provisioning, review of output, or configuration. Overlooking these expectations can leave gaps that neither party's controls address.
Who it's relevant to
Virtual and Fractional CISOs
A vCISO or fractional CISO advising a client that consumes third-party services is often the person who reads vendor SOC reports and translates CUECs into concrete internal controls for the client. This is a governance and risk activity: the security leader identifies which customer-side controls must exist, directs their implementation, and flags gaps. Accountability for actually operating those controls remains with the client organization and its officers; the vCISO advises and directs rather than assuming liability. The value of this work depends on the client granting access to vendor reports and to the stakeholders who own the relevant systems.
Service Organizations and SaaS Providers
Providers issuing SOC reports use CUECs to communicate clearly which controls they expect customers to implement so that stated control objectives are met. Enumerating CUECs accurately helps set correct expectations and avoids customers assuming the provider covers responsibilities that actually belong to the customer. Providers should note that CUECs describe expected customer-side controls and do not, by themselves, guarantee that any customer has implemented them.
User Entities Relying on SOC Reports
Any organization that consumes a third-party service and relies on a SOC 1 or SOC 2 report for assurance is a user entity with a direct stake in CUECs. Such organizations should map each CUEC to an internal control rather than assuming the vendor's report closes all risk. A common mistake is treating a favorable SOC report as complete coverage; failure to implement the identified CUECs may leave gaps the provider's controls were never designed to address.
Compliance, Audit, and Risk Teams
Internal audit, GRC, and vendor risk management teams use CUECs to evaluate how well a service relationship is controlled end to end. These teams verify that listed CUECs have corresponding, operating internal controls and document any exceptions. It is important to remember that implementing CUECs supports control objectives but does not by itself guarantee compliance or transfer accountability to the service provider.
Inside CUECs
Definition of CUECs
Complementary User Entity Controls are controls that a service organization assumes its customers (user entities) will implement for the service organization's own controls to operate effectively. They are documented in a SOC 2 or SOC 1 report and represent shared responsibility between the service provider and the customer.
Placement within the SOC report
CUECs typically appear in the description of the service organization's system, often alongside or near the control objectives or trust services criteria. They signal where the effectiveness of the service organization's controls depends on actions taken outside its boundary.
Shared responsibility boundary
CUECs delineate the line between what the service organization is responsible for and what the user entity must handle. Examples commonly referenced include user access management on the customer side, timely deprovisioning of terminated users, and appropriate configuration of customer-controlled settings.
Relationship to control effectiveness
The service organization's stated control objectives may not be fully achieved unless the corresponding CUECs are implemented by the user entity. This means reliance on a SOC report is incomplete without evaluating whether the reader's organization meets the assumed CUECs.
Reader responsibility
User entities are expected to review CUECs, assess whether they have implemented equivalent controls, and identify gaps. This assessment is part of vendor risk management and due diligence rather than something the service organization performs on the customer's behalf.
Common questions
Answers to the questions practitioners most commonly ask about CUECs.
Does a SOC 2 report from a service provider mean my organization is automatically covered for the controls it describes?
No. A service provider's SOC 2 report typically assumes that certain controls are implemented by the customer, not the provider. These are the Complementary User Entity Controls (CUECs). The report generally states that the provider's control objectives can only be met if the user entity also operates its own specified controls. Assuming the provider covers everything is a common mistake; your organization usually remains responsible for the CUECs, and gaps in them can undermine the assurance the report is meant to provide.
Are CUECs just a formality that auditors include, or do they actually require action from my organization?
They require action. CUECs are not boilerplate to be skimmed and filed. They typically describe specific responsibilities the user entity must carry out, such as managing user access, configuring security settings, or reviewing outputs. If these controls are not implemented and operating, the assurance in the provider's report may not extend to your environment. Treating them as a formality is a frequent oversight that a security leader would insist on correcting.
How does a virtual CISO help an organization address CUECs identified in a vendor's SOC 2 report?
A virtual CISO can typically review the vendor's report, extract the listed CUECs, and map them to the organization's existing controls and responsible owners. Their role is generally advisory and directive: identifying gaps, recommending how to close them, and helping establish governance so the controls are assigned and monitored. In many engagements the vCISO does not perform the hands-on control operation itself, and accountability for implementing and maintaining the CUECs usually remains with the client organization and its officers.
Where should responsibility for each CUEC sit within our organization?
Responsibility often varies by the nature of the control. Access management CUECs may sit with IT or identity administration, while data review or approval CUECs may sit with business or process owners. A common practice is to document each CUEC, assign a named owner, and confirm the control is actually being performed. A vCISO can advise on this allocation, but the organization typically retains accountability for ensuring owners are designated and the controls operate.
How often should CUECs be reviewed?
Review cadence may vary by provider report cycle and organizational maturity, but CUECs are often reassessed when a new SOC report is received, when the service relationship changes, or on a periodic basis aligned with the organization's control review schedule. Because the CUECs listed can change between report periods, relying on a one-time review is generally not sufficient. The value of ongoing review depends heavily on stakeholder cooperation and clearly defined ownership.
How do CUECs relate to broader frameworks like NIST CSF or ISO 27001 that we may be aligning to?
CUECs often overlap with controls an organization would already be maintaining under frameworks such as NIST CSF or ISO 27001, for example access control, monitoring, and configuration management. Addressing CUECs can support alignment with those frameworks, but it does not by itself assert certification or guarantee compliance. A vCISO can help map CUECs to a chosen framework so that responsibilities are not duplicated or missed, while being clear that meeting CUECs supports readiness rather than guaranteeing any certification outcome.
Common misconceptions
A clean SOC 2 report from a vendor means the customer has no security responsibilities for that service.
A SOC report often assumes CUECs are in place at the customer. If the user entity has not implemented those complementary controls, the service organization's controls may not achieve their intended objectives, leaving gaps the customer is responsible for closing. Legal and organizational accountability for the customer's own control environment typically remains with the customer.
CUECs are the service organization's obligation to implement or monitor.
By definition, CUECs are controls the service organization expects the user entity to perform. The service provider documents the assumption but generally does not implement, verify, or take accountability for controls that fall on the customer side of the boundary.
Reviewing CUECs is a purely technical exercise.
Evaluating CUECs is a governance and risk management activity as much as a technical one. It requires mapping documented expectations to the organization's own policies, access processes, and configurations, and often involves business stakeholders, not only technical staff.
Best practices
When reviewing any vendor SOC report, locate the CUEC section explicitly and treat it as a required part of due diligence rather than optional background material.
Map each documented CUEC to a specific control your organization has implemented, and record where equivalent controls are missing so gaps can be tracked and remediated.
Assign clear ownership for each CUEC internally, since these controls are the customer's responsibility and require named accountable stakeholders to be effective.
Reassess CUECs whenever the service, its scope, or the SOC report period changes, because assumed customer responsibilities may shift between report cycles.
Incorporate CUEC evaluation into your vendor risk management process so that reliance on a service organization's report reflects your own control posture, not just the provider's.
Engage security leadership, such as a virtual or fractional CISO where appropriate, to interpret CUECs in the context of business risk and to advise on remediation, while keeping accountability for decisions with the client organization.