Complementary User Entity Control

A vendor sends its SOC 2 Type II report. It is 80 pages, the opinion is unqualified, the risk committee marks the vendor as assured and closes the item. Nobody opens section four, where the auditor listed the 10 to 30 things it assumed the customer does before concluding that the vendor's controls achieved their objectives: you remove leavers within 5 days, you enforce multi-factor authentication on your tenant, you restrict who holds admin roles, you configure retention, you rotate API keys.

Those are the complementary user entity controls, and they are the seam where most SaaS incidents happen. The auditor tested the vendor's platform, not your configuration of it, so the assurance you believe you bought is conditional on work that was silently assigned to you.

Why it matters

A modern estate runs on other people's software, and third-party assurance reports are the main instrument for governing it. Reading one as a pass/fail stamp gets two things wrong at once. First, the report covers a period that has already ended — commonly 180 or 365 days — so it says nothing about today; the gap is usually papered over with a bridge letter, which is management's assertion rather than tested evidence. Second, the opinion is conditional, and the conditions are the customer's side of a shared-responsibility model that nobody in the customer organisation has been told they own.

The consequence is a control with no owner. The vendor believes the customer runs it. The customer believes the report covers it. The control does not operate, and the failure surfaces as a data exposure with a configuration at its root.

Implementation patterns

• Extract CUECs into your own control register at onboarding, each with a named owner and a test. This is the only part of reading a vendor report that changes anything in your architecture.
• Automate the testable ones. Leaver removal, MFA enforcement and admin-role counts are queries against the vendor's API, run daily, not annual attestations.
• Map them to the tenant configuration as code where the vendor supports it, so drift is a pull request rather than a discovery.
• Record the subservice method. A report using the carve-out method excludes the vendor's own providers; the inclusive method covers them. For a thin vendor over other services, carve-out leaves most of the supply chain untested, and you should ask for those reports too.
• Diarise the period end and request the next report before the gap exceeds 90 days.
• Read the exceptions, not the opinion. A repeated exception in access removal tells you more about the vendor than an unqualified conclusion does.

Industry example

The structure is not vendor-specific: every major cloud and SaaS provider publishes a shared-responsibility position that says identity, tenant configuration and data classification stay with the customer, and their assurance reports formalise the same split as CUECs. The Institute of Internal Auditors' 2020 Three Lines Model describes where the report sits: it is the vendor's third line reporting to your first line, and it does not substitute for either your management of the risk or your own independent assurance over how you use the service.

Failure scenarios

• The unread list. No CUEC has an owner; the vendor's opinion technically covers nothing about your tenant, and the first evidence of this is an incident.
• The stale period. The report covers a year that ended eight months ago and a major platform change has since shipped. The opinion describes a system that no longer exists.
• Carve-out blindness. The vendor's own hosting provider is excluded; the outage that hits you originates there and nobody assessed it.
• Attestation theatre. CUECs are "confirmed" annually in a spreadsheet by the person who would have to fix them, with no system evidence.
• Scope mismatch. The report covers security only, and you depended on it for availability or confidentiality, which were never in scope.

Trade-offs

The honest position is that the full treatment does not scale past a few dozen vendors. Triage by what the vendor holds, because a control programme spread evenly across 400 suppliers is thinner everywhere than it needs to be anywhere.

When not to use it

For a low-consequence vendor — a diagramming tool with no customer data, a status page — the CUEC programme is cost with no risk reduction. Record that the report was reviewed, note the two settings that matter, and move on. Reserve the full treatment for identity providers, payment processors, data processors and anything whose failure would appear in your own incident report. The lighter alternative wins whenever the work of tracking the control exceeds the loss the control prevents.

Interview question

Q: Your largest SaaS vendor's SOC 2 Type II report is unqualified and its period ended five months ago. Your CISO wants the vendor risk closed. What do you say, and what would you build?

What a strong answer covers: the report is about the vendor's platform for a past period, not your tenant today · the CUECs are your controls and need owners and automated tests · carve-out versus inclusive determines how much of the supply chain is untested · the exceptions and scope statement carry more signal than the opinion · the bridge letter is an assertion, not evidence · and the proportionality call: this treatment for the few vendors that matter, a light touch for the rest.

Quick check

Quiz: A vendor report lists 22 complementary user entity controls and your organisation operates none of them. What is the status of the vendor's clean opinion for you? — It stands for the vendor and does not extend to your instance; the auditor's conclusion assumed controls you are not running.

Flashcard: Where in a SOC 2 report does your own work get assigned to you? — In the complementary user entity controls: 10 to 30 controls the auditor assumed the customer operates, which is where most SaaS exposures actually occur.