Category: SOC Reporting

Complementary User Entity Controls Reliance

Also known as: CUEC Reliance, CUEC Reliance, Reliance on Complementary User Entity Controls, User Entity Control Dependencies

Simply put

Complementary User Entity Controls (CUECs) are security practices that a service provider expects its customers to put in place so that the provider's services work as intended. CUEC reliance refers to the way a service provider's control objectives depend on customers carrying out those responsibilities on their own side. In other words, some controls are shared: the provider handles part, and the customer must handle the rest.

Formal definition

In a SOC report, Complementary User Entity Controls are controls that the service organization assumes will be implemented by user entities (its customers) in order for the service organization's control objectives or applicable Trust Services Criteria to be met. CUEC reliance describes the dependency embedded in the report: the service organization's described controls, and the auditor's evaluation of them, presume that these user-side controls are operating. Because the SOC report attests only to the service organization's controls over the period and scope covered, it does not provide assurance over CUECs themselves; user entities are typically expected to review the listed CUECs and confirm they have implemented equivalent controls within their own environment as part of their third-party or vendor risk management. The specific CUECs, and the extent to which control objectives depend on them, vary by service organization, engagement scope, and the criteria in play.

Why it matters

Complementary User Entity Controls Reliance matters because a SOC 2 report rarely tells the whole story of how a service is secured. The service organization's control objectives and applicable Trust Services Criteria are typically designed with an assumption that customers will perform certain controls on their own side. If a user entity reads a SOC 2 report and treats it as a guarantee that the provider covers every risk, it may overlook responsibilities that were never the provider's to fulfill. The report attests only to the service organization's controls over the period and scope covered; it does not provide assurance over the CUECs themselves.

The practical consequence is that gaps can open at the boundary between provider and customer. A provider might implement encryption or access controls competently, but if a CUEC calls for the customer to manage its own user provisioning, enforce strong authentication, or configure services appropriately, and the customer fails to do so, the intended control outcome may not be achieved. Because the specific CUECs and the degree to which control objectives depend on them vary by service organization, engagement scope, and criteria in play, there is no universal checklist that applies to every relationship.

For this reason, reviewing CUECs is generally treated as an important part of third-party and vendor risk management. User entities are typically expected to read the listed CUECs and confirm they have implemented equivalent controls within their own environment. Skipping this step can leave a shared control only half-implemented, undermining the assurance the report was intended to support.

Who it's relevant to

Vendor and Third-Party Risk Managers

Professionals running vendor risk programs use CUEC listings to identify the responsibilities a service provider expects them to fulfill. Reviewing CUECs is typically an important part of a third-party management program, since a provider's control objectives may depend on the customer implementing equivalent controls on its own side. Overlooking these dependencies can leave shared controls only partially in place.

Compliance and GRC Teams at User Entities

Teams responsible for their organization's own compliance posture need to map each CUEC in a provider's SOC report to a corresponding internal control and confirm it is implemented. Because the report attests only to the service organization's controls, GRC teams cannot assume the provider covers customer-side responsibilities and must treat CUECs as their own to satisfy.

Service Organizations Preparing SOC Reports

Providers that expect customers to perform certain controls should identify these as Complementary User Entity Controls in their SOC report. Clearly articulating which control objectives or Trust Services Criteria depend on user-side actions helps set accurate expectations and clarifies the boundary of what the provider's attestation does and does not cover.

Auditors and CPA Firms

Auditors performing a SOC 2 examination under the AICPA's attestation standards evaluate the service organization's controls on the presumption that identified CUECs are operating at user entities. Because CUECs sit outside the scope of the service organization's attestation, auditors must ensure the report accurately describes these dependencies rather than implying assurance over controls the provider does not operate.

Inside CUEC Reliance

Complementary User Entity Controls (CUECs)

Controls that a service organization assumes its customers (user entities) will implement for the overall control objectives or Trust Services Criteria to be met. In a SOC 2 report, these are listed by the service organization because certain controls fall outside the service organization's boundary and must be operated by the user entity.

Reliance by the User Entity

The act of a customer organization depending on the service organization's SOC 2 report as part of its own control environment, while accepting responsibility for implementing the CUECs identified in that report. Reliance is only appropriate where the user entity actually operates the complementary controls described.

Shared Responsibility Boundary

The delineation between controls operated by the service organization and controls the user entity must operate. CUECs make this boundary explicit, clarifying what the SOC 2 report does and does not cover for the customer.

Report Scope and Period Dependency

Reliance is constrained by the scope, Trust Services Criteria selected, and, for a Type II, the review period covered by the report. A user entity typically maps the CUECs to its own controls before placing reliance, since coverage is limited to what the report addresses.

Complementary Subservice Organization Controls (CSOCs)

A related but distinct concept where controls are expected to be operated by a subservice organization (a vendor of the service organization) rather than by the user entity. CUECs address user-side controls; CSOCs address downstream vendor-side controls, and the two should not be conflated.

Common questions

Answers to the questions practitioners most commonly ask about CUEC Reliance.

Does a service organization's SOC 2 report cover all the controls needed to secure our use of the service?

No. A SOC 2 report typically identifies Complementary User Entity Controls (CUECs), controls the service organization assumes you, as the user entity, will implement on your side. The report attests only to the controls at the service organization over the period covered; it does not cover the controls that remain your responsibility. Achieving the intended outcomes generally depends on both parties operating their respective controls effectively.

If the service organization received a clean SOC 2 opinion, does that mean we don't need to do anything on our end?

Not necessarily. A favorable opinion addresses the suitability of design (Type I) or the design and operating effectiveness (Type II) of the service organization's controls over the defined scope and period. Where CUECs are listed, the report's assurance is premised on the user entity carrying out those complementary controls. Relying on the report without implementing the applicable CUECs can leave gaps the service organization's controls were never intended to address.

Where in a SOC 2 report do we find the controls we are expected to implement?

CUECs are typically presented within the description of the service organization's system, often in a dedicated section listing the complementary controls the service organization assumes user entities have in place. The specific placement and level of detail vary by report and by the service organization's chosen presentation, so reviewing the full system description is advisable.

How should we handle a CUEC that does not apply to how we actually use the service?

In most engagements, each listed CUEC should be assessed for applicability against your specific configuration and use of the service. Where a CUEC does not apply, documenting the rationale for that determination is a common practice. Where it does apply, mapping it to an existing internal control, or implementing one, helps demonstrate that the reliance placed on the report is supported on your side.

Can we map CUECs to our own control framework or ISMS?

Yes, and doing so is often practical. Many organizations map applicable CUECs to their internal control set, whether aligned to the Trust Services Criteria, an ISO 27001 ISMS, or another framework, so that responsibility is clearly assigned and evidence of operation can be maintained. Because mapping between frameworks is partial, a CUEC satisfying one framework's expectation does not automatically satisfy another's.

How often should CUEC reliance be revisited?

Reliance is typically reassessed when a new SOC 2 report is issued, since the listed CUECs, the covered period, and the scope can change between reports. Reassessment may also be warranted when your use of the service changes or when the service organization modifies its system. Confirming that the report period aligns with the timeframe over which you rely on it is also a common consideration.

Common misconceptions

A clean SOC 2 report means the user entity has nothing further to do and is fully covered.

A SOC 2 report attests only to the controls and, for a Type II, the period it covers. When CUECs are present, the report's conclusions typically assume the user entity implements those complementary controls; failing to operate them can leave gaps the report does not address.

CUECs and complementary subservice organization controls are the same thing.

CUECs are controls expected of the customer (user entity), while complementary subservice organization controls are expected of a downstream vendor used by the service organization. They sit on different sides of the responsibility boundary and should be evaluated separately.

Relying on a service organization's SOC 2 report satisfies the equivalent requirements of ISO 27001.

SOC 2 is an attestation examination under the AICPA framework, whereas ISO 27001 is a certification against a management system standard. Mapping between them is partial, and a SOC 2 report, including its CUECs, does not automatically satisfy ISO 27001 requirements or a user entity's own ISMS obligations.

Best practices

Read the CUEC section of each SOC 2 report and map every complementary user entity control to a specific control you actually operate, documenting ownership and evidence.

Confirm that the report's scope, selected Trust Services Criteria, and review period (for a Type II) align with your reliance needs before treating the report as coverage.

Distinguish CUECs from complementary subservice organization controls, and understand how any subservice organizations are handled (carve-out versus inclusive) so you know what remains outside the report.

Track CUEC implementation status over time, since reliance is only appropriate where you continuously operate the complementary controls the report assumes.

Escalate and remediate any CUECs you cannot implement, treating them as potential control gaps rather than assuming the service organization covers them.

Retain the report and your CUEC mapping as evidence for your own audits, and refresh the assessment when a new report period is issued or your use of the service changes.