What you'll learn
- The difference between "Assumed in Design" CUECs (where the service organisation's controls depend on them) and "Additional Recommended" CUECs (risk mitigation, not a design dependency)
- Why year-end-only CUEC testing is the most common PCAOB and AFM finding on service organisation reliance
- How the "Risk if CUEC Not Implemented" column tells user auditors exactly what breaks
- How the ISAE 3402 template pack's CUEC register documents testing responsibilities with six pre-populated examples
An engagement quality reviewer pulls your ISAE 3402 file and asks one question: "When were the CUECs tested?" You check the working papers. All six complementary user entity controls were evaluated at year-end. None were tested for operating effectiveness during the period. The reviewer sends the file back.
Complementary user entity controls (CUECs) under ISAE 3402.9(b) are controls that the service organisation assumed user entities would implement. Testing them only at year-end (confirming they exist in December) misses the point: user auditors must evaluate whether CUECs operated throughout the period covered by the service organisation's report, not just whether they were in place at the reporting date.
What CUECs are and why they exist
A service organisation processes transactions on behalf of user entities. The service organisation designs controls to achieve its control objectives. But some of those controls assume that the user entity is doing something on its end.
ISAE 3402.9(b) requires the service organisation's system description to identify controls that the service organisation assumed would be implemented by user entities. These are CUECs. They are not controls the service organisation operates. They are controls the service organisation expects the user entity to operate, because without them, the service organisation's own controls cannot achieve their objectives fully.
Consider how this works in practice. A payroll processing bureau designs a variance review control that compares payroll output to input. That control works only if the input was authorised by the user entity before submission. If the user entity submits unauthorised payroll transactions, the variance review will process them accurately (the control "operates effectively") but the output is still wrong. The CUEC fills this gap: the user entity must authorise payroll transactions before submitting them to the service organisation.
ISAE 3402.16(a)(vii) requires CUECs to be disclosed in the system description. ISA 402 then places the responsibility on the user auditor to evaluate whether the CUECs actually operated at the user entity. The service auditor identifies them. The user auditor tests them.
Two types: assumed in design versus additional recommended
Not all CUECs carry the same weight. The CUEC register in the ISAE 3402 template pack distinguishes between two types, and the distinction changes how the user auditor approaches testing.
Assumed in Design means the service organisation's controls are designed to rely on this CUEC. If the CUEC does not operate, the control objective has a gap. The service organisation's control cannot compensate for the user entity's failure because the design assumes the user entity performs its part.
Personnel change notification is a clear example. The service organisation's quarterly access review can only detect stale user accounts if the user entity notifies the service organisation of leavers and joiners. If the user entity fails to notify, former employees retain access for up to three months (until the next quarterly review cycle catches the stale account). The access review control operates effectively on its own terms (it reviews the list it has), but the list is incomplete because the user entity did not provide the update. The CUEC is assumed in the design of the access review. Without it, the access management control objective has a gap.
Additional Recommended means the CUEC is a risk mitigation measure but is not a design assumption. The service organisation's controls can still achieve their objectives if this CUEC does not operate, but the user entity faces incremental risk.
Subservice organisation SOC report review is a typical example. Under the carve-out method, the service organisation excludes the cloud infrastructure provider's controls from its report. The CUEC recommends that user entities obtain and review the subservice organisation's own SOC 2 Type II report for the relevant period. If the user entity does not do this, the service organisation's report is still valid (it never claimed to cover the infrastructure controls). But the user entity now has a gap in its own assurance coverage. The CUEC fills that gap, though it was not assumed in the service organisation's control design.
In practice, Assumed in Design CUECs are non-negotiable for user auditors. If an Assumed in Design CUEC does not operate, the user auditor cannot fully rely on the service organisation's report for the affected control objective. Additional Recommended CUECs are important but do not create the same gap in the service auditor's report.
Why year-end testing misses the point
Remember that the service organisation's report covers a period, typically twelve months. CUECs are assumed to operate throughout that period. Testing them at year-end tells you they exist in December. It does not tell you they operated in March or in September.
This is the finding that generates the most review notes. Both PCAOB and AFM inspections consistently cite year-end-only CUEC testing as the top deficiency in user auditor reliance on service organisation reports. The pattern is the same every time: user auditors confirm at year-end that the CUECs are "in place" and conclude their evaluation. But "in place" is a design question. The user auditor needs to answer an operating effectiveness question: did this CUEC operate throughout the period covered by the Type II report?
Consider the payroll authorisation CUEC. At year-end, the user entity has an authorisation policy. The user auditor confirms the policy exists. But from January to September, the authorisation was performed by a single person with no segregation of duties. The policy was revised in October to require dual authorisation. Year-end testing sees the revised policy. Period-through testing sees the nine months of inadequate authorisation.
Year-end versus period-through testing maps directly to the same design-versus-operating-effectiveness distinction that applies to any control. A CUEC that exists at year-end has a design that is (presumably) effective. A CUEC that operated consistently from January to December has operating effectiveness that supports reliance on the service organisation's report for the full period.
The "risk if not implemented" column
Each CUEC in the register includes a column that explains, in plain language, what risk materialises at the user entity if the CUEC does not operate. This column is written for user auditors, not for the service organisation.
For personnel change notification (Assumed in Design): former employees retain ERP access for up to three months between quarterly review cycles. Unauthorised access during this window is undetected by the service organisation's access review.
For payroll authorisation (Assumed in Design): unauthorised payroll transactions are processed accurately by the service organisation. The variance review control operates correctly on fraudulent input. The output is technically accurate but substantively wrong.
For journal entry dual authorisation (Assumed in Design): unauthorised or fictitious manual journal entries are submitted to the service organisation and processed through the Financial Controller's review control before being posted. The service organisation's control checks the entry against supporting documentation that the user entity provided. If the user entity did not independently authorise the entry, the service organisation's control cannot detect the unauthorised origination.
For bank balance verification (Additional Recommended): user entities rely solely on the service organisation's reconciliation without independent verification. If the service organisation's reconciliation has a gap (as demonstrated by the bank reconciliation finding in the gap analysis), the user entity has no independent check.
These risk descriptions transform the CUEC from an abstract compliance item into a practical risk assessment tool. A user auditor reading "former employees retain ERP access for up to three months" understands the stakes immediately. The description also makes it clear why period-through testing matters: the risk exists every day the CUEC does not operate, not just at year-end.
User entity testing responsibility: what the user auditor evaluates
Each CUEC includes a column documenting what the user auditor needs to evaluate. This is not a vague instruction ("consider whether the CUEC operates"). It is a specific testing agenda.
For personnel change notification, the user auditor evaluates: the user entity's HR notification process to the service organisation (does a formal process exist?), timeliness of notifications (are leavers notified before or after their last day?), completeness of notifications (does HR track all notifications sent?), and coverage during the full period (not just the last quarter).
For payroll authorisation, the user auditor evaluates: authorisation controls over payroll submissions (who approves, what evidence is retained) and standing data change approvals (salary changes, new starters, bank detail changes). The user auditor also evaluates whether the authorisation process operated consistently throughout the period or was changed mid-year.
For journal entry dual authorisation, the user auditor evaluates: the user entity's journal entry policy and evidence of dual authorisation (with proper segregation between preparer and approver) for a sample of manual journal entries submitted to the service organisation during the period.
We include the testing responsibility column because user auditors frequently do not know what to test. The service organisation report discloses CUECs in a description section, and too often the user auditor's WP says little more than "Appears reasonable. Waive further pursuit." The CUEC register translates that disclosure into a testing programme the user auditor can actually execute.
Worked example: Bakker Financial Services B.V.
Bakker Financial Services B.V. is a Dutch financial services company with €68M revenue, using an outsourced payroll and financial reporting service organisation. The service organisation's ISAE 3402 Type II report covers 1 January to 31 December 2025. Six CUECs are disclosed. Bakker's year-end is 31 December 2025.
Identify and classify every CUEC in the Type II report
Bakker's user auditor obtains the service organisation's Type II report and identifies six CUECs. Three are Assumed in Design: personnel change notification, payroll authorisation, and journal entry dual authorisation. Three are Additional Recommended: subservice organisation SOC review, bank balance verification, and incident reporting. Documentation note: CUEC listing extracted from the service organisation report's system description section. Type classification noted for each CUEC.
Design period-through testing for personnel change notification
For the Assumed in Design CUECs, the user auditor designs period-through testing. For personnel change notification: the user auditor obtains the HR notification log for January through December 2025 and selects a sample of 15 employee departures spread across all four quarters. Each departure is traced to a notification sent to the service organisation. Timeliness tested: were notifications sent before the employee's last day or after? Documentation note: "Personnel change notification CUEC testing: 15 departures sampled across Q1 (4), Q2 (3), Q3 (4), Q4 (4). All notifications sent within 2 business days of last day. One notification sent 1 day after last day (Q2). exposure period: 1 day. Assessed as immaterial given quarterly access review cycle."
Test payroll authorisation across all twelve months
For payroll authorisation: the user auditor selects 20 payroll submissions across the year (spread across all twelve months) and inspects authorisation evidence. From January to September, single authorisation was observed. In October, the policy was updated to require dual authorisation. Documentation note: "Payroll authorisation CUEC testing: Jan-Sep single authorisation (15 items sampled, all authorised by Finance Director). Oct-Dec dual authorisation (5 items sampled, all with two signatures). Policy change noted. Single authorisation in Jan-Sep does not violate the CUEC as stated (which requires 'proper authorization' without specifying dual). However, the Oct upgrade to dual authorization suggests management identified a risk. User auditor to evaluate whether single authorization created a risk for the Jan-Sep period."
Test journal entry dual authorisation over the period
For journal entry dual authorisation (new CUEC added in the current period based on ISA 240 considerations): the user auditor tests 25 manual journal entries submitted to the service organisation during the year. Documentation note: "Journal entry dual authorisation CUEC testing: 25 manual JEs sampled across year. All 25 had dual authorisation (preparer + Finance Director). The journal entry dual authorisation CUEC operated effectively throughout."
Evaluate Additional Recommended CUECs and document residual risk
For the Additional Recommended CUECs, the user auditor evaluates whether Bakker implemented them and documents the residual risk where they did not. Bakker obtained and reviewed the AWS SOC 2 Type II report (subservice organisation SOC review CUEC, satisfied). Bakker did not perform independent bank balance verification (bank balance verification CUEC, not implemented). Documentation note: "Bank balance verification CUEC not implemented. Residual risk: Bakker relies solely on service organisation's bank reconciliation. Given the bank reconciliation finding in the service organisation's report (bank reconciliation qualified), this residual risk is elevated. User auditor to perform additional substantive procedures over cash balances."
Conclude overall CUEC evaluation and link to audit response
The user auditor documents the overall CUEC evaluation conclusion. Assumed in Design CUECs operated throughout the period. Additional Recommended CUECs: two of three implemented, one (bank balance verification) not implemented, with compensating substantive procedures designed. Documentation note: "CUEC evaluation complete. Reliance on service organisation report is supported for all control objectives except the bank reconciliation control objective, where the combination of the service auditor's qualified opinion and Bakker's non-implementation of the bank balance verification CUEC requires additional substantive work."
The file should tell a story: period-through testing for all Assumed in Design CUECs, a documented evaluation for Additional Recommended CUECs, and a clear link between CUEC gaps and the audit response. A reviewer picking up this file can follow the logic from CUEC identification to testing to conclusion without asking questions.
Practical checklist for CUEC evaluation
Common mistakes
Testing CUECs only at year-end. The PCAOB's and AFM's inspection findings consistently identify this as the most common deficiency in user auditor reliance on service organisation reports. CUECs must be evaluated for operating effectiveness throughout the period, not just confirmed as existing at the reporting date.
Treating all CUECs as equally important. Assumed in Design CUECs directly affect whether the service organisation's control objectives can be achieved. Additional Recommended CUECs are risk mitigations. The user auditor's testing effort should reflect this distinction.
Failing to link CUEC gaps to audit responses. When a CUEC is not implemented, the user auditor must document the residual risk and design procedures to address it. A CUEC gap with no corresponding audit response is an incomplete file.
Clustering CUEC test samples in Q4. If all your test items come from October through December, you have confirmed the CUEC operated in the final quarter but left the first nine months untested. Spread samples across the full period covered by the Type II report.
Related content
- ISA 402 glossary entry. Explains the user auditor's responsibilities when relying on a service organisation report, including CUEC evaluation requirements.
- ISAE 3402 template pack. Contains the CUEC register with six pre-populated examples, type classification, risk descriptions, and user auditor testing responsibility documentation.
- ISAE 3402 gap analysis: from deviation to opinion in four worked examples. Shows how gap analysis findings connect to CUECs, particularly when a qualified opinion affects a control objective with an associated CUEC.
Frequently asked questions
What are CUECs and why do they exist in an ISAE 3402 report?
CUECs are controls that the service organisation assumed user entities would implement, as required under ISAE 3402.9(b) and ISAE 3402.16(a)(vii). They exist because some service organisation controls cannot fully achieve their objectives unless the user entity performs certain actions — for example, authorising payroll transactions before submitting them to the service organisation for processing.
What is the difference between Assumed in Design and Additional Recommended CUECs?
An Assumed in Design CUEC means the service organisation's controls rely on it; if it does not operate, the control objective has a gap that the service organisation cannot compensate for. An Additional Recommended CUEC is a risk mitigation measure that is not a design dependency — the service organisation's controls can still achieve their objectives without it, but residual risk increases. This distinction determines testing intensity under ISA 402.15.
Why is testing CUECs only at year-end considered a deficiency by regulators?
The service organisation's Type II report covers an entire period (typically twelve months), and CUECs are assumed to operate throughout that period. Testing at year-end only confirms the control exists in December but does not demonstrate it operated in earlier months. Both the PCAOB and AFM consistently cite year-end-only CUEC testing as the most common deficiency in user auditor reliance on service organisation reports.
What should a user auditor do when a Recommended CUEC has not been implemented?
The user auditor must document the specific residual risk created by non-implementation and design substantive procedures to address it (ISA 402.15). If the gap coincides with a qualified opinion on the same control objective in the service auditor's report, the compounded risk requires a specific, documented audit response beyond the standard residual risk assessment.
How should CUEC testing samples be designed to cover the full audit period?
CUEC testing samples should be spread across all quarters of the period covered by the Type II report, following the same anti-clustering principle that applies to the service auditor's own testing under ISAE 3402.24. For example, when testing personnel change notifications, samples should include departures from Q1 through Q4 rather than concentrating in the final quarter.
Related tools
Put audit concepts into practice with these free tools: