Complementary user entity controls in SOC 2 and ISAE 3402: your share of the work

When you receive a SOC 2 or ISAE 3402 report from a vendor, you typically read the opinion, browse the test results and check for reported exceptions. There is another section that almost nobody reads and that is actually about you: the complementary user entity controls, or CUECs. These are the controls the service organization assumes you, as its customer, have implemented yourself. The report says so explicitly: the control objectives or criteria are only achieved if those assumptions hold. Ignore the list and you are leaning on assurance that is not there.

What exactly are CUECs?

A service organization can never control the entire process of its customers. A SaaS vendor manages the platform, the infrastructure and the changes to it, but has no idea who joins or leaves your organization. The vendor therefore cannot possibly guarantee that only authorized people from your organization have access. That piece of control sits with you.

That is why the service organization describes in the system description of the report which controls it assumes at the user entities. In a SOC 2 report, the CUECs sit in the system description (Section III), often in a separate table, sometimes linked to specific criteria. An ISAE 3402 report works the same way, linked to the control objectives. The service organization's auditor does not test these CUECs. They fall outside the opinion. They are assumptions in the design of the control framework, not tested reality.

Typical examples

The list differs per service, but some CUECs appear in almost every report. Managing your own user accounts: the customer decides who gets access, in which role, and revokes access promptly when people leave. Configuring the security options the customer chooses itself, such as enforcing MFA or SSO and password settings. The accuracy and completeness of data the customer submits. Reviewing reports or output the service produces, such as checking processing summaries. And keeping contact persons up to date, so that incident notifications from the vendor reach the right people.

Pay attention to the wording as you read. A good CUEC is concrete: "the user entity reviews the list of active accounts monthly". A vague CUEC ("the user entity maintains appropriate security measures") is a sign that the service organization is shifting responsibility, and you are entitled to raise that in your vendor assessment.

Why this matters for your own audit

CUECs become tangible the moment your own auditor shows up. If your ISO 27001 certification, DigiD assessment or financial statement audit relies on a vendor's SOC 2 or ISAE 3402, the auditor's standard question is: has the organization identified and covered the CUECs? After all, the vendor's report itself states that the criteria are only achieved in combination with operating user entity controls. If you cannot show that mapping, the report is only half the story for your file.

In third-party risk management processes, this is where we often see things go wrong. Procurement or security ticks the box that the vendor has a SOC 2 report, archives the PDF and moves on. Nobody has verified that the assumed controls exist on their own side. The classic example: an organization with a perfectly fine SOC 2 report from its payroll provider, while accounts of departed employees remain active in that payroll system for months. Exactly the risk the CUEC was meant to cover.

How to process CUECs in practice

A workable approach consists of a few fixed steps. During the annual report round, collect the SOC 2 and ISAE 3402 reports of your key vendors and extract the CUEC list from each report. Map every CUEC to an existing internal control, or establish that it is missing. Assign an owner per CUEC, because "the organization" is not an owner. Record where the evidence of operation can be found, such as the periodic account review or the MFA configuration. And repeat this with every new report: CUECs change when the vendor's service or control framework changes, and it is precisely those changes you miss if the mapping was a one-off exercise.

If you work with a carve-out report, also look at the complementary subservice organization controls (CSOCs). Those are the controls assumed at subservice organizations, such as the cloud platform underneath the service. They need the same treatment, except the ball is not in your court there: the question is whether the service organization monitors its subservice providers.

For service organizations: write CUECs that hold up

If you are starting a SOC 2 or ISAE 3402 engagement yourself, give the CUEC list in your system description real attention. Every CUEC is an assumption that carries the design of your control framework, and reviewing customers and their auditors read that list more critically than you might think. Keep the list short and realistic. Only include controls that genuinely belong with the customer, word them concretely and link them where possible to the criteria or control objectives they support. An inflated CUEC list that pushes responsibilities onto the customer may feel safe, but it raises questions in reviews and makes your report less usable for your customers. And that report is ultimately a sales document.

The lesson

A SOC 2 or ISAE 3402 report is not a free pass but a division of labour. The service organization shows what it controls and describes what it expects from you. So treat the CUEC list as a mandatory part of every vendor assessment: extract, map, assign an owner, arrange evidence, repeat annually. It takes half a day per vendor at most, and it is the difference between a report in a drawer and demonstrable control over your supply chain.