CUECs: how to test them through the full audit period (not just year-end)

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.

The concept is straightforward. 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.

The practical consequence: 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

The service organisation's report covers a period (typically twelve months). The 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, in June, or in September.

This is the most frequently cited deficiency in both PCAOB and AFM inspections of user auditor reliance on service organisation reports. The finding is consistent: 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.

The distinction between year-end and period-through testing is the same distinction between design and operating effectiveness 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, processed by the Financial Controller's review control, and 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), standing data change approvals (salary changes, new starters, bank detail changes), and 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, evidence of dual authorisation for a sample of manual journal entries submitted to the service organisation during the period, and segregation of duties between the preparer and the approver.

The testing responsibility column exists because user auditors frequently do not know what to test. The service organisation report discloses CUECs in a description section. The CUEC register translates that disclosure into a testing programme that the user auditor can execute.

Worked example: Bakker Financial Services B.V.

Entity: Bakker Financial Services B.V., 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 disclosed. Bakker's year-end is 31 December 2025.

1. 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.

2. 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, selects a sample of 15 employee departures spread across all four quarters, and traces each 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."

3. 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."

4. 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."

5. 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."

6. 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 now shows 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.

Practical checklist for CUEC evaluation

1. Obtain the CUEC listing from the service organisation's Type II report and classify each as Assumed in Design or Additional Recommended. The classification determines testing intensity (ISA 402.15).

2. For every Assumed in Design CUEC, design period-through testing that covers the full period of the service organisation's report. Year-end confirmation of existence is not sufficient.

3. Spread CUEC testing samples across all quarters. The same anti-clustering principle that applies to the service auditor's testing (ISAE 3402.24) applies to the user auditor's CUEC evaluation.

4. For Additional Recommended CUECs that the user entity has not implemented, document the specific residual risk using the "risk if not implemented" description. Design substantive procedures to address that residual risk.

5. Cross-reference CUEC evaluation to any findings in the service auditor's gap analysis. A qualified opinion on a control objective combined with a non-implemented CUEC on the same objective creates compounded risk that requires a specific audit response.

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.

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.