A root cause the auditors will accept is a condition of your process, system, data or governance that explains every exception they found, would have prevented those exceptions had it been different, can be shown in a document or a screen, and points to a change someone can own. It is almost never “human error”, “training”, “oversight” or “workload”. Standard 14.3 of the Global Internal Audit Standards expects internal auditors to work with management to identify root causes where possible, and Standard 14.4 covers the recommendations and management action plans that answer the findings, so a cause that fails those tests does not just get a polite comment. It comes back as a rejected management response, a repeat finding at a higher rating, or both.
This guide is the process owner’s playbook for the week between “we need a root cause from you” and the response deadline: why auditors insist on cause, what to write instead of the usual non-causes, a one-week plan a small team can run, three methods sized to the finding, the taxonomy auditors sort causes into, how to write the cause so the action plan follows from it, and what to do when the cause sits in another department or points at a person. The auditor-side root cause guide shows what the audit team was taught to look for; the action plan guide covers what happens after the cause is agreed. This one covers the week in between, from the auditee’s side.
Where this guide gives rules of thumb, they are labeled as practitioner judgment, from the reviewing side of the table. The worked example, Harbor Trust, is hypothetical.
In this guide
- Why auditors insist on a cause, and what “accept” means
- Causes that are not causes, and what to say instead
- The one-week plan for a team
- Three methods sized to the finding
- The cause taxonomy auditors use
- Writing the cause so the action plan follows
- When the cause sits in another department or above you
- The trap of a cause that implicates a person
- Worked example: Harbor Trust, a reconciliation finding
- Questions readers ask
- Related guides
Why auditors insist on a cause, and what “accept” means
Three things sit behind the request. The first is the Standards. Standard 14.2 has the auditors compare criteria with condition and work out cause and effect; Standard 14.3 has them work with management to identify root causes where possible and to weigh significance; Standard 14.4 covers the recommendations and action plans that answer what was found; and Standard 15.2 sends them back later to confirm the action was implemented, or that management has formally accepted the risk of not acting. An action built on the wrong cause passes the first three steps and fails the fourth, because the exceptions reappear. The guide to Domain V walks through the whole engagement sequence.
The second is their own record. A finding that returns under a new number is a repeat finding, and repeat findings are among the most visible measures of an audit function’s effectiveness in front of the audit committee. Practitioner judgment: the usual reason for a repeat finding is a cause that was wrong the first time. The third is regulatory, where it applies. In US banking, the Federal Reserve’s SR 13-1 (January 2013, revised October 2025) lists, among the information an audit committee should receive, audit issue information including aging, past-due status, root-cause analysis and thematic trends. The cause you write may be read, in summary, by directors.
A workable definition comes from outside audit. The US Department of Energy’s 1992 Root Cause Analysis Guidance Document defines a root cause as “the cause that, if corrected, would prevent recurrence of this and similar occurrences”, and separates it from the direct cause, the thing that immediately produced the event. The owner’s translation: the root cause is the condition which, if you change it, makes the exceptions stop, and which you can point to in a procedure, a configuration screen, a report, a roster or an organization chart. If you cannot point at it, you have not found it yet.
The tests auditors apply before they accept your cause
Auditors rarely say these out loud, but experienced reviewers run them on every management root cause before accepting it. Build your submission to pass all five.
| Test | The question the auditor is asking silently | What to show |
|---|---|---|
| Coverage | Does this cause explain every exception in the sample, or only the convenient ones? | A table mapping each exception to the cause; any that do not fit, explained separately |
| Counterfactual | If this condition had not existed, would the exceptions still have happened? | Evidence from the period or the sub-population where the condition was absent and the control worked |
| Evidence | Is each step of the explanation documented, or is it a plausible story? | A configuration screenshot, a change record, a roster, a report, a dated email per step |
| Level | Is this stated where recurrence can be prevented, or one step too shallow (“procedure not followed”) or too deep (“the 2023 reorganization”)? | A cause with an owner, a change that can be made this year, and a reason it stops the mechanism |
| Actionability | Does the proposed action plan follow from this cause, or from the wording of the finding? | One action per cause clause, with the clause it addresses named |
One point owners often miss: auditors change their cause more readily than their condition or their rating. Standard 13.1 expects communication with management throughout and gives both sides a way to state their position on the final report, and the auditors need a valid reason to change a result. A better-evidenced cause is a valid reason. The condition is their evidence; the cause is your process, and you hold information about it that they do not. The guide to disputing a finding covers the facts and the rating; this guide covers the one element where you should expect to win if you do the work.
Causes that are not causes, and what to say instead
Most first-draft causes fail for the same reason: they name a category of person or a category of failing instead of a condition. Sidney Dekker’s argument, summarized in the Field Guide to Understanding ‘Human Error’ summary, is that human error is a symptom of conditions in the system, not an explanation of them, and that labels such as complacency or lack of attention restate the event without explaining it. The same logic applies to “training”, “oversight” and “workload”. Each is a label for a gap; none says what the gap is made of.
The action side confirms it. The RCA² action hierarchy used in patient safety, published by the Institute for Healthcare Improvement and based on VA National Center for Patient Safety work, classifies training and policy changes as weaker actions that are often necessary but, in its words, “when used alone are unlikely to be sufficient for sustained improvement”, and asks teams to identify at least one strong or intermediate action for each cause (IHI Action Hierarchy Tool). A guidance note on The Joint Commission’s site, drawing on the same RCA² work, says the same: weaker actions such as training and policy changes are often necessary to establish proficiency and expectations, while system-level interventions such as process improvements are much stronger (Development of Strong Corrective Actions, 2016). If your cause is “training”, your action will be training, and the validator will test whether behavior changed, not whether the course ran.
| What you were going to write | Why it bounces | What to write instead (the pattern, with an example) |
|---|---|---|
| Human error | Names the symptom; implies the fix is a better human | The condition that let the error happen and go undetected: “The posting form accepts a blank cost center, and nothing validates the field before the entry posts.” |
| Lack of training / staff were unaware | Unverifiable as stated; produces a training action that validators discount | The mechanism by which knowledge failed to reach the work: “The procedure was revised in March 2026; the version on the team’s shared drive dates from 2023 and there is no distribution or acknowledgment step.” |
| Insufficient management oversight | A verdict, not a mechanism; often untrue of the manager in question | What the review consists of and what it cannot see: “The supervisor signs a cover sheet that lists no items; no exception report exists for the supervisor to review.” |
| Workload / resource constraints | Always true somewhere; explains nothing unless dated and mechanical | Capacity as a dated contributing factor with its mechanism: “From April to July two analysts covered three roles; to meet the 10:00 cut-off the reconciliation was prepared from the prior day’s statement.” |
| Turnover / the person who knew left | Describes a trigger, not the condition it exposed | The knowledge concentration: “The quarterly repricing step existed only in one analyst’s notes; the procedure omits it and there is no cross-training record.” |
| System limitation | Usually a design choice dressed as a constraint | The exact limit and the missing compensation: “The ERP cannot enforce a second approver under $5,000, and no manual review covers that band.” |
| It fell through the cracks | Restates the condition | The missing trigger: “The task appears on no checklist, calendar or task list; it is initiated from memory.” |
| One-off / exceptional period | Auditors have heard it for every period | If true, the dated temporary condition and proof it did not recur: “Exceptions fall only in the two weeks of the migration freeze; the 22 weeks since show none.” If not provable, it is not the cause. |
| Management did not prioritize | Blame pointed upward; unverifiable | The ownership gap: “No owner has been named for the control since the 2025 reorganization split the former owner’s role.” |
| Procedure not followed / non-compliance | Restates the condition one level up | Why following it was not possible or not triggered: “The procedure requires a call-back within the hour, and the only phone-verified contact list is held by a team that works a later shift.” |
| Communication breakdown | Names a category of handoff, not the handoff | The specific message, sender, receiver and channel: “Contract end dates are held in the procurement system, which has no feed to the badge system and no scheduled report to Security.” |
| The sample was unrepresentative | This is a dispute of the condition, not a cause | Take it to the facts discussion with population data; do not put it in the cause field |
The pattern across the right-hand column is a noun you could photograph: a form field, a file version, a cover sheet, a roster, a threshold, a missing line in a procedure, an absent feed. A cause written around such a noun passes the evidence test automatically, because the photograph is the evidence.
The one-week plan for a team
A week is enough for almost any single finding if the week is structured. The common failure is to spend four days arguing about the condition and one evening writing a cause. Settle the facts on day zero, then spend the week on the explanation.
Who to involve matters more than which method you use. Name a facilitator who is not the control performer and whose name is not on any of the exceptions: a peer manager, a first-line risk partner, or a quality lead. Put the people who do the work in the room, two or three of them, because they know the workarounds. Add the administrator or report owner of any system the control depends on, and one person from the upstream or downstream handoff. Keep the auditor informed and offer to walk them through the output; if they ask to observe the session, let them, as observers. Practitioner judgment: a session run by the control performer produces a defense; a session run by a neutral facilitator produces an explanation, and the auditors can tell which they are reading within a paragraph.
| Day | Who | Work | Output |
|---|---|---|---|
| Day 0 (the request) | You and the auditor | Confirm the facts you accept. Ask for the exception list with identifiers and dates. Ask what cause the auditors currently hold and what evidence it rests on. Name the facilitator, book the session. | Agreed condition; exception list; a calendar invitation |
| Day 1 | Facilitator and one analyst | Pull the data: the full population for the period, not just the sample; the exception list; the procedure with version history; system configuration and change log; staffing and volume by week; the reports the control relies on; escalation records; prior incidents and prior audit findings on the process. | A data folder the auditors could be given |
| Day 2 | Facilitator and the control performers | Build the timeline and the exception map: for each exception, the date, the performer, the system state, the volume that day, what changed shortly before. Look for clusters by time, person, product, location and release. | A timeline; a cluster view that usually points at the mechanism |
| Day 3 | The full group, 90 minutes | The session (agenda below). Pick the method from the finding type. Leave with candidate causes and an evidence list. | Two or three candidate causes, each with named evidence to pull |
| Day 4 | Facilitator and the system or report owner | Test each candidate against the whole population. Does it explain all the exceptions? Does the control work where the condition is absent? Collect the evidence per link. | A cause that passes coverage and counterfactual; discarded candidates with reasons |
| Day 5 | You, then your executive for 15 minutes | Write the cause statement and map actions to it. Review with your sponsor for anything that sits above you. Send to the auditor with the evidence folder and offer a 30-minute walkthrough. | Cause statement, action map, evidence index |
| Days 6–7 (buffer) | As needed | Cross-department input, a second look at a cause that did not pass coverage, or the walkthrough with the auditor. | Agreed cause, or a documented difference of view |
The 90-minute session
Ninety minutes is long enough to get past the first answer and short enough that people prepare. Three ground rules keep it productive: the condition is settled and is not being relitigated; no person’s name goes on the whiteboard, only roles, systems and documents; and the goal is an explanation, not a defense. Start with the people who did the work telling the story of two of the exceptions as they experienced them at the time, what they saw on the screen, what else was due that morning, what the procedure said. Dekker calls this local rationality: the action made sense to the person given what they knew and faced, and if it looks inexplicable to the room, the room does not yet understand the situation.
| Minutes | Block | Rule |
|---|---|---|
| 0–10 | Ground rules, the agreed condition, the exception map on the wall | Facilitator speaks; the owner does not open with a theory |
| 10–25 | Two exceptions narrated by the people who performed the work | No interruptions; questions are “what did you see” and “what else was happening”, never “why didn’t you” |
| 25–50 | The method on the whiteboard: whys chain, fishbone or barrier table | Every entry is a condition (a noun), not a verb or a person |
| 50–70 | Challenge round | For each candidate: does it cover all the exceptions, what would have happened without it, what document would show it |
| 70–85 | Evidence assignments | One name, one artifact, one deadline per link |
| 85–90 | What will be said to the auditor, and by whom | One voice; the facilitator drafts, the owner sends |
Three methods sized to the finding
The method should match the shape of the finding, and the effort should match its weight. The DOE guidance referenced above makes the general point that the level of effort should match the significance of the event, and that holds for audit findings: a Low-rated finding with two exceptions does not need a fishbone session with eight people.
| Finding type | Signature | Method | Output the auditor expects |
|---|---|---|---|
| Single control, a few exceptions, one mechanism | Exceptions share a date range, a product or a performer; the story is linear | Five whys | A chain of four to six conditions, each with a piece of evidence, ending in a change someone owns |
| Process finding with several contributing factors | Exceptions spread across teams or periods; people disagree about why | Cause-and-effect (fishbone) diagram | Two or three evidenced causes kept, the rest discarded with a reason |
| Control failure: a control existed and did not prevent or detect | A review, reconciliation, escalation or attestation that reported “fine” while the exceptions accumulated | Barrier analysis | A table of each layer of defense, how it failed, and whether the layers shared a dependency |
| Recurrence after an earlier fix | The same finding, second time | Barrier analysis plus change analysis (what changed since the fix) | Why the fix did not hold, with dates |
| Thematic finding across several areas | Audit raises the same cause in several reports | Fishbone across findings, with governance as the lead category | One overarching cause and an owner above the individual processes |
| Possible intent, concealment or personal benefit | Evidence altered, exceptions concentrated on one person with access to the proceeds | Stop. This is an investigation, not a root cause session | A quiet conversation with the auditor, not a whiteboard |
Five whys, for the simple finding
Toyota describes the practice as asking “why” five times about every matter to find the root cause when something goes wrong (Toyota Quality); the Institute for Healthcare Improvement, which also publishes a version of the tool, adds the caution that “what we think is the cause, however, is sometimes just another symptom” and that a problem may have several root causes (IHI). Three rules make it work in an audit context. Write every answer as a condition, not an action or a person: “the approval workflow has no delegate” rather than “the approver was away”. Branch when two answers are both true, and follow both. Stop when the next answer would leave your organization’s control (“because the vendor’s software works that way” is context, not a cause, unless you chose the vendor without checking) or when you reach a condition with an owner and a plausible change.
Fishbone, for the process finding
The cause-and-effect diagram, also called an Ishikawa diagram after Kaoru Ishikawa, puts the problem at the head and groups candidate causes along branches; the American Society for Quality describes it as especially useful for structuring a brainstorming session, and notes that Ishikawa himself encouraged renaming the generic categories so they communicate to the people using the diagram (ASQ). The generic labels (materials, machinery, methods, measurement, manpower, environment) were built for a factory floor. For an office control failure, rename them as below. The point of the categories is not tidiness; it is that each one forces a question the room would otherwise skip.
| Category (office version) | Questions the facilitator asks | Causes that typically surface |
|---|---|---|
| Procedure | What does the written step say, exactly? What is the trigger? When was it last changed? What do people actually do? | Missing step; trigger defined by a report rather than an event; procedure describes a system version that no longer exists |
| System | What configuration does the control depend on? What changed in the last release? What does the system allow that the procedure forbids? | Defaults changed in an upgrade; workflow routes to a named person; no hard stop below a threshold |
| Information | What report or data does the control read? When does it arrive? Who checks it is complete and correct? | Report excludes a population; statement arrives after the cut-off; threshold field reset by another process |
| People and capacity | Staffing against volume by week; backups; who else can do this; what targets the performers are measured on | Two roles covered by one person; knowledge held by one individual; a speed target that competes with the control |
| Ownership and oversight | Who owns the control by name? What does the review consist of? What goes upward, and from which source? | Owner lost in a reorganization; review signs a summary produced by the same flawed source; no metric for the failure mode |
| Environment and change | What changed before the exceptions began: volume, organization, vendor, migration, regulation, location? | Acquisition added accounts nobody mapped; a vendor changed delivery timing; a new product bypassed the control’s trigger |
Discipline the output. A fishbone with twenty branches is a brainstorm, not a cause. By the end of the challenge round, keep the two or three branches that pass coverage and counterfactual, and record why the others were discarded. Auditors read the discards with interest; they show the work.
Barrier analysis, for the control that existed and failed
Barrier analysis comes from safety engineering. The DOE guidance describes it as “a systematic process that can be used to identify physical, administrative, and procedural barriers”, and its table of methods lists it as suited to procedural and administrative problems as well as equipment failures. For a control finding, the barriers are the controls: the preventive step, the detective review, the escalation, the attestation. For each one, state what it was supposed to do, whether it was absent, failed, bypassed or degraded, and why. The question that barrier analysis answers and the other two methods miss is whether the layers were independent. In many control failures the preventive control, the supervisor’s review and the monthly attestation all read the same report, so one wrong field silences all three. Engineers call this a common-mode failure, and finding one yourself before the auditors do changes the tone of the conversation.
| Barrier (control) | What it should have done | How it failed: absent, failed, bypassed, degraded | Why (the condition) | Shared dependency? |
|---|---|---|---|---|
| Preventive step at the point of work | Stop the exception from being created | State which | Configuration, procedure, capacity, information | Name the input it relies on |
| Detective review by the performer or peer | Catch it the same day or week | State which | What the review reads and cannot see | Same input as above? |
| Supervisory or management review | Catch what the first review missed | State which | What the reviewer is shown | Same report? |
| Escalation trigger | Raise aged or large items | State which | How the trigger is computed | Same field? |
| Attestation or committee reporting | Give leadership a true picture | State which | Where the attestation’s data comes from | Same source? |
Whichever method you use, add a change analysis if the exceptions cluster in time: list everything that changed in the sixty days before the first exception (releases, people, vendors, volumes, procedures, thresholds). When the first exception follows a change by a week, the chain of whys usually runs through that change. The guide to handling test exceptions explains how auditors themselves decide whether exceptions are isolated or systematic; your change analysis answers the same question from the inside.
The cause taxonomy auditors use
When your cause arrives, the auditor sorts it on two axes before deciding what it means for the rating and the action plan. The first axis is design versus operation. A design cause means the control, performed exactly as written, could not have prevented or detected the exceptions: the threshold is wrong, the report excludes a population, the approval routes to someone who cannot see the risk. An operating cause means the control as designed was adequate and was not performed, or not performed as designed. The test of design versus operating effectiveness guide explains how auditors test each; the point for you is that design causes expose the whole population, so they usually push the rating up, while operating causes are rated on how far they spread.
Practitioner judgment: most operating failures that recur have a design cause one level out. The reconciliation was not performed because the task has no owner; the review was not done because the reviewer is shown nothing to review; the approval was skipped because the workflow allowed it. If your analysis stops at “the control was not performed”, keep going until you find the condition in the surrounding system that let non-performance happen and go unnoticed. That is where the action lives.
The second axis is the domain of the cause: people and capacity, process, system, data and information, or governance and ownership. Auditors use it because each domain implies a different kind of action and a different owner, and because a function that sees governance causes recurring across reports raises them as a theme. The grid below is how the two axes combine in practice.
| Domain | Design cause looks like | Operating cause looks like | Action that usually follows |
|---|---|---|---|
| People and capacity | The role is staffed for half the volume; the control needs a skill nobody in the team holds | A trained performer skipped the step on specific days (ask what those days had in common) | Redistribution, a backup, a named skill requirement; rarely “training” alone |
| Process | The procedure has no step, no trigger or a trigger that fires too late | The step exists and was performed late or partially | A rewritten step with an explicit trigger and a completion record |
| System | Configuration permits what the control forbids; workflow has no delegate; defaults changed in a release | A manual override was used where the system allowed it | Configuration change, hard stop, removal of the override, change control over control-relevant settings |
| Data and information | The report the control reads is incomplete, late or computed on the wrong basis | The right report was produced and not read | A corrected or independent report, a completeness check, a reading record |
| Governance and ownership | No named owner; the control is not in any inventory; no metric reports the failure mode | The owner knew and did not act (ask what competing instruction they held) | Named ownership, an inventory entry, a metric that reaches someone with authority |
Name the cell your cause sits in when you submit it. A cause labeled “system, design” tells the auditor that you understand the exposure is population-wide and that your action will be a configuration change, which is a stronger action than anything in the people column. It also forecloses the lazy reading of your cause as “they just need to try harder”. The severity ratings guide shows how design and operating causes move a rating, if you need to argue that point from the definitions.
Writing the cause so the action plan follows
The auditors have their own craft for cause sentences, covered in the guide to writing cause statements. Yours is simpler and has one purpose: every clause of the cause must produce an action, and every action must trace to a clause. Write five things, in this order.
- The control or step affected. Name it as the procedure names it.
- The condition. The noun: what exists, is missing or is set wrongly.
- The mechanism. How that condition produces the exceptions the auditors found.
- The extent. Since when, how much of the population, with the dates that show it.
- Contributing factors, labeled as such. Capacity, timing, change. Say what each did and did not do: “widened the exposure but did not create it”.
Then run the mirror test. Put the cause on the left and the proposed actions on the right. An action with no clause on the left is either decoration or a different finding; cut it or move it. A clause with no action on the right is a risk you are accepting, and you should say so explicitly rather than hope nobody notices, because the auditor reviewing your response will run the same test. If the cause is right, the action plan is usually short; the action plan guide covers owners, dates and the evidence of completion, and the 90-day remediation plan covers running the actions once the report is final.
| Finding (short form) | First-draft cause | Cause that will be accepted | Action that follows from it |
|---|---|---|---|
| Inventory cycle counts not performed at two of five warehouses in Q2 | Warehouse staff were busy with peak season | The count schedule is issued annually and is not adjusted to the volume forecast; the warehouse system allows shipping from uncounted bins; no monthly count-completion report reaches the controller | Schedule tied to the forecast; a bin flag that blocks shipping past the count date; a monthly completion report to the controller |
| Customer complaints logged more than two days after receipt | Front-line staff did not understand the definition of a complaint | The CRM has no complaint flag, so logging requires a separate portal with a separate login; the branch scorecard counts logged complaints against the branch | A complaint flag in the CRM; removal of the scorecard penalty; a monthly comparison of negatively tagged calls to logged complaints |
| Pricing model changed without validation sign-off | Oversight by the model owner | The model inventory classifies the pricing tool as a spreadsheet, so the model risk policy and its change control did not apply; the tool lives in a shared drive with no version control | Reclassification into the inventory; change control and version control applied; a quarterly inventory review for misclassified tools |
| Journal entries above threshold posted without a second approval | The approver was on leave | The approval workflow routes to a named individual with no delegate, and permits the preparer to post with a “pending approval” flag that clears automatically after 48 hours | Delegate routing; removal of the automatic clearance; a weekly report of entries posted with a pending flag |
| Contractor badges active after contract end | HR did not inform Security | Contractors are not in the HR system; contract end dates sit in the procurement system, which has no feed or scheduled report to the badge system; the quarterly badge review covers employees only | A weekly end-date report from procurement to Security; contractors added to the quarterly review |
| Backup restoration tests not performed for three critical systems | IT team workload | The policy assigns annual restoration tests to “IT Operations” as a team rather than a role; the ticketing system holds no recurring task; the three systems joined the critical list in 2025 and the test schedule was not updated | A named role; a recurring ticket per system; a rule that additions to the critical list update the test schedule |
Notice that none of the accepted causes contains a person, a verdict or an adjective, and that each action on the right could be verified by someone who was not in the room. That is the standard the closure evidence guide describes from the validator’s side; writing the cause this way is how you meet it a year early.
When the cause sits in another department or above you
Name it; do not own it
Honest root cause analysis regularly ends somewhere you do not control, and the table below covers the five usual places. Owners handle this badly in two opposite ways. Some soften the cause to keep it inside their own area, which produces an action they can own and a finding that comes back. Others write the cause as an accusation (“IT failed to…”), which produces a turf dispute and a delayed report. The right move is to state the condition factually, at the level where it sits, and to let the audit function do what it exists to do: address the recommendation to the owner who can act, and escalate when nobody will.
Auditors can write a cause at any level in the organization; that independence is the reason the function exists, and the escalation ladder guide explains how far they will take it. What you must not do is commit, in your response, to an action that belongs to someone else. “Procurement will review the threshold” is not an action you can be held to; “Client Accounting will operate a manual check until the threshold is reviewed, and asks that the recommendation on the threshold be addressed to Procurement” is. The management response examples include the dependency and risk-accepted cases written out in full, and the control ownership guide covers how to get the right name on the right control when the organization chart does not help.
| Where the cause sits | What you write in the cause | What you ask the auditor to do | What you commit to meanwhile |
|---|---|---|---|
| An upstream system or feed owned by IT | The dependency, factually: what the feed lacks and since when | Name IT as owner or co-owner of the system action; keep your action separate | A manual detective check on the output until the feed is fixed, with a date you will stop |
| A policy or threshold set by a central function | The threshold’s effect on your control, with the numbers | Address the recommendation on the policy to that function | A compensating step in the band the policy leaves open |
| A capacity decision above you (vacancy freeze, budget) | The staffing against volume, dated, and what absorbed the shortfall | Report the cause at that level; auditors can write it there and will | Your executive decides: fund, redesign the process to need fewer hands, or accept the risk through the proper channel |
| A third party or vendor | The contractual or operational mechanism (delivery time, file format, SLA) | Route the vendor action through vendor management | Your own check on what the vendor delivers |
| A group-wide ownership gap (no owner for the end-to-end process) | The gap, and the other areas you know it touches | Raise one overarching finding instead of several local ones | Interim ownership of your segment, in writing, with an end date |
Where the honest answer is that the fix will not be funded, the correct path is formal risk acceptance by an executive with the authority to accept it. Under Standard 11.5, if management accepts a risk the chief audit executive believes exceeds the organization’s appetite, the CAE escalates to senior management and, if unresolved, to the board. That is not a threat; it is the mechanism that gets the decision made by the right person instead of by default.
The trap of a cause that implicates a person
Sooner or later a root cause session arrives at a name. One analyst performed every one of the exceptions; one approver waved every one through; one manager stopped running the review in March. The temptation is to write that down as the cause, because it is true in the narrow sense and it is comfortable for everyone else in the room. It is a trap for three reasons.
First, it fails the level test. If one person could cause the finding, the control depended on one person, and that dependence is the condition. Replace the person and the dependence remains. Second, it stops the learning. Matthew Syed’s argument in Black Box Thinking, summarized in the Black Box Thinking summary, is that blame drives reporting underground: once a root cause exercise is seen as a way of allocating fault, the people who know how the work really happens stop telling you. Third, an audit report is not a personnel document. In most functions (practitioner observation, not a rule in the Standards) the report names the action owner, usually an executive or senior manager, and nobody below; a cause that points at a named individual is unusable to the auditors and will be rewritten by them anyway. Dekker draws the same distinction between backward-looking accountability (who is to blame) and forward-looking accountability (who will do what so it does not recur). The audit report is a forward-looking document.
What to do instead depends on the facts, and one of the cases below is not a root cause question at all.
| If the facts are | Then the cause is | What to write | Handled where |
|---|---|---|---|
| The performer followed the procedure as written and it still failed | Design | The procedure or system condition; the person does not appear | The audit response |
| The performer deviated under time pressure, a conflicting target or a conflicting instruction | The pressure, target or instruction, and the absence of a check that would have caught the deviation | The condition and the missing detective layer, by role | The audit response |
| The performer lacked knowledge and nothing in the process supplied it | Information or capacity: how knowledge was supposed to arrive and did not | The distribution, acknowledgment or handover gap | The audit response |
| One person’s repeated non-performance went unnoticed for months | The oversight condition: no review, no metric, no record that would have revealed it | The missing review or metric, by role; any performance matter is a separate conversation | The audit response for the condition; HR for the person, separately and later |
| Evidence was altered, exceptions were concealed, or someone benefited | Not a root cause question | Nothing on the whiteboard; stop the session | A private conversation with the auditor the same day; see the first-48-hours protocol for what happens next |
Two practical rules. Keep the learning review and any performance process separate in time, in people and in paper; a session in which a manager is taking notes for a performance file is not a root cause session, and everyone in the room knows it. And if the auditors’ draft cause names or clearly identifies an individual, ask for it to be rewritten by role and condition, and offer the condition yourself. They will almost always agree, because their own craft for cause statements says the same: the subject of a cause is a control, system, process or role, never a named individual. This guide is general and educational; it is not legal or employment advice.
Worked example: Harbor Trust, a reconciliation finding
Harbor Trust is a hypothetical trust and custody bank. Its Client Accounting team reconciles the client omnibus cash account daily: the custody ledger against the depository bank’s statement. The procedure requires any break older than five business days, or larger than $10,000, to be escalated to the Head of Client Accounting, and the Head attests monthly to the Trust Operations Committee that no aged breaks exist. In an audit of client asset reconciliations, internal audit sampled 40 daily reconciliations from March to August 2026 and found 11 with breaks older than five business days that were not escalated. Three of the breaks exceeded $10,000; the largest, $186,000, stayed open for 23 business days before clearing. The monthly attestation reported no aged breaks in each of the six months. The draft finding was rated High and the draft cause read: “Reconciliation staff did not follow the escalation procedure; management oversight of the reconciliation process was insufficient.”
The Head of Client Accounting had a week. The first instinct, drafted on day zero and fortunately not sent, was: “Root cause: analyst workload following a staff departure in April. Corrective action: the vacancy has been filled and the team has received refresher training on the escalation procedure.” Run that against the five tests. It does not explain why the aging report showed zero aged breaks while a $186,000 item sat open for 23 business days (coverage); it does not explain the exceptions in March, before the departure (coverage again); it gives no reason to think the attestation would have been right with a third analyst (counterfactual); and its only forward-looking action is training, which sits in the weakest tier of the action hierarchy above. The auditors would have bounced it in an afternoon.
Days one and two: the data and the timeline
A peer manager from Fund Accounting facilitated. On day one the team pulled every daily reconciliation from January to August, 167 of them, deliberately wider than the audit’s March-to-August period so that a before-and-after view was possible; plus the reconciliation tool’s break aging report for each month, the tool’s change log, the staffing roster and daily volumes, the escalation mailbox, and the workpapers behind the six attestations. On day two the exception map showed two things the sample had not: the 11 sampled exceptions were part of 34 across the March-to-August population, and every unescalated aged break in the eight months, including the first few in late February, fell after the 14 February tool upgrade. The handful of aged breaks before that date had all been escalated on time. The timeline explained why.
| Date (2026) | Event | Source | Relevance |
|---|---|---|---|
| 14 February | Reconciliation tool upgraded to version 4.2 by the vendor | Tool change log; vendor release note | First aged, unescalated break appears two business days later |
| 14 February | Release changes the default basis of the “break age” field from days since origination to days since last activity | Vendor release note, page 6; configuration screen | Any break partially matched or re-keyed restarts at zero days |
| 2 March | Depository bank moves statement delivery from 06:00 to 09:30 | Bank notice; file arrival logs | Daily reconciliation now prepared against the prior day’s statement to meet the 10:00 cut-off, producing “timing” breaks that are re-keyed the next day |
| 10 April | One of three analysts leaves; backfill requested | Roster; requisition | Two analysts carry three workloads; partial matching increases |
| March to August | Monthly attestation prepared from the tool’s aging report | Attestation workpapers | Report shows zero aged breaks because of the field basis; all six attestations inherit the error |
| 21 July | Backfill starts | Roster | Volume pressure eases; aged breaks continue because the field basis is unchanged |
Day three: the session
Two analysts, the supervisor, the tool administrator, a Treasury Operations representative (the other side of most breaks) and the facilitator met for ninety minutes. The analysts narrated two of the exceptions. In both, they had seen the break, matched part of it against a next-day timing item, and watched the age reset to zero; from their chairs, the item was no longer aged and the procedure did not require escalation. That is local rationality in one sentence. The room then ran a chain of whys on the escalation failure, and a barrier analysis on why three separate controls had all reported a clean position.
| Why | Answer (written as a condition) | Evidence |
|---|---|---|
| Why were aged breaks not escalated? | The escalation trigger is the tool’s break-age field, and the field showed fewer than five days for every one of the 34 breaks | Aging reports for March to August; the procedure, step 7 |
| Why did the field show fewer than five days? | Since version 4.2 the field counts days since last activity, and each break had been partially matched or re-keyed within five days | Vendor release note; configuration screen; activity log on the $186,000 item showing four resets |
| Why was the basis of the field changed? | The release changed the default and the setting was never reviewed; the upgrade was treated as a vendor patch with no business sign-off on configuration | Change record: “vendor maintenance release, no business impact”; no Client Accounting approval on file |
| Why was there no business sign-off? | The tool’s change procedure classifies vendor releases as technical changes; no list exists of the configuration settings that controls depend on | IT change procedure, section 4; absence of a control-settings inventory |
| Why did nobody notice for six months? | The supervisor’s daily review and the monthly attestation both read the same aging report; no control reads the break population from origination date | Attestation workpapers; supervisor review checklist |
| Barrier | Should have | How it failed | Why | Shared dependency |
|---|---|---|---|---|
| Analyst escalation at five days or $10,000 | Raised each aged or large break | Failed on age; bypassed on amount | Age trigger read a field that reset; amount trigger relied on the analyst noticing a figure the tool did not flag | Break-age field |
| Supervisor daily aging review | Caught breaks the analysts missed | Failed | Reviewed the aging report, which showed none | Break-age field |
| Monthly attestation to the committee | Told leadership the true position | Failed | Prepared from the same aging report | Break-age field |
| Change control on the tool | Caught a change to a control-relevant setting | Absent for vendor releases | No business review step; no inventory of control-relevant settings | None; this is the upstream cause |
Days four and five: testing, writing, mapping
On day four the tool administrator re-ran the aging from January to August on an origination-date basis. All 34 breaks in the audit period appeared as aged, including the 11 in the audit sample; the breaks from before the 14 February upgrade had been escalated at the time and showed the same age on both bases. That passed coverage and the counterfactual in one report. The capacity question was tested too: partial matches per week rose from an average of 9 to 27 after the April departure and fell back to 12 after the July backfill, but aged breaks on the corrected basis continued through August. Capacity had widened the exposure and had not created it. The cause statement that went to the auditors on day five read as follows.
“Escalation of aged reconciliation breaks on the client omnibus cash account depends on the break-age field in the reconciliation tool. The vendor release of 14 February 2026 (version 4.2) changed the field’s default basis from days since origination to days since last activity, so any break partially matched or re-keyed restarted at zero. Because the analyst escalation trigger, the supervisor’s daily aging review and the monthly committee attestation all read the same field, none of the three could detect an aged break after that date; every unescalated aged break between January and August, including all 34 in the audit period and the 11 sampled, falls after it, and none falls before. The release was implemented under the tool’s change procedure as a technical vendor change with no business review of control-relevant settings, and no inventory of such settings exists. Contributing factor: from 10 April to 21 July two analysts covered three roles, which raised partial matching and widened the exposure; it did not create it. The cause is a system design cause with a governance cause upstream.”
| Cause clause | Action | Owner (role) | Target | Evidence of completion |
|---|---|---|---|---|
| Break-age field counts from last activity | Reconfigure to origination date; lock the setting; re-run aging for the open population | Head of Client Accounting with the tool administrator | 30 November 2026 | Configuration screen before and after; change record; re-run aging report |
| Three controls share one field | Add a weekly aged-break listing built from the depository statement side, outside the tool, reviewed by the supervisor | Client Accounting supervisor | 15 December 2026 | Six weekly listings with review sign-off |
| Amount trigger relies on the analyst noticing | Configure a tool alert for breaks over $10,000 at creation | Tool administrator | 30 November 2026 | Alert configuration; alert log |
| Attestation reads the same report | Amend the attestation to include a trace of the ten oldest breaks to origination date | Head of Client Accounting | January 2027 attestation | Revised attestation template; January workpaper |
| Vendor releases bypass business review; no settings inventory | Inventory of control-relevant settings; Client Accounting sign-off on any release that touches them | IT change manager (recommendation addressed to IT); Client Accounting to supply the inventory | 31 January 2027 | Inventory; revised change procedure; first release approved under it |
| Capacity (contributing) | Backfill complete; add a cross-trained backup from Fund Accounting; interim daily manual aged-break list from origination date until the configuration fix is validated | Head of Client Accounting | Interim list from 10 November 2026 | Roster; cross-training record; interim lists |
The auditors accepted the cause and rewrote their own. The finding stayed High, because six monthly attestations to a governance committee had been wrong and that effect does not shrink with a good explanation. But the report now described a system design cause with a governance cause upstream rather than staff who did not follow procedure; it addressed the change control recommendation to IT; and under Standard 15.1 it acknowledged the actions already started, including the interim listing and the re-run aging. Validation nine months later tested the configuration, sampled the weekly listings and the January attestation, and closed the finding at the first attempt, which is the point of the sustainability period the validators insist on. The first-draft response would have produced a training record, a filled vacancy, and the same finding in the following year’s plan.
Questions readers ask
What is the root cause of an audit finding?
It is the condition in a process, system, data flow or governance arrangement which, if changed, would stop the exceptions the auditors found from recurring. It is distinct from the direct cause (the event that immediately produced each exception) and from the condition (the exceptions themselves). A usable root cause can be pointed at in a document or on a screen and has an owner who can change it.
How do you do a root cause analysis for an audit finding?
Settle the facts first, then pull the full population, the exception list, the procedure history, the system change log, staffing and volumes, and the reports the control relies on. Build a timeline, run a 90-minute session with the people who do the work and a neutral facilitator, apply five whys, a fishbone or a barrier analysis depending on the finding’s shape, test the candidate cause against every exception, and write a five-part cause statement that maps clause by clause to actions. A week is enough for a single finding.
Is human error an acceptable root cause for an audit finding?
No. Human error describes what happened, not why the process allowed it to happen and go undetected. Auditors expect the condition behind the error: the form that accepts a blank field, the workflow with no delegate, the review that is shown nothing to review. The same applies to “training”, “oversight” and “workload” unless each is stated as a dated mechanism with evidence.
Can an audit finding have more than one root cause?
Yes, and many do: typically one design cause that created the exposure and one or two contributing factors that widened it. State them separately, label the contributing factors as contributing, and say what each did and did not do. Each cause that you keep should produce its own action; a contributing factor with no action is a risk you are choosing to accept and should be named as such.
Who is responsible for root cause analysis, the auditor or management?
Both, and the Standards say so: Standard 14.3 expects auditors to work with management to identify root causes where possible. In practice the auditors arrive with a hypothesis built from the evidence they gathered, and management holds the process knowledge to confirm or replace it. A management root cause that is better evidenced than the auditors’ draft usually becomes the cause in the report.
What is the difference between the cause and the root cause in an audit report?
In the five elements of a finding (criteria, condition, cause, effect, recommendation), “cause” is the slot and “root cause” is the standard the slot should meet. A finding whose cause is “the control was not performed” has filled the slot without finding the root. The guide to the 5 C’s explains how the elements fit together.
What if I cannot find the root cause within the week?
Tell the auditor before the deadline, not after, and send what you have: the timeline, the candidates you have ruled out and why, and the evidence still being pulled. Agree a short extension for the cause alone and an interim measure in the meantime. Most functions accept a well-documented “not yet” over a confident guess, because a guessed cause fails at validation and costs them a repeat finding.
Is there a template for an audit finding root cause analysis?
The tables in this guide are the template: the one-week plan and session agenda for the process, the barrier analysis table for a control failure, the five-part cause statement (control, condition, mechanism, extent, contributing factors), and the clause-to-action map. Copy the Harbor Trust tables, replace the content, and keep the column headings.
Related guides
- Being Audited? The hub — every guide for people on the receiving end of an audit, by stage.
- Root Cause Analysis for Audit Findings: 5 Whys Worked Examples — the auditor-side method, so you know what the team across the table was taught.
- Writing Cause Statements That Point to the Fix — the auditors’ sentence patterns and their checklist for the cause element.
- Writing Management Action Plans That Actually Close — owners, dates, interim measures and evidence once the cause is agreed.
- The 5 C’s of Audit Findings — how criteria, condition, cause, effect and recommendation fit together.
- When You Disagree With an Internal Audit Finding — disputing the facts or the rating, as distinct from the cause.
- Evaluating Management Responses — the tests the auditor runs on your response, from their side.
- Risk Acceptance by Management — the right process when the fix will not be funded.
- Control Ownership — getting a name on a control when the cause is “nobody owns this”.
- Management Responses to Audit Findings: 15 Examples From “Agree” to “Risk Accepted” — the finished response block your cause goes into, by situation.
- Remediating Audit Findings: The 90-Day Plan — running the actions, the evidence binder and the status report after the cause is agreed.
- Evidence Standards for Issue Closure — what validators will want to see for each action a year from now.
- The Field Guide to Understanding ‘Human Error’ (Dekker) — the case against “human error” as an explanation.
- Black Box Thinking (Syed) — why blame destroys the information a root cause session needs.
Leave a Reply