Complementary user entity controls (CUECs) are controls a SOC 2 report assumes your customers operate themselves, such as managing who in their organization has access to your product, for the criteria to be met. Subservice organizations are vendors you rely on to deliver the service, such as a cloud hosting provider. A report treats them in one of two ways: the carve-out method leaves the vendor's controls out of scope and lists the complementary subservice organization controls (CSOCs) you expect the vendor to run, while the inclusive method brings the vendor's relevant controls into the examination. Carve-out is by far the more common. If the complementary controls do not operate, the auditor's opinion does not cover the gap.
A SOC 2 report describes one company's controls, but no service runs on one company's controls alone. Your customers manage their own users, and your infrastructure runs on someone else's data centres. The report deals with both through complementary controls, and they are the part of a SOC 2 that readers most often skip.
What complementary user entity controls are
When the design of your controls assumes the customer does something, the report says so. Those assumptions are the complementary user entity controls. Typical examples for a SaaS product:
- Customers grant and remove access for their own users, and review that access.
- Customers enforce multi-factor authentication through their identity provider when they sign in with single sign-on.
- Customers keep API keys and credentials issued to them secure, and rotate them.
- Customers configure settings they control, such as data retention or sharing, to fit their own requirements.
- Customers report suspected security incidents involving the service to you promptly.
The CUECs are listed in the description of the system, and the auditor's opinion is conditional on them: it says the controls achieved the criteria if the complementary user entity controls assumed in their design also operated effectively. The auditor does not test them, because they are the customer's controls.
Subservice organizations: carve-out or inclusive
A subservice organization is a vendor that performs part of the service your report covers, such as cloud hosting, a managed database or an outsourced support desk. The report has to say how it treats each one:
| Method | What is in scope | What the report contains | When it is used |
|---|---|---|---|
| Carve-out | Your controls only | A description of the vendor's services and the complementary subservice organization controls you assume it runs; the vendor's controls are not tested | The usual choice, and the only practical one for large providers such as public clouds |
| Inclusive | Your controls and the vendor's relevant controls | The vendor's controls described and tested, with a written assertion from the vendor's management | A closely tied vendor that agrees to take part, such as an affiliate or a dedicated managed service provider |
Complementary subservice organization controls (CSOCs) are to vendors what CUECs are to customers: the controls your design assumes the vendor operates, such as physical security of the data centre or the hardware patching underneath a managed service.
What carve-out means for you
Carving out a vendor does not make it someone else's problem. The common criteria still expect you to assess and monitor the vendors your service depends on, and your auditor will ask how you do it. In practice that means:
- Collecting each subservice organization's own SOC 2 report every year, along with a bridge letter when there is a gap.
- Reading the opinion and the exceptions, not just confirming the report exists.
- Taking the CUECs listed in your vendor's report and making sure you operate them, because to that vendor you are the user entity.
- Recording the review and any follow-up as evidence for the period.
Reading complementary controls as a customer
If you are relying on a vendor's SOC 2, the complementary controls are where the report hands work back to you. Find the CUEC list in the system description, assign each item to someone in your organization, and confirm it runs. Then look at the subservice organizations, decide which ones matter for your data, and ask for their reports too. The comparison of SOC 1, SOC 2 and SOC 3 covers which kind of report to ask each vendor for.
Writing good CUECs
A well-written CUEC is specific enough that a customer knows exactly what to do, and it exists because a criterion genuinely depends on it. A list that pushes ordinary vendor responsibilities onto customers reads as evasive to an experienced reviewer and invites questions. Keep the list short, tie each item to the criterion it supports, and make sure your product actually gives customers the means to do it, such as access reviews, MFA enforcement or audit logs they can read.