Complementary User Entity Controls in SOC Reports
Complementary user entity controls are the specific control activities a service organization expects its clients to run on their own side of the fence. Skip them, and the SOC opinion you're relying on doesn't carry the weight you think it does. The auditor's clean opinion covers the service organization's controls, not yours; CUECs are the seam where those two control environments meet, and that seam is where I've watched more than one audit go sideways.
The idea is older than the current vocabulary. Anyone who worked with SAS 70 reports before 2011 remembers "user control considerations," which did roughly the same job under a clunkier name. The AICPA sharpened the terminology since then, but the logic underneath hasn't moved much. A service organization designs its controls assuming the user entity is holding up its end. The SOC opinion is only as good as that assumption, and the gap tends to surface at the worst possible moment.
People mix up user responsibilities and CUECs constantly, and they aren't the same thing. User responsibilities come out of the service contract; somebody negotiated them, both sides signed off, and they're explicit and enforceable as contract terms. CUECs come from the service organization's own control design and may never show up in any contract at all. They're necessary for the control objectives to actually get met, contract or no contract. Both affect the user entity, but they arise from different places and carry different weight when something goes wrong.
Where CUECs appear in a SOC report and how the report is structured around them
A SOC report follows a standard four-part layout: the auditor's opinion, management's assertion, the system description, and the tests of controls. CUECs don't sit in just one of these. They show up in two spots, and a reader who checks only one is working from half the picture.
The system description carries a dedicated CUEC subsection, usually written at a general level, describing the kinds of complementary controls users are expected to have running. Separately, the control activities and tests-of-controls section embeds specific CUECs right alongside the exact control objectives they support. Management's assertion sometimes adds a quiet line noting that the stated control objectives assume CUECs are in place, and that line is easy to skim past without noticing.
Placement shifts depending on report type. In a SOC 1, CUECs sit inside the control objectives and related testing section, tied directly to internal control over financial reporting. In a SOC 2, they're identified within the Trust Services Criteria and the applicable control objectives, and those criteria span 61 points across security, availability, processing integrity, confidentiality, and privacy. Nobody hands a reader a single tidy list. That legwork, hunting down both the system-description CUECs and the control-level CUECs, falls on whoever is actually reading the report line by line.
How many CUECs to expect, and what the absence of them signals
Numbers help more than instinct here. The 2024 SOC Benchmark Study put the average number of CUECs across all reports at 12.5. Split by report type, SOC 1 reports averaged 14.7 CUECs against 8.9 for SOC 2, which tracks with SOC 1's heavier lean toward financial process controls. Meanwhile, 81.9% of reports landed in the 0-to-20 CUEC range. The field is fairly consistent, not scattered.
The AICPA's SOC 2 guide allows for the possibility that CUECs may not be required in every case, which is fine in theory. In practice, a modern service environment reporting zero CUECs should make a user entity pause rather than exhale in relief. Why would that happen? Occasionally it means the service organization genuinely designed a control environment where user-side dependencies don't exist. More often it means nobody on the service organization's side sat down and actually worked through where shared responsibility lives. A report with no CUECs deserves a second look, not comfort, and it should prompt more questions rather than fewer.
The same logic extends to subservice organizations, though the mechanics differ slightly. The 2024 study found service organizations relying on subservice providers averaged roughly 10 CSOCs, complementary subservice organization controls. A report listing none of those is worth a closer look at how the service organization actually oversees its own vendors, because somebody, somewhere, is depending on somebody else's controls, and that chain doesn't stop just because the report says it does.
The two types of CUECs: complementary and compensating
CUECs split into two distinct roles, and the split matters more than it looks at first glance. Complementary controls are the designed, planned mode of shared responsibility. They're built into the control framework from day one, working alongside the service organization's own controls toward a control objective both parties are aiming at together.
Compensating controls do something different. They're the workaround, the patch applied because a primary control just isn't feasible for some specific requirement. Take the classic case: a service organization has no reliable way of knowing the moment a user entity's employee gets terminated, and it can't see inside the user entity's HR system. So the user entity has to compensate, putting in place and actually enforcing a timely access-removal process on its own end. That's the only thing standing between an ex-employee and continued system access.
Complementary controls, by design, tend to be stable and predictable. Compensating controls are workarounds, and workarounds need more active monitoring to confirm they're actually functioning the way everyone assumes. Don't confuse CUECs with CSOCs while you're at it, either: CSOCs describe what the service organization's own vendors need to put in place, CUECs describe what the user entity needs to put in place. Accountability runs in opposite directions even though the two acronyms look like cousins on the page.
What CUECs look like in practice: concrete examples by control domain
Access management is probably the most common domain, and for good reason. A user entity's employee leaves the company, and that employee's access to a shared file-sharing platform needs to be cut off. The service organization has no visibility into the user entity's HR process, so it has no way to act on the termination itself. Multi-factor authentication for user logins comes up often too, usually spelled out as a CUEC for logical access security rather than assumed as something the service organization's own MFA setup already covers.
Change management shows its own version of this problem. When a managed IT service provider pushes changes into a user entity's environment, the CUEC typically requires the user entity to approve every change before it goes live. The service organization can document that a change happened; it cannot force the approval step to happen. That part belongs entirely to the user entity.
Data transmission is a quieter example, and no less real for being quiet. A bank sending large data files to a service organization may be required, by CUEC, to transmit using industry-standard encryption. The service organization's controls pick up once the data lands. Getting it there safely is the bank's problem to solve.
Physical security rounds it out. When a service organization installs an appliance or a server inside the user entity's own server room, the user entity is on the hook for restricting physical access to that room to authorized people. The service organization has zero reach into that physical space.
The pattern across these four domains isn't subtle once you've seen it a few times: the control boundary falls exactly where the service organization's authority runs out. CUECs mark that boundary in writing, out loud, instead of leaving it implied and hoping everyone reads the fine print the same way.
What user entity auditors must do when CUECs appear in a SOC report
Under AU-C 402 from the AICPA and AS 2601 from the PCAOB, an auditor planning a financial statement audit of a user entity has to evaluate how the service organization's controls affect that entity's internal control over financial reporting. Receiving the SOC report isn't the finish line, and I mean that literally: it has to be read, taken apart, and acted on, pulled apart section by section, not skimmed for a headline opinion.
CUECs are the piece most often glossed over, and that's a mistake with real teeth. They require the user auditor to test whether the user entity is actually performing the controls the service organization assumed it would perform, not merely whether the control exists on paper somewhere. Take a payroll processor's SOC report specifying that user entities must review and approve payroll registers before submission. That review is a CUEC. The audit team has to test whether the review actually happens, consistently, with evidence, rather than noting that the requirement is written down somewhere in a policy binder nobody's opened in a year.
Documentation matters just as much as the testing itself. Audit workpapers need to show how the team reviewed the SOC report, mapped it to the ICFR-relevant areas of the audit, and addressed every CUEC along with any exceptions found. Timing adds another layer: a Type 2 report needs to cover a period that overlaps a substantial part of the user entity's own financial statement period, and the industry rule of thumb is at least six months of overlap. A report covering some other window entirely doesn't give the auditor much to stand on for risk assessment.
Then there's the exception problem. In 2024, 54.9% of SOC reports carried at least one control exception, up from 51% the year before, though the average number of exceptions per report actually dropped, from 2.7 down to 1.73. User auditors have to work out whether those exceptions on the service organization's side undermine the user entity's ability to rely on those controls at all, or whether the damage is contained.
How control exceptions in SOC reports interact with CUECs
When a service organization's control fails, the next question is whether a CUEC on the user entity's side compensates for that failure, or whether the gap just sits there unmitigated.
The 2024 benchmark data on what actually causes exceptions is worth sitting with for a moment. Business approvals and reviews accounted for 16.5% of exceptions. User access reviews came in at 15.6%, terminations sat at 12%, and change management at 11.7%. Set that against the CUEC examples from a few sections back: access termination, access reviews, change approval. Not just common exception categories; they're precisely the domains where CUECs get written most often in the first place.
That overlap isn't coincidence. It's the same fault line showing up from two different angles. When a service organization stumbles in one of these areas, the user entity's own complementary controls matter more, not less, and a user entity that treats its CUECs as a formality is exposed exactly where the service organization is already showing weakness. Reading exception language carefully, figuring out whether a given failure was isolated, systemic, or already remediated, should shape how a user entity adjusts its own control posture going forward. It rarely does, in my experience, which is its own quiet problem.
How CUECs operate in financial services: broker-dealers and mortgage banking
Broker-dealers lean hard on third-party platforms for transaction processing, ledger maintenance, and safeguarding client assets. The SOC report covers the provider's side of that arrangement. CUECs define everything the broker-dealer itself is on the hook for.
Skip those CUECs and the fallout isn't abstract: incomplete trade data, cash movements that never got recorded, misstatements creeping into regulatory filings. Regulators expect broker-dealers to govern both their own internal controls and the third-party relationships stacked on top of them. Daily reconciliations, system access reviews, and exception-handling protocols are the CUEC types that show up again and again in this corner of the business.
Mortgage banking runs on a related but distinct track. SOC 1 reports are the relevant format there, because mortgage servicers, loan originators, and secondary market participants outsource functions, loan servicing platforms, escrow processing, investor reporting, that touch ICFR directly. CUECs in this environment tend to cover data submission standards, who gets access to servicing systems, and approval workflows for loan modifications or disbursements. When these fail, the damage doesn't stay contained. It surfaces in financial statement audits, investor reporting reviews, and regulatory exams, often all at once, which is exactly the kind of compounding mess nobody wants to untangle after the fact.
Lease accounting under ASC 842 offers a useful parallel, oddly enough. Even the most capable lease accounting software can't guarantee compliance on its own if the user entity hasn't put in place the CUECs covering data integrity, lease identification, and ongoing treatment. The software's controls and the entity's controls depend on each other the same way a service organization's and a user entity's controls do. Neither half works alone.
How user entities should build a repeatable process for reviewing and implementing CUECs
Reading a SOC report once doesn't get you anywhere durable. What works is a process, repeated every cycle, not a fire drill each time a new report lands in the inbox.
Start by pulling every CUEC out of both the system description and the control activities section, treating them as one combined list instead of two separate findings living in isolation. From there, map each CUEC to whatever internal control at the user entity is supposed to satisfy it. If nothing exists to satisfy a given CUEC, that's a gap, and somebody has to decide what to do about it instead of letting it ride into next year's audit.
Having a control described on paper isn't the same as having one that actually runs. Check operating effectiveness directly: are access reviews happening, are approvals logged, are termination procedures documented and carried out on schedule? Assign a named owner to each CUEC, since controls without an owner tend to quietly stop happening after a quarter or two; if nobody's watching it, nobody's doing it. Treat the whole CUEC list as a living document, not a checkbox exercise finished once and filed away, since service organizations update their control environments and CUECs shift when they do.
If a user entity genuinely can't satisfy a CUEC as written, that's a conversation to have directly with the service organization, either because the control expectation was described poorly or because a compensating control needs to be worked out and agreed on. All of this pays off later. User auditors will ask for evidence that CUECs were performed, and having that evidence organized and easy to pull cuts down on audit friction considerably.
What firms with expertise in SOC examinations bring to the CUEC review process
Reading a SOC report critically, telling which CUECs actually carry weight, which exceptions are consequential versus cosmetic, whether the overall control environment holds up under pressure, takes real familiarity with how these reports get built and how ICFR reliance actually functions inside an audit. It's not something you pick up from a single read-through, and I'd be skeptical of anyone who claims otherwise.
For a user entity going through a financial statement audit, how the auditor handles CUECs isn't a side note. It shapes risk assessment, it shapes how much testing gets done and where, and it ultimately shapes the audit opinion itself. Service organizations issuing SOC 1 or SOC 2 reports benefit just as much from working with experienced auditors who can help them write CUECs that are specific and genuinely useful, rather than generic boilerplate that leaves the user entity guessing at what's actually expected of it.
Specialized settings add another layer on top of all this: HUD Section 232 arrangements, skilled nursing facilities, mortgage banking, broker-dealers. Each one carries its own regulatory obligations layered over the SOC framework, which calls for auditors fluent in both sides, not just one.
Pease Bell conducts SOC 1 and SOC 2 examinations and brings that same assurance mindset into financial statement audits for user entities, so clients on either side of the service organization relationship work with practitioners who understand how the CUEC framework functions end to end. That orientation carries into newer assurance work the firm has taken on too, including AIUC-1 examinations for AI systems. Control environments keep getting more layered and more interdependent, and the controls each party owns only grow more consequential as a result. The need for everyone involved to share a clear, common understanding of who owns what doesn't fade as that complexity grows; if anything, it sharpens.
