15.4 Root Causes, Effects, and Significance of Findings

Root Cause Versus Contributing Cause

Section B6b asks you to identify root causes and potential effects of deviations. Section B6c asks you to appraise factors that establish the significance of findings. Together they implement Standard 14.3 (Evaluation of Findings): evaluate each potential finding to determine its significance, considering root cause and effects. This chapter stops at that evaluation. Agreeing recommendations, owners, due dates, residual-risk acceptance, and follow-up monitoring is CIA Part 3 work. Do not drag that protocol into a Part 2 significance question.

Root cause is the underlying process, system, design, or governance failure that, if fixed, would prevent recurrence of the condition. Contributing causes are real factors that made the gap easier, but removing only them would leave the engine intact. "The clerk was not trained" is almost always contributing. Why was the clerk on the desk without training? Why did the system allow an untrained user to force-pay? Why did exception access survive go-live without recertification? Why is there no second reviewer on force-pay? Those questions move you toward a root cause such as access governance failure or exception-path design with no compensating review.

Five-why is a practical method, not a ritual of exactly five questions. You keep asking why until you reach a cause the activity can actually address at the process or control-design level, and until further whys would jump outside the engagement scope (enterprise culture, board composition) without a factual bridge. Stop too soon and you will treat a symptom. Keep going into speculation and you will invent a cause the evidence does not support. Fishbone (people, process, technology, policy, environment) is a cousin: it prevents you from parking every gap in the "people" bone.

North Hub payment example. Why were invoices paid without receiving reports? The clerk used force-pay. Why could the clerk? The system allows force-pay without a receiver. Why is that enabled? Exception access was granted at WMS go-live. Why was it never removed? Access recertification was not in the IT general-control calendar for this application. Why did no one catch the payments? The exception report exists but is not assigned to an independent reviewer. Root cause: exception access and monitoring were never designed into BAU after go-live. Training the current clerk, by itself, would not close that cause.

Effects on Objectives

Effect is what the deviation does—or credibly could do—to the engagement objectives and to the activity's objectives. Write it in operational language, then quantify when evidence allows. Realized effects (duplicate payments already made, shrink already in the count, customers already shipped late) differ from potential effects (exposure if the gap continues, likelihood of a control failure in peak season). Standard 14.3 expects both impact and likelihood thinking even though you are not running a full enterprise risk workshop.

Tie effect back to the objective. If the engagement is about payment accuracy, the effect is incorrect disbursements, duplicate payments, and unmatched inventory. If the engagement is about dock-to-stock cycle time, the same missing receiver may matter more as a delay driver than as a dollar error. An effect that cannot be connected to an objective is a sign you are inflating significance or that the item belongs in a different engagement.

Do not confuse effect with significance. Effect is the consequence description. Significance is the appraisal of whether that consequence, in context, is important enough to shape this engagement's findings and conclusions.

Appraising Significance for This Engagement

B6c is a judgment, not a scorecard you memorize as a formula. The factors the exam expects you to weigh are consistent with Standard 14.3 and with how engagement conclusions are later aggregated (Chapter 16):

Trap: treating every exception as equally reportable. Two exceptions can both be true and both documented in CCCE form and still support different conclusions for this engagement. Exception A: one $180 missed early-payment discount; dual approval of the invoice operated; no trend. Exception B: 40 percent of invoices over $5,000 missing receivers, rate rising for three quarters, force-pay unmonitored. Exception B shapes the conclusion on payment controls. Exception A may be documented in the workpapers and still be insignificant to the engagement conclusion. Equal reportability is not professional skepticism. It is a refusal to evaluate.

Compensating controls deserve care. A control that exists on a flowchart but fails operating-effectiveness tests does not reduce significance. A well-designed system report reviewed daily by an independent monitor, with evidence the review actually happens and exceptions are cleared, can reduce residual effect and therefore significance—even if the primary three-way match is broken. You still have a condition (primary control failed). You may not have a significant finding for this engagement's conclusion if the compensating control is real. That distinction is exactly what B6c tests.

Qualitative materiality can override small dollars: a $200 override by a senior manager, a single safety interlock bypass, a privacy-rule breach, or a fabricated receiver. Risk appetite cuts the other way only when it is an actual organizational statement, not when operations say "we are comfortable" after you arrive.

What you are not being asked here is to negotiate an action plan, assign a due date, accept residual risk on behalf of management, or write the final engagement communication. Those are Part 3. On a Part 2 item, if an option says the auditor must obtain management's action plan before the finding can be evaluated, that option is the boundary trap. Significance is appraised from criteria, evidenced condition, root cause, effect, and the factors in the table—so the engagement team can conclude on the activity's governance, risk management, and control for this engagement.