Complementary user entity controls are the part of a SOC 2 report that creates work for the reader. Most organisations file the report as evidence that a supplier is secure, without noticing that a section of it is a list of things they must do.
If you do not do them, the criteria the report covers are not met for your use of the service — regardless of how clean the opinion is.
What complementary user entity controls are
A SOC 2 report describes a service organisation’s system and the controls it operates. But many controls only work as a pair. The provider can enforce multi-factor authentication; it cannot decide who in your organisation should have an account. It can log administrative actions; it cannot review those logs on your behalf.
Where meeting a trust services criterion depends on something the customer does, the service organisation states it as a complementary user entity control — a control it assumes you operate.
Three consequences follow, and they are the whole reason this matters:
- They are assumptions, not findings. The service auditor tests the provider’s controls. It does not test whether you perform the CUECs.
- They are conditions on the conclusion. The description is built on the premise that these controls operate at user entities. Where they do not, the intended outcome may simply not be achieved for you.
- They transfer silently. Nobody sends you a task list. The obligation arrives inside a PDF that a procurement team files.
Complementary user entity controls are one of three populations

Reading a SOC 2 report properly means separating three populations, only one of which the report actually tests.
There is the service organisation’s own controls, described and tested. There are the complementary user entity controls, described and assumed. And there are the controls of the provider’s own suppliers — where a subservice organisation is involved.
That last one is where reports differ most, and it is worth checking before you rely on anything.
Under the carve-out method, the subservice organisation’s controls are excluded from the description and are not tested. The report will typically list complementary subservice organisation controls — controls the provider assumes its own supplier operates. Under the inclusive method, the subservice organisation is brought inside the scope and examined.
A carved-out report covering a service that runs entirely on a third-party platform can therefore say very little about the platform. That is not a defect — it is a scoping choice you need to notice.
How to use the complementary user entity controls list
Treat the complementary user entity controls list as an inbound requirements document, because that is what it is.
- Extract the list from every SOC 2 report you receive, into your own register — not left in the PDF.
- Assign an owner per CUEC inside your organisation. Most are configuration or process controls belonging to IT, HR or a service owner.
- Confirm each is actually performed, rather than assumed. This is where the surprises are: user access reviews, offboarding, encryption key handling, configuration choices left at default.
- Record the evidence, because your own auditors will eventually ask how you satisfied the assumptions in your supplier’s report.
- Re-read on renewal. CUEC lists change between report periods, and nobody flags the diff.
The common failure mode is quiet: a supplier’s report lists twelve CUECs, the customer performs eight, and both parties believe the arrangement is covered. The gap only becomes visible after an incident.
Complementary user entity controls when you are the provider
If you issue a SOC 2 report, your complementary user entity controls list is a design decision with commercial consequences.
A long list moves responsibility to customers, which weakens the report’s value as a sales asset and invites questions during diligence. A short list means you have taken more into your own control boundary, which is a stronger position to sell but a more expensive one to operate.
The unhelpful middle is a list written defensively by advisors — long, generic, and impossible for a customer to operationalise. It protects nobody, because a CUEC that no customer implements is not a control, it is a disclaimer.
How this fits your assurance work
| Area | Connection |
|---|---|
| SOC 2 compliance | The wider programme, and what the report covers on the provider side |
| Third-party risk management | CUECs are inbound obligations from suppliers. They belong in the supplier record, with an owner |
| ISO 27001 | Most CUECs map to access control, change management and operations controls you already run — the work is confirming, not building |
| CSA STAR | The Cloud Controls Matrix states which actor implements each control, which is the same shared-responsibility question in a clearer format |
Where to start with complementary user entity controls
- Pull the CUEC section from your most critical supplier’s report today. Most organisations have never read it.
- Check whether the report uses the carve-out or inclusive method, and what that excludes.
- Own each control internally, by name.
- Close the gaps you find, which are usually access review and offboarding.
- Add CUEC review to renewal, not just report collection.
- If you issue reports, keep your list short and operable, and write it for a customer to act on.
This guide describes SOC 2 reporting practice as at 16 August 2026. Report structure and terminology follow the AICPA’s attestation framework; your service auditor is the authority on how a specific report is scoped.
The SOC2 Toolkit provides the documentation pack behind a SOC 2 programme, including the control descriptions, the system description and the evidence records a service auditor works from.