Somewhere in the middle of almost every SOC report there is a table that readers skim past on their way to the test results. It lists things the customer is expected to do. Those are complementary user entity controls, and they are the part of the report that quietly moves work onto your side of the line.
The definition is short. Complementary user entity controls (CUECs) are controls that the service organization assumes its customers have implemented, and which are necessary — in combination with the service organization’s own controls — for the applicable trust services criteria or control objectives to be achieved. They are not suggestions and they are not disclaimers. They are load-bearing. If the report says user entities are responsible for removing terminated employees from the application and you do not do that, the criterion is not met at your organization, regardless of how clean the auditor’s opinion looks.
Why a report needs them at all
Any outsourced service splits control responsibility between two parties, and the split is rarely obvious from the outside.
Take a payroll platform. The provider controls how the application authenticates users, how data is encrypted, how changes reach production and who at the provider can touch customer data. What the provider cannot control is which of your employees you grant administrator rights to, whether you enable multi-factor authentication in the tenant settings you own, or whether anyone at your end reviews the payroll register before it is released.
Those decisions sit with you, they materially affect whether the service works correctly, and the auditor examining the provider has no visibility into them. So the service organization’s description states the assumption openly: we designed our controls on the basis that user entities do these specific things. That statement is the CUEC list.
What they actually look like
CUECs are usually presented as a table or bulleted list in Section 3 of the report, the system description written by management. Common ones include:
- User entities are responsible for provisioning, modifying and removing their own users’ access within the application, including prompt removal on termination.
- User entities are responsible for configuring available security settings such as password policy, session timeout, SSO and multi-factor authentication.
- User entities are responsible for maintaining the confidentiality of credentials and API keys issued to them.
- User entities are responsible for reviewing reports and output for completeness and accuracy, and for notifying the service organization of discrepancies within a stated period.
- User entities are responsible for notifying the service organization promptly when an authorized contact or administrator leaves.
- User entities are responsible for determining whether the configuration and use of the service meets their own legal and regulatory obligations.
In SOC 1 reports the list often runs longer and more specific, because the controls in question feed someone’s financial statements. You will see items about authorizing transactions before submission, reconciling output to source records, and reviewing exception reports within a defined timeframe.
What the auditor did and did not do here
This is the part that gets misread most often. The service auditor does not test complementary user entity controls. They sit outside the service organization’s system boundary. The auditor tests the service organization’s controls, forms an opinion on those, and the CUECs are disclosed as an assumption underpinning the design.
So a report with an unmodified opinion and a page of CUECs is saying something more conditional than it first appears: our controls, as designed and operated, meet the criteria provided our customers do the things listed. The opinion does not extend to whether any particular customer did them.
For SOC 1 in particular, this matters to your financial statement auditor. When they read a service organization’s report as part of your audit, the CUEC list tells them which controls they need to look for at your organization. If a CUEC says you reconcile the provider’s output monthly and you cannot show them a reconciliation, that is now a finding in your audit, not the provider’s.
If you are the customer: how to use the list
Filing the report in a vendor folder is not the same as reading it. Three practical steps.
Extract the CUECs into your own control documentation. For each one, name an owner and note where the evidence lives. “Terminated users removed from the billing platform within one business day — owner: IT operations — evidence: offboarding ticket with deprovisioning checklist.” If you cannot complete that sentence, you have a gap.
Check the ones that look generic. A CUEC saying you are responsible for reviewing access quarterly is easy to nod along to and easy to not do. Pull last quarter’s review for that specific system and see whether it exists with a date and a reviewer on it.
Notice when the list is doing too much work. A short, specific CUEC list is a sign of a service organization that has thought carefully about its boundary. A sprawling list that reads like a general security policy — “user entities are responsible for maintaining an information security programme” — can be a sign that responsibility is being pushed outward rather than described. It is fair to ask the provider which criteria each CUEC supports.
If you are the service organization: writing CUECs that hold up
Two failure modes show up repeatedly in readiness work.
The first is a CUEC list copied from a template that does not match the service. If your platform does not let customers configure their own password policy, do not claim they are responsible for it. Auditors read the list against the description of the system, and a mismatch invites questions about how carefully the description was prepared.
The second is using CUECs to cover a control you should own. If the criterion could reasonably be met by a control inside your system and you have simply chosen not to build it, saying “user entities are responsible for detecting unauthorized activity in their tenant” is not a fix. It is a design gap with a sentence in front of it.
Good practice is to work backwards from the criteria. For each applicable trust services criterion, ask what has to happen for it to be met, then separate what happens inside your system from what necessarily happens at the customer. Only the second group belongs in the CUEC list, and each entry should be specific enough that a customer could hand it to a team and have them act on it. Practice on formatting varies between firms — some map each CUEC to the criteria it supports, others present a single consolidated list — so ask your service auditor what they expect to see.
CUECs are not the same as subservice organization controls
These two get conflated because they appear near each other in the description and both describe controls someone else operates.
CUECs sit downstream of you — they are your customers’ controls. Complementary subservice organization controls (CSOCs) sit upstream — they are the controls assumed to be implemented at a vendor whose services you have carved out of your report, such as a cloud infrastructure provider or a managed data centre. Both are disclosed assumptions, and neither is tested by your service auditor. But they point in opposite directions, and a reader trying to understand where a control actually lives needs to keep them separate.
What to do next
Pull the most recent SOC report from your two or three most critical vendors and find the CUEC section — it will be in the system description, usually near the end. Read the list and mark every item you cannot immediately name an owner and an evidence source for. That short list is a genuine gap in your control environment, and it is one your own auditor may well ask about.
If you are on the other side of this and preparing a report, review your draft CUEC list against your system description line by line before it reaches the auditor. Assurion is a licensed CPA firm and works through this boundary with clients during readiness, well before it becomes a comment in fieldwork.