What Is a Complementary User Entity Control (CUEC)?

Our glossary defines the term this way: "A complementary user entity control is a control that a service organization assumes its customers will implement, and that must be operating for the service organization's own controls to meet the applicable criteria." The AICPA's attestation standard says the same thing in the vocabulary of a SOC 1 report: complementary user entity controls are "controls that management of the service organization assumes, in the design of the service organization's system, will be implemented by user entities and are necessary to achieve the control objectives stated in management's description of the service organization's system." Two words in those definitions carry the whole meaning. Assumes: the vendor built its controls on the premise that you are doing these things. Necessary: without them, the vendor's own controls do not get there. And one fact sits outside both definitions and matters more than either. The vendor's auditor does not test CUECs. The illustrative report language in the standard says so in terms: "Our examination did not extend to such complementary user entity controls, and we have not evaluated the suitability of the design or operating effectiveness of such complementary user entity controls."

So a CUEC is an obligation transferred to you by a document you probably filed unread, and it is an obligation nobody has verified. This article is what the standard says, why the auditor stops at the boundary, how a CUEC differs from its mirror image the CSOC, the procedure for the CUECs you have inherited from your own vendors, and how to write the CUEC section of your own report without either of the two mistakes that cost a revision cycle. The twenty-minute walkthrough of a vendor's report is a separate article and is not repeated here.

Key takeaways

• A complementary user entity control is one the service organization assumes its customers operate and that is necessary for its own controls to meet the criteria. The vendor's auditor does not test it, and the report says so.
• CUECs point up the chain to the customer. Complementary subservice organization controls (CSOCs) point down the chain to a carved-out provider. Both are assumptions the opinion rests on and neither is examined.
• Every CUEC in a vendor's report is a control you are expected to operate. Extract each one, map it to a control you already run or a gap you do not, name an owner, and evidence it as you would any other control.
• When you write your own report, the test for a CUEC is the definition's word "necessary". A CUEC that describes a control you actually operate, or that hands the customer a responsibility your service commitments cover, is a misstatement of your system, not a disclosure.
• The CUECs in your vendors' reports and the CUECs in your own are the same chain viewed from two ends. Managing them as one inventory is the procedure this term exists to trigger.

The definition in the standard, and how SOC 2 uses it

The definitions live in paragraph .08 of AT-C section 320, the AICPA attestation section written for SOC 1 examinations, which is why its wording speaks of "control objectives" and of user entities' internal control over financial reporting. A SOC 2 report is performed against the Trust Services Criteria rather than against control objectives, and it carries the same construct with the criteria in place of the objectives. That is the substitution our glossary makes when it says "the applicable criteria". The idea does not change: a control the vendor assumes you run, without which its own controls fall short.

Paragraph .A6 of the same section adds the constraint most reports ignore: complementary user entity controls "are specific and relevant to the services provided by the service organization". Specific and relevant. A CUEC is not a general security expectation of customers. It is tied to a particular service and to a particular control the vendor operates, which is what makes it necessary rather than merely advisable.

Typical CUECs in a SaaS vendor's SOC 2 report look like this: the customer configures single sign-on and enforces multi-factor authentication for its own users, or reviews and removes its own users' access on a cadence. The fuller list of common entries belongs to how to read a SOC 2 report and is not restated here. Each one exists because a control in the vendor's Section 4, usually a logical access control, only meets the criterion if the customer's side is also working.

Why the auditor stops at the boundary

An examination covers the service organization's system, and the customer's control environment is not part of it. The service auditor cannot visit every customer, cannot sample every customer's access review, and does not try. The standard's illustrative report language handles this with the sentence quoted above, which does two things at once. It tells the reader that certain control objectives (criteria, in a SOC 2 report) "can be achieved only if complementary user entity controls assumed in the design" of the vendor's controls "are suitably designed and operating effectively, along with related controls at the service organization", and it then says the examination did not extend to them.

Read that as a buyer and the consequence is direct. The clean opinion in Section 1 is conditional. It holds on the assumption that you are operating the CUEC list, and if you are not, the part of the vendor's control environment that depends on you is not covered by anything. Read it as a vendor and the consequence is the mirror image: the CUEC list is where you disclose the edge of your responsibility, and the disclosure is part of the description your auditor opines on, so its wording is in scope even though the controls it names are not.

CUEC, CSOC, and your own controls

The term arrives with a twin, and the two are confused constantly. The standard defines complementary subservice organization controls as "controls that management of the service organization assumes, in the design of the service organization's system, will be implemented by the subservice organizations and are necessary to achieve the control objectives". Our glossary calls a CSOC "a control that a service organization assumes a carved-out subservice organization is operating, and that is necessary for the service organization to meet the applicable criteria." Same construct, opposite direction.

CSOCs exist only under the carve-out method, because an included subservice organization's controls are tested directly, and our carve-out versus inclusive article owns that decision and its disclosure work. What matters here is the symmetry: a SOC 2 opinion sits on two sets of assumptions, one about the customer and one about the supplier, and neither set has been examined by anyone.

The procedure for the CUECs you have inherited

Every SOC 2 report in your vendor file contains a CUEC list, and every item on it is a control you are expected to operate. Here is the procedure, and it takes an afternoon per critical vendor.

Extract the list into your own control inventory. Copy each CUEC out of the vendor's description, verbatim, with the vendor's name and the report period. A CUEC that lives only in a PDF in a shared drive is not being managed.

Map each CUEC to a control you already operate. Most CUECs will land on controls you already run for your own SOC 2 or your own security programme: access provisioning and removal, periodic access reviews, MFA enforcement, key management, API monitoring. Record the mapping. The vendor's CUEC becomes one more reason that control exists.

Name the gaps. Some CUECs will map to nothing. The vendor assumes you review your users' access in its application quarterly and nobody does. That is a control gap in your environment, discovered through someone else's report, and it belongs in your risk register with an owner and a response, exactly as a gap found in your own readiness assessment would.

Assign an owner and evidence it. A CUEC you claim to operate needs the same evidence your own controls need: the access review export, the SSO configuration, the ticket showing the departed user was removed. In our experience this is where the exercise pays for itself, because the evidence you gather for a vendor's CUEC is usually evidence your own auditor will also ask for.

Feed the result into your own description. If you are a service organization yourself, the CUECs in your vendors' reports frequently become controls in your own system description, and sometimes become CUECs you pass on to your customers in turn. The chain is continuous; the inventory should be too.

This sits inside a vendor programme rather than replacing one. Tiering vendors, deciding which get this depth of review and what to do when a vendor will not supply a report are programme questions, and our vendor risk management guide owns them.

Writing the CUEC section of your own report

The definition gives you the test. A CUEC is a control you assume the customer operates and that is necessary for your own controls to meet the criteria. Every candidate line has to pass both halves.

It must be a customer control, not one of yours in disguise. If your platform enforces MFA on every login, MFA is your control and appears in Section 4. If your platform offers MFA and the customer chooses whether to switch it on, the customer's choice is the CUEC and your control is that the option exists and works. Writing "customers are responsible for authentication" when you in fact operate authentication is not a disclosure; it is a description that understates your own system, and your auditor opines on that description.

It must be necessary, not merely wise. "Customers should train their staff in security awareness" is good advice and a poor CUEC, because no control in your Section 4 depends on it. The standard's paragraph .A6 language, specific and relevant to the services provided, is the filter. If you cannot name the control of yours that fails when the customer does not do the thing, it is not a CUEC.

It must be something the customer can actually do. A CUEC that assumes a capability your product does not expose (an audit log the customer cannot access, an access review with no user list export) is an assumption the customer cannot meet, and a careful reviewer at a large customer will say so during procurement.

It must match what your product documentation says. Customer security teams read the CUEC list against your help centre and your contract. A CUEC that assigns the customer a responsibility your service commitments say you carry is the single fastest way to lose a security review.

Write each CUEC as a control statement: who does what, how often, and what it protects. Then read the list once more as a prospect's security reviewer would, because that is the reader who will act on it.

The two mistakes that cost a revision cycle

Shifting responsibility. The tempting move, when a control is weak, is to describe it as the customer's problem. Auditors read Section 4 and the CUEC list together, and a control that appears in neither, because it was quietly reassigned to the customer, is a completeness problem in the description that surfaces in fieldwork. Fix the control or disclose the exception; do not relocate it.

Boilerplate. A CUEC list copied from another company's report describes another company's system. The specific-and-relevant test in the standard is the reason: a CUEC that does not tie to one of your own controls is not one, and a reviewer who asks which control it supports will get no answer.

Where Top Floor fits

Two places. For a company receiving reports, the extraction and mapping procedure above is a piece of compliance as a service work when nobody inside owns the vendor file, and a one-off exercise you can run yourself when somebody does. For a company issuing a report, drafting the CUEC section so that it passes the necessity test and matches the product is SOC 2 readiness work, and it is one of the cheaper places to avoid a description rewrite in fieldwork. Where a customer is challenging your CUEC list during procurement, audit and assurance advisory is the conversation. We do not issue the report; a CPA firm does.

How to decide this week

Pull the SOC 2 report of your single most critical vendor and find the CUEC list. Count the items, then count how many map to a control you can evidence today. The difference is your inherited gap, and it was in your environment before you read the report.

If you issue a report yourself, read your own CUEC list and for each item name the Section 4 control that depends on it. Any item with no answer is either not a CUEC or is a control you have relocated onto customers, and both need to come out before the description goes to your auditor.

Frequently asked questions

What is the difference between a CUEC and a CSOC?

Direction. A complementary user entity control is one the service organization assumes its customer operates; a complementary subservice organization control is one it assumes a carved-out supplier, usually its cloud provider, operates. The standard defines both with the same structure: controls assumed in the design of the system that are necessary to achieve the objectives. Neither is tested by the service organization's auditor. The reader deals with them differently: a CUEC is a control you must operate and evidence, while a CSOC points you to a provider whose own report you must obtain and read.

Are CUECs tested in a SOC 2 audit?

No. The examination covers the service organization's system, and the customer's control environment is outside it. The illustrative report language in the AICPA standard states that the examination did not extend to complementary user entity controls and that the auditor has not evaluated their design or operating effectiveness. The opinion in the report is therefore conditional on the customer operating the CUEC list, which is why the list is the section to read first when you receive a vendor's report.

Do CUECs appear in a Type I report?

Yes. CUECs are part of the system description, and both report types include the description. A Type I describes the system as of a date and a Type II throughout a period, but in either case the CUEC list tells the reader what the service organization assumes of its customers. The difference is only that in a Type II the vendor's own controls have been tested for operation across the window; the CUECs have been tested in neither.

What should we do if we cannot implement one of a vendor's CUECs?

Treat it as a control gap in your own environment, because that is what it is. Record it in your risk register with an owner, decide on a response, and understand which part of the vendor's control environment is now unsupported on your side. If the CUEC assumes a capability the vendor does not actually expose to you, raise it with the vendor during the security review, because a CUEC the customer cannot perform is a defect in the vendor's description rather than in your programme.