What is an example of SOC 2 Complementary User Entity Controls in practice?

What CUECs look like in day-to-day operations

An effective CUEC is not a provider-side control. It is a customer-side responsibility that sits in the customer’s own environment, tenant, or operating model, because the provider’s assurance depends on that control being performed consistently. In practice, the clearest examples are approval, review, and segregation duties that the customer must enforce locally, not something the SaaS provider can do on the customer’s behalf.

For this reason, a CUEC should be written as an operational instruction the customer can actually carry out and evidence. A good example is “only designated approvers can grant privileged access,” or “someone independent of system administration must review privileged activity logs on a defined cadence.” Those are not abstract principles, they are concrete actions that can be assigned, monitored, and tested.

How the access-review example works

The most common pattern is access governance. If the provider relies on the customer to keep access approvals segregated, then the customer must decide who may approve new users, elevated roles, or exceptions. That matters because the provider cannot validate whether the customer has granted excessive access, approved their own access, or ignored an exception that undermines the control environment.

In a tenant-based service, this often means the customer documents who may approve access requests, who may review privileged activity, and how often that review happens. The control is effective only when the customer both performs the review and retains evidence that it happened. For a practical overview of how SOC reports frame access-related responsibilities, see the SOC 2 Guide.

A related evidence point is that the customer should be able to show the approval trail, reviewer identity, review date, and any remediation taken. If those artifacts are missing, the CUEC exists on paper but does not function as part of the provider’s control reliance.

What the provider and customer each need to document

The provider’s job is to describe the CUEC clearly enough that the customer can assign an owner, understand the required timing, and produce evidence without guessing. The customer’s job is to map the CUEC to an internal control owner and confirm that the activity is actually being performed, not merely assumed. That is why CUECs are usually phrased in a report, control matrix, or responsibilities appendix with enough specificity to operationalize them.

When the control is about access approval or privileged review, the wording should identify the system scope, the role responsible, and the expected cadence. If the wording is too vague, customers often over- or under-implement it, which weakens the assurance model even if the provider’s own control is sound.

For readers comparing control language against reporting guidance, the SOC 2 Trust Services Criteria (AICPA) is the primary external reference point for how these responsibilities are typically framed in assurance work.

Practitioner Guidance

What to verify: Confirm that every CUEC has a named owner, a clear operating cadence, and an evidence source before the report is circulated to customers. If the control cannot be evidenced by logs, approvals, review records, or ticket history, it is too vague to rely on in an audit or vendor review.

Decision rule: If the control depends on customer approval or review, treat it as a customer-operated control, not a vendor promise. If the customer cannot realistically perform it, the provider should rewrite the CUEC or replace it with a control the service model can actually support.

Practitioner takeaway: The best CUECs are specific enough to assign, test, and evidence, because a control that cannot be owned by the customer is not really a complementary user entity control at all.

Related resources from NHI Mgmt Group

• How should service providers implement complementary user entity controls in a SOC 2 program?
• Why do complementary user entity controls matter for SOC audit outcomes?
• How do SOC 2 complementary user entity controls work?
• What do organisations get wrong about complementary user entity controls?