Complementary controls
CUECs and CSOCs: writing the controls other people own.
Your system is designed on assumptions about what customers and vendors will do. The report states them as Complementary User Entity Controls (CUECs) and Complementary Subservice Organization Controls (CSOCs). Written well, they tell each party exactly what to operate. Written badly, they read as a way of shifting risk.
Back to SOC 2 services01 · Two lists
Two lists, two owners
Both describe controls outside your control that your controls depend on.
CUECs
Owned by your customers
- Controls the system's design assumes user entities operate
- Example: customers manage which of their staff hold accounts
- If customers skip them, some criteria may not be met for that customer
CSOCs
Owned by your carved-out vendors
- Controls the design assumes subservice organizations operate
- Example: the host restricts physical access to its sites
- Required only under the carve-out method
02 · Where they appear
Where each appears in the report
In the description, and referred to in the opinion.
Both lists sit in management's system description (Section 3), because the description criteria require them. The service auditor's opinion then refers to them: the opinion is conditional on customers and carved-out vendors operating the complementary controls the description lists. That is why a reader who ignores CUECs misreads the opinion.
Under the inclusive method the vendor's controls are tested inside your report, so no CSOCs are listed for that vendor.
03 · How to write them
How to write one that can be checked
Each statement should name who, does what, and why it matters.
- Tied to a criterion. Every complementary control should support a specific control or criterion in your report. If none, delete it.
- One action per statement. Split “manage users and protect data” into separate, testable actions.
- Observable. A customer or vendor could show evidence that it happens.
- Proportionate. Ask only what your design genuinely relies on, not general good practice.
- Plain language. Readable by a customer's IT lead without a glossary.
A practical method: walk through your control list and ask, for each control, “what must be true outside our walls for this to work?” If your access control relies on the customer telling you when a user leaves, that is a CUEC. If your backup control relies on the host's storage being durable, that is a CSOC. Anything that does not come out of this exercise probably does not belong on either list.
04 · Weak vs strong
Weak versus strong examples
Illustrative rewrites.
| Type | Weak | Strong |
|---|---|---|
| CUEC | “Customers are responsible for security.” | “Customers remove access for their users who leave their organization, using the admin console.” |
| CUEC | “Customers protect their data.” | “Customers enable single sign-on or multi-factor authentication for their users where the platform offers it.” |
| CUEC | “Customers review the system.” | “Customers review the user list for their account at least as often as their own access-review policy requires.” |
| CUEC | “Customers ensure data is accurate.” | “Customers check that files they upload are complete before submitting them for processing.” |
| CSOC | “The vendor maintains appropriate controls.” | “The hosting provider restricts physical access to data centres housing the system to authorized personnel.” |
| CSOC | “The vendor keeps systems available.” | “The hosting provider maintains power and cooling redundancy at facilities housing the system.” |
05 · Customers acting on CUECs
How a customer should act on CUECs
Treat the list as a to-do list, not small print.
- Extract every CUEC from the vendor's description into your vendor review record.
- Assign an owner on your side for each one.
- Confirm you operate it, or record why it does not apply to how you use the service.
- Fold relevant CUECs into your own control set, so your own audit tests them.
- Recheck on each new report; lists change when the vendor's system changes.
- A CUEC list that copies the vendor's whole security policy. Readers stop reading, and real dependencies get lost.
- CUECs that contradict the product. Asking customers to enforce MFA on a product that offers no MFA setting.
- CSOCs with no matching control in the vendor's report. If the vendor's report does not cover it, your assumption is unverified.
Sources: AICPA description criteria DC section 200 (complementary user entity controls and complementary subservice organization controls); AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization; AICPA attestation standards AT-C 205.
Questions about complementary controls
Can we have zero CUECs?
Rarely.
Almost every service relies on customers to manage their own users and credentials. A report with none may be fine, but a reader will ask why.
Does a longer CUEC list protect us?
No. It weakens the report.
Over-long lists read as pushing responsibility onto customers and make the opinion harder to rely on. Keep each item tied to a real design dependency.
Who checks that customers actually perform CUECs?
The customer, and the customer's own auditor.
Your CPA firm does not test your customers. Each customer evidences its CUECs in its own control environment.
Should CSOCs copy the vendor's own control wording?
Close is helpful; identical is not required.
Write what your system assumes, then confirm a matching control exists in the vendor's report. Keep the mapping with your vendor review.
Complementary controls a reader can act on.
We draft your CUECs and CSOCs against your actual design and map each CSOC to the vendor report that supports it.