Half the report is about you

A vendor sends you its SOC 2 report. You check the opinion, look through the auditor's tests, scan for exceptions, then save the PDF as evidence that the vendor has been reviewed.

There may still be a section telling you that some of the controls you just relied on assume you are doing something too. They are called Complementary User Entity Controls, usually shortened to CUECs.

They are easy to skip. They are also one of the most useful parts of the report.

Some controls have two sides

A SaaS vendor can provide strong authentication features. It cannot make you configure them correctly. It can provide separate administrative roles. It cannot decide which of your employees should receive them.

It can generate audit logs. It cannot make your team review them. It can give you mechanisms for removing users. It cannot know that somebody left your company yesterday unless your side of the lifecycle tells it.

This is the boundary CUECs help describe.

The vendor operates its controls. The report may assume the customer operates complementary controls of its own. If an applicable assumption is not true in your environment, a clean vendor report does not make that gap disappear.

These are not generic security tips

A CUEC is not simply a list of good ideas the auditor thought customers might appreciate. It identifies controls at user entities that the service organization's control environment expects customers to operate for the relevant service commitments and system requirements to be achieved. That makes the section different from a security checklist.

The useful question for every applicable CUEC is: What are we relying on here, and are we actually doing it?

Sometimes the answer is yes exactly as written. Sometimes you meet the objective through a different control. Sometimes it genuinely does not apply to your use of the product. And sometimes the answer is simply no. Those four answers should not be treated as the same thing.

What tends to appear there

The exact controls vary with the service. Common themes include customer responsibilities around:

• User account administration.
• Authentication configuration.
• Protecting credentials.
• Assigning appropriate roles.
• Reviewing activity or reports made available by the service.
• Keeping customer-side systems and integrations secure.
• Providing accurate configuration or input data.
• Reporting suspected security events to the service provider.

The wording matters. Do not replace the actual CUECs in the report with a generic checklist from somewhere else. The whole value is understanding what this service organization says it relies on its customers to do.

“Supported” does not mean “implemented”

This is one of the easiest distinctions to miss during vendor review. The vendor supports SSO. That does not mean your tenant uses it.

The product has granular roles. That does not mean your administrators have separated them. Audit logs exist. That does not mean anybody has access to them, retains them or looks at them.

The vendor's report can be completely accurate while your configuration leaves part of the intended control model unused. This is why procurement evidence and implementation evidence are not the same thing.

The SOC 2 belongs in the vendor record. Your configuration belongs in your own control evidence. You need both.

Turn the section into four columns

The easiest way to make CUECs useful is to stop reading them as prose. For each applicable CUEC, record four things.

Requirement What does the report expect the customer to do?

Status Use one of four answers:

• Implemented
• Equivalent control
• Not applicable
• Gap

Owner Who is actually responsible for keeping it true?

Evidence How would you demonstrate that it is happening?

That final field is where vague answers become visible. “We remove users when they leave” sounds complete. “Okta deprovisioning log plus quarterly SaaS access review” is evidence.

If there is no evidence, the first answer may be an assumption rather than a control.

Not applicable needs a reason

Some CUECs genuinely will not apply. A control about a feature you do not use may be irrelevant. A responsibility delegated to another managed service may be covered elsewhere.

That is fine. Write down why.

“Not applicable” with an explanation is an assessment. “Not applicable” used to make the table shorter is not.

The same applies to equivalent controls. If you satisfy the objective differently, record how. The purpose is not to reproduce the vendor's wording mechanically. It is to understand the dependency and show how your environment addresses it.

The table can reveal a bad report too

Sometimes the CUEC section itself is difficult to use. Responsibilities are vague. Relationships to the service's controls are unclear. The table appears incomplete. Or something referenced elsewhere in the report is missing.

Do not invent the missing interpretation. Ask the vendor.

A serious vendor should be able to explain what it expects customers to operate and, where appropriate, obtain clarification from the party responsible for the report. Their response is useful evidence too.

Keep the result with the vendor record

Saving the SOC 2 PDF proves you received a report. An annotated CUEC assessment proves you understood part of what it asks of you.

For an important service, keep the completed assessment with the vendor record: Requirement | Status | Owner | Evidence

Then revisit it when the product or your use of it changes. Enabling a new integration, moving authentication to SSO or expanding the kind of data stored in the service can change which customer responsibilities matter.

The report is not only something the vendor has to renew. Your side can change too.

The check worth running

Open the SOC 2 report for one important SaaS platform. Find the Complementary User Entity Controls section.

Take the first five applicable entries and answer: Implemented, equivalent control, not applicable or gap?

Then name the owner and evidence for each. If the only answer you have is “the vendor is SOC 2,” you have read the vendor's half of the arrangement and missed your own.

Explore this expertise: Security Readiness & Response

All technical notes