Control and Function

Vendor Risk · Subservice Organizations

Complementary User Entity Controls, and why holding a vendor’s SOC 2 is not reviewing it

Control and Function · August 2026

Every SOC 2 report you collect from a vendor contains a section most people never read. It lists the controls that report assumes you are operating. Not the vendor. You.

They are called Complementary User Entity Controls, CUECs, and they are the reason a filing cabinet full of vendor reports can still fail an audit.

What they actually are

A service organization gets audited on the controls it operates. But almost no service is self contained. AWS secures the hypervisor and the physical data center. It does not configure your security groups, rotate your access keys, or decide who on your team gets production access. Those are yours, and AWS says so, in writing, inside the report you downloaded.

That list is the CUECs. It is the vendor stating the conditions under which their opinion means anything. Read plainly, a CUEC says: our controls work, provided you are doing these specific things on your end. If you are not, the assurance you think you bought does not extend as far as you think.

You will usually find them in the description of the system, often as a table near the end, sometimes in an appendix. They are easy to miss because they sit after the part everyone actually reads, which is whether the opinion was clean.

The mistake almost everyone makes

Here is the pattern I see constantly.

A company gets asked to evidence vendor risk management. They pull the SOC 2 reports for their major subprocessors, drop them in a folder, link the folder in their compliance platform, and mark the control complete. The platform turns green. Everybody moves on.

What that evidences is that the report was obtained. The control usually asks whether vendor risk was assessed. Those are different words and only one of them was done.

Collecting a report proves you can download a PDF. It says nothing about whether you read it, whether the opinion was qualified, whether the period covers yours, or whether the things it assumes about your environment are true.

What an auditor actually does with it

They will not ask whether you have the report. They will assume you do.

They will ask who reviewed it, when, and what came out of the review. Then, if they are any good, they will ask how you addressed the CUECs.

That last question is where it falls apart, because the honest answer is usually that nobody knew there were CUECs. I have watched competent teams, who genuinely run good programs, discover mid fieldwork that their cloud provider has been assuming something about their key management that has never been true.

It is not a gotcha. It is in the report. It has always been in the report.

How to actually do it

The work is not complicated, it is just tedious, which is why it does not happen.

For each subprocessor whose report you rely on, open the report and find the CUEC list. Take each one and do one of three things with it.

Map it. Name the control in your own program that satisfies it. Not a policy that mentions the topic, an actual control with an owner and evidence. If your vendor assumes you review privileged access quarterly, point at your quarterly access review and the record that it ran.

Rule it out. Some CUECs genuinely do not apply, usually because you do not use the feature they cover. Write down why. An auditor will accept “not applicable because we do not use their SSO integration” far more readily than silence.

Flag it. If a CUEC lands on you and you have nothing behind it, that is a finding you just gave yourself for free, months before an auditor would have handed it to you. That is the best possible outcome of this exercise and the reason to do it early.

When you are done you have a table: every CUEC, its source report, its disposition, and the control or the reason. That table is the evidence. It is what turns “we have the report” into “we assessed the vendor,” and it takes an afternoon per vendor at most.

Two traps worth knowing about

Period alignment. A SOC 2 Type II covers a specific window. If your audit period runs January through December and your vendor’s report covers October through September, there are three months at the end of your period their report says nothing about. The fix is a bridge letter from the vendor covering the gap. Ask for it before fieldwork, not during, because it takes them weeks and it is not a priority for them.

Carve out versus inclusive. Most reports carve the subservice organization out, meaning the vendor’s controls are explicitly excluded from the opinion. People read that as the vendor being covered elsewhere. It is closer to the opposite. A carve out means the report is silent about them, the CUECs land squarely on you, and your own report needs to say how you handle it.

Why this is worth an afternoon

The gap between holding a vendor’s report and having assessed that vendor is not a paperwork distinction. It is the difference between assurance you actually have and assurance you assume you have.

A subprocessor’s clean opinion is conditional. The conditions are printed in the report. Reading them takes an afternoon, mapping them takes another, and doing it before an auditor asks converts what would be a finding into a table you hand them.

Almost nobody does it. That is most of why it is worth doing.

Anthony Proctor runs Control and Function, a SOC 2 readiness practice. He ran a SOC 2 Type I program end to end as the sole IT operator at a prior company, where a licensed CPA firm performed the attestation. Control and Function is not an audit firm and does not audit its own preparation work.

Talk through your vendor set →

Related

SOC 2, HECVAT, and FERPA for Ed Tech Vendors
If your buyers are universities, the SOC 2 report is only part of the ask. What HECVAT 4 actually checks and where FERPA obligations land.