Complementary User Entity Controls (CUECs) are controls that a service organization’s management assumes, in the design of its system, will be implemented by its user entities: its own customers, the companies relying on its service. They are necessary, in combination with the service organization’s own controls, to achieve the control objectives and Trust Services Criteria stated in the service organization’s system description. In plain terms, some control objectives can only be met if both the vendor and the customer each do their part. CUECs are the customer’s part, written down in the vendor’s own report.

If you have ever read a vendor’s SOC 2 report as part of your own due diligence and hit a section titled “Complementary User Entity Controls” with a list of things that sound like they are your job, not the vendor’s, this is what that section is for. It is one of the most commonly skipped parts of a SOC 2 report review, and one of the most consequential to skip.

Why CUECs Exist: The Shared-Responsibility Framing

A service organization cannot unilaterally guarantee certain outcomes that depend on how its customer configures or uses the service. A vendor can build single sign-on and multi-factor authentication into its product, but it cannot force a customer to actually enable and enforce it on their own tenant. A vendor can offer fine-grained access controls, but it cannot force a customer to promptly review and revoke their own users’ access when someone leaves the team. A vendor can provide data classification tooling, but it cannot force a customer to classify what they upload as sensitive.

In each of these cases, the control objective, keeping access properly restricted, keeping sensitive data properly handled, genuinely depends on an action the customer takes, not just an action the vendor takes. Rather than silently claiming to guarantee an outcome it does not fully control, a well-run audit lists that dependency explicitly as a CUEC. This is the honest version of a shared-responsibility model: the vendor states what it controls, tests it, and gets an opinion on it; and it states, separately, what the customer needs to control for the whole system to actually work as described.

This is also why a vendor listing CUECs is not a red flag on its own. It usually means the audit was scoped carefully enough to distinguish “things we control” from “things you control,” rather than glossing over that boundary. A report with zero CUECs for a service where customer configuration clearly matters (identity, access, data handling) is worth a second look, not necessarily the other way around.

Where CUECs Appear, and How Many You Should Expect

CUECs are documented in Section III of the report, the system description, alongside the description of the vendor’s own systems, boundaries, and controls. They are not a mandatory component of every SOC 2 report. Whether any appear at all, and how many, depends on the nature of the service and on a judgment call made by the vendor’s management and confirmed by their auditor: is a customer-side action actually necessary to meet a stated control objective, or is the objective fully achievable by the vendor alone?

Because of that judgment call, the number of CUECs in a report varies widely. A narrowly scoped infrastructure service might list none. A typical SaaS platform might list somewhere between a handful and a dozen, commonly touching on access management, authentication configuration, and data classification. A complex platform, especially one with significant customer-side configuration surface (permissions models, integrations, data residency choices), can list 30 or more. There is no fixed count to expect, and a shorter list is not automatically better; it may just mean the service’s own controls cover more of the objective without customer dependency.

CUECs vs. CSOCs: Two Different Directions of Dependency

It is easy to confuse CUECs with a similarly named concept: Complementary Subservice Organization Controls (CSOCs). They sound alike and both appear in the “complementary controls” family, but they describe dependencies in opposite directions.

A CUEC is a control the vendor’s management assumes its own customers, the user entities, will implement. A CSOC is a control the vendor’s management assumes its own subservice organizations, the other vendors it relies on, have in place. If your SaaS vendor runs on a cloud infrastructure provider and relies on that provider’s physical and environmental security controls rather than testing them directly, that dependency shows up as a CSOC, tied to the carve-out method of handling subservice organizations. CUECs point down toward the customer; CSOCs point down toward the vendor’s own vendors. We cover the carve-out method and how subservice organizations get handled in a SOC 2 scope in more depth in our guide to the carve-out vs. inclusive method; this page stays focused on the customer-facing side.

How to Actually Read and Act on a CUEC Section

Reading the CUEC list is not the hard part. Acting on it is. Here is a practical process for reviewing a critical vendor’s SOC 2 report as part of your own vendor risk management:

  1. Pull Section III from each critical vendor’s SOC 2 report and locate the CUEC list. It is usually near the end of the system description, sometimes presented as a table.
  2. Read every listed CUEC individually and map each one to a specific internal control and a named owner at your own company. “Customer is responsible for configuring SSO” needs to map to an actual policy, an actual system setting, and an actual person accountable for it, not a vague assumption that IT “probably handles that.”
  3. Confirm each one is actually implemented, not just assumed. This means checking the live configuration, not just asking whether a policy document mentions it. A CUEC that says you are responsible for quarterly access reviews only matters if those reviews are actually happening and are evidenced.
  4. Document a gap and a remediation plan for anything missing. If a CUEC is not implemented, do not quietly ignore it. Log it as a known gap in your vendor risk register with an owner and a target date, the same way you would document an internal control gap found in your own readiness work.
  5. Repeat this review every time you receive a renewed report from that vendor. The CUEC list is not static. A vendor’s control environment changes, their scope can change, and the CUEC list can be added to, trimmed, or reworded between report periods. A CUEC review done once at initial onboarding and never revisited is a stale review.

This process is really just an extension of standard SOC 2 vendor management practice applied to one specific, frequently overlooked artifact inside the report you already collect.

What Happens If You Ignore Your CUECs

This is the part that gets underappreciated. If a user entity (the customer) never implements the CUECs listed in a vendor’s report, the vendor’s own SOC 2 report and opinion are not automatically invalidated. The auditor tested the vendor’s own controls, and those results stand on their own. But the customer’s ability to rely on the vendor’s stated control objectives for the parts that depend on the missing CUEC is undermined. A clean vendor SOC 2 report does not mean the whole system is secure if the customer’s own half of a shared control was never actually put in place.

This is meaningfully different from a vendor’s own control failing during their audit, which is a distinct issue covered by SOC 2 exceptions and qualified opinions: that page covers what happens when the vendor’s own tested controls fail. A CUEC failure is not that. It is a gap on the customer’s side of a shared responsibility, and it will not show up as an exception in the vendor’s report at all, because the vendor was never being tested on it in the first place.

In practice, an unaddressed CUEC gap tends to surface in one of a few ways. It can sit as unaddressed real risk in your own environment, invisible until something goes wrong, since nobody’s audit was actually testing for it. It can become a finding in your own SOC 2 audit, if your auditor tests your vendor risk management controls, which commonly includes whether you actually reviewed vendor CUECs and acted on them, not just whether you collected the report. Or it can simply remain an unmanaged gap indefinitely, since a vendor’s clean SOC 2 report tends to create a false sense that “the vendor side is handled,” with nobody separately confirming the customer side is handled too.

It is worth being honest about the framing here: this is a shared-responsibility failure, not automatically a formal audit failure on anyone’s part. The vendor did not lie about anything in their report, and the customer did not necessarily violate any stated commitment. But it is a real, often underappreciated risk, precisely because it falls in the gap between two organizations’ audits rather than inside either one.

A Note on the Terminology

CUECs were not always called that. Under the older SAS 70 auditing standard, the equivalent idea went by a different name: User Control Considerations, or UCCs. When the AICPA moved to SSAE 18 and AT-C 320, the standard that governs SOC 2 reports today, the terminology evolved to Complementary User Entity Controls. If you come across an older report, or an older reference document, that uses “user control considerations,” it is describing the same underlying concept CUEC describes now.

Putting This in Context with Your Own Scope

If you are on the other side of this, preparing your own SOC 2 report rather than reading someone else’s, the CUEC question comes up during scoping: which control objectives in your own system description genuinely depend on your customers doing something, versus which ones you fully own yourself. That determination is part of the broader work of SOC 2 scope determination, where you and your auditor agree on what your system description actually claims, and what it correctly pushes back onto the customer as a CUEC rather than overclaiming full ownership of an outcome you cannot unilaterally control.

Whether you are reading CUECs in someone else’s report or writing your own, the underlying discipline is the same: name the dependency honestly, assign it to whichever side actually controls it, and confirm, on a recurring basis, that the assigned side is actually doing its part.

FAQ

What are Complementary User Entity Controls (CUECs)?

Complementary User Entity Controls are controls that a service organization’s management assumes, in the design of its system, will be implemented by its user entities, its own customers. They are necessary, in combination with the service organization’s own controls, to meet the control objectives or Trust Services Criteria stated in the report. In plain terms, some control objectives can only be met if both the vendor and the customer each do their part, and CUECs describe the customer’s part.

Where do CUECs appear in a SOC 2 report?

CUECs are listed in Section III, the system description, of a SOC 2 report. They are not mandatory in every report. Whether any appear depends on the nature of the service and on management’s and the auditor’s determination of whether customer-side controls are actually necessary to meet the stated objectives. Some reports list none, others list a handful, and complex services can list 30 or more.

What is the difference between CUECs and CSOCs?

CUECs are controls the vendor’s management assumes its customers will implement. Complementary Subservice Organization Controls (CSOCs) are the reverse relationship one layer down: controls the vendor’s management assumes its own subservice organizations, the vendors it relies on, have in place. CUECs are about the customer’s responsibility; CSOCs are about a subservice provider’s responsibility.

What happens if a customer never implements its CUECs?

The vendor’s own SOC 2 report and opinion are not automatically invalidated, since the vendor’s own tested controls are still what they are. But the customer’s ability to rely on the control objectives that depend on the missing CUEC is undermined. A clean vendor report does not mean everything is secure if the customer’s own half of a shared control was never implemented. This can surface as unaddressed risk in the customer’s environment, or as a finding in the customer’s own SOC 2 audit if their auditor tests vendor risk management controls, including whether CUECs were reviewed and acted on.

How should a buyer review a vendor’s CUECs?

Pull Section III from the vendor’s SOC 2 report, read every listed CUEC, and map each one to a specific internal control and owner at your own company. Confirm each is actually implemented, not just assumed to be in place. Document a gap and a remediation plan for anything missing rather than ignoring it, and repeat the review every time you receive a renewed report from that vendor, since the CUEC list can change between report periods.

Were CUECs always called that?

No. Under the older SAS 70 standard, the equivalent concept was called User Control Considerations (UCCs). The AICPA’s terminology evolved to Complementary User Entity Controls under SSAE 18 / AT-C 320, the standard that governs SOC 2 reports today.

Reading CUECs carefully is one small piece of a much larger vendor due diligence and audit-readiness picture. If you are choosing your own SOC 2 auditor and want a firm that scopes reports clearly rather than burying dependencies, SOC2Auditors helps you compare verified audit firms based on real pricing and timelines. Get three tailored auditor matches in 24 hours, without the sales calls, and make a data-driven choice with confidence. Start your auditor search at https://soc2auditors.org.