An audit function is judged, in the end, by whether anything changes because of it, and the issue log is the only document that answers the question. It is also the document most functions keep worst: a spreadsheet with a column called “status” that means whatever the last person to type in it meant, due dates that have been revised so often the original is unknowable, items closed because an email said they were, and a committee report built from it each quarter by someone who no longer trusts it. The fix is not software. It is a template with a field dictionary, a status taxonomy with rules about who may move an item where, and ageing that measures from the date that was first agreed.
This guide is that template, complete: every field defined, the status set and its permitted transitions, escalation and due-date rules by rating, the five committee-reporting cuts, and how to build it at Excel tier without losing anything a GRC platform would give you. It closes the Templates Suite with the MidState Beverage route cash findings — the five from the report, which came from the walkthrough gaps, which came from the memo’s risks — tracked six months on, including the one that did not close cleanly.
In this guide
- What the log is for, and the two ways it fails
- Field dictionary: every column, defined
- Status taxonomy and permitted transitions
- Ageing, due-date rules and the escalation ladder
- The five committee-reporting cuts
- Building it: Excel tier to GRC tier
- Worked example: MidState’s five findings, six months on
- Six ways issue logs fail
- Adapting the log: advisory items, external findings, sensitive rows
What the log is for, and the two ways it fails
The log holds every finding from the day the final report is issued to the day internal audit validates that the agreed action was done and worked. In between it must answer, at any moment and for any reader, four questions: what is open, who owns it, how late is it against what was originally promised, and what has moved since the last time anyone asked. Everything in the template exists to make one of those four answers reliable.
Logs fail in two opposite directions. The graveyard is the log where items accumulate: open for years, due dates revised into the indefinite future, owners who left the company, a committee that has stopped reading the page. The laundromat is the log where items disappear: closed on the owner’s say-so, closed because a policy was reissued whether or not anyone follows it, closed because the finding was “superseded” by a project that has not started. The graveyard is embarrassing; the laundromat is dangerous, because it tells the committee that risks were addressed when they were not. The template defends against both with the same mechanism — rules about who may change a status and what evidence the change requires — and with ageing that cannot be reset.
One structural decision comes before the fields. The unit of the log is the action, not the finding. A finding with three agreed actions and three owners is three rows sharing a finding ID, because they will complete on different dates and one of them will be late. Logs that keep one row per finding end up with a status column that reads “partially complete” for two years. The finding-level view is a roll-up, and the committee sees it; the working log is action-level.
Field dictionary: every column, defined
Thirty-two fields in six groups. Fewer than that and something the committee will ask for is missing; more and nobody maintains it. The “maintained by” column is part of the template: a field that management may edit and a field that only audit may edit behave differently, and the build must enforce the difference.
Group 1 — Identity
| Field | Definition | Maintained by | Rule |
|---|---|---|---|
| Action ID | Unique key: report number, finding number, action letter — FY27-01-F1a | Audit | Never reused; never changed after creation |
| Finding ID | Report number and finding number — FY27-01-F1; groups actions for the roll-up | Audit | Matches the report’s summary-of-findings table exactly |
| Source | Internal audit report / advisory memo / external auditor / regulator / self-identified by management | Audit | Drives the reporting flag and the validation rule (see “adapting”) |
| Report title and final date | The report the finding came from and the date the final was issued | Audit | Ageing of the finding itself runs from this date |
| Finding title | The condition sentence, verbatim from the report | Audit | Not paraphrased; not shortened to a topic |
| Rating | High / Medium / Low, from the report | Audit | Changes only by a documented re-rating with reason and date |
| Theme | A fixed list: segregation of duties, monitoring not performed, system configuration, procedure outdated, evidence retention, access, and so on | Audit | One theme per finding, from the list; used for the thematic view |
| Root cause category | A fixed list: staffing, design, system, awareness, oversight, change not managed | Audit | From the report’s cause paragraph |
| Entity / location / process | Where the finding sits in the organisation | Audit | From the audit universe, same names as the plan |
Group 2 — Ownership
| Field | Definition | Maintained by | Rule |
|---|---|---|---|
| Action owner | Named individual and title accountable for completing the action | Audit, from the report; changes by owner’s manager | A person, never a department; a change of owner is logged with date and reason, and does not reset any date |
| Executive sponsor | The executive to whom the owner reports for this action — first escalation point | Audit | From the report header |
| Audit contact | The auditor responsible for follow-up and validation | Audit | Reassigned when staff change; never blank |
Group 3 — The action
| Field | Definition | Maintained by | Rule |
|---|---|---|---|
| Agreed action | The action as written in the report, verbatim | Audit | Rewording requires a documented agreement with the owner and sponsor, logged in the update narrative |
| Evidence of completion (as agreed) | The artifact that will exist when the action is done, from the report’s action plan | Audit | This is the validation standard; it does not change at validation time |
| Validation approach | Inspect / re-perform / re-test sample / observe — from the report | Audit | Sets the effort and evidence the validator needs |
Group 4 — Dates
| Field | Definition | Maintained by | Rule |
|---|---|---|---|
| Original due date | The date agreed in the final report | Audit | Never changes. Ageing and “overdue” are computed from this date |
| Current due date | The date currently committed to | Management, via the revision process | Every change increments the revision count and requires a reason and an approver |
| Revision count | Number of times the due date has been revised | Computed | 1 revision: sponsor approves. 2 revisions: visible to the committee by name. 3: CAE and committee chair informed |
| Date implemented (claimed) | The date management reports the action complete | Management | Starts the validation clock |
| Date validated / closed | The date audit validated and closed the action, or closed it under another closure status | Audit | Only audit enters this date |
Group 5 — Status and progress
| Field | Definition | Maintained by | Rule |
|---|---|---|---|
| Status | One value from the taxonomy below | Management up to “Implemented — awaiting validation”; audit for all closure states | Transitions restricted as in the taxonomy |
| Status date | Date the status last changed | Computed or entered with the change | Drives the “stale” flag: no change in 90 days on an open item is reported |
| Last update (narrative) | What has happened since the previous update, in two sentences, dated and attributed | Management (monthly); audit at follow-up | Appended, never overwritten — the log keeps the history |
| Next milestone and date | The next concrete thing that will happen | Management | Required for any open item with more than 60 days to run |
| Validation evidence received | Links or references to the evidence submitted | Management submits; audit records | Held with the log, not in email |
| Validation result | Validated / partially validated (with residual) / not validated (with reason) | Audit | A partial result creates a new action row for the residual with its own due date |
| Validator and date | Who validated and when | Audit | Not the auditor who wrote the finding, where staffing allows |
| Risk acceptance reference | For items closed as risk accepted: the acceptance document, the accepting executive, the date, and the committee meeting at which it was reported | Audit | Required for that closure status; blank otherwise |
Group 6 — Reporting flags (computed or set once)
| Field | Definition | Maintained by | Rule |
|---|---|---|---|
| Age (days) | Today minus original due date for open items; date closed minus original due date for closed items | Computed | Negative means not yet due |
| Overdue | Open and age greater than zero | Computed | Measured against the original date, always |
| Escalation level | Owner / sponsor / executive / committee, from the ladder | Computed from age and rating | See “ageing” |
| Committee reportable | High findings always; medium findings when overdue or twice-revised; anything regulatory | Computed, with an audit override | Override reasons logged |
| Repeat finding | The same condition reported previously for the same entity or process | Audit | Reference to the prior finding ID required |
| Regulatory / external | The finding was raised by, or is reportable to, a regulator or the external auditor | Audit | Never closed as risk accepted without CAE and committee-chair sign-off |
| Restricted | Row visible to a named list only (fraud, HR, legal privilege) | Audit | Restricted rows still count in every total |
Drafting guidance. Resist adding fields. The ones that tempt — “percent complete,” “priority,” “management comment” — are the ones that rot: percent complete is a feeling, priority duplicates rating, and a free-text comment field becomes the place where the narrative should have gone. The two fields functions most often lack are the ones that do the most work: original due date, frozen, and evidence of completion as agreed, fixed at report stage. With those two, ageing is honest and validation has a standard. Without them, the log measures whatever management last agreed to and validates against whatever management last supplied.
Status taxonomy and permitted transitions
Eight statuses. Each has one meaning, a rule for who may set it, and a rule for what it requires. The set is deliberately asymmetrical: management can move an item forward as far as “implemented,” and only audit can move it to any state that begins with “closed.” That asymmetry is the whole defence against the laundromat.
| Status | Meaning | Who sets it | Requires | Counts as open? |
|---|---|---|---|---|
| Open — not started | Final report issued; no work begun | Audit, at log creation | — | Yes |
| In progress | Work under way toward the agreed action | Management | An update narrative and a next milestone | Yes |
| Implemented — awaiting validation | Management reports the action complete and has submitted the agreed evidence | Management | Date implemented; evidence submitted against the “evidence of completion” field | Yes — until validated |
| Validated — closed | Audit confirmed the action was done and addresses the finding | Audit only | Validation result, validator, date; evidence on file | No |
| Closed — risk accepted | Management has decided not to act and accepted the risk | Audit only, on receipt of acceptance | Written acceptance by an executive at the level the rating requires; reported to the committee at its next meeting; risk acceptance reference populated | No — but reported separately, and re-reviewed annually |
| Closed — superseded | The action was replaced by a different agreed action, which has its own row | Audit only | The replacement row’s ID; the replacement inherits the original due date for ageing | No (the replacement is) |
| Closed — no longer applicable | The process, system or entity no longer exists | Audit only | Evidence that it no longer exists — not that it is planned to stop | No |
| Deferred | Action postponed with approval, typically pending a system implementation | Audit, on sponsor’s written request | Approver, new date, and an interim mitigation stated; counts as revised; ageing continues from the original date | Yes |
Permitted transitions are few. Open moves to in progress; in progress to implemented, deferred, or (through audit) superseded or no longer applicable; implemented to validated, or back to in progress when validation fails; anything open to risk accepted, through audit, with the acceptance on file. What is not permitted is the transition that laundromats depend on: implemented straight to closed by the owner. And a validation that fails does not close anything — it returns the item to in progress with a note, and the age keeps running.
Drafting guidance. “Closed — superseded” is the status to watch. It is legitimate — a finding about a spreadsheet control is properly superseded when the ERP report that replaces the spreadsheet is agreed as the new action — and it is the status most often abused, because a project on the roadmap is not a replacement action. The rule that keeps it honest is inheritance: the replacement row carries the original due date, so a superseded finding cannot be made young again. Risk acceptance is similar: it is a valid decision that management is entitled to make, and the log’s job is to make sure it is made by someone senior enough, in writing, and in front of the committee — not to prevent it.
Ageing, due-date rules and the escalation ladder
Ageing is where most logs quietly lie. If age is measured from the current due date, every revision makes the item young again, and a finding that has been revised four times over two years shows as “due next month.” The template measures every age from the original due date, and it constrains that date at report stage so that management cannot agree to a due date so distant that ageing never starts.
| Rule | High | Medium | Low |
|---|---|---|---|
| Maximum original due date from final report | 90 days, with an interim mitigation stated in the report | 180 days | 365 days |
| Longer than the maximum | Permitted only with the sponsor’s written reason in the report’s action plan, and the item is flagged “extended” from day one | ||
| First due-date revision | Sponsor approves in writing; reason and interim mitigation recorded | Sponsor approves; reason recorded | Owner’s manager approves; reason recorded |
| Second revision | Reported to the committee by name at its next meeting, whatever the rating | ||
| Third revision | CAE and committee chair informed at the time; item reported as “chronic” until closed | ||
| Stale | No update narrative in 90 days on any open item, whether or not it is due — reported to the sponsor | ||
| Validation service level | Internal audit validates within 45 days of “implemented”; the backlog beyond that is audit’s own overdue and is reported as such | ||
Age buckets are fixed — not yet due; 1–30 days; 31–90; 91–180; over 180 — and the escalation ladder is a function of bucket and rating, computed by the log, not decided each month by whoever is maintaining it. The ladder says who is told, not what they must do; the point is that lateness becomes visible at a level above the owner on a schedule the owner knew about when the date was agreed.
| Days overdue (from original due date) | High | Medium | Low |
|---|---|---|---|
| 1 | Owner and sponsor notified | Owner notified | — |
| 15 | Executive (CFO or COO) notified | — | — |
| 30 | CEO and committee chair notified | Sponsor notified | Owner notified |
| 90 | Committee agenda item, by name | Executive notified | Sponsor notified |
| 180 | Committee agenda item, by name, each meeting until closed | Committee agenda item, by name | Executive notified |
| 365 | Reported to the committee as chronic; the CAE states in writing whether the risk is being accepted by default | ||
Drafting guidance. Publish the ladder in the audit charter or the committee’s terms of reference, so that an executive who is told at day 15 that a high finding is late cannot regard the message as audit being difficult. The interim mitigation requirement on high findings is the clause that does the most for the organisation: it forces the question “what protects us until this is fixed” to be answered at the moment the date slips, and the answer goes in the log. And keep the validation service level honest. A function that holds management to dates and then takes four months to validate a completed action has no standing to complain about ageing.
The five committee-reporting cuts
The committee does not want the log; it wants five answers from it, in the same shape every quarter. Each cut below is a view of the same rows — no cut requires data the log does not already hold — and each answers one question.
| Cut | Question it answers | Shape | Rule |
|---|---|---|---|
| 1. Open actions by rating and age bucket | How much is open, and how late is it? | Matrix: rating down the side, age bucket across, count in each cell, totals; the same matrix from the previous quarter beside it | Counts actions, not findings; restricted rows included in the counts |
| 2. Overdue by owner | Who is late? | Table: owner name and title, count overdue, oldest original due date, number of revisions on the oldest | Named individuals, by design; sorted by oldest first, not by count |
| 3. Movement since last meeting | Is it getting better or worse? | Opening open count; plus new; minus validated-closed; minus risk-accepted; minus superseded or no longer applicable; equals closing count — with revised and escalated as memo lines | A reconciliation, not a summary: it must foot |
| 4. Exceptions: risk accepted, chronic, and re-rated | What has management decided to live with? | Table, one row per item: what, who accepted or why chronic, reference | Every risk acceptance appears here once, the quarter it is made; chronic items appear every quarter |
| 5. Validation backlog | Is audit keeping up its side? | Count of “implemented — awaiting validation” by days waiting; items beyond 45 days listed | Audit’s own overdue, reported with the same prominence as management’s |
Once a year add a sixth: themes and root causes across everything closed and open in the period, from the two fixed-list fields. This is the cut that turns a log into insight — that a third of the year’s findings share a root cause of “change not managed,” say — and it is only possible because the fields were fixed lists rather than free text.
Building it: Excel tier to GRC tier
The template works in Excel, and a well-built Excel log beats a badly configured platform. What separates a log from a spreadsheet is four sheets rather than one, a handful of computed columns, and an update process that keeps management’s edits out of audit’s columns.
| Sheet | Contents | Why it is separate |
|---|---|---|
| Log | One row per action, the 32 fields as columns, validation lists on status, rating, theme, root cause and source; audit-only columns locked | The system of record |
| Updates | Append-only: action ID, date, author, narrative | History survives; the Log shows the latest narrative by lookup |
| Changes | Every edit to a due date, owner, rating or status: action ID, field, old value, new value, who, when, reason, approver | The audit trail; revision count is computed from it |
| Snapshots | A copy of the Log’s status, dates and rating columns saved at each committee cut-off date | “Movement since last meeting” is a comparison of two snapshots; without them it is a memory |
Computed columns, in words rather than formulas so they survive any tool: age is today less the original due date while open, and the closure date less the original due date once closed; overdue is open and age greater than zero; escalation level is a lookup on age bucket and rating against the ladder; stale is more than 90 days since the last update; revision count is the number of due-date rows in Changes for that action ID; validation lag is the validation date less the implemented date. The management update cycle is monthly: owners receive their open rows, return narrative, next milestone and any claim of implementation through a form or a separate update sheet, and audit merges — management never edits the Log directly. That single rule is what makes the status column trustworthy.
The middle tier — a SharePoint list with automated reminders and a Power BI report over it — gives the same log with the cuts refreshed on demand and the reminders sent without anyone remembering to send them; the field dictionary transfers column for column. At GRC tier (AuditBoard, TeamMate+, Diligent, Workiva and their peers) the temptation is to accept the platform’s default status list and workflow. Check them against the taxonomy above before migrating, in particular whether the platform lets an owner close an item and whether it measures age from the original date. If it does not, configure it until it does; the dictionary is the specification, and the platform is an implementation of it.
Worked example: MidState’s five findings, six months on
The route cash report was finalised on 21 March FY27 with five findings and eleven agreed actions. This is the log extract for FY27-01 at 30 September, the cut-off for the October committee meeting — the working columns, condensed. Three things happened that a template has to be able to hold: one action slipped and was revised twice, one validation came back partial, and one matter had to be tracked without being visible to everyone who can see the log.
| Action ID | Agreed action (condensed) | Rating | Owner | Original due | Current due | Rev. | Implemented | Validated / closed | Status at 30 Sep | Age | Val. lag |
|---|---|---|---|---|---|---|---|---|---|---|---|
| F1a | HQ performs daily reconciliation for nine depots, by route | High | Dir. Route Accounting | 1 May | 1 May | 0 | 28 Apr | 12 Jun | Validated — closed | 42 | 45 |
| F1b | ERP depot role split; reconciliation removed from clerks | High | Dir. Route Accounting | 30 Jun | 30 Jun | 0 | 22 Jun | 14 Aug | Validated — closed | 45 | 53 |
| F1c | Procedure reissued (rev. FY27) | High | Dir. Route Accounting | 30 Jun | 30 Jun | 0 | 30 Jun | 14 Aug | Validated — closed | 45 | 45 |
| F2a | Override listing emailed daily to depot managers and HQ; weekly trend by route | High | VP Operations | 15 Apr | 15 Apr | 0 | 11 Apr | 10 Jun | Validated — closed | 56 | 60 |
| F2b | Tolerance reduced to $5; reason code on every shortage | High | VP Operations | 15 Apr | 15 Apr | 0 | 11 Apr | 10 Jun | Validated — closed | 56 | 60 |
| F2c | Override approval requires depot-manager credentials | High | VP Operations | 31 May | 31 Jul | 1 | 28 Jul | 9 Sep | Validated — closed | 101 | 43 |
| F2x | Referred matter — see General Counsel file (restricted row) | High | General Counsel | — | — | — | — | — | Open — restricted | — | — |
| F3a | Sync exceptions routed to HQ daily; chased within one business day | Medium | IT Director | 30 Apr | 30 Apr | 0 | 24 Apr | 10 Jun | Validated — closed | 41 | 47 |
| F4a | ERP deposit-listing report in bank format | Medium | Dir. Route Accounting | 30 Jun | 30 Sep | 2 | — | — | In progress — twice revised; escalated to CFO 1 Sep | 92 | — |
| F4b | Procedure describes interim re-key process and its weekly HQ check | Medium | Dir. Route Accounting | 30 Jun | 30 Jun | 0 | 30 Jun | 14 Aug | Validated — closed | 45 | 45 |
| F5a | Paper statements reinstated for customers without email | Medium | Dir. Route Accounting | 31 Jul | 31 Jul | 0 | 31 Jul | 20 Aug | Validated — closed (partial; residual F5c) | 20 | 20 |
| F5b | Email capture added to driver handheld | Medium | Dir. Route Accounting | 31 Jul | 31 Jul | 0 | 15 Jul | 20 Aug | Validated — closed | 20 | 36 |
| F5c | Residual: obtain a valid statement address for 168 accounts with neither email nor mailing address; statements issued | Medium | Dir. Route Accounting | 31 Oct | 31 Oct | 0 | — | — | In progress | −31 | — |
The Updates and Changes sheets, for the two rows that matter
F4a — Changes. 20 Jun: current due 30 Jun → 31 Aug; reason “IT capacity committed to acquisition ERP migration (engagement FY27-02); interim: depots agree spreadsheet listing to ERP check detail weekly, reviewed by HQ”; approved VP Operations. 25 Aug: current due 31 Aug → 30 Sep; reason “report specification returned by vendor for rework”; approved VP Operations; second revision — committee-visible. 1 Sep: escalation level → executive; CFO notified. Under the ladder a medium item reaches executive level at 90 days overdue, which would have been 28 September; the CAE escalated early on the second revision, and the Changes sheet records that decision and its reason. F4a — Updates. 12 Sep (owner): “Revised specification accepted by vendor 9 Sep; build scheduled; UAT 15 Oct.” 30 Sep (audit): “Interim control observed operating at three depots in September follow-up; keying differences found: none.”
F5a — Updates. 20 Aug (audit): “Validation: August statement run reached 4,032 of 4,200 route customers (96%). 168 accounts have neither an email address nor a mailing address on file and received no statement. Action validated as implemented; residual raised as F5c with original due 31 Oct, agreed with owner 20 Aug.”
The committee page for FY27-01, October meeting
Route Cash Handling (FY27-01, Unsatisfactory, 21 March). Eleven agreed actions plus one residual. Movement since June: opening open 7; new 1 (F5c residual); validated-closed 6 (F1b, F1c, F2c, F4b, F5a, F5b); closing open 2 — F4a and F5c — plus one restricted item. Overdue: F4a, Director of Route Accounting, original due 30 June, twice revised, now 30 September, escalated to the CFO on 1 September; interim control observed operating. Both high-rated findings are validated and closed. Finding 2’s self-approval removal (F2c) closed 101 days after its original date, one revision, with the HQ weekly review operating as interim mitigation throughout. Validation lag for this engagement averaged 45 days against the 45-day service level; the June cycle carried the backlog.
Some things to notice. Age is measured from the original date throughout, so F2c reads 101 days at closure even though it was implemented three days before its revised date — the committee sees both the lateness and the revision, and the interim mitigation that covered the gap. F4a is the log doing its job on the graveyard side: two revisions made it committee-visible by name, and the Changes sheet holds both reasons and both approvals, so the discussion in October is about IT capacity rather than about whether anyone knew. F5a is the log doing its job on the laundromat side: a 96 percent result was not rounded up to closed. The action was validated as done, the residual got its own row with its own date, and the finding stays open until the last 168 customers get a statement. F3a shows the log being honest about audit: management delivered six days early, and the item stayed open for 41 days past its due date because validation waited for the June follow-up cycle — that number is audit’s, and the validation-lag column is what lets the committee tell the difference. And F2x is how a fraud referral is tracked without a spreadsheet full of names: one restricted row, counted in every total, visible to the CAE and the committee chair, with the substance held by the General Counsel.
Six ways issue logs fail
| Failure | Symptom | What it costs | Fix in the template |
|---|---|---|---|
| The graveyard | Items open for years; owners who have left; the committee page unchanged quarter to quarter | The function is seen to change nothing, and the committee stops reading | Ageing from the original date; the escalation ladder; second-revision visibility; the chronic flag |
| The laundromat | Items closed on an email; “superseded” by projects not started; policies reissued and findings closed the same day | The committee is told risks are addressed when they are not | Only audit closes; evidence of completion fixed at report stage; superseded rows inherit the original date |
| Due-date creep | Age measured from the current due date; every revision resets the clock | Lateness is invisible; the log reports whatever was most recently promised | Original due date frozen; revision count computed from the Changes sheet |
| Finding-level rows | One row for a finding with four actions; status “partially complete” for two years | Nothing can be validated, escalated or closed at the level it actually happens | One row per action; finding status is a roll-up |
| Management-set status | Owners edit the log directly; the status column means whatever the last editor meant | The status the committee sees is a self-assessment | Management updates through a form or update sheet; audit merges; audit-only columns locked |
| The private spreadsheet | One file on one auditor’s drive, no history, no snapshots, no change trail | Movement cannot be reported, changes cannot be explained, and the log dies when the auditor leaves | Four sheets; snapshots at each cut-off; the Changes sheet; a shared location with controlled access |
Adapting the log: advisory items, external findings, sensitive rows
Advisory-sourced items
Observations from advisory memos do not enter the log — they were suggestions, and tracking them would turn advisory work into assurance by the back door. The exception is the memo’s “matters for attention”: anything that would have been a high finding in an assurance engagement is logged with source “advisory memo,” rated, owned and aged like any other finding. The source field is what lets the committee see how much of the open population came from advisory work, which is itself a useful number.
External auditor and regulator findings
One log, not three. External auditor management-letter points and regulatory findings go in the same log with their source and the regulatory flag set, so the committee sees the whole population of open matters in one place and the escalation ladder applies to all of them. Two special rules: a regulatory item is never closed as risk accepted without the CAE’s and the committee chair’s sign-off, and the log is reconciled to the external auditor’s own tracking list each quarter, because the two will drift and the committee will notice when they do. Where an internal finding is also a control deficiency for financial reporting, the log is the population from which the quarterly aggregation and severity assessment is drawn; the theme and entity fields are what make the aggregation possible.
Management self-identified issues
Encourage them into the log with source “self-identified” — a control environment where management logs its own issues is a stronger one — and validate them with a lighter touch, typically inspection rather than re-performance. Report them as a separate line in the movement cut so that the committee can see the proportion grow, and never let a self-identified issue be used to pre-empt a finding: if audit was already testing the area, the finding is audit’s and the source says so.
Restricted rows and group structures
Fraud referrals, HR matters and anything under legal privilege are tracked as restricted rows: an ID, a rating, an owner, a status, and a pointer to where the substance is held — visible to a named list, counted in every total. The count is the point; a committee that is told there are 41 open actions must be told the true number, and a log that omits sensitive items reports the wrong one. In a group with local audit teams, each entity keeps rows in the same dictionary and the group log is the union, with the entity field doing the filtering; a local log in a different format is a reconciliation waiting to happen.
Where this sits in the engagement
The log is the last document in the suite and the one that outlives the engagement. It is fed by the report’s summary-of-findings and action-plan tables — its columns are theirs — and it feeds the next annual plan, because open high findings and chronic items are risk-assessment inputs, and the repeat-finding flag is how a process earns its way back onto the plan. The Global Internal Audit Standards’ Domain V requirement to monitor action plans and report on their status is met by the five cuts above, delivered on the committee’s calendar; the severity logic that drives the ladder is the same one used to rate the findings in the first place, from finding severity ratings.
The Templates Suite
- The Annotated Internal Audit Plan Template — the FY27 plan, where open findings feed next year’s risk assessment
- The Engagement Planning Memo Template — the route-cash memo that named risks R1–R5
- The Walkthrough Documentation Template — the Dayton walkthrough whose gap log became Findings 1 to 4
- The Audit Report Template Set — the FY27-01 report with the five findings and eleven actions
- The Finding and Issue Log Template — this guide
Leave a Reply