July 21, 2026

Complementary User Entity Controls: What Auditors Test When Clients Rely on SOC Reports

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Key Insights

A clean SOC report covers the vendor's controls, not the complementary user entity controls (CUECs) it expects your client to run. Testing those is on you.
PCAOB inspectors keep flagging the same CUEC misses: wrong control tested, implementation unchecked, gaps left out of the conclusion.
Access tasks slip most: removing terminated employees and approving changes to their environment.
Map each CUEC to a client-side owner before relying on the report.

A client's vendor sends over a SOC 2 with a clean opinion, and the audit team checks the box: the vendor's controls work. Months later, an inspector reviewing the file asks a simpler question. Who confirmed the client removed access for the employees it let go during the period? The vendor's report assumed the client handled that. Nobody on the engagement tested whether it did. The control sits in the client's environment, outside the vendor's report, and confirming it ran was the audit team's job.

This article covers what complementary user entity controls (CUECs) actually are, why they require explicit attention when a client relies on a service organization, and how to map each applicable CUEC to a client-side owner before you establish reliance.

What complementary user entity controls are

A service organization is an outside provider a company hands part of its operations to: a payroll processor, a cloud host, a data center. The companies that rely on it are its user entities, and when one of them is the company you audit, it is your client. A SOC report is the independent examination of the provider's controls. The report answers one question: are the provider's controls designed and operating well? It stops at the provider's edge. Anything the client does on its own side falls outside it.

Complementary user entity controls are the ones the service organization expects the client to operate so the provider's own controls can work. Take access: the service organization secures the application, but only the client can remove a user when one of its employees leaves. If the client never does it, the provider's access controls can't fully meet the trust services criteria, no matter how well they are designed. CUECs show up most often in SOC 2 reports, because some control objectives only hold when both sides operate their piece.

Not every obligation in the report counts as a CUEC, and the bar for what does is high. A control is a true CUEC only when the provider's objectives genuinely depend on the client running something on its end. Routine account-holder obligations, the contractual housekeeping every vendor agreement carries, do not qualify. When a report pads its list with those, the few controls that actually matter for the audit are easy to miss.

Why a SOC report can't stand on the service org alone

A SOC report only speaks to what the service organization manages, and it rests on an assumption: that the client is operating its side. PCAOB AS 2601 addresses this directly. The service auditor evaluates the provider's controls on the premise that the client holds up its end, then issues an opinion on the provider alone.

That gap is what makes a clean opinion misleading on its own. The report confirms the provider's controls work. It says nothing about whether the client ran its piece. A provider's access controls can be perfectly designed, and if the client never removed the people it let go, the exposure is still live. The clean report and the open risk sit side by side, and only the second one shows up in your audit.

The CUECs clients commonly miss

A CUEC becomes a real problem any time the action it depends on happens outside the service organization's view. HR terminations, business-need approvals, sign-offs on configuration changes: none of those show up in the service organization's logs, so the report hands them back to the client.

Access administration is where this most often goes unowned. The report may list control points that sit on the client's side, unassigned:

Removing access when someone leaves. Only the client knows an employee is gone. If no one cuts their access, the former employee keeps it.
Reviewing who has access, on a set cadence. The provider can't confirm the people with access still need it. The client has to.
Approving configuration changes. When a setting depends on the client's input, the provider needs sign-off before it goes live. No sign-off, no record to test.
Reviewing the provider's output. Some reports assume the client checks reports, alerts, or reconciliations the provider generates. If the client never looks, an error can run for months.

Because the relationship runs almost entirely through the service organization's platform, it is easy for a client to assume the service organization handles everything. The CUEC section is where the report makes the dependency explicit, and it is the section that most often receives a single read rather than a systematic mapping.

What CUECs mean for your evidence trail

CUECs split the evidence in two. The service auditor who issued the SOC report can confirm the CUECs are identified and described well, but that opinion stops at the service organization's edge. Whether your client actually operated those controls is the client's to run and yours to test. A Type 2 opinion does not extend to the client's side, so your assurance over CUECs has to come from procedures you perform on the client's own operation of them.

That is where your work gets specific. PCAOB keeps flagging the same three failures, and each has a direct fix:

Testing a control that doesn't address the CUEC. Confirm the control actually satisfies the CUEC objective before you rely on it.
Never confirming the CUEC was implemented. Test whether the client put it in place at all.
Finding a deficiency but leaving it out of the conclusion. Follow the gap through to its effect on the related control objectives.

The thread that ties them together is simple: a CUEC is only addressed when the right control is tested, shown to be operating, and carried into what you conclude.

Each of those steps is a discrete, evidence-driven check, exactly the kind of work Fieldguide is built around. On Fieldguide, practitioners direct the work through Field Orchestrator, which coordinates a set of Field Agents that execute it. Request Agent reviews client evidence the moment it comes in and flags gaps before they reach the workpaper, so missing or insufficient evidence for a CUEC surfaces at submission rather than at review. Testing Agent executes control testing by matching evidence to samples, documenting results, and flagging exceptions. Practitioners review every output and own the conclusion.

How to map CUECs when a client relies on a SOC report

Before relying on the report, map every applicable CUEC to an owner inside the client's organization. Search the report for "complementary user entity controls," then trace each item to the trust services criterion or business process it supports. CUECs may be absent from a SOC report. When they appear, your engagement team owns the work of confirming they were operated.

For each CUEC, work through the same short sequence:

Assess whether it applies to how the client actually uses the service.
Map it to a specific client-side control: a policy, a system setting, a manual review.
Identify an owner, a frequency, and where evidence is maintained.
Confirm the control operated throughout the reliance period.
Where the control is missing, assess the effect on the related control objectives and document the conclusion.

Timing also matters. In cloud environments, customer responsibility for risk and compliance remains with the organization, and the engagement team's review includes confirming the client obtained and evaluated its vendors' SOC reports. Reliance over a period requires monitoring CUEC performance across that period and addressing any bridge between the report period and the period you are auditing. That ownership map needs to be in place before you establish reliance, not assembled after a deficiency surfaces.

See how Fieldguide supports the engagement work behind CUEC testing

The CUEC work this article describes is a chain: identify the controls your client owns, request the evidence, test whether each one operated, and carry the result into your conclusion. When that chain runs across email, spreadsheets, and a separate request tool, the gaps the PCAOB flags are exactly the ones that slip through. Fieldguide keeps the chain in one place. It is an end-to-end, AI-native platform built for audit and advisory firms, where request management, control testing, review, and documentation stay connected, so a missing CUEC surfaces at submission instead of at review.

Field Agents execute the work; practitioners review the output and sign the conclusion. Half the Top 100 US CPA firms run on Fieldguide, including members of the Big Four. To see how it handles control testing and evidence on one system, request a demo.