SOC 2 Complementary User Entity Controls Explained
Complementary user entity controls, or CUECs, are the controls a service provider assumes its customers will operate for the provider’s own controls to work. They appear in a dedicated section of a SOC 2 report, they are the customer’s responsibility, and the provider’s auditor never tests them. If you receive a supplier’s SOC 2 report and ignore its CUEC list, you have accepted a set of obligations without reading them.
This matters in both directions. If you buy software, CUECs are a list of work assigned to you. If you are preparing your own SOC 2 report, your CUECs are how you tell customers where your responsibility stops.
What are complementary user entity controls in a SOC 2 report?
Complementary user entity controls are controls that the service organisation has assumed its customers will implement, and which are necessary for the service organisation to meet its own trust services criteria.
An example makes the idea concrete. A SaaS provider’s SOC 2 report may state that logical access to the platform is restricted to authorised users. The provider controls the authentication mechanism, the session handling and the audit logging. The provider does not control who you decide to give an account to, or whether you remove that account when the person leaves. So the report carries a complementary user entity control saying the customer is responsible for requesting, approving and removing user access in a timely manner.
Both halves are needed for the control objective to hold. Only one half sits inside the audit opinion.
Where do you find the CUECs in a SOC 2 report?
Complementary user entity controls appear in Section 3 of a SOC 2 report, the section written by management that describes the system. They usually sit near the end of that description, under a heading such as complementary user entity controls or user control considerations.
A SOC 2 report has four sections, and knowing the layout makes the CUECs easy to locate:
- Section 1, the auditor’s opinion. Whether the description is fair and the controls operated effectively.
- Section 2, management’s assertion. The provider’s own statement about the system.
- Section 3, the system description. How the service works, the controls in place, and the complementary user entity controls.
- Section 4, tests of controls and results. What the auditor tested and any exceptions found.
CUECs are typically presented as a numbered list of between five and twenty-five statements. If a report has none at all, that is worth a question rather than a relief, because almost every service has some customer-side dependency. Reviewing a supplier’s report properly is covered in how to vet a supplier’s SOC 2 report.
What do complementary user entity controls usually require?
Most complementary user entity controls fall into a small number of recurring themes, and the same themes appear across almost every SaaS provider’s SOC 2 report.
| Theme | What the CUEC typically asks of you | What it looks like in practice |
|---|---|---|
| User access | Request, approve and revoke accounts promptly | A leaver is deactivated the day they finish |
| Authentication | Enforce multi-factor authentication and password policy | MFA turned on for every user, not just admins |
| Access review | Review who has access periodically | A documented quarterly or half-yearly review |
| Configuration | Configure the service securely for your use | Sharing settings, retention and IP restrictions set deliberately |
| Data accuracy | Check the completeness of data you submit | Reconciling what you uploaded against what processed |
| Incident reporting | Report suspected issues to the provider promptly | A named contact and a route to raise it |
| Endpoint security | Secure the devices that access the service | Managed, patched laptops with disk encryption |
Read the actual wording rather than assuming the theme. CUECs vary in how demanding they are, and the difference between reviewing access periodically and reviewing access quarterly with documented evidence is the difference between a task and a control.
What happens if you ignore the CUECs in a supplier’s SOC 2 report?
Ignoring a supplier’s complementary user entity controls leaves a gap that belongs to you, not the supplier. A clean SOC 2 opinion does not transfer those controls across.
Three consequences follow, in roughly the order businesses encounter them:
- A control gap you believe is covered. You record the supplier’s SOC 2 report as assurance over access control, while nobody in your business removes leavers from the platform. The assurance covers the provider’s mechanism, not your use of it.
- A finding in your own audit. If you are pursuing ISO 27001 or SOC 2, an auditor who sees you relying on a supplier report will ask how you addressed the CUECs in it. Having no answer is a finding about your supplier management.
- An incident with your name on it. If a former employee’s account is still live and is used to extract customer data, the cause is your access removal process, regardless of how well the provider’s platform is built.
The same logic runs through the SaaS shared responsibility model. CUECs are simply the shared responsibility model written down and signed off by an auditor.
How do CUECs differ from complementary subservice organisation controls?
Complementary user entity controls are assigned to the provider’s customers. Complementary subservice organisation controls, or CSOCs, are assigned to the provider’s own suppliers. They sit in the same part of the report and are easy to confuse.
If a SaaS provider runs on a major cloud platform and carves that platform out of its SOC 2 scope, the report will describe controls it expects that cloud provider to operate, such as physical security of data centres. Those are complementary subservice organisation controls. The controls the SaaS provider expects you to operate, such as removing your leavers, are complementary user entity controls.
The practical difference for a reader is what to do next. For CSOCs, the question is whether the subservice organisation has its own report covering those controls. For CUECs, the question is whether you are actually performing them. Carve-outs and the inclusive method are covered in SOC 2 subservice organisations.
What should you do with a supplier’s CUEC list?
Treat a supplier’s complementary user entity controls as a short work plan: extract them, assign each one to a person, and record how each is performed.
- Extract them into your own register. Copy the CUECs out of the report into your supplier record, so they survive the report expiring.
- Assign an owner to each. Access removal usually belongs with whoever runs onboarding and offboarding. Configuration decisions usually belong with the system administrator.
- Map each to a control you already have. Most CUECs are covered by an existing process. The work is recording the link, not inventing new controls.
- Flag the ones you do not meet. If a CUEC requires quarterly access reviews and you have never run one, that is a gap to treat as a risk rather than a line to tick.
- Recheck at renewal. Providers change their CUECs between reports. Compare the new list against the one you recorded last year.
For organisations with many suppliers, this is the point where supplier review becomes a repeatable process rather than a yearly scramble. Where a report has lapsed between periods, a bridge letter covers the gap, though it does not change the CUECs themselves.
How do you write CUECs for your own SOC 2 report?
Write complementary user entity controls that are specific, limited to things your customers genuinely control, and consistent with how your product actually works.
Good CUECs share three qualities. They are testable, so a customer can tell whether they are doing it. They are within the customer’s power, which rules out anything your platform does not expose as a setting. And they match the trust services criteria your report covers, so each one supports a stated criterion rather than appearing on its own.
The failure mode in the other direction is a CUEC list written as a liability shield: twenty-five broad statements pushing responsibility to the customer for things your platform ought to handle. Sophisticated buyers read that list, and an auditor may question whether your controls meet the criteria if the customer is doing the heavy lifting. Scope decisions and criteria selection are covered in SOC 2 scope and the trust services criteria.
Do CUECs change anything under Australian privacy law?
Australian Privacy Principle 11 requires an entity to take reasonable steps to protect the personal information it holds, and that obligation stays with the entity when it uses a third-party service. Outsourcing the processing does not outsource the accountability.
That makes the CUEC list directly relevant to Australian businesses. If a supplier’s report says the customer is responsible for removing user access, and you do not remove it, then the reasonable steps you are required to take under APP 11 have a hole in them that is documented in writing by your supplier’s own auditor. The OAIC’s guidance on APP 11 sets out what reasonable steps involve, and our guide to the Australian Privacy Principles covers the broader obligations.
Common questions
What are complementary user entity controls (CUECs)?
Complementary user entity controls are controls a service organisation assumes its customers will perform so that the service organisation’s own controls achieve their objectives. They are listed in the system description of a SOC 2 report, they remain the customer’s responsibility, and the service auditor does not test them. Common examples include removing user access for leavers and enforcing multi-factor authentication on your own accounts.
Who is assumed to implement complementary user entity controls?
The user entity, which means the customer of the service organisation. If your business subscribes to a SaaS platform and reads that platform’s SOC 2 report, your business is the user entity and the CUECs are assigned to you. Within your organisation, the controls usually land with whoever manages user accounts, whoever administers the platform’s settings, and whoever runs periodic access reviews.
What do complementary user entity controls require?
They require the customer to operate specific, named controls on its side of the service. Most commonly that means managing user accounts and removing them promptly, enforcing authentication standards, reviewing access periodically, configuring the service securely, checking the accuracy of data submitted, and reporting suspected security issues to the provider. The exact wording differs by provider, so the report itself is the authority.
Do complementary user entity controls appear in SOC 1 reports as well as SOC 2?
Yes. SOC 1 reports cover controls relevant to financial reporting and routinely include complementary user entity controls, often around data submission accuracy and authorisation of transactions. The concept is the same in both report types: controls the service organisation assumed the customer would run. The difference is subject matter, which is explained in SOC 1 versus SOC 2 versus SOC 3.
What are some examples of complementary user entity controls?
Typical examples include: removing access for terminated employees within a defined period; enforcing multi-factor authentication for all users; reviewing the list of users with administrative privileges at least quarterly; configuring data retention and sharing settings appropriately; validating the completeness and accuracy of data transmitted to the service; and notifying the provider promptly of suspected unauthorised access.
Reading the report properly
A SOC 2 report is not a certificate, and the CUEC section is where that becomes obvious. The report tells you what the provider does and what it expects you to do. Both halves have to hold for the assurance to mean anything, and only one half has been audited.
Siege Cyber helps Australian organisations prepare for SOC 2 and assess the reports their suppliers provide. See the SOC 2 service, read more about SOC 2 in Australia, or get in touch. Background on the SOC framework itself is published by the AICPA.