A finding is not a sentence in a report. It is a thing with a life: it is born as an exception on a testing sheet or a hit on an analytics run, it is corroborated or it dies, it is evaluated against criteria and rated, it is argued about with management, it is written, it is reported, it goes into a log, it gets an owner and a date, it is remediated or it is not, it is validated or it is closed on a promise, and a year later a different auditor finds it again or does not. Most audit functions manage the middle of that life well, the writing and the reporting, and manage the beginning and the end badly: exceptions are dropped without a record of why, and issues are closed on the day management says they are fixed. The five Cs tell you how to write the finding; this guide tells you what has to happen to it at every stage from the first exception to the last re-test, who owns each stage, what artifact each stage produces, which Global Internal Audit Standard governs it, and where findings die when they should not and survive when they should not.
The Standards frame the life in four places. Standard 14.2 governs the analysis that turns information into potential findings; Standard 14.3 governs their evaluation, which is where criteria, condition, cause and effect are established and significance is judged; Standard 14.4 governs recommendations and action plans; Standard 15.1 governs the final communication; Standard 15.2 requires the chief audit executive to confirm that recommendations or action plans have actually been implemented; and Standard 11.5 governs what happens when management decides to accept the risk instead. Everything between those points is the function’s own methodology, and it is where the quality of a function’s findings is decided. The guide follows one finding through its whole life, MidState Beverage’s bank-detail change finding, from an analytics hit to a High finding, through remediation, to a re-test that found it reduced to a Low a year later, with every date and artifact.
In this guide
- The twelve stages, their owners and their artifacts
- Birth: from exception to potential finding
- Evaluation: criteria, condition, cause, effect and significance
- Fact validation: how to run the conversation
- The four kill points, and the record every dropped finding needs
- The finding record: one template for the whole life
- Reporting: the finding meets its audience
- The afterlife: log, remediation, validation, closure
- Worked example: the life of MidState’s bank-detail change finding
- Timing: how long each stage should take
- Where findings die when they should not, and survive when they should not
- Common mistakes
- Where to go next
The twelve stages, their owners and their artifacts
The table is the whole guide in one place. Every stage has an owner, an artifact that proves the stage happened, a governing reference, and a characteristic failure. A function that can produce the artifact for every stage of every finding has a finding process; a function that cannot has a report-writing process with gaps at both ends.
| Stage | Owner | Artifact | Reference | Characteristic failure |
|---|---|---|---|---|
| 1. Exception | Auditor | The testing sheet line, analytics hit or walkthrough note, with the item identified | Standard 14.1 | Exceptions noted verbally and never written down |
| 2. Potential finding | Auditor | An entry in the potential findings list: what was observed, against what expectation, with the evidence reference | Standard 14.2 | Exceptions dropped as “immaterial” with no record of the judgment |
| 3. Corroboration | Auditor and reviewer | Additional evidence, re-performance or expanded sample; the exception confirmed or explained | Standard 14.2 | A single exception reported as a pattern, or a pattern dismissed as a single exception |
| 4. Evaluation | Auditor, then engagement lead | Criteria, condition, cause and effect written; significance assessed | Standard 14.3 | Cause stated as the condition restated; effect stated as “risk of” without a mechanism |
| 5. Fact validation | Engagement lead with management | Management’s confirmation of the facts, or their contrary evidence, recorded | Methodology | Facts negotiated instead of validated; the finding softened before it is rated |
| 6. Rating | Engagement lead, calibrated by the function | The rating with its basis against the function’s scale | Standard 14.3, and the severity guide | Ratings set by negotiation or by the auditor’s temperament |
| 7. Recommendation and action plan | Auditor proposes; management owns the plan | A recommendation addressing the cause; management’s action plan with owner and date | Standard 14.4 | Recommendations that restate the condition; action plans that promise a review |
| 8. Report | Engagement lead, chief audit executive | The finding in the final communication, with the rating, the response and the overall conclusion | Standard 15.1 | The finding rewritten for the audience until the condition disappears |
| 9. Log | Audit function | The issue log entry with every field the follow-up will need | Standard 15.2 | Findings logged with the report’s wording and none of the fields |
| 10. Remediation | Management | Evidence that the action plan was implemented, produced by management | Standard 15.2 | Status updates as evidence; “in progress” for years |
| 11. Validation and closure | Audit function | Independent confirmation that the action was implemented and operates, to an evidence standard by rating | Standard 15.2 | Closure on management’s assertion; validation of the action rather than the risk |
| 12. Re-test and aggregation | Audit function | The finding re-tested in the next engagement; themes across findings reported to the board | Standard 11.3 | Nobody looks again; the same finding reborn under a new number |
Birth: from exception to potential finding
Findings are born in three places. On the testing sheet, where an attribute fails: the approval that was not there, the reconciliation that was late, the receipt that did not match. On the analytics run, where a hit appears: the bank change followed by a payment, the duplicate invoice, the credit memo approved by its issuer. And in the walkthrough, where the process as performed turns out not to be the process as documented. In each case the birth is an act of recording, and the discipline is that every exception is written down at the moment it is found, with the item identified, the expectation it failed, and where the evidence sits, before anyone decides whether it matters. The model workpaper shows the form: a line on the disposition grid for every hit, including the ones that will be cleared, because the record of what was cleared and why is what a reviewer, a regulator or the next auditor will ask for.
The exception becomes a potential finding when the auditor decides it may indicate a control that did not operate, a process that does not exist, or a risk that is not managed, and puts it on the potential findings list, a running document the engagement lead reviews at least weekly. The list is where the first triage happens: is this one item or a pattern, is it a control failure or an error, does it need more evidence before anyone talks to management about it. An exception that is one item is still recorded, and may still be reported as an observation, but the list separates the items that need corroboration from the ones that already have it. A function that keeps no potential findings list will find, when it looks, that a third of its exceptions never became anything at all and nobody can say why.
Evaluation: criteria, condition, cause, effect and significance
Standard 14.3 requires findings to be evaluated by establishing the criteria, the condition, the cause and the effect, and by assessing significance. Each element is a question, and the order matters. Criteria first: what should be, stated with its source, a policy clause, a standard, a contract, a control description, or the organization’s own procedure, because a finding without a stated criterion is an opinion. Condition second: what is, stated as facts with numbers and denominators, which means the corroboration in stage 3 has to be finished before the condition can be written. Cause third, and this is the element that separates a finding from a complaint: why the gap exists, which is never “the control did not operate” and always something about design, resourcing, incentive, system configuration or knowledge that explains why it did not; the root cause analysis guide gives the method. Effect fourth: what the gap has done or could do, stated as a mechanism with a magnitude, actual losses where there are any and a plausible path to harm where there are not. Significance last, because it depends on all four, and it is assessed against the function’s scale in the severity ratings guide rather than against the auditor’s mood or the auditee’s reaction.
Two disciplines protect the evaluation. The first is that condition and cause are written before management is consulted, so that the facts are validated rather than negotiated; management can correct a fact and can disagree with a cause, and both are recorded, but the auditor writes first. The second is that significance is calibrated across the function, not decided engagement by engagement: a High in the payroll audit has to mean what a High means in the treasury audit, which requires a scale with anchors and a periodic review of ratings across reports, and is the reason the severity guide exists.
Fact validation: how to run the conversation
Stage 5 is a conversation, and it goes wrong when it is run as a negotiation or skipped as a formality. Its purpose is narrow: to confirm that the condition is factually right before it is rated and written for the report, and to hear management’s view of the cause while it can still change the evaluation. The script below is the one the sibling engagements on this site use; it takes twenty minutes per finding and it is the cheapest insurance a report can buy, because a finding whose facts management has confirmed in writing cannot be reopened in the draft stage on the facts.
Fact validation script. 1. Frame: “Before we evaluate this, I want to make sure the facts are right. I am going to read you what we found; tell me if anything is wrong, and if it is, show me.” 2. Condition: read the condition with its numbers and denominators and the evidence reference; pause after each number. 3. Correction: for anything management disputes, ask for the evidence, not the assurance; record what was produced; agree a date if it will take time. 4. Cause: “Here is why we think it happened. What is your view?” Record management’s cause beside the auditor’s; where they differ, both go in the record and the auditor’s evaluation says why one is preferred. 5. Fixes in progress: “Has anything already changed?” Record it, ask for the evidence, and note whether it addresses the condition or the cause. 6. What is not on the table: “We are not discussing the rating or the wording today; those come with the draft, and you will have the chance to respond to both.” 7. Close: summarize what was confirmed, what was disputed and what evidence is expected by when, and send it in writing the same day.
Step 6 is the one auditors skip and regret. A fact validation meeting that drifts into the rating becomes the negotiation stage 8 was supposed to contain, and it happens before the function’s calibration has been applied, which means the rating that reaches the draft has already been argued down once.
The four kill points, and the record every dropped finding needs
Findings die at four points, and three of the four deaths are legitimate when they are recorded and illegitimate when they are not. The table gives each kill point, the legitimate reason, the record required, and the illegitimate version that looks the same from outside.
| Kill point | Legitimate reason | Record required | The illegitimate twin |
|---|---|---|---|
| After corroboration | The exception was an error in the auditor’s test, a documented exception to the control, or a single item with no pattern and no consequence | The disposition grid line: what was checked, what explained it, who cleared it | “Immaterial” written by the auditor who found it, with no reviewer and no evidence of the check |
| After fact validation | Management produced evidence that the condition did not exist as stated | The evidence itself in the file, and the potential findings list updated with the reason | Management’s assurance that it does not happen, accepted without evidence |
| Fixed during fieldwork | Management corrected the condition and, where the cause was a one-off, the cause | The finding reported as fixed during the engagement, with the evidence of the fix; the cause still reported if it persists | The condition fixed for the sampled items only, and the finding dropped as resolved |
| Risk accepted | Management with the authority to do so accepted the risk after the finding was reported, and the acceptance is documented | The acceptance, its rationale, the approver, and the chief audit executive’s judgment under Standard 11.5, with escalation to the board where the CAE disagrees | Management declined to act and the finding was quietly downgraded or closed |
The common thread is the record. A finding that dies with a record is a finding the function can defend to a regulator, an external auditor or an audit committee that asks why something was not reported; a finding that dies without one is indistinguishable from a finding that was suppressed, and a function’s credibility rests on the difference being visible.
The finding record: one template for the whole life
Most functions hold a finding in three or four documents that do not agree with each other: the workpaper, the report, the issue log and the follow-up file. The finding record below is one template whose fields are filled in as the finding moves through its stages, and which becomes the issue log entry when the report is issued. It is the same record the issue log template is built from, expanded to the stages before the report.
Finding record. 1. Origin: the engagement, the test or analytic, the item or hit, the date found and the auditor. 2. Potential finding: the observation in one sentence and the expectation it failed; the date added to the list. 3. Corroboration: the additional evidence obtained, the sample expanded to, and the result: confirmed as a pattern, confirmed as a single item, or cleared, with the reviewer. 4. Evaluation: criteria with source; condition with numbers and denominators; cause; effect with mechanism and magnitude; the date written. 5. Fact validation: the management contact, the date, the facts confirmed, the facts disputed with management’s evidence, and the resolution. 6. Rating: the rating, the scale anchor it meets, and the calibration reviewer. 7. Recommendation and action plan: the recommendation addressing the cause; management’s action plan, owner, target date, and whether the plan addresses the cause or only the condition. 8. Report: the report reference, the finding number, and the report date. 9. Remediation: management’s status updates with dates and the evidence provided at each. 10. Validation: the evidence standard for the rating, the validation performed, the date, the validator, and the result: closed, closed with residual, or reopened. 11. Re-test: the next engagement that will re-test the control, and its result when known. 12. Disposition history: every change of rating, date or owner, with who approved it and why.
Reporting: the finding meets its audience
Standard 15.1 requires the final communication to include the engagement’s objectives, scope and conclusions, the findings with the elements from Standard 14.3, the recommendations or action plans, and ratings where the function uses them. The reporting stage changes a finding in two ways that the earlier stages have to anticipate. It compresses it: the evaluation that ran to a page in the workpaper becomes a paragraph, and the compression has to keep the criteria, the numbers and the cause, because those are what a reader acts on; the report library shows the compression done well and the report template gives the structure. And it exposes it to negotiation: the draft goes to management, and the stage-5 validation of facts turns into a stage-8 argument about wording, rating and consequence. The discipline is that facts were validated in stage 5 and are not reopened in stage 8; wording can change, the rating can be re-argued against the scale’s anchors, and the condition cannot be softened without new evidence. The report writing guide covers the craft, and the finding’s rating is reported with the basis that stage 6 recorded, which is what makes the rating defensible when the audit committee asks why a Medium is not a High.
The afterlife: log, remediation, validation, closure
The report is the midpoint of a finding’s life, not the end, and the second half is governed by Standard 15.2: the chief audit executive must confirm that the recommendations or action plans have been implemented. Four stages carry it. The log entry is the finding record with its report fields filled and its follow-up fields open, and the issue log template sets out the fields that make follow-up work: owner, target date, rating, the action’s relationship to the cause, and the evidence standard closure will require. Remediation is management’s work, and the function’s job during it is to track status against the target date, to distinguish a status update from evidence, and to escalate slippage under a rule that everyone knows in advance; the issue tracking guide covers the mechanics and the high-risk issues guide covers why a High is tracked differently from a Low. Validation is the function’s independent confirmation that the action was implemented and that it operates: for a High that means re-performance on post-remediation data, for a Medium inspection of the implemented control and a small sample, for a Low management’s evidence reviewed; the issue validation guide sets the standard by rating, and the validation workpaper guide shows what the file looks like. Closure is a decision with three possible outcomes, closed, closed with a residual finding at a lower rating, or reopened, and the outcome is recorded in the finding record’s disposition history with the validator’s name, because closure is the stage regulators examine most closely and the one functions document least.
Regulatory findings follow the same life with a harder afterlife: the MRA and MRIA lifecycle guide covers how a bank’s regulator expects remediation to be validated before it will close a matter, and the validation standard it describes is the one a mature function applies to its own High findings.
Worked example: the life of MidState’s bank-detail change finding
MidState Beverage, the three-state drinks distributor used across this site, has one finding whose whole life is written up in the sibling guides: the vendor bank-detail change control. The table follows it from the analytics hit to its re-test a year later, with the stage, the date by month of the FY27 and FY28 audit years, the artifact and what happened.
| Stage | When | Artifact and what happened |
|---|---|---|
| 1. Exception | FY27, March | The function’s first AP analytics run flagged 46 vendor bank-detail changes in fourteen months, 14 of them followed by a payment above 25,000 dollars within ten days; each hit recorded on the triage grid |
| 2. Potential finding | March | Entered on the run’s potential findings list as a possible failure of the call-back control, with the 14 change-then-payment hits marked for corroboration first |
| 3. Corroboration | April, in the AP audit | All 46 changes tested in the accounts payable audit: 31 had no evidence of a call-back to a known contact; one of the 14 was a business email compromise attempt stopped by the bank, not by the control |
| 4. Evaluation | May | Criteria: the AP procedure requiring an independent call-back before any bank change takes effect. Condition: 31 of 46 without evidence, 14 preceding large payments. Cause: changes accepted from emailed remittance letters by AP clerks with no system enforcement and no monthly change review sign-off. Effect: one attempted diversion of 62,000 dollars stopped by the bank rather than by the control; the fourteen large payments made within ten days of a change exposed to the same mechanism. Significance: High |
| 5. Fact validation | May | The AP manager confirmed the 31 and produced call-back notes for none; disputed the cause as “the bank would catch it”, recorded and rejected with the bank’s own letter |
| 6. Rating | May | High, against the scale’s anchor for a control failure with a demonstrated loss path; calibrated by the audit manager against the year’s other Highs |
| 7. Recommendation and action plan | June | Recommendation: system-enforced dual approval with a verification record before a change takes effect. Action plan: a vendor portal with dual approval by September, a master-data analyst at head office by October, the monthly change review signed off from July; owner the controller |
| 8. Report | July | Finding 2 of eight in the AP report, one of four Highs; overall rating Needs Improvement; audit committee briefed on the stopped attempt |
| 9. Log | July | Issue log entry with owner, three dated actions, and the validation standard set at re-performance on post-remediation changes |
| 10. Remediation | July to October | Monthly review signed from July; portal live in September with dual approval enforced; analyst in post in October; status updates with evidence at each step |
| 11. Validation and closure | FY27, December | Twenty post-remediation changes re-performed: all dual-approved through the portal with a verification record; closed, with a note that the verification record’s channel-independence element was not yet a mandatory field |
| 12. Re-test | FY28, the vendor master audit | 52 changes in the year: all dual-approved; 49 with a complete record; three missing the channel-independence line, two followed by payments, both genuine. Reported as a Low, the finding’s residual, with the mandatory field as the action |
Three things about that life generalize. The finding was strong because stage 3 was thorough: all 46 changes tested, not a sample, so that the condition was a population statement management could not argue with. The closure in December was correct and incomplete at once, and the record says so; the residual the re-test found a year later was the element the closure note had flagged, which is what a good disposition history does. And the finding’s effect was written around one stopped attempt, which is what made a control finding about paperwork into the High the audit committee remembered: the effect element is where a finding earns its rating, and it was earned with a bank’s letter rather than an auditor’s adjective.
Timing: how long each stage should take
Findings decay when they wait. An exception found in week two and evaluated in week six has lost the context the auditor had when it was found; a report issued three months after fieldwork reports conditions that may no longer exist; a validation performed two years after closure was requested validates a memory. The table gives the intervals a well-run function holds itself to, and the metric that shows whether it is holding them.
| Interval | Target | Metric to report |
|---|---|---|
| Exception to potential findings list | Same day | Exceptions on testing sheets not on the list at the weekly review |
| Potential finding to corroborated or cleared | Within the fieldwork week it arose, or the next | Open potential findings older than two weeks |
| Corroboration to written evaluation | Three working days | Findings evaluated after fieldwork ended |
| Evaluation to fact validation | Five working days, and before fieldwork closes | Findings validated after the closing meeting |
| Fieldwork close to draft report | Ten working days | Days from last fieldwork day to draft |
| Draft to final | Fifteen working days, with management’s response inside it | Days from draft to issue; drafts older than thirty days |
| Final report to log entry | Same day | Reports issued with no log entries |
| Target date to validation started | Within thirty days of the target date, or of management’s claim of completion | Issues past target date not yet validated |
| Closure to re-test | The next engagement covering the control, and no later than eighteen months for a High | Closed Highs not re-tested within eighteen months |
Where findings die when they should not, and survive when they should not
A function can test its own finding process by looking for the eight patterns below in its last year of engagements. Four are premature deaths and four are undead findings; both kinds are visible in the records if the records exist, and their absence is visible if they do not.
| Pattern | How to detect it | What it costs |
|---|---|---|
| Exceptions that vanish between the testing sheet and the potential findings list | Count exceptions on testing sheets against entries on the list for three engagements | Findings the function never knew it had; a regulator who finds them first |
| Findings softened at fact validation without new evidence | Compare the stage-4 condition to the reported condition; look for numbers that shrank | A report that understates what the file shows |
| Ratings negotiated in the draft stage | Compare stage-6 ratings to reported ratings; every downgrade should have a recorded basis against the scale | A rating scale that means nothing; committee attention misdirected |
| Findings “fixed during fieldwork” on the sampled items only | Check whether the cause was reported and whether the population was fixed | The same finding next year, larger |
| Findings closed on assertion | Look for closures with no validation artifact, or validation of the action rather than the risk | Issues the board believes are fixed and are not |
| Findings carried for years as “in progress” | Age the log; anything past two target-date extensions is either accepted risk or a governance failure | A log that hides risk acceptance from the board |
| Findings that survive the cause being removed | Look for issues still open after the process, system or entity they related to has gone | Noise that buries the real open items |
| Findings reborn under a new number | Match this year’s findings to closed findings by control and process | Validation that did not validate; the credibility of every closure |
Common mistakes
Writing the finding before corroborating it, so that the condition is a sample statement dressed as a population statement. Stating the cause as the condition in different words (“the control did not operate because approvals were not obtained”). Letting the effect be “there is a risk that” with no mechanism, no magnitude and no example, which is why so many Highs read like Lows. Validating facts and negotiating ratings in the same meeting. Accepting an action plan that promises a review, a reminder or a training session when the cause was a design gap. Logging the report’s paragraph instead of the finding record’s fields. Treating a status update as evidence. Closing on management’s word because the target date has arrived. Setting one evidence standard for closure regardless of rating, which either wastes hours on Lows or under-validates Highs. And never re-testing, which is the mistake that makes all the others invisible.
Where to go next
Give every finding a record from the day it is born, and fill the record in at every stage rather than reconstructing it for the file review. Corroborate before evaluating, evaluate before consulting, validate facts before negotiating words, calibrate ratings across the function, log the fields the follow-up needs, and close only on evidence proportionate to the rating. The writing of the finding is covered in the five Cs masterclass, its rating in the severity ratings guide, its cause in the root cause analysis guide, its afterlife in the issue validation guide and the issue log template, and its most difficult death, acceptance by management, in the risk acceptance guide.
Related guides
- The 5 C’s of audit findings — the writing of stage 4 and stage 8, with dissected examples
- Finding severity ratings — the scale and the anchors stage 6 is calibrated against
- Root cause analysis for audit findings — the method behind the cause element
- Evaluating control deficiencies — from exception to material weakness, the SOX version of stages 3 to 6
- Internal audit report examples — the compression of stage 8 done well
- The internal audit report template — where the finding sits in the report
- How to write an internal audit report — the craft of stage 8
- The finding and issue log template — the record after the report
- Issue validation in internal audit — the evidence standard by rating
- Issue validation workpapers — what the validation file looks like
- Tracking internal audit issues — the mechanics of stage 10
- Treating high-risk issues differently — why a High’s afterlife is tracked differently
- The MRA and MRIA lifecycle — the regulatory version of the same life
- Annotated workpaper examples — the disposition grid where findings are born
- How to audit accounts payable — the engagement that reported the worked example’s finding
- How to audit the vendor master file — the engagement that re-tested it
- The accounts payable analytics catalog — the run that found it
- Findings and reporting guides and issue validation guides — the full collections
- Evaluating Management Responses — when to accept an action plan and when to push back.
- Anatomy of an Internal Audit Report — structures that serve every reader.
- Negotiating Audit Findings Without Watering Them Down — scripts and escalation ladders.
- Writing Airtight Audit Conditions — stating what is, without editorializing.
- Writing Cause Statements That Point to the Fix — causal logic on paper.
- Writing Impact That Lands — audit consequences in dollars, risk and plain sight.
- Writing Audit Recommendations Management Can Actually Implement — owners, dates and end states.
- Finding Makeovers — five real-shaped audit findings rewritten before your eyes.
Leave a Reply