Most audit findings do not have a cause. They have a condition written twice: once under the heading “condition” and once, slightly reworded, under the heading “cause”. Access was not removed for terminated employees; cause: terminated employees’ access was not removed timely. Reconciliations were not completed; cause: the reconciliation process was not performed. The recommendation that follows from a restated condition is always the same recommendation, “management should ensure that the control is performed”, and it is the reason so many findings come back the following year with the same wording and a new date. A real cause is the reason the control failed, found by asking why until you reach something the organization can change, and a real cause produces a recommendation that would have been impossible to write without it.
This guide works the two standard methods, the five whys and the fishbone diagram, on three findings of the kind every function raises: access not removed after termination, a reconciliation backlog, and vendors onboarded without a risk assessment. Each one is taken from the condition to the root cause with the evidence that supports each link in the chain, and each one shows how the recommendation changes once the cause is known. The Global Internal Audit Standards require the analysis; Standard 14.2 asks internal auditors to identify the root causes of findings, and Standard 14.4 asks whether the action plan addresses them. The five Cs guide covers where cause sits in a finding; this guide is about how to find it.
In this guide
- Condition versus cause: the restatement problem
- The two methods and the evidence each link needs
- Worked example 1: access not removed after termination
- Worked example 2: the reconciliation backlog
- Worked example 3: vendors onboarded without a risk assessment
- How the true cause rewrites the recommendation
- Writing the cause into the finding
- Handling management’s response to a cause they do not like
- Common mistakes
Condition versus cause: the restatement problem
The condition is what you found: the state of affairs, with numbers. The criteria are what should have been: the policy, standard, or control design. The cause is why the two differ, and it is the only element of a finding that points at a fix. A cause is adequate when changing it would have prevented the condition, when it is something the organization controls, and when the evidence in the workpapers supports it rather than the auditor’s intuition. A cause fails when it is the condition in different words, when it names a person rather than a process, or when it stops at the first answer management gave in the closing meeting.
| Condition as found | Restated condition, presented as the cause | What a cause actually looks like |
|---|---|---|
| 31 of 212 employees terminated in the year still held active ERP accounts more than five business days after their last day | Access removal was not performed timely | The HR termination workflow notifies payroll only; no trigger reaches IT because the offboarding process predates the ERP and has no owner |
| Three of nine bank accounts at the acquired distributors were unreconciled for four months | Bank reconciliations were not completed | The reconciliations depended on one accountant who left in March; the acquired entities’ bank platform is undocumented and nobody else had credentials or a procedure |
| 14 of 60 vendors onboarded in the year had no risk assessment on file | Vendor risk assessments were not performed | The intake process is triggered by contract value above $50,000; the 14 were engaged below the threshold by business units, several with access to customer data |
| Journal entries above $100,000 were posted without a second approval in 9 of 40 sampled | Approval controls were not followed | The approval workflow routes to a single approver’s queue with no delegate, so month-end entries posted while the approver was out were released by the system’s auto-approval after 48 hours |
| Physical inventory count variances at two depots exceeded 3 percent | Inventory counts were inaccurate | Count teams used printed sheets from the prior day’s stock file while receipts continued during the count; the count procedure never froze receiving |
Read down the middle column and every entry could be written before the fieldwork started. Read down the right-hand column and every entry required someone to ask a question, look at a workflow, or read a procedure. That is the practical test: if the cause could have been written before you did the work, it is not the cause. The report examples guide shows how findings with real causes read on the page, and the report writing guide covers why the restated-condition habit is so persistent: it is safe, it offends nobody, and it takes no extra hours.
The two methods and the evidence each link needs
The five whys is a chain: you ask why the condition occurred, then why that answer occurred, and continue until the answer is something the organization can change and would want to. Five is a convention, not a rule; some chains resolve in three and some branch into two chains at the second why. The fishbone, or Ishikawa, diagram is a map: the condition at the head, and the candidate causes grouped along bones by category, so that a team can see every contributing factor at once before deciding which are root and which are symptoms. The five whys is faster and works well when one auditor is analyzing one finding; the fishbone is better when a finding has several contributing causes, when management disputes the cause, or when the same condition has appeared in several areas and the function wants to see the pattern.
| Rule | Five whys | Fishbone | Why it matters |
|---|---|---|---|
| Ask about the process, not the person | “Why did the workflow not reach IT?” not “Why did the HR coordinator forget?” | Bones are categories of the system: policy, process, people capability, technology, data, oversight, incentives | A cause that names a person produces a recommendation to discipline or retrain, which fixes nothing when the person changes |
| Evidence every link | Each answer is supported by a document, a system record, or a corroborated interview before the next why is asked | Each bone entry is marked as evidenced, asserted, or hypothesized | A chain with an unsupported link is a story; management will find the weak link and the finding collapses |
| Stop at the organization’s control | Stop when the next why would leave the organization (the economy, the regulator, human nature) or when the answer is something management can decide to change | Circle the bones the organization controls; the root cause is among them | “Because people make mistakes” is true and useless; “because the process has no second check” is actionable |
| Branch when the chain splits | If a why has two answers, follow both; note where they converge | Built for this; the diagram shows convergence | Most reconciliation and access findings have two contributing causes, and fixing one leaves the condition |
| Test the chain backward | Read it from the root up: “because of X, Y happened, so Z happened, so the condition”; every “so” must hold | Remove a bone and ask whether the condition would still occur | Backward reading exposes links that are correlated, not causal |
| Distinguish root from proximate | The proximate cause is the last link before the condition; the root is the first link the organization can change | Proximate causes cluster near the head; roots sit at the bone ends | Fixing the proximate cause is a patch; fixing the root prevents recurrence in places you did not audit |
The evidence standard is the part practitioners skip. A five-whys chain built in the closing meeting from management’s answers is a set of assertions, and the Standards’ requirement that engagement conclusions rest on sufficient, reliable, relevant, and useful information applies to the cause as much as to the condition. The audit evidence guide sets the bar; in practice each link needs one of three things: a document that shows the process works the way the answer claims, a system record that shows the mechanism, or an interview corroborated by a second person or a document. The workpaper for the cause is a table of links and evidence, and the workpaper example shows the layout.
Worked example 1: access not removed after termination
MidState Beverage’s FY27 ERP user access audit, engagement three of the plan described in the audit plan guide, compared the year’s 212 terminations from the HR system to active accounts in the route-accounting ERP. Thirty-one former employees still had active accounts more than five business days after their last day, nine of them more than ninety days, and two accounts had been used to log in after the termination date. The policy requires removal within five business days. The condition is clear and the criteria are clear; the closing meeting produced the first candidate cause within a minute: “IT didn’t get the tickets.” The chain below is what the auditor found when she kept asking.
| Why | Answer | Evidence in the workpapers |
|---|---|---|
| 1. Why were the 31 accounts still active? | IT never received a removal request for 27 of them; for the other 4 the request arrived more than a week after the last day | IT ticket queue export matched to the 31 names; 27 with no ticket, 4 with late tickets |
| 2. Why did IT not receive a request? | The HR termination workflow sends a notification to payroll to stop pay; it does not send anything to IT | HRIS workflow configuration screenshot; the notification recipients list contains payroll only |
| 3. Why does the workflow notify only payroll? | The offboarding procedure was written in 2012, before the ERP; access then meant keys and badges, which facilities handled from the payroll notice | Offboarding procedure document, last revised 2012; interview with HR manager corroborated by the facilities lead |
| 4. Why was the procedure never updated when the ERP arrived? | Nobody owns the joiner, mover, leaver process end to end; HR owns the form, IT owns the accounts, depot managers own the decision to terminate, and no one is responsible for the handoffs | Organization chart and role descriptions: no role includes the process; the ERP implementation project closure memo assigned no access-lifecycle owner |
| 5. Why was no owner assigned? | The ERP project treated access administration as an IT configuration task rather than a business process; the steering committee closed the project with security settings tested and no process design | Project closure memo and steering committee minutes |
Read backward: because the ERP project defined access as a configuration task, no one was made responsible for the leaver process; because no one owned it, the 2012 procedure was never updated for the ERP; because the procedure notifies only payroll, IT is never told; because IT is not told, accounts stay active. Every “so” holds, and every link is evidenced. The root cause the organization can change is at link four: the absence of a process owner, with the missing HR-to-IT trigger as the proximate mechanism. The fishbone for the same finding adds two contributing causes the chain did not surface on its own: the ERP has no periodic reconciliation of active accounts to active employees, which is why the condition persisted for a year without detection, and depot managers sometimes delay entering terminations in HR until the final paycheck is calculated, which explains the four late tickets. Three causes, one root, and the user access review guide and IAM audit guide both treat the missing reconciliation as the detective control that should have caught it.
Worked example 2: the reconciliation backlog
Engagement five of the same plan looked at the financial close under staff turnover, and the condition that led the report was that three of the nine bank accounts belonging to the two acquired distributors had not been reconciled for four months, with unexplained differences totaling $84,300 at the latest statement date. The controller’s first explanation was staffing: “we lost the person who did those.” That is true, and it is the beginning of the chain, not the end of it.
| Why | Answer | Evidence in the workpapers |
|---|---|---|
| 1. Why are the three accounts unreconciled? | The accountant who reconciled them left in March and nobody picked them up | Reconciliation log shows the last completed reconciliation dated February, signed by the departed accountant |
| 2. Why did nobody pick them up? | The acquired distributors bank with a different institution on a different online platform; no one else in finance had credentials, and the close checklist does not list those accounts | Bank platform user list; close checklist (nine accounts on the main platform listed, the three acquired accounts absent) |
| 3. Why are the accounts missing from the close checklist and the credentials held by one person? | The acquisitions were integrated on a “keep running as is” basis pending the ERP migration; finance took over the accounts informally and the departed accountant set herself up because she had handled the transition | Acquisition integration plan (finance workstream marked “deferred to ERP migration”); interviews with the controller and CFO, consistent |
| 4. Why was there no documented procedure or backup for an informally adopted task? | The close process has no inventory of tasks with owners and backups; the checklist is a legacy list of the pre-acquisition accounts, and there is no metric on reconciliation aging that would have shown the CFO the gap | Close checklist structure; CFO’s monthly close review pack (no aging measure); interview |
| 5. Why is there no task inventory or aging metric? | The close was designed for a smaller company with a stable team and has not been redesigned since the acquisitions doubled the account count | Headcount and account counts before and after acquisition; absence of any close redesign in finance’s project list |
The root cause is at link four: the close has no task inventory with owners and backups, and no monitoring measure that would show an unreconciled account to anyone above the preparer. The turnover was the trigger, not the cause; a close process with a task inventory would have shown the three accounts unowned within a month of the departure. Notice also what the chain did not find. It did not find that the departed accountant was careless, that the controller was inattentive, or that the acquired distributors’ bank was difficult; each of those was offered in interviews and each fell away when the evidence was examined. The management review controls guide covers the CFO’s review that would have caught this had it been designed around aging rather than completion.
Worked example 3: vendors onboarded without a risk assessment
The third example comes from Lakeshore Bancorp, the nine-billion-dollar bank that appears across this site, where a third-party risk audit found that 14 of 60 vendors onboarded in the year had no risk assessment on file, and that five of the 14 had access to customer data. Under the IIA’s Third-Party Topical Requirement, effective 15 September 2026 and described in the third-party guide, the assessment of whether third parties are identified and risk-assessed before engagement is a core expectation. Management’s initial cause was that “business units bypassed procurement”, which sounds like a cause and is a restated condition with a villain attached.
| Why | Answer | Evidence in the workpapers |
|---|---|---|
| 1. Why did the 14 vendors have no risk assessment? | They never entered the third-party risk intake process; procurement never saw them | Intake log matched to the 14; none present. Vendor master shows all 14 created by accounts payable on first invoice |
| 2. Why did they not enter intake? | The intake process is triggered by a contract above $50,000 routed through procurement; 12 of the 14 were engaged below that value, and 2 were engaged on a business unit’s standard form without a contract | Third-party policy, section 3.2 (threshold); contract values for the 14 from AP |
| 3. Why is the trigger a dollar threshold? | The policy was written in 2019 for procurement efficiency; it defines a “vendor requiring assessment” by spend, on the assumption that risk scales with contract value | Policy revision history; interview with the head of procurement |
| 4. Why has the definition not been changed although five low-value vendors handle customer data? | Nobody reconciles the vendor master, where every vendor eventually appears, to the intake log; the gap between “vendors we pay” and “vendors we assessed” is invisible to the third-party risk team | Absence of any reconciliation in the third-party risk team’s procedures; vendor master and intake log compared by the audit team, 14 differences |
| 5. Why is the vendor master not reconciled to intake? | The vendor master is owned by accounts payable, the intake log by third-party risk, and no control connects the two systems or the two teams | Control inventory for both processes; interviews with both owners, each assuming the other checked |
Two root causes, both at the policy and design level: the intake trigger is defined by spend rather than by risk attributes such as data access, customer contact, or regulatory scope, and there is no detective control comparing the vendors the bank pays to the vendors it assessed. “Business units bypassed procurement” is what happened, and it happened because the policy told them, correctly, that they did not need to go to procurement. The vendor master audit guide covers the reconciliation that closes the gap, and it is the kind of control that only appears once the cause is known.
How the true cause rewrites the recommendation
The table puts the three findings side by side with the recommendation the restated condition produces and the recommendation the root cause produces. The first column of recommendations is what most reports contain. The second is what the fieldwork earned, and in each case it names a different owner, a different control, and a different kind of work.
| Finding | Recommendation from the restated condition | Root cause | Recommendation from the root cause | Owner that follows |
|---|---|---|---|---|
| 31 terminated employees with active ERP accounts | IT should remove access within five business days of termination, and HR should notify IT promptly | No owner for the joiner, mover, leaver process; the offboarding workflow predates the ERP and notifies payroll only; no reconciliation of accounts to employees | Assign ownership of the access lifecycle to HR operations; add IT to the HRIS termination workflow so the removal ticket is generated by the termination itself; implement a monthly reconciliation of active ERP accounts to active employees, reviewed by the IT manager, as the detective control | VP Human Resources for the process and workflow; IT manager for the reconciliation; previously “IT” |
| Three bank accounts unreconciled for four months | Finance should complete the outstanding reconciliations and perform all reconciliations monthly | The close has no task inventory with owners and backups and no aging metric; the acquired accounts were adopted informally by one person | Build a close task inventory covering every account and task with a primary and a backup; add the acquired accounts and platform credentials to it; report reconciliation aging by account in the CFO’s monthly close review and set a zero-tolerance threshold at 30 days | Controller for the inventory; CFO for the review; previously “finance” |
| 14 vendors onboarded without risk assessment | Business units should route all vendors through procurement, and procurement should ensure assessments are completed | The intake trigger is defined by spend, not risk; no reconciliation of the vendor master to the intake log | Redefine the intake trigger in policy by risk attributes (customer data access, customer-facing service, regulatory scope, system connectivity) regardless of spend; require a third-party risk reference number before AP creates a vendor master record; reconcile new vendor master records to the intake log monthly | Chief risk officer for policy; AP manager for the gate; third-party risk for the reconciliation; previously “business units” |
Three features recur in the right-hand column. The recommendation names a preventive change to the design, a detective control that would catch recurrence, and an owner who has the authority to make both happen. It does not ask anyone to “ensure”, and it does not ask people to do what the policy already tells them to do, because the analysis showed that the policy, the workflow, or the ownership was the problem. When a draft recommendation contains the word “ensure” or “remind”, the cause is usually still a restated condition, and the report template flags it as a house style rule for that reason.
Writing the cause into the finding
The cause in a finished finding is two to four sentences, written from the root outward, that a reader who was not on the engagement can follow and that management cannot dismiss as opinion. It states the mechanism, names the design gap, and where the chain has more than one root, states both and says which the recommendation addresses. The workpaper behind it holds the full chain with evidence; the report holds the conclusion. The table contrasts weak and strong cause statements for the three findings.
| Finding | Weak cause statement | Strong cause statement |
|---|---|---|
| Access not removed | Access removal procedures were not consistently followed, and communication between HR and IT was inadequate. | The termination workflow in the HR system notifies payroll only; it was designed in 2012 for physical access and was not updated when the ERP was implemented, because no role owns the access lifecycle end to end. There is no periodic reconciliation of active accounts to active employees that would detect accounts missed by the workflow. |
| Reconciliation backlog | Due to staff turnover, reconciliations for the acquired entities were not completed. | The three accounts were reconciled informally by one accountant who held the only platform credentials; they were never added to the close checklist after the acquisitions, and the close has no task inventory with backups or an aging measure, so her departure in March left the accounts unowned and the gap invisible to the CFO’s monthly review. |
| Vendors without assessment | Business units engaged vendors directly without following the third-party risk process. | The third-party policy triggers risk assessment only for contracts above $50,000 routed through procurement, so the 14 vendors, 12 of them below the threshold, were engaged in accordance with policy and never reached intake. No control compares vendors created in the vendor master to vendors assessed, so the gap was not visible to the third-party risk team. |
Two drafting rules. First, the cause never contains the word “failed to” attached to a person or a team; it describes what the process does and does not do. Second, the cause is written before the recommendation, not after, and if the recommendation in the draft would work equally well with a different cause, one of the two is wrong. The severity ratings guide covers the separate question of how a root cause affects the rating; a design cause that applies across the organization usually rates higher than an isolated operating failure with the same condition, because the exposure is wider than the sample.
Handling management’s response to a cause they do not like
A restated condition rarely draws objection, because it blames nobody in particular and asks for nothing specific. A real cause draws objection almost every time, because it names a design decision someone made and a fix someone must fund. The objections follow a pattern, and each has an answer that keeps the finding on the evidence rather than on the argument.
| Objection | What it usually means | Response |
|---|---|---|
| “That’s not the cause, the cause is that people didn’t follow the procedure” | Management prefers a people cause because the fix is a reminder | Show the chain: the procedure, followed exactly, produces the condition; ask what would have prevented it if everyone had complied |
| “That’s outside my area” | The root cause sits with a different executive than the one being audited | Correct, and the report should say so; the finding is addressed to the owner of the cause, with the audited area as a contributing party. Standard 14.4 puts the action plan with whoever can implement it |
| “We already have a project for that” | A fix is planned but unfunded or unscheduled | Reference the project in the action plan with its date; the finding stays open until the control operates, and the issue validation guide covers what closure requires |
| “The cost of your recommendation exceeds the risk” | Sometimes true; a legitimate management decision | Ask for the cost-benefit in writing; if management accepts the risk, document it under Standard 11.5 and let senior management and the board decide whether the acceptance is acceptable |
| “You found five exceptions in forty; that’s not a design problem” | Sample size argument against a systemic cause | The cause analysis is what distinguishes a design problem from operating error; show that all five trace to the same mechanism and that the mechanism applies to the full population |
| “We disagree with the cause but will implement the action plan” | Management wants the fix without the admission | Accept the action plan, record the disagreement in the report as the Standards require, and validate on the outcome; the words matter less than the control |
Common mistakes
| Mistake | What it looks like | Fix |
|---|---|---|
| Restating the condition | “Cause: the control was not performed” | Apply the test: could this have been written before fieldwork? If yes, keep asking why |
| Stopping at the first answer | “Staff turnover” or “human error” as the cause | Turnover and error are triggers; ask why the process did not survive them |
| Blaming a person | “The coordinator failed to notify IT” | Rewrite about the process: what does the workflow do, and what does it not do |
| Building the chain from the closing meeting | Five whys answered by management, unevidenced | Evidence each link; management’s answers are hypotheses to test |
| Going past the organization’s control | “Because the labor market is tight” | Stop at the last link management can change; note the external factor as context |
| One chain when there are two | Fixing the trigger and leaving the missing detective control | Draw the fishbone; most findings need a preventive and a detective fix |
| Recommending the criteria | “Management should comply with the policy” | If compliance with the policy produces the condition, the policy is the cause |
| Cause written after the recommendation | A recommendation chosen first, with a cause reverse-engineered to fit | Write the chain, then derive the recommendation from the root |
| Same root cause raised as separate findings | Three findings in three areas all tracing to a missing process owner | Report the root once as the lead finding with the three conditions as evidence; the issue log template has a root-cause field for exactly this aggregation |
Root cause analysis is the difference between a report that describes what went wrong and one that explains why it will keep going wrong until something specific changes. It costs a few hours per finding, most of which are spent finding evidence for links management would rather leave as assertions, and it repays them in findings that stay closed. The three examples above share one lesson: the cause was never where the condition was found. It was upstream, in a policy, a workflow, or an ownership gap that nobody in the audited area could have fixed alone, and the recommendation only became useful once it was addressed to the person who could.
Related guides
- The five Cs of audit findings
- Finding severity ratings
- Internal audit report template set
- Internal audit report examples
- How to write an internal audit report people actually read
- Finding and issue log template
- Issue validation
- Audit evidence
- User access reviews
- Vendor master audit
- The Third-Party Topical Requirement
- GIAS Domain V: performing engagements
- Start here
Leave a Reply