What are SOC 2 complementary user entity controls, and who owns them?
When a customer's security questionnaire or vendor review asks about complementary user entity controls (CUECs), the short answer is this: CUECs are controls the service organization assumes its customers run on their own side of the service, and they are the customer's responsibility, not the auditor's test subject. The service auditor does not sample them as part of the service organization's controls, so a clean report does not prove that a customer's part of the arrangement is in place. The list is set in management's system description, which is prepared against the AICPA's 2018 SOC 2 description criteria (DC 200). DC 200 includes a specific criterion, DC7, for complementary user entity controls, so the list is a design decision the service organization documents and the auditor evaluates for completeness and clarity.
The CUEC list belongs to the organization that wrote the system description, not to the reader. The independent CPA firm that performs the examination issues the report and its opinion. Neither the service organization nor any implementation partner issues a SOC 2 report or certifies a control, so a customer should never read a CUEC list as a statement made by a consultant. Before you engage a CPA firm, confirm with the firm how it will evaluate the CUEC list, and ask the service organization which of its listed controls are expected of you and who on your side owns each one.
For a customer, the practical step is to map every CUEC in the report to a named owner, a written procedure and a piece of evidence you could show an auditor. If a listed control is missing from your program, the gap is yours, and the report does not cover it. The same applies to your data: user entities remain responsible for protecting the data they submit to a service organization, even if a breach occurs at the service organization. Reading the report's user entity responsibilities section first, and treating it as your own control list, is the most direct way to find these gaps before an incident or an audit question exposes them.
Which customer controls usually appear in the list
A CUEC list describes what the customer must do for the service's controls to work. The categories below cover the duties that most often appear, and each one is a point where the customer's own program, not the provider's report, carries the risk. Each card is illustrated with a hypothetical example.
User access administration and approvals
Customers decide who in their organization gets an account, which role they hold, and when access is removed. In a hypothetical example, a customer's HR system never notifies the vendor when a contractor leaves, so the contractor keeps working access for months. Check whether the provider's list names your joiner, mover and leaver steps, and confirm who in your organization reviews user lists on a schedule.
Protecting data you submit
Customers classify the data they upload, decide what should not be sent at all, and keep their own copies under their own retention rules. A provider's report can describe encryption in transit and at rest, yet it does not make the customer's choices about which records to submit. Confirm whether the provider expects you to minimize or mask personal data before upload.
Configuring integrations and API keys
Customers connect the service to their identity provider, cloud accounts and other tools, and they create the API keys and tokens those connections use. In a hypothetical example, a customer issues a long-lived API key to a script that is then committed to a public repository. Check who owns key creation, rotation and revocation, and whether the provider lists these steps as your responsibility.
Reviewing outputs and reports
Customers are often expected to check the results the service produces, such as reports, alerts, calculations or exported records, before acting on them. If a provider's processing is correct but the customer never reviews an exception report, the failure is in the customer's process. Ask which outputs the provider expects you to review, how often, and what evidence of that review you should keep.
Reporting incidents affecting your users
Customers detect and report misuse of their own accounts, such as a compromised user login or an employee sharing credentials. The provider's incident process covers its platform, while the customer's process covers its people and accounts. Confirm the contact path the provider expects, the time window it names for notice, and who on your side is authorized to raise a report.
Maintaining your own endpoints
Customers keep the laptops, browsers and mobile devices their staff use to reach the service, including patching, screen locks and disk encryption. In a hypothetical example, a finance user opens the service from an unmanaged personal device that has no current browser updates. Check whether the provider lists endpoint hygiene as a customer duty and how your device management tooling supports it.
How customers and service organizations should read CUECs
When a vendor's SOC 2 report arrives, the complementary user entity controls section tells your organization which controls the service auditor assumed you operate. The service auditor tested the vendor's controls on the basis of those assumptions, so the vendor's clean opinion does not cover your side of the boundary. Start by locating the CUEC list. In Microsoft's SOC reports, user entity responsibilities appear at the very end of the document, after the auditor's opinion, management's responses and the test results, so a reader who stops at the opinion will miss them. Microsoft Learn describes this layout for its SOC 2 Type 2 reports for Azure.
- Map each CUEC to one internal owner: Assign a named person or team, such as identity administration, the platform team or the application owner, who answers for that action.
- Name the evidence source: Record where proof lives, such as the identity provider's access review export, the ticketing system or the cloud account's configuration history.
- Check the period: Confirm the control ran across the Type 2 observation window, not only at a single point in time.
- Flag CUECs with no owner: Escalate any item that no team wants to run before the contract is signed or the data is sent.
- Compare against your own data flows: Note which CUECs apply only if you use a specific feature or integration, and record that decision.
Before you rely on the report, confirm that every CUEC has an owner, a recurring evidence source and a documented date for your next review.
A service organization writes its CUECs in the system description, which management prepares against the AICPA's 2018 description criteria, DC 200. Criterion DC7 covers complementary user entity controls. A vague line such as "customers should manage access appropriately" gives a customer nothing to test and gives an examiner nothing to judge. Each CUEC should describe one action the customer takes, the condition under which it applies and what the customer should keep as proof.
- State the actor and the action: For example, "The customer's administrators approve new users of the admin console before access is granted."
- Tie it to a service feature: Name the setting, console area or API the customer uses, so the action can be located in the customer's environment.
- Set a condition where one exists: If the action applies only to customers who enable a feature, say so, so customers without that feature are not misled.
- Avoid duplicating your own controls: A CUEC covers what the customer must do. Anything you run yourself belongs in the control matrix, not the CUEC list.
- Keep the list in step with the matrix: Review CUECs whenever a feature, integration or default changes.
Before publishing, have someone outside the control owner's team read each CUEC and describe back what they would do and what they would keep. If the answers differ, rewrite the item.
A CUEC does not move risk off your organization. The Journal of Accountancy has made the point that a user entity requesting a service auditor's report to assess risk keeps its own responsibility for that risk. The same article notes that user entities remain responsible for protecting the data they submit to a service organization, even if a breach occurs at the service organization. Where the vendor runs a platform in your cloud account, the boundary also shifts with the cloud provider's model, so the CUEC list has to be read alongside the subservice organization section.
- Do not read a clean opinion as coverage: The opinion covers the controls the vendor tested, within the boundaries it describes.
- Check the cloud side separately: Under the AWS shared responsibility model, the customer manages its own configurations and guest operating systems on services such as Amazon EC2, and those tasks may appear as CUECs or in your own control set.
- Document the decision when you accept a gap: If you choose not to run a CUEC, record the compensating control or the risk acceptance and who approved it.
- Revisit regulated obligations: Where your regulator expects third-party oversight, compare the CUECs against those expectations, including the Interagency Guidance on Third-Party Relationships if you are a US bank.
- Track changes to the vendor's controls: Ask for a bridge letter or the next report when the vendor changes platform or scope.
Before signing, confirm in writing which CUECs your organization accepts and which it has assigned to someone else.
Why a SOC 2 report cannot cover controls the customer was expected to run
A SOC 2 report examines the service organization's controls against the criteria it has chosen, and nothing else. When a report lists complementary user entity controls (CUECs), those are the controls the service organization assumes the customer runs on its own side. The auditor does not test them at the service organization, so the report gives no assurance that they operate. A customer that reads a clean opinion as proof that its own access reviews, user provisioning or data classification are covered has relied on something the examination never looked at. The organization owns its controls, and only the independent CPA firm that performed the examination issues the report.
Requesting a service auditor's report to assess risk does not transfer that risk. The Journal of Accountancy's 2016 explanation of SOC reports makes this point directly: a user entity that asks for the report is not relieved of its own responsibility for the risk it is assessing. In practice, the customer's risk owner should map each CUEC in the report to a named internal control, an owner and a date of last evidence, then record any CUEC that the customer does not run as an accepted gap for the risk committee. Confirm the exact wording of each CUEC with the provider, since the report wording governs what the provider expects you to do.
Data is the sharpest case. The same Journal of Accountancy article notes that user entities remain responsible for protecting the data they submit to a service organization, even if a breach occurs at the service organization. A provider's clean report therefore does not reduce the customer's duty to classify what it uploads, restrict who can export it and keep its own retention and disposal records. Before relying on the report, ask the provider which CUECs cover data submission, encryption keys and account administration, then confirm that your team has the tooling and records to show each one. If you run the platform in your own cloud account, the same logic applies to the shared responsibility model, where the customer manages the configuration of the services it chooses to use.
How to work through a vendor's CUEC list in practice
This sequence turns a vendor's list of complementary user entity controls into a register your team owns, with each item checked against your own environment, evidence and gaps.
Obtain the current report and system description
Request the vendor's latest SOC 2 report, including the system description and the management assertion, and confirm the report period, the trust services categories in scope and whether it is a Type 1 or Type 2. Read the section listing complementary user entity controls alongside the system description, since the report describes which controls the vendor expects you to run. The step is done when the report and its date range are filed in your vendor record and you can state which categories the report covers.
Extract every CUEC into a register
Copy each complementary user entity control from the report into a CUEC register, one row per control, with the criterion it relates to and the exact wording the vendor used. Do not summarize or merge items at this stage, because a merged row can hide an obligation. The register is complete when its row count matches the list in the report and each row cites the report section and page it came from.
Assign an internal owner to each control
Name one accountable person inside your organization for every row, usually the team that already operates the matching process, such as access administration, identity, procurement or security operations. Record the owner and a backup in the register. The step is done when no row is unowned, and each owner has confirmed in writing that the control falls to them and not to the vendor.
Check that each control exists and produces evidence
For each row, the owner describes how the control operates in your environment and points to the evidence it produces, such as an approval record, an access review export, a configuration file or a system log. Confirm that the evidence is retained for the period the vendor's report covers and that someone outside the team can retrieve it. The step is done when every row has a named evidence source or is marked as not operating.
Record gaps and choose a response
Mark each row as operating, partially operating or missing. For each gap, decide between building the control, documenting a compensating control with its own evidence, or asking the vendor a written question about whether the gap affects the scope of its report. Keep the decision and its owner in the register. The step is done when every gap has a recorded response and a named person accountable for it.
Send targeted questions to the vendor
Where your team cannot confirm how the vendor depends on a control you run, send written questions that quote the CUEC row and ask what the vendor assumes you do. Log each question, the answer and the date received in the register. The step is done when every open question has a documented answer or a recorded decision to accept the risk, and the answer is stored with the vendor record.
Review the register and keep it current
Have a risk or compliance owner review the completed register with the control owners, then assign a point in your process to revisit it when the vendor issues a new report, changes its services or your own systems change. Note in the register that the report covers only the vendor's controls, while your obligations for the data you submit remain yours. The step is done when the review is signed off and the register is linked from the vendor record.
What a service organization needs before the CUEC list is final
A CUEC list is only as accurate as the work behind it. The items below are the inputs an auditor will test against, and each one should be checked by the service organization before fieldwork starts, not discovered during it.
A control matrix that flags customer dependence
Every control in the matrix should record whether it operates entirely inside the service organization or depends on something the customer must do, such as configuring SSO, approving access requests or reviewing its own user lists. Controls that depend on the customer are the candidates for CUECs, so the matrix is the starting point for the list. Check that each flagged control names the customer action it relies on and that no customer dependency is hidden inside a control described as fully automated.
A system description reviewed against DC 200
Management's system description must cover the complementary user entity controls criterion (DC 200 item DC7) and the related controls it relies on. Ask whether the CUEC section matches the controls in the matrix, the service commitments in the contract and the actual product behavior. A reviewer should be able to trace each listed CUEC back to a description of the system and forward to the control it supports.
Customer guidance for each CUEC
A CUEC is only useful if the customer knows what to do. For each item, write plain guidance that names the action, the owner on the customer side, the product setting or screen involved and how often it should happen. Test the guidance by asking a customer administrator to follow it without help. Where the guidance points to product documentation, confirm that the documentation is current for the version the customer runs.
A process for updating the list
Product changes, new integrations and new deployment options can add or remove customer responsibilities. Define who reviews the CUEC list when a feature ships, when a change touches access, logging or data handling, and when a subservice organization changes. Record each review in change management so the auditor can see that the list tracked the system during the period, not only on the day the description was written.
Evidence that obligations reach customers at onboarding
Listing a CUEC in a report does not show the customer knows about it. Keep records showing that the responsibilities were presented during contracting or onboarding, were acknowledged, and were repeated when the customer's configuration or user population changed. Ask who signs for the customer, where the acknowledgment is stored and how the service organization handles customers who never acknowledge the list.
Where an implementation partner helps and where it cannot
An implementation partner can make complementary user entity controls testable, but it cannot make them the auditor's conclusion. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, so its work often covers the very configuration a customer must run. Where a vendor or internal team asks for help, DeployOpen can prepare configuration guides for each CUEC the service organization lists, collect evidence for the controls the organization owns (such as role assignments, backup job records and logging settings), and write runbooks that name the customer-side owner of each step. DeployOpen does not write the auditor's opinion, does not decide which CUECs the auditor accepts, and does not issue a SOC 2 report. Only an independent CPA firm does that.
Many self-hosted deployments place CUECs on the customer's own infrastructure. In that case the partner's job is to make those obligations explicit: which console, which role, which review cadence, and which record proves it happened. Ask the partner to produce a written handover that maps each listed CUEC to a named owner, a system of record and a testing step the customer can perform. Confirm with your auditor, before work starts, whether the wording of each CUEC in the draft system description is specific enough to be tested. Scope decisions about which CUECs appear in the report belong to management and the CPA firm, not to the implementation partner.
Questions buyers ask about CUECs
What is a complementary user entity control in plain terms?
A complementary user entity control, or CUEC, is a control that the service organization assumes its customers will run on their own side. The service organization's system depends on that control for some of the security or processing outcomes its own controls are designed to achieve. Management lists the CUECs in the system description so that readers can see which responsibilities stay with the customer. Typical examples are reviewing user access to the customer's own tenant, approving the customer's own configuration choices, or protecting credentials issued to the customer's staff. A CUEC is not a suggestion, and the service auditor tests the service organization's controls, not the customer's.
Can a customer skip a CUEC if it does not use a feature?
Often yes, but only if the feature the CUEC relates to is genuinely out of scope for that customer. If the service organization lists a CUEC tied to a module, integration or configuration option, and the customer never enables it, the control may not apply to that customer's environment. Confirm this in writing with the provider, because the system description describes the service as a whole and a customer may not be able to infer which controls depend on which features. Do not assume a CUEC is irrelevant because it sounds administrative. Access reviews, log retention and encryption key handling frequently apply even to light users of a platform.
Does a SOC 2 report prove the provider's controls work for my organization?
A SOC 2 report describes the provider's controls and, for a Type 2 report, reports on whether those controls operated effectively over a period. It does not certify that the controls work for your specific environment, data or configuration. The report is limited to the system described, the trust services criteria in scope and the testing performed by the service auditor. Your own use of the service, including the controls you were expected to run, sits outside the auditor's conclusion. Read the report alongside the CUEC list, the exceptions section and the subservice organization disclosures, and map each CUEC to a named owner in your organization.
What should we do about a CUEC we cannot meet?
Treat it as a risk decision that must be documented before you rely on the service. There are three practical paths: implement a compensating control of your own, change how you use the service so the CUEC no longer applies, or accept the residual risk formally with an owner and a review date. Raise the gap with the provider early, because some providers can explain alternative configurations or confirm whether the CUEC is relevant to your tier. Record the decision in your third-party risk file. Remember that a customer that requests a service auditor's report to assess risk is not relieved of its own responsibility for that risk, so an unmet CUEC remains your exposure.
Can the CUEC list change between a Type 1 and a Type 2 report?
Yes, it can. A Type 1 report describes the system and the design of controls as of a point in time, while a Type 2 report covers a period and may reflect changes made during that period, such as new features, retired integrations or revised configuration guidance. Management prepares the system description for each report, so the CUEC list should match the system as it existed in that report's scope. Compare the two lists rather than assuming continuity. If a CUEC was added or removed, ask the provider why, and check whether your internal control owners were told about the change in time to act on it.
How much internal effort does a CUEC review take?
The effort depends mostly on how many CUECs apply to your use of the service and how many already have an owner and an operating procedure. Reviewing the list is usually a bounded task for a small number of relevant controls, but mapping each one to evidence, assigning responsibility and checking that the control runs on a recurring basis takes longer. Expect one-time work for the first review and recurring work each time the provider issues a new report or changes its system. Ask the provider how it expects customers to demonstrate each CUEC and whether it offers a mapping, since that reduces the time your team spends interpreting the report. If an outside party helps, the scope of that work should be written down before it starts.
How DeployOpen prepares CUEC documentation and evidence
DeployOpen works on SOC 2 complementary user entity controls as part of a self-hosted platform implementation inside the client's own infrastructure. We prepare the systems, control records and evidence that show which customer-side controls exist, while the organization owns its controls and an independent CPA firm issues the report.
How we scope
- Engagements are fixed-scope, with the CUEC list, deliverables and timelines agreed in writing before work starts.
- The written scope names which platform components and customer-side responsibilities the CUEC documentation covers.
- We confirm with the client and its CPA firm which CUECs belong in the system description and which are out of scope.
- Ongoing support for CUEC upkeep is available as a retainer, scoped separately from the initial engagement.
How we build
- We draft a CUEC register that maps each customer-side control to the criteria it supports and the owner responsible for it.
- We configure the self-hosted platform so that the controls a customer must run, such as access reviews and logging, can actually be operated.
- We set up the records and system-generated reports that show each CUEC operating, so evidence exists before the auditor asks for it.
- We test each CUEC procedure with the client's team to confirm it is workable in the client's own environment.
How we hand over
- We deliver the CUEC register, runbooks, evidence locations and owner assignments as documented artifacts the client keeps.
- We walk the client's operators through each customer-side procedure so responsibilities are understood, not assumed.
- We give the client a clear list of CUECs it must confirm with its service provider and with its own auditor or assessor.
- We document open items and the controls the client still has to adopt, so nothing depends on DeployOpen staff remembering it.
How we support
- We can review changes to the platform that alter a CUEC, such as new integrations, upgrades or access model changes.
- We help the client refresh CUEC evidence ahead of each assessment period, based on the agreed retainer scope.
- We recommend that the client confirm final CUEC wording with its CPA firm, since only the independent auditor issues the report.
- Security testing of the platform can be scheduled separately to check that controls the client relies on continue to function.
