Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →The section of a SOC 2 report that assigns work to the reader. What CUECs are, how they get written, and what it means that no auditor tests whether you did them.
Complementary user entity controls, or CUECs, are controls that a service organization assumes its customers are operating. They exist because a SOC 2 report can only cover the part of the system the service organization runs, and some of the trust services criteria are only achieved if the customer does their half. CUECs appear in the system description section of the report, and often again next to the criteria they relate to. The service auditor does not test them. Nobody checks whether you implemented them. If a CUEC says customers are responsible for configuring multi-factor authentication for their own users and you did not, the vendor's clean SOC 2 report is still clean and the exposure is entirely yours. For a buyer, the CUEC list is the most actionable page in the report and the one most often skipped.
A complementary user entity control is a control that the service organization assumed, when it designed its service, would be implemented by the customer, and which is necessary for one or more of the trust services criteria to be achieved. In plainer terms: it is a piece of the security model that only works if the customer does their part, and the vendor has written down which parts those are.
The term contains its own definition if you read it slowly. Complementary means it sits alongside the vendor's own controls rather than replacing them. User entity is the report's term for the customer, the organization using the service. Control means a specific, testable action rather than a general obligation to be careful.
They are a disclosure, not a contract. A CUEC does not create a legal obligation on the customer by itself; the contract does that. What the CUEC does is tell any reader of the report exactly which assumptions the vendor's control design rests on, so the reader can decide whether those assumptions hold in their own environment.
The practical significance is asymmetric. For the service organization, CUECs are a small drafting exercise that clarifies the boundary of the report. For the customer, they are a list of things that will be nobody's job unless someone at the customer picks them up, and the assurance in the report is void in exactly those places.
A SOC 2 examination is scoped to a system: a defined set of infrastructure, software, people, procedures and data that delivers a defined service. The service auditor forms an opinion on whether controls within that system were suitably designed, and for a Type II report whether they operated effectively over the period. The customer's own environment is outside that system, so no opinion can extend to it.
But security models are rarely clean at the boundary. A multi-tenant application can enforce that only authenticated users see a tenant's data; it usually cannot enforce that the tenant deprovisions employees who leave. It can offer single sign-on, session timeouts and role-based permissions; it cannot make a customer use them. It can log administrative actions and expose them; it cannot make anyone read the log.
Without CUECs, a reader could reasonably conclude that the criteria are met end to end. The disclosure exists to prevent exactly that misreading. It is the report saying: here are the specific points where our design depends on you, and we have formed no view on whether you did it.
There is a second, less-discussed reason. Writing CUECs forces the service organization to be explicit about its own shared responsibility model, which is a useful discipline. A vendor that cannot articulate its CUECs usually has not thought carefully about where its system ends, and that vagueness tends to show up in other places, including incident response and data deletion.
A SOC 2 report is conventionally organized into numbered sections. Section ordering varies a little between audit firms, but the standard shape is: the independent service auditor's report containing the opinion, management's written assertion, the description of the system prepared by management, the section pairing the applicable trust services criteria with the controls and, in a Type II, the auditor's tests and results, and finally an unaudited other-information section where management can add material the auditor takes no responsibility for.
CUECs live in the system description, usually near the end, under a heading such as "complementary user entity controls" or "user entity responsibilities". This placement matters because the description is management's document. The auditor evaluates whether the description is presented in accordance with the description criteria and is fairly presented, but the CUEC list is written by the vendor.
Better reports also reproduce each CUEC next to the criteria it supports in the controls and testing section, so a reader working through a specific criterion sees the dependency at the point of use. This is not universal, and its absence is not a defect, but it makes the report considerably easier to act on.
Occasionally a vendor puts an expanded shared responsibility matrix in the unaudited other-information section. That material is useful but read it knowing what the section is: content the auditor has explicitly not examined. If something in there contradicts the system description, the system description is the part that carries weight.
A usable CUEC is specific about the actor, the action, and the object. "User entities are responsible for removing access for their own personnel within one business day of termination" names who, what, and by when. Someone at the customer can turn that into a checklist item and later evidence it.
Filler CUECs are recognisable because they cannot be actioned or evidenced. "User entities are responsible for maintaining appropriate security over their environment" is a sentence, not a control. "User entities are responsible for complying with the terms of the agreement" is a restatement of the contract. Lists that consist mostly of these are a signal that the vendor treated the section as a liability disclaimer rather than a design disclosure.
A second signal to watch for is a CUEC that describes something the vendor actually controls. If a report says user entities are responsible for ensuring data is encrypted in transit, but the platform terminates TLS and offers no plaintext option, the CUEC is misassigning a control the vendor operates. Occasionally it is deliberate boundary-blurring. More often it is a template copied from another report without editing.
The third and most consequential signal is volume. A report with sixty CUECs is not being thorough; it is pushing the security model onto its customers. Five to twenty is normal for a SaaS product. Beyond that, read the list carefully, because the vendor is describing a service that assumes an unusual amount of customer competence, and the assurance you are actually buying is smaller than the page count suggests.
If you are the service organization, the CUEC list is drafted during readiness and finalised with the auditor while the system description is being written. The wrong way to produce it is to copy a list from another company's report. The right way takes about half a day.
Start from the criteria rather than from a template. Walk the applicable trust services criteria and, for each, ask whether the criterion is fully achieved by controls inside your system boundary. Most are. For the ones that are not, ask precisely what the customer has to do for the criterion to hold. That question produces a specific sentence, because you are describing a real dependency you already know about.
The dependencies cluster in predictable places. Identity and access is the largest: user provisioning and deprovisioning within the customer's own tenant, role assignment, credential hygiene, and whether they enable the multi-factor or single sign-on options you offer. Configuration is the second: security-relevant settings you expose with defaults, retention and deletion settings, IP allow-lists, integration and API key management. The third is the customer's own monitoring: reviewing the audit logs you make available, and acting on the notifications you send. The fourth is data handling: what customers put into fields not designed for sensitive data, and any decision about data residency you leave to them.
Write each one with an actor, an action, and a frequency or timeframe where one applies. Then apply two tests. Test one: could a customer evidence that they did this? If not, rewrite it. Test two: does your platform actually let them do it? A CUEC requiring quarterly access review is unfair and unhelpful if your product has no way to export a user list.
Reconcile the finished list against your contracts and your documentation. If a CUEC states an obligation your master agreement does not mention, either add it to the agreement at renewal or soften the CUEC. And publish the same list in your product documentation, because the number of customers who read your SOC 2 report is small and the number who read your onboarding guide is large. The CUEC list is only protective if customers actually see it.
This is the part that surprises people, so it is worth stating flatly. The service auditor performs no procedures on complementary user entity controls. They do not select customers. They do not sample. They do not ask whether any user entity implemented anything. There is no testing column, no result, and no exception rate for CUECs, and the opinion does not extend to them.
What the auditor does do is evaluate the system description as a whole for fair presentation against the description criteria, and consider the CUECs when evaluating whether the vendor's controls, taken with the assumed customer controls, are suitably designed to achieve the criteria. A CUEC that is obviously unreasonable or that misdescribes the service is a description problem the auditor may push back on. But an untested assumption remains an untested assumption.
The consequence for a buyer is precise: a clean, unqualified SOC 2 Type II opinion tells you the vendor's controls operated effectively over the period, given that customers did the things in the CUEC list. It does not tell you that you did those things, and it cannot.
This is also why the CUEC list is worthless as a defence for the customer. Nobody is going to send you a finding because you ignored one. The failure shows up later, in your own SOC 2 or ISO 27001 audit, in a breach, or in a customer questionnaire you cannot answer.
Nothing happens immediately, which is the whole problem. There is no alert, no notification and no consequence at the point of failure. The controls simply are not running, and everyone involved believes they are because the vendor holds a SOC 2 report.
The most common concrete outcome is orphaned accounts. A CUEC assigns deprovisioning of the customer's own users to the customer. The customer offboards people from their identity provider but the vendor platform was never wired into single sign-on, so the accounts persist. Eighteen months later a departed employee's credentials still work against a system holding production data. The vendor's report is clean. The vendor did nothing wrong. The exposure is entirely the customer's.
The second is unreviewed privilege. Most platforms have a small number of tenant administrators with the ability to export everything or change security settings. Where the CUEC assigns periodic review of those administrators to the customer and nobody does it, administrator counts only grow. This is one of the first things an auditor looks at during your own SOC 2 or ISO 27001 audit, and finding a critical vendor with eleven administrators and no review record is a finding against you.
The third is silent misconfiguration. Where a security setting ships permissive by default and the CUEC says customers are responsible for configuring it, the default is what you are running. Public sharing links, long-lived API tokens, retention periods longer than your own policy allows, and disabled audit logging all live in this category.
The fourth appears during an incident. A CUEC saying user entities are responsible for monitoring notifications the service organization sends is dangerous precisely because it is easy to comply with in theory. If the vendor's security notifications route to a shared inbox nobody owns, the vendor has met its obligation to notify and you have not met yours to act, and the gap is invisible until it costs you.
The fifth is a contractual and regulatory mismatch. Where the vendor makes deletion available on request but assigns the request to the customer, and your privacy commitments promise deletion within thirty days, the obligation you signed up to is only met if someone at your end actually raises those requests. This is where CUECs stop being a security matter and become a compliance one.
CUECs have a mirror image elsewhere in the report: complementary subservice organization controls, or CSOCs. Where a CUEC pushes a dependency down to the customer, a CSOC pushes one up to a vendor the service organization itself relies on and has carved out of its report.
Under the carve-out method, the service organization excludes a subservice organization's controls from the scope of its own examination, describes the services that subservice organization provides, and lists the controls it assumes that subservice organization is operating. Those are CSOCs, and like CUECs they are not tested by the service auditor. Under the inclusive method, the subservice organization's relevant controls are brought inside the examination and are tested, and no CSOCs are needed for those services. We cover the choice in detail in the guide to subservice organizations in SOC 2.
For a reader, the two lists together define the actual shape of the assurance you are getting. The vendor's tested controls sit in the middle. Above them are assumptions about their providers. Below them are assumptions about you. A report where all three are clearly stated is more useful than one with a longer testing section and no boundaries, because you can see what you are relying on.
One structural point worth understanding: a carve-out is a chain, and the chain has to be walked. If the vendor carves out its cloud provider, the vendor is obliged to monitor that provider, typically by obtaining and reviewing the provider's own SOC 2 report. That provider's report will in turn have its own CUEC list, and the controls in it are ones the vendor is supposed to be operating. When you assess a vendor, asking whether they read their cloud provider's CUECs is a sharp question, and the answer is informative regardless of which way it goes.
Most vendor reviews consist of confirming a SOC 2 report exists, checking the period and the opinion, skimming the exceptions, and filing it. That takes twenty minutes and captures almost none of the value. Adding the following forty minutes changes the outcome.
One: locate the CUEC list in the system description and copy it out verbatim into your vendor file. Do not summarize it. The wording is what you will be held to.
Two: for each CUEC, assign a named owner in your organization. Not a team. If no name can be attached, that CUEC is not being performed, and you have found the gap in the cheapest possible way.
Three: for each, record the current state in one line: performed and evidenced, performed but not evidenced, not performed, or not applicable to how we use this service. The middle two categories are where the work is.
Four: for anything not performed, decide. Implement it, accept the risk explicitly and record the acceptance with a named acceptor, or compensate for it another way. All three are legitimate. An undecided item is not.
Five: put the recurring ones into your compliance calendar with the right frequency. Access reviews of your tenant administrators, configuration checks after major platform updates, and reviewing whichever logs the vendor exposes are the three that recur most often.
Six: re-read the list when the vendor issues a new report. CUECs change when products change. A new integration, a new permission model or a new data residency option usually adds one, and it will not be announced anywhere else.
Do this properly for your top ten vendors by data sensitivity and you have both closed a real risk and produced exactly the evidence your own auditor wants when they test third-party risk management. Our vendor risk calculator is a reasonable way to decide which vendors are worth the forty minutes.
Across SaaS reports the same dependencies recur, because the same architectural boundaries recur. Knowing the standard set lets you spot both the omissions and the unusual additions quickly.
Identity and access: creating, modifying and removing users within your own tenant; assigning roles on a least-privilege basis; periodically reviewing who has access and at what level; protecting and rotating credentials, API keys and service account tokens; enabling multi-factor authentication or single sign-on where the platform offers it.
Configuration: setting security-relevant options rather than leaving defaults; managing sharing and public link settings; configuring session timeouts; setting data retention in line with your own policy; maintaining IP allow-lists where offered.
Data: deciding what data classes are appropriate to put into the service; not placing regulated or sensitive data in free-text fields not designed for it; raising deletion and export requests when your own retention schedule or a data subject request requires it.
Monitoring and response: reviewing the audit logs the vendor exposes; routing vendor security and status notifications to a monitored destination with a named owner; reporting suspected incidents to the vendor through the stated channel within the stated timeframe.
Integration: securing anything you connect to the service; managing webhook endpoints and the secrets that protect them; controlling which third-party applications you authorise into your tenant.
Availability, where the availability criteria are in scope: understanding the recovery objectives the vendor commits to and maintaining your own contingency for the gap, including retaining your own copy of data where continuity requires it.
Copied wholesale from another report, so the list describes a service the vendor does not operate. Look for references to features the product does not have; it is a reliable tell.
Written as a liability disclaimer. Long, vague and defensive, with several items amounting to "the customer is responsible for security". A reader learns nothing and the section does not do its job.
Assigning to the customer something the vendor controls. Either boundary-blurring or careless editing, and both are worth raising with the vendor.
Requiring something the platform makes impossible. A CUEC demanding periodic access review from a product with no way to list users is unactionable.
Never updated. A CUEC list identical across three years of reports from a product that shipped significant features in that time has not been reviewed. Comparing consecutive reports takes two minutes and is one of the more informative diffs available to a buyer.
Buried and unpublished. If the list exists only inside a report distributed under NDA to procurement, the engineers who administer the tenant have never seen it. Vendors who put the same content in their public documentation get far better outcomes, and buyers should ask for that version.
Ignored by the buyer, which is by far the commonest failure and the only one entirely within your control.
| Typical CUEC | What you actually have to do | What goes wrong if nobody owns it |
|---|---|---|
| Provision and deprovision your own users | Wire the platform into your identity provider, or add it to a manual offboarding checklist with a stated deadline, and keep the completion record. | Departed employees keep working credentials against production data. This is the most common finding in your own audit, not the vendor's. |
| Review tenant administrators periodically | Export the administrator list quarterly, have the system owner confirm each one, remove the rest, and keep the signed export. | Administrator counts only grow. An auditor sampling a critical vendor finds eleven admins and no review record. |
| Enable MFA or SSO where offered | Turn it on tenant-wide, enforce rather than encourage, and confirm no local accounts bypass it. | A single reused password on an account outside SSO becomes the whole tenant's exposure. The vendor offered the control; you declined it. |
| Configure security-relevant settings | Walk the settings screens at onboarding, record the chosen values as a baseline, and re-check after major platform releases. | You inherit permissive defaults: public sharing on, audit logging off, retention longer than your own policy permits. |
| Manage API keys and integration secrets | Inventory every key, assign each an owner and a purpose, store them in a secret manager, and rotate on a schedule and on staff departure. | Long-lived tokens in personal accounts and repositories survive offboarding and sit outside every access review you run. |
| Review the audit logs the vendor exposes | Decide what you would look for, ship the logs to where you already look, and record who reviews them and when. | Detection you assumed you had does not exist. The evidence of an incident is present in a log nobody opened. |
| Monitor vendor security notifications | Route them to a monitored channel with a named owner and a response expectation, not a shared inbox. | The vendor discharged its notification duty and you did not act. Common in the first hours of a supply chain incident. |
| Control what data you put into the service | Classify the service, write down which data classes are permitted, and tell the people who use it daily. | Regulated data lands in a system that was never assessed for it, breaking your own classification policy and possibly your DPA. |
| Raise deletion and retention requests | Map the vendor's retention behaviour against your own schedule and put the request in your privacy runbook. | Personal data persists past the period you promised customers, which is a privacy exposure rather than a security one. |
| Report suspected incidents to the vendor | Record the vendor's reporting channel and required timeframe in your incident response plan, per critical vendor. | You lose hours at the start of an incident finding out who to tell and how, and may miss a contractual notification window. |
They are controls the service organization assumed its customers would implement, and which are necessary for one or more trust services criteria to be achieved. They document the points where the vendor's security design depends on the customer doing something, and they appear in the system description section of the report.
No. The service auditor performs no procedures on CUECs and forms no opinion on them. There is no testing, no sampling of customers and no exception rate. The auditor considers them when evaluating whether the vendor's controls are suitably designed, but whether any customer implemented them is outside the scope of the examination.
Nothing at the moment you ignore it, which is why it is dangerous. The vendor's report stays clean and the risk moves entirely to you. It usually surfaces later as orphaned accounts, unreviewed tenant administrators, permissive default settings, or a security notification that nobody acted on, and it is found by your own auditor or by an incident rather than by the vendor.
Not by themselves. A CUEC is a disclosure in a report, not a contract term. Legal obligations come from the agreement between the parties. That said, CUECs frequently mirror clauses in the master agreement or the acceptable use policy, and a vendor defending itself after an incident will point at both, so the practical distinction is smaller than it sounds.
Five to twenty is typical for a SaaS product. A very short list can mean the vendor genuinely controls most of the model, or that they did not think about the boundary. A very long list, beyond twenty or thirty, usually means the security model leans heavily on customer competence, and the assurance you are buying is narrower than the report length suggests.
They point in opposite directions. A CUEC is a control the service organization assumes its customer operates. A complementary subservice organization control, or CSOC, is a control it assumes a provider it has carved out of the report operates, such as a cloud hosting provider. Neither is tested by the service auditor, and together they define the real boundary of the assurance.
Yes, if your service genuinely depends on customer-side controls, which almost every multi-tenant product does. Derive them from the criteria rather than copying another report, make each one specific enough that a customer could evidence it, confirm your product actually allows what you are asking, reconcile the list against your contracts, and publish the same content in your customer documentation so people other than procurement see it.
In the description of the system, usually towards the end, under a heading such as complementary user entity controls or user entity responsibilities. Some reports also repeat each one beside the criterion it supports in the controls and testing section. If a report contains no such list at all, that is worth asking the vendor about directly.
traztech Workspace has all 61 criteria of SOC 2 written in plain English, with what the standard asks for, what to do about it, and somewhere to attach the proof. You answer them, it scores you, and nothing is locked behind an upgrade.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We review the reports your critical vendors send you, extract the CUECs, assign them owners in your organization, and turn the recurring ones into calendar items your auditor can see running.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.