User Entity Responsibilities in SOC Engagements
You can't rely on a SOC report alone without implementing your own required controls.
Getting a SOC report is not a finish line, but a handoff: the service organization has told you what it controls, and now the harder work starts, figuring out what you control, whether you're actually doing it, and whether the two halves fit together into something an auditor can rely on. This piece walks through that handoff in practice, from the mechanics of complementary user entity controls to what happens when they get ignored, and why the whole exercise looks different once regulators are in the room.
Why the service organization's controls alone are never the complete picture
A SOC report describes what one organization does. It is written for a broad population of user entities, which means it cannot, and does not try to, account for how any single one of them manages its own access reviews, approval chains, or data handling. That is by design, but it also means the report you're holding is only half the picture, and treating it as the whole picture is where a lot of control environments quietly fail.
Third-party vendors caused 62% of data breaches, according to the 2024 Verizon Data Breach Investigations Report, a statistic that alone should reframe how anyone reads a SOC report: the risk doesn't live neatly inside the service organization's walls. It lives at the boundary, in the handoffs between what the vendor does and what the client does with the access, data, or output the vendor provides. IBM's 2024 Cost of a Data Breach Report put the average cost of a third-party breach at $4.76 million, not a rounding error in a risk assessment, but a number that should change how much attention gets paid to the boundary itself.
Here's the mechanism worth sitting with: service organization controls are built on assumptions about what the user entity will do on its end. A background check vendor assumes its client will notify it promptly when an employee is terminated. A cloud hosting provider assumes the client will manage its own credentials responsibly. Remove those assumed actions and the vendor's controls, however well-designed, stop achieving anything close to the stated objective. The report can be spotless while the combined environment stays broken.
SSAE 18 added another wrinkle here, too. Service organizations now have to disclose Complementary Subservice Organization Controls, meaning their own third-party dependencies come into view. So the boundary a user entity has to think about isn't just one line anymore; it can be two or three, depending on how many hands the data passes through before it gets back to you.
What complementary user entity controls are and how SSAE 18 sharpened their definition
Complementary user entity controls, CUECs for short, are the controls a user entity has to run for the service organization's stated objectives to actually be met. They're listed in the SOC report itself, usually in a section most teams skim past on their way to the opinion letter, which is a mistake, because that section is arguably the most operationally important part of the whole document.
SSAE 18 tightened the definition in a way that matters. Under the prior standard, SSAE 16, CUECs could include controls that weren't strictly necessary to the control objective, just generally relevant or advisable. SSAE 18 narrowed that scope to controls that are actually required for the objective to be achieved. This produces a meaningfully shorter, more actionable list than what came before, and it's worth knowing the history if you're comparing an old report format to a new one.
It's also worth drawing a line between CUECs and what's sometimes called broader user entity responsibilities. CUECs are the necessary controls, disclosed in the report, tied directly to specific control objectives. User entity responsibilities are a wider set of operational expectations that aren't disclosed the same way and aren't as tightly scoped. Conflating the two is easy to do and leads to a false sense of coverage; you can satisfy your general responsibilities and still miss a CUEC that an auditor is going to ask about directly.
A concrete example helps. Say a payroll processor's control objectives assume the client reviews and approves payroll registers before they're submitted for processing. That review step is a CUEC, and it's not optional, nor something the payroll processor's own controls can substitute for, no matter how good their internal review process is. If the client skips that step, the objective (accurate, authorized payroll disbursements) isn't met, even though nothing in the processor's environment failed.
One more distinction that trips people up: service auditors evaluate whether management has adequately disclosed CUECs, per the guidance in DC 6, but they do not test whether the user entity actually implemented them. Testing that happens later, done by the user entity's own auditor, during the financial statement audit. So the SOC report tells you what you're supposed to be doing; whether you did it is a separate question entirely.
What breaks when CUECs are not implemented or documented
A SOC report with no CUECs listed at all should raise an eyebrow, not offer comfort. It usually means the service organization hasn't properly specified the assumptions baked into its own control design, which leaves the user entity's auditor without a clear map of what's expected on the client side. An incomplete disclosure is, in its own way, a red flag.
The more common failure isn't absence, though, it's neglect. CUECs are listed, clearly, in black and white, and the user entity simply hasn't implemented them. In that scenario the service organization's controls can be operating perfectly, the SOC report can come back clean, no exceptions, unqualified opinion, and the combined control environment can still fail its objective completely, because the missing half was never the vendor's to provide.
Take access control. A service organization might run strong authentication, detailed logging, real-time monitoring, everything you'd want to see. If the user entity hasn't implemented timely revocation of access when employees leave, or hasn't separated duties so no single person can both request and approve access changes, the objective of preventing unauthorized access simply isn't achieved. The gap sits entirely on the user entity's side of the line, and no amount of vendor diligence closes it.
Three failure patterns show up again and again. Poor documentation is the first: the control might genuinely exist in practice, someone really is reviewing that report every month, but there's no evidence trail, so an auditor testing it finds nothing to test. Unclear ownership is the second: nobody was formally assigned the CUEC, so it lives in the space between departments until an audit exposes the gap. Overlooked subservice organizations round out the list: when the vendor itself relies on another vendor, the actual flow of data and control responsibility can extend further than anyone at the user entity realized, particularly if the SOC report uses a carve-out method that pushes assurance over that subservice organization outside its own scope.
Under AU-C 402 and AS 2601, the user entity's auditor has to consider how the service organization's controls bear on the user entity's own internal control environment. If CUECs are missing or unimplemented, that auditor cannot lean on the SOC report to reduce their own testing, which means the absence of a working CUEC doesn't just create a control gap; it creates more audit work, more scrutiny, and less benefit from having paid for the SOC report in the first place.
How user entities should actually work through a SOC report they receive
So what does actually working through one of these reports look like, step by step, rather than as an abstraction?
Start with the basics: confirm the report type and the period covered. A Type I report only evaluates the design of controls at a single point in time; it says nothing about whether those controls operated effectively over any stretch of the year. A Type II report covers design and operating effectiveness over a defined window, typically six to twelve months, and it's the version most auditors and counterparties actually want to rely on. Check the dates too, since a Type II report whose coverage period ended eight months ago may not be current enough for this year's audit cycle, and there's no regulatory requirement forcing any service organization to produce a SOC 1 in the first place, so gaps in coverage are the user entity's problem to catch early, not the vendor's obligation to flag.
From there, go straight to the CUEC section, not just the auditor's opinion at the front. Map every listed CUEC to a named internal control owner at your own organization. If that control doesn't exist yet, that's a finding, and it needs to get fixed before the next audit starts, not discovered during it.
Look hard at any exceptions noted in the body of the report. An exception in a Type II report requires actual judgment: what exactly failed, how often did it happen, and does it touch any of the specific controls your organization is depending on? Not every exception is disqualifying, but every exception deserves a real answer, not a shrug.
Check for subservice organizations too. If the vendor uses the carve-out method to exclude a subservice provider from its own report's scope, you may need to go get assurance over that subservice organization separately, on your own initiative.
Document all of it, since written evidence that each CUEC was reviewed, evaluated, and mapped to a functioning internal control is exactly what an auditor is going to ask for later. If there's no SOC report available at all, because the vendor hasn't commissioned one, the obligation to assess that vendor's control environment doesn't disappear; it just means you're doing that assessment with less to work from.
How this plays out in regulated industries where the control stakes are higher
In a standard financial statement audit, the SOC 1 report is close to a routine annual request from the user entity's auditor. But routine doesn't mean low-stakes: gaps in CUECs flow directly into the auditor's risk assessment, and a client who hasn't implemented its side of the bargain is a client whose audit gets harder and more expensive.
Regulated housing and healthcare settings raise the stakes further. Take HUD's Section 232 program for multifamily and residential care financing. More than 26,000 HUD Multifamily and Office of Residential Care Facilities participants submit annual financial data electronically, and independent CPA firms serve as HUD's first line of defense in reading that data for signs of financial trouble. As of June 2024, 167 of 3,670 HUD-insured Section 232 borrowers, nearly 5 percent, had defaulted on their mortgages. That's not a small number, and part of what HUD's Office of Inspector General has scrutinized is whether oversight gaps let financial difficulties go undetected for too long. FASSUB attestation requirements add a procedural layer here too: the CPA has to reconcile the electronic submission against the hard copy audit report, which only works if the borrower, the user entity in this chain, has maintained reliable underlying records in the first place. That recordkeeping obligation functions much like a CUEC, even outside the formal SOC framework: it's the thing the borrower has to hold up for the rest of the oversight structure to mean anything.
Skilled nursing facilities face a similar dynamic through the annual Medicare cost report. Filing that report accurately is itself a core user entity responsibility, full stop, since CMS uses the data inside it to monitor facility performance and audits it to verify that reported costs match actual expenditures. The OIG's FY2025 priority areas include related-party cost report compliance and SNF Medicare reimbursement, and as of early 2025, Medicare cost reports from nursing facilities aren't routinely audited for related-party compliance. That's a real exposure for any facility that isn't imposing rigorous controls on itself, because nobody else is guaranteed to catch the gap first. Non-compliance or inaccuracies in these filings can trigger repayment demands or, in the more severe cases, exclusion from Medicare and Medicaid altogether, and the consequence of a weak internal control here isn't theoretical; it's a facility's ability to keep operating.
What fulfilling these responsibilities looks like as an ongoing program rather than an annual review
Here's the uncomfortable truth about the annual SOC report review: by the time it lands on your desk, it's already describing the past, and the period under examination has closed. A user entity that only thinks about CUECs once a year, when the report arrives, is permanently a step behind its own risk.
The alternative is treating CUEC management as a standing program rather than an annual event. That means keeping a live register that maps every service organization's CUECs to a specific internal control owner, updated whenever the vendor relationship changes or a new SOC report comes in. It also means paying attention to vendor change management in real time: when a service organization swaps subservice providers, updates its system, or issues a bridge letter to cover a gap in reporting periods, the CUEC mapping tied to that vendor needs to be revisited immediately, not filed away until next year's audit prep.
It means treating CUECs as things to test throughout the year, not just document once. Internal audit or management can build these into regular testing cycles the same way they'd test any other internal control, so that when the external auditor asks for evidence, there's something concrete to hand over rather than an assertion that the control "generally happens."
For organizations operating in HUD-regulated housing, skilled nursing, or mortgage banking, this isn't optional groundwork; the regulatory audit cycle is coming regardless, and it will scrutinize the exact controls CUECs are meant to complement. Catching a gap late in those environments doesn't just cost extra audit hours, since it shows up as restatements, repayment demands, or formal regulatory findings, the kind of outcomes that are far more expensive to fix after the fact than to prevent with a functioning CUEC register maintained all year long.
Working with auditors who understand both the SOC framework itself and the specific regulatory terrain a given industry sits in tends to shrink that gap, between what a report technically says and what it actually means for a particular organization's risk. That's often the difference between an audit that confirms what you already knew and one that surfaces, too late, what you should have caught months earlier.
