The cause is the element auditors write last and worst. The condition was earned in fieldwork, the criteria were copied from the policy, and the consequence was argued out at the closing meeting; the cause was typed in the week the draft was due, and it says, in one form or another, that the control did not operate because the control was not operated. That sentence is not a cause. It is the condition with the word “because” in front of it, and its effect on the finding is precise: the action plan that answers it will be a reminder to operate the control, the reminder will be issued, the finding will be closed, and the condition will return in the next audit under a new number. Standard 14.3 requires the evaluation of findings to establish the cause, and the whole value of the requirement is that a cause stated at the right level produces an action plan that changes something.
This guide is about writing causes that point to the fix. It covers what a cause is and the level at which it has to be stated, the six families every cause belongs to and the action type each implies, how to run the chain of whys and where to stop, the sentence patterns that put causal logic on paper, the causes that blame and how to rewrite them, what to do when management’s cause differs from the auditor’s, how the cause affects the rating, a checklist, ten causes from the engagements on this site rewritten from their first drafts, and the mistakes that keep producing reminders. It is the second of five guides on writing the elements of a finding, after conditions and before impact, recommendations and the makeovers, and it builds on the root cause analysis guide, which covers the analysis; this guide covers the sentence.
In this guide
- What a cause is, and the level it has to be stated at
- The six cause families, and the action each implies
- The chain of whys, and where to stop
- Interviewing for cause: five questions
- Evidence for the cause: what goes in the file
- Causal logic on paper: the sentence patterns
- Causes that blame, and how to rewrite them
- When management’s cause differs
- How the cause affects the rating
- Causes across findings: the systemic cause
- When the cause was wrong: what follow-up reveals
- The cause checklist
- Ten causes rewritten
- Common mistakes
- Where to go next
What a cause is, and the level it has to be stated at
A cause is the reason the gap between the criteria and the condition exists, stated at the level at which the organization can change it with reasonable effort. Every clause of that definition does work. “The reason the gap exists” excludes the condition restated and the criteria restated; the cause explains, it does not describe. “At the level at which the organization can change it” excludes both the too-shallow cause, the clerk who did not perform the step, which the organization cannot change by acting on the clerk, and the too-deep cause, the culture, the history, the industry, which the organization cannot change at all. “With reasonable effort” is the stopping rule: the chain of whys is followed until it reaches a thing that has an owner, a budget and a plausible fix, and it stops there even if another why is available.
Causes live in a chain. The proximate cause is the thing that happened just before the condition: the clerk accepted an emailed remittance letter. The contributing causes are the conditions that let the proximate cause produce the gap: nobody checked the change before it took effect; the monthly change review was produced but not signed off. The root cause is the thing that, if changed, removes the contributing causes: the workflow does not enforce a verification step before a bank change takes effect, because it was built for speed during the depot roll-out and exempted from the block that applies to other changes, and nobody has owned the change process since. A finding can state more than one level, and the best ones do, because the reader who owns the proximate fix and the reader who owns the root fix are different people. What a finding cannot do is state only the proximate cause and call it root, which is what “the control did not operate because the clerk did not perform the call-back” does.
The six cause families, and the action each implies
Almost every root cause in an audit finding belongs to one of six families, and naming the family is the fastest check that the cause has been stated at the right level, because each family implies an action type, and a cause whose implied action does not match the plan management proposed is a cause that has not landed.
| Family | The cause says | Example | Action type it implies |
|---|---|---|---|
| Design | The control, system or process is built so that the condition can occur | The workflow permits the user who enters a route-cash adjustment to approve it; the routing rule was exempted from the self-approval block | Configuration or process change |
| Capacity and capability | The people responsible cannot do the work in the time or with the skills they have | Two accountants own 140 of the 410 reconciliations alongside the post-close journals | Staffing, redistribution, training that is specific |
| Incentive and pressure | The measures, targets or budgets reward the condition | Plant managers spend repair budgets to avoid capital approval, so improvements are expensed | Change to targets, thresholds or approval design |
| Information | The people responsible did not have the data or the visibility to act | The certification form does not display the tool’s exception status, and is completed by delegates | Reporting, system output, monitoring |
| Ownership and governance | Nobody owns the process, or the owner lacks authority | The complementary user controls in the provider’s SOC 1 report were listed and assigned to no one | Assignment, charter, escalation path |
| Change | A migration, acquisition, reorganization or departure broke a control that used to work | The acquired distributors’ credit workflow was not integrated when their revenue was; 22 close tasks lost their owner at a departure | Completion of the change, with a control over future changes |
The families overlap and a cause may name two: a change cause usually produces a design or ownership cause, and an incentive cause usually has an information cause beside it. The discipline is to name the family the action plan will have to address, and to write the cause so that a reader can see which family it is without being told.
The chain of whys, and where to stop
The method for finding the cause is the one every quality discipline uses: ask why, answer with a fact, and ask why of the answer, until the answer is a thing the organization can change. The table runs the chain on MidState Beverage’s bank-detail change finding from the accounts payable audit, and it shows the two things the method teaches. The first is that each answer has to be a fact the auditor can evidence, not a guess; the chain is an investigation, and the workpapers have to show the interviews and documents that support each link. The second is where to stop. The chain below could continue: why was nobody assigned to own the change process after the migration? Because the migration project closed without a handover. Why? Because the project’s closure checklist had no line for control ownership. That is true, and it is a finding about project governance, not about bank changes; the bank-change finding stops at the level with an owner who can fix it this quarter, and the project governance point goes to the potential findings list for the next engagement or into a separate finding if the evidence supports one.
| Why | Answer, with evidence | Level |
|---|---|---|
| Why were 31 of 46 bank-detail changes made without a call-back record? | AP clerks accepted emailed remittance letters as the source of the change and keyed them directly (interview, change log) | Proximate |
| Why did the clerks key them directly? | The procedure requires a call-back but the system does not require one before the change takes effect; the change is live on save (configuration inspection) | Contributing: design |
| Why was the monthly change review not catching it? | The review report was produced by the system but not signed off by anyone; there was no evidence it was read (report log, absence of sign-off) | Contributing: information and ownership |
| Why is there no enforcement and no reviewer? | The bank-change workflow was built for speed during the depot roll-out, exempted from the dual-approval requirement applied to other master-data changes, and never revisited; the master-data role that would have owned it was not created when the acquired distributors were migrated (project records, org chart) | Root: design and change |
| Stop | The root has owners (the controller for the workflow, the CFO for the role) and a plausible fix (portal with dual approval; master-data analyst); the next why is a project governance finding |
Interviewing for cause: five questions that get past the first answer
The chain of whys is run in interviews, and the first answer in every interview is the proximate cause offered by someone who would rather the conversation stopped there. The five questions below get past it without confrontation; they are asked of the process owner and of the person who performs the step, separately, because the two answers usually differ and the difference is often the cause.
Cause interview questions. 1. “Walk me through what happens when a change like this arrives, from the moment it lands to the moment it takes effect. What does the system make you do, and what does it let you skip?” (design) 2. “If you did this step the way the procedure says, every time, what would it cost you in time, and what would you have to stop doing?” (capacity) 3. “What are you measured on, and what happens when this step slows that down?” (incentive) 4. “What would you have needed to see, and from whom, to know this was going wrong before we found it?” (information) 5. “Who owns this process, who could change the system if it needed changing, and when did that last happen?” (ownership and change)
The answers are recorded in the interview note with the question, and the cause sentence cites them. A cause that cannot point to an interview note or a document for each link is a hypothesis, and the finding should say so or the auditor should go back and ask.
Evidence for the cause: what goes in the file
The condition’s evidence is the grid; the cause’s evidence is more varied and more often missing. For a design cause, the file holds the configuration extract, the workflow diagram or the screenshot that shows the system permitting the condition, dated, because configurations change. For a capacity cause, it holds the allocation: who owns how many reconciliations, how many hours the step takes, what else the same people do, from the calendar or the task tool rather than from an estimate. For an incentive cause, it holds the measure or the threshold and the evidence that behavior clusters around it: the histogram under the approval limit, the budget line the repairs were coded to. For an information cause, it holds the report that was not produced or not read, and the evidence of who received it. For an ownership cause, it holds the org chart, the process document with no owner named, the SOC 1 report with the complementary controls listed and no assignment. For a change cause, it holds the project record, the migration mapping, the departure date. The reviewer’s test of a cause is the same as the reviewer’s test of a condition: every clause traces to a document, and the document is in the file. A cause with no evidence reads as an opinion in the closing meeting and is treated as one.
Causal logic on paper: the sentence patterns
A cause sentence has a mechanism in it: something that, being the way it is, produces the condition. The patterns below put the mechanism in the grammar, so that a sentence written in one of them cannot be the condition restated. The first pattern is the workhorse: “[The control or process] [does or does not do X] because [design fact], so [the condition can occur].” The second is for absences: “No [control] exists for [population]; [the gap arose when].” The third is for capacity and incentive: “[The people] [cannot or are rewarded not to] [do X] because [fact about resources or measures].” The fourth is for change: “[The change] [moved or removed] [the control] without [replacement], and [nobody has owned it since].” The table sets weak sentences against strong ones for the same finding.
| Weak cause | Why it is weak | Strong cause |
|---|---|---|
| “The call-back control was not performed.” | The condition restated | “The system applies a bank-detail change on save without requiring a verification record, so a clerk who accepts an emailed letter can make the change effective alone; the monthly change report that would catch it is produced but has no reviewer.” |
| “Staff were not aware of the credit policy.” | A guess about knowledge, offered as a fact | “The acquired depots’ order system carries no approval routing for credit memos, so the issuing representative approves by default; the migration integrated their revenue into the ERP without integrating the credit workflow.” |
| “There was insufficient oversight of sole-source awards.” | “Insufficient oversight” is a verdict with no mechanism | “The policy permits sole-source awards on a justification memo but sets no standard for what the memo must demonstrate, requires no market check, and routes approval to the same level as a competed award, so an assertion of uniqueness is accepted as a demonstration of it.” |
| “The close process needs improvement.” | Topic, not cause | “Two accountants own 140 reconciliations and the post-close journal work that corrects what the reconciliations miss; the reconciliation tool permits aged items to roll forward without re-investigation; and the status report is produced but not escalated, so lateness in reconciliations becomes post-close entries rather than a signal.” |
| “Management did not review the certifications adequately.” | Blame plus “adequately” | “The certification form lists accounts and a signature line, does not display the reconciliation tool’s exception status, and is completed by the owner’s delegate in most business units, so an owner can certify an account with an open exception without seeing it.” |
Causes that blame, and how to rewrite them
Blame in a cause statement is not only unkind; it is inaccurate, because it names a person where a mechanism was needed, and it produces an action plan aimed at the person. “The AP manager failed to enforce the procedure” invites a plan that reminds the AP manager, and the next AP manager inherits the same workflow. The rewrite rule is that the subject of a cause sentence is a control, a system, a process, a document, a role or a measure, never a named individual and rarely “management”. Where a person’s action was in fact the proximate cause, the sentence states the action without the verb of failure (“the clerk keyed the change from the emailed letter”) and then states the design that made the action effective. Where the cause is a role rather than a person, the role is named (“no role owns the bank-change process since the migration”). Where the cause is management’s decision, the decision is named as a decision with its rationale (“the routing rule was exempted from the self-approval block to speed the roll-out”), because a decision with a rationale can be revisited and a failure cannot. The test is whether the cause would still be true if every person in it were replaced tomorrow; if it would, it is a cause, and if it would not, it is an accusation.
When management’s cause differs
Management often has a different cause, and sometimes a better one, because they know the process. The fact validation conversation asks for their view before the evaluation is finished, and the rule for what happens next is simple: where management’s cause is supported by evidence the auditor did not have, the auditor’s cause changes; where the two causes differ on judgment, both are stated, the auditor’s in the finding with the reasoning and management’s in the response, and the action plan reveals which one management actually holds, because plans address the cause their author believes. Brightwater’s head of procurement believed the sole-source condition was caused by buyer inexperience, and the audit believed it was caused by a policy with no memo standard; the action plan management eventually wrote adopted the memo template and the market check, which is to say it addressed the audit’s cause, and the report recorded both views without needing to declare a winner. The management responses guide covers the evaluation; the cause element’s job is to be stated clearly enough that the comparison can be made.
How the cause affects the rating
The rating is driven by the consequence, but the cause moves it in two ways that the severity ratings guide makes explicit. A design cause means the condition will recur for the whole population until the design changes, which pushes a finding toward the anchor for a control absent by design; a capacity or change cause means the condition is bounded by the circumstance that produced it and may already be receding, which is worth stating. And a cause that reaches ownership or governance, nobody owns this process, usually means the finding is broader than the process it was found in, and the rating and the report’s overall conclusion should reflect that the same cause probably operates elsewhere. The cause therefore has to be written before the rating is set, not after, and a rating set from the condition alone is provisional until the cause is known. The practical sign of a cause written after the rating is a cause that has been fitted to it: a High with a cause that says “a clerk made an error” is either an over-rated finding or an under-investigated one.
Causes across findings: the systemic cause and the thematic report
When the causes of a report’s findings are written properly, a pattern often appears that no single finding shows: three findings in different processes with the same root. MidState’s order-to-cash report had nine findings, and the causes of six of them named the same thing, the acquired distributors’ processes integrated for revenue but not for controls; Pennine’s close report had nine, and the causes of five named the same two accountants and the same unescalated status report. A cause that recurs across findings is a finding in its own right, at a higher level, and the report should say so: in the executive summary as one of the three messages, and in an overarching finding whose condition is the recurrence itself (“six of the nine findings in this report arise in the two acquired depots and share the cause that their order, credit and settlement processes were not migrated to the group’s controls when their revenue was”) and whose action plan is the one that fixes all six. Across reports, the same logic produces the thematic analysis the chief audit executive brings to the audit committee: the causes of the year’s High findings, grouped by family, tell the board what kind of organization it is running, and the life of a finding treats that aggregation as the finding’s last stage.
When the cause was wrong: what follow-up reveals
Follow-up is where causes are tested, because a fix that addressed the stated cause and did not remove the condition proves the cause was wrong or incomplete. Brightwater’s threshold-clustering finding was fixed at the 10,000-dollar plant limit and the clustering reappeared at the 100,000-dollar tender threshold a year later; the original cause, “the plant limit’s approval logic permitted splitting”, was true and too narrow, and the fuller cause, “the monitoring of every threshold in the ladder was absent”, only became visible on re-test. The right response is not embarrassment but a record: the reopened finding states the original cause, what the fix changed, what the re-test found, and the revised cause, so that the function learns what kind of cause it tends to under-state. Most functions, on running that exercise across a year of reopened findings, find the same thing: the causes stopped one why too early, at the place where the fix was cheap.
The cause checklist
Cause checklist. 1. The sentence contains a mechanism: something that, being the way it is, produces the condition. 2. It is not the condition with “because” in front of it. 3. Its subject is a control, system, process, document, role, measure or decision, not a person and not “management”. 4. It would still be true if everyone involved were replaced tomorrow. 5. It names a family: design, capacity, incentive, information, ownership, change. 6. Each link in the chain of whys has evidence in the file. 7. It stops at a level with an owner, a budget and a plausible fix. 8. The proximate cause is stated where it helps the reader, and labeled as proximate. 9. Management’s view was sought before the evaluation was finished, and is stated where it differs. 10. The action plan proposed addresses the thing the cause names; if it does not, either the cause or the plan is wrong. 11. The cause was written before the rating was set. 12. A reader who owns the process could read the cause and know what to change on Monday.
Ten causes rewritten
| First draft | Family it should have named | Rewritten |
|---|---|---|
| “Rate changes were approved by the same person who entered them because the HR administrator did not follow the segregation requirement.” | Design | “The HR workflow allows the user who enters a rate change to approve it; the enter-and-approve roles were combined in one profile when the workflow was configured, and no periodic review of workflow roles exists to catch it.” |
| “Expense approvals are rubber-stamped because approvers are too busy.” | Design and information | “The expense system routes flagged items to the approver with no requirement to comment before approval, presents reports in bulk, and reports no approval-velocity or flag pass-through metric to anyone, so an approver can clear forty reports in three minutes without any signal reaching management.” |
| “Post-close journals are high because the close is under time pressure.” | Capacity and design | “Reconciliation differences and pack errors are corrected after the deadline by journal because the workflow does not distinguish post-close entries from in-period ones, and the two accountants who own the affected reconciliations also book the corrections, so the deadline moves the work rather than the control.” |
| “Assets were expensed because plant staff misunderstood the capitalization policy.” | Incentive | “Capital requests above 25,000 dollars require plant-level approval that takes weeks, and repair budgets do not, so plant managers code improvements to repairs; the invoice coding is performed by accounts payable clerks from the description, with no capitalization review above the threshold.” |
| “Credit holds were released inappropriately by depot managers.” | Design | “The order system grants hold-release rights to depot managers as well as to credit, a configuration inherited from the acquired distributors’ setup, and no release report reaches the credit function.” |
| “Reconciling items were carried forward because preparers were not diligent.” | Design and information | “The reconciliation tool permits a prior month’s items to roll forward without re-dating or re-investigation, the aged-item report is produced but not escalated, and preparers on eight accounts hold posting rights to the accounts they reconcile.” |
| “The sanitation chemicals emergency recurred because procurement was not monitoring sole-source awards.” | Design and ownership | “The emergency-purchase rule requires a follow-up competition for the ongoing need but assigns no owner and no date to it, so an emergency award renews by default each quarter.” |
| “Certifications were signed over exceptions because owners were careless.” | Information | “The certification is a list of accounts with a signature line; it does not display the reconciliation tool’s status, and delegates complete it in most business units, so an owner has no visible reason not to sign.” |
| “The provider’s complementary controls were not performed because nobody read the SOC 1 report.” | Ownership | “The SOC 1 report is received by procurement and filed; the complementary user controls it lists have never been assigned to an owner on MidState’s side, and no reliance review is scheduled, so the controls exist in a document rather than in a role.” |
| “Ghost employee indicators were not detected because HR did not run the analytics.” | Information and change | “No analytic over the payroll and HR masters had been run before this engagement; the two acquired distributors’ employees were loaded to the platform without a duplicate-bank-account check, and no periodic reconciliation of the two masters exists.” |
Every first draft above contains a person or a group doing something wrong, and every rewrite contains a mechanism that would produce the condition with any people at all. That is the whole transformation, and it is the one that turns a reminder into a configuration change.
Common mistakes
Restating the condition with “because”. Naming a person, a team or “management” as the cause. Stopping at the proximate cause because the root is uncomfortable, or going past the root into culture because the root is too specific. Writing the cause after the rating and fitting it to the rating. Guessing at knowledge or intent (“staff were unaware”, “management did not prioritize”) without evidence. Writing a cause with no family and therefore no implied action. Accepting management’s cause because it was offered, or rejecting it because it was theirs. Omitting the evidence for the chain from the file. And the mistake that contains the others: writing the cause in the week the draft is due, when the interviews that would have answered the whys are over.
Where to go next
Ask why until the answer has an owner, write the mechanism into the sentence, name the family, keep people out of the subject, and write the cause before the rating. The analysis behind the sentence is in the root cause analysis guide; the element before it is in writing airtight conditions; the element after it is in writing impact that lands; the plan that has to address it is in writing recommendations and evaluated in the management responses guide; and all four elements are assembled in the finding makeovers.
Related guides
- Root cause analysis for audit findings — the analysis behind the sentence
- Writing airtight conditions — the element before
- Writing impact that lands — the element after
- Writing recommendations management can actually implement — the plan that must address the cause
- Finding makeovers — five findings rewritten element by element
- The 5 C’s of audit findings — the structure
- Evaluating management responses — the cause test an action plan has to pass
- The life of a finding — where the cause is written and validated
- Finding severity ratings — how a design cause moves the rating
- Preventive, detective and corrective controls — the design vocabulary causes are written in
- Segregation of duties beyond the ERP — the most common design cause, explained
- How to audit accounts payable — the engagement behind the chain of whys
- Writing guides and findings and reporting guides — the full collections
- Anatomy of an Internal Audit Report — structures that serve every reader.
- Negotiating Audit Findings Without Watering Them Down — scripts and escalation ladders.
Leave a Reply