Remediating audit findings is a small program with a deadline, not a list of tasks. Owners who close findings first time run it the same way each time: in the first ten days they name one accountable person per action, agree in writing what “done” means in evidence terms, open the evidence binder and start a weekly rhythm; from day 10 to day 60 they design and implement the fix, capturing evidence as each change happens; from day 60 to day 90 they let the new control run on its own calendar and collect its output, so the validator finds a track record rather than a narrative. Ninety days is a common due date for a High-rated action in many issue-tracking methodologies, and a useful planning unit even when your date is longer.
This guide assumes the action plan is written, the craft covered in writing management action plans that actually close, and picks up the morning the final report issues. It covers the three phases, the definition of done by action type, the evidence binder, a one-page status report with an honest-slippage rule, the dependency log, date changes, and the hand-off to issue validation, then works three 90-day timelines: an access review, a reconciliation, and a policy with training. It is one of the after-the-report guides on the Being Audited? hub.
In this guide
- Remediation is a program, not a to-do list
- The 90-day plan by phase
- Days 0 to 10: mobilize
- Days 10 to 60: design and implement
- Days 60 to 90: operate and collect
- The evidence binder
- Status reporting upward
- Dependencies on IT and vendors
- When to ask for a date change
- The hand-off to validation
- Why remediation fails validation
- Three worked 90-day timelines at Westbrook Components
- Questions readers ask
- Related guides
Remediation is a program, not a to-do list
The actions in a report are written in the last week before issue, under time pressure. The day after the final report they become several actions with different owners and kinds of evidence, a date already reported upward that will appear in the audit committee pack, and a validator at the end who tests rather than reads. The end standard is Standard 15.2 of the IIA’s Global Internal Audit Standards: internal audit confirms that action plans were implemented, or that management has accepted the risk of not acting. It confirms that the agreed action is in place, not that work was done.
Practitioner judgment: three mistakes account for most of the failed closures we see, and all three are decided in the first two weeks. The first is treating “done” as “we did the thing”, when validators test whether the control operates, which is why done is not the same as closed. The second is collecting evidence at the end, when the before-state is gone and the only screenshot has no date. The third is status that stays green until it turns red, which is how an owner ends up named in a committee pack’s overdue list with no warning given. Every action also needs one named person who controls the resources to deliver it, the principle in control ownership; with more than three or four actions, appoint a remediation lead to run the tracker, the weekly meeting and the status report, and treat the owners’ executive as sponsor, the person who unblocks dependencies and approves a date-change request before it goes to internal audit.
The 90-day plan by phase
Each phase has one goal and a kind of evidence that enters the binder. The fourth row is not part of the 90 days; it is the reason the first three exist.
| Phase | Days | Goal and outputs | Evidence entering the binder | Most common failure |
|---|---|---|---|---|
| Mobilize | 0 to 10 | Everyone can state what “done” means per action; owner, tracker, dependency log, weekly slot and binder in place | Report extract; action list verbatim; dated baseline | Starting work before agreeing what evidence closes the action |
| Design and implement | 10 to 60 | The fix is in production and addresses the cause; interim measures running meanwhile | Design note and audit’s review; tickets; before and after configuration; first performed instances | Building what is easy instead of what the cause calls for |
| Operate and collect | 60 to 90 | The control runs without the project team; monitoring hook in place | Each period’s output with reviewer evidence; exception log; re-measured metric | Reporting “complete” on go-live day and stopping the collection |
| Hand-off | 90 onward | Validation passes first time | Index; population listings with parameters; evidence map to tabs | A narrative and three screenshots instead of a population |
Days 0 to 10: mobilize
Ten days is how long it takes to get the owners in a room, pull the baseline and agree definitions of done with the audit contact. It is not ten days of waiting: anything that cuts the exposure now, such as disabling leaver accounts, is done and evidenced in week one. The final report already acknowledged what was fixed before issue, as Standard 15.1 requires; what you fix after issue counts only if you can prove it.
Agree what done means for each action
The validator tests against the action as written and the “evidence of completion” the report named, a column in the finding and issue log for exactly this reason. If the action is vague (“strengthen the access review process”), convert it now into something testable and ask the audit contact to record the conversion against the action ID; we would far rather do that on day 10 than discover on day 90 that you built something we cannot test. Write the definition in evidence terms: not “training delivered” but “attendance reconciled to the role list, and 25 post-training transactions sampled with no exceptions”.
| Action type | Done means | Evidence that proves it | Track record before you ask for validation |
|---|---|---|---|
| Policy or procedure change | Approved, published, communicated and followed | Approved version with date and approver; acknowledgments; compliant instances after the effective date | One to two months of transactions; expect a sample of 25 to 60 items, or the full population through analytics |
| New or redesigned manual control | Performed each period by the named person, with evidence of what was checked | Control description; each period’s output with reviewer marks and date; exception follow-up | Two to three month-ends for a monthly control; eight weeks to a quarter for a daily or weekly one |
| System configuration or workflow change | Live in production and under change control | Change ticket with approvals; before and after configuration showing user, system and date; post-change transactions | About a month of activity plus the change record |
| Access or segregation-of-duties fix | Conflicts and stale accounts gone; the process that let them arise fixed | Full-population re-run of the conflict or leaver analysis showing none; joiner-mover-leaver evidence | Immediate for the clean-up itself; one cycle of the review control, two where the finding is High, so one or two quarters for a quarterly review |
| New report or monitoring analytic | Produced each period, complete and accurate, acted on | Query logic and parameters; completeness check to source; reviewer actions per period | Several periods of reviewer action |
| Training | Delivered to the right people; behavior changed | Attendance reconciled to the role list; assessments; post-training transactions tested | One to two months of transactions after training |
| Data or population clean-up | Every item in the original population dispositioned | Original count reconciled to corrected, written off or justified; write-off approvals | None beyond completion; the accompanying preventive fix needs its own |
| Staffing or organizational change | Person in role, trained, performing the control | Appointment record; role description; the control’s output since the start date | About a quarter of output |
The track-record column compresses the operating periods in the evidence standards for issue closure, where the minimums by control frequency live; functions differ on the exact figures, so ask your audit contact for the methodology’s number on day 10 and write it into the definition. The planning lesson: a monthly control that goes live on day 50 cannot have three month-ends of evidence by day 90, so either it goes live before the first month-end in your window or the validation-ready date sits after the due date, and you say so on day 10. A quarterly control can rarely be validated inside 90 days: one quarter-end is the usual minimum, two where the finding is High, so plan on three to six months after go-live.
Open the tracker and the binder on day one
Your tracker uses the same action IDs and status words as internal audit’s issue log, whose data model is in audit issue tracking, so your status transfers without translation. Nine columns are enough: action ID; accountable owner (a person, never a department); definition of done; three to six dated milestones; original and current due dates side by side, the original never overwritten; dependency reference; red, amber or green status with one sentence; binder reference, updated when evidence is filed; and the validation-ready date, shown separately from the due date.
Start the weekly rhythm
Thirty minutes, the same slot every week, all owners present, the sponsor once a month. The agenda never changes. The second item carries the 30-day look-ahead: for every open action, whether a feasible path to the date still exists using only the dependency dates you hold in writing. Asked weekly, that question produces a date-change request before the date instead of an explanation after it. The last item is the one most teams skip and the one that makes validation easy.
| Minutes | Item | Output |
|---|---|---|
| 0 to 5 | Tracker walk: each owner reads their status line aloud | Status lines confirmed or corrected |
| 5 to 15 | Slippage and the 30-day look-ahead: milestones missed this week with cause; for each action, whether the date still holds on the written dependency dates; recovery plan or date-change decision | Decision recorded; any action without a feasible path flagged red |
| 15 to 22 | Dependencies: anything blocked more than five working days | Log updated; escalation owner named |
| 22 to 27 | Evidence: what was filed this week; what is still missing | Binder index updated |
| 27 to 30 | Audit contact: design review to request, date risk to flag, question to ask | One email, sent the same day |
Days 10 to 60: design and implement
Most plans contain four kinds of change: process, system, training and documentation, each with its own evidence and its own way of failing. Before building any of them, re-read the cause statement in the finding. The fix has to address that cause, which Standard 14.3 asks auditors to identify together with management where possible, and a fix that treats the symptom fails validation on design however well it operates. If the cause in the report is thin (“human error”), the method in root cause analysis for audit findings shows what a usable cause looks like; do that work in week two, not week eleven.
Ask for a design review before you build
Practitioner judgment: a fifteen-minute design review with the audit contact, before anything is configured or published, is the highest-return meeting in the program. We will say whether the design addresses the cause, whether its evidence will be testable, and whether the reviewer you have named is independent enough. We will not design the control, because that would compromise our objectivity when we validate it. A design we have seen rarely fails on design; it fails, if at all, on operation, the difference explained in test of design versus operating effectiveness.
Where the permanent fix takes longer than a month or two, put an interim measure in place now and evidence it like a control, because the validator will ask what covered the risk in between; compensating controls explains what makes one credible. Where volume allows, pilot at one site for two weeks: the pilot’s output is early operating evidence, and its exceptions improve the design while that is still cheap.
Capture evidence at the moment it happens
Evidence is captured by the person making the change, when the change is made, and filed the same day; nobody reconstructs anything in week twelve. For a system change that means the ticket, the approvals and a before-state export showing user, system and date, because the before-state disappears at go-live and tickets get archived. For an access removal it means the log entry and a re-run of the listing, because logs roll off. For training it means the invitation list reconciled to the role list, attendance and the content as delivered, because learning-system records get purged. For a clean-up it means the original population with count, date and source, because it cannot be reproduced later. Any listing you pull from a system is information produced by the entity, and validators will ask how it was generated (IPE testing lists the questions), so record source, parameters, date pulled and record count on the file itself.
Days 60 to 90: operate and collect
The last month exists to build a track record. A control that went live on day 55 has design and implementation evidence and nothing else; the validator needs its output over a period, produced by the person who will own it from now on. By day 75 three things should be true. The control runs on its own calendar, and nobody from the remediation team performs it. Exceptions are appearing and being handled, with the handling filed, because a control with no exceptions over a quarter is either excellent or not really running, and the output alone cannot tell us which. And a monitoring hook exists: a metric, exception report or self-test with a named reader and a threshold, which is what sustainability testing looks for six or twelve months after closure.
Hand the control over formally: the business-as-usual owner performs it from the first live period, the project lead observes two instances and then stops attending. We interview the performer during validation, and we notice when the performer is still the project manager. Draft the closure request in week twelve even if the validation-ready date is months away; drafting it shows which tab is thin while there is time to fill it. For quarterly and annual controls the plan ends at “implemented, validation scheduled”, the status many issue logs use for a fix that is live but not yet testable, with a validation-ready date agreed with audit. That is a normal outcome; it becomes a problem only when nobody said it on day 10 and the committee pack shows the action overdue because the status still reads “in progress” on day 91.
The evidence binder
The binder is one shared folder per finding, opened on day 0, with the index as its first file. Its tabs follow the four levels validators think in, set out in the evidence standards for issue closure: design artifact, implementation, operating effectiveness and outcome. That guide’s observation is that most wrongly closed issues were closed at the first two levels when the finding needed the last two, and a binder built this way shows you the gap before it shows us. Four rules: every file name carries the action ID, what the file is and its date; every system-produced file carries source, parameters and record count; the before-state is never overwritten; and the index states what each file proves, not just what it is, the discipline in audit evidence: sufficiency, appropriateness and the hierarchy.
| Tab | Contents | What it proves | Filed by |
|---|---|---|---|
| 00 Cover note and index | Finding, actions, status, what each tab proves, validation-ready date | Orientation | Owner, weekly |
| 01 The finding | Report extract: condition, cause, rating, action, evidence of completion as written | The standard being tested | Owner, day 0 |
| 02 Baseline | Before-state: population, metric, configuration or listing, dated and sourced | Starting point for outcome evidence | Owner, days 0 to 10 |
| 03 Definition of done | The agreed definition and audit’s acknowledgment | Agreed criteria | Owner, day 10 |
| 04 Design | Control description, procedure, flow, audit’s design review note | Design (level 1) | Owner, days 10 to 30 |
| 05 Implementation | Tickets, approvals, before and after configuration, training records, publication | Implementation (level 2) | Action owners, as each change lands |
| 06 Operation by period | One subfolder per period: output, reviewer evidence, exceptions, follow-up | Operating effectiveness (level 3) | Control performer, each period |
| 07 Outcome | Re-measured metric against the baseline, by audit’s original method | Outcome (level 4) | Owner, day 85 onward |
| 08 Dependencies and correspondence | Dependency log, escalations, date-change requests and approvals | Governance of the program | Remediation lead |
| 09 Status reports | Each report as issued | What was said when | Remediation lead |
| 10 Closure request | Cover note, action list with status, evidence map to tabs | The hand-off | Owner, week 12 |
Practitioner judgment: give the audit contact read access to the binder from day one. Nothing in it should surprise anyone at validation, and a validator who has watched tab 06 fill up month by month arrives with a sample already chosen. Some owners hesitate because the binder shows the slips as well as the progress. A visible slip with a recovery plan costs nothing; a hidden one costs the closure.
Status reporting upward
Two readers receive your status: your sponsor, and internal audit’s follow-up process, which feeds the quarterly pack described in reporting to the audit committee, where overdue actions are listed with their owner and executive sponsor. One page, the same format every time, every line citing a number and a binder tab, original and current due dates side by side.
The honest-slippage rule is practitioner judgment, and it is what keeps everyone calm: report a slip in the week you can see it on the critical path, not the week it happens. Amber means a milestone has slipped or a dependency is at risk, and a recovery plan holds the end date. Red means the end date is at risk or has passed, whether or not anything has been missed yet, and it triggers a date-change decision before the date. Green means on plan with the evidence filed to date. A status that goes from green to red in one step is a reporting failure, and sponsors and auditors both read it that way.
| Field | What goes in it | Example line |
|---|---|---|
| Header | Finding ID and title, rating, owner, sponsor, status date, original and current due dates | F1 ERP user access review (High); owner: Controller; sponsor: CFO; status at 8 Dec 2026; original due 15 Feb 2027; current due 15 Feb 2027 |
| Overall status | Red, amber or green under the rule, with the reason | Amber: milestone 3 (leaver feed live) forecast to slip eight days; end date holds |
| Done since last report | Dated facts with binder tabs | 23 of 23 leaver accounts disabled; re-run shows none active (tab 05, 27 Nov) |
| Next two weeks | Milestones due, each with an owner | Reviewer matrix approved by 11 Dec (Controller); conflict ruleset in test by 18 Dec (IT security lead) |
| Slippage and recovery | What slipped, cause, recovery plan, residual risk | Feed change awaited a change-board slot; moved to the next board; interim weekly manual leaver check running (tab 06) |
| Dependencies and asks | What you need, from whom, by when, escalation state | CR-4471 approval needed by 15 Dec; blocked seven working days; ask sponsor to raise with the IT director |
| Evidence status | Tabs populated of total; what remains | Tabs 00 to 05 complete; tab 06 holds the interim weekly check; quarterly review output begins with the January review |
| Validation-ready date | When audit can test, and when that was agreed | After the second quarterly review, late April 2027 (agreed with audit 27 Nov) |
The wording of status lines decides whether a reader trusts the rest of the page. These pairs recur.
| Situation | Don’t write | Write instead |
|---|---|---|
| A milestone slipped | “On track” | “Milestone 5 (conflict ruleset in production) slipped from 5 Jan to 13 Jan; recovery: contractor added for the ruleset build; end date holds” |
| A dependency is blocked | “Waiting on IT” | “CR-4471 awaiting a change-board slot since 30 Nov; escalated to the IT director 9 Dec; needed by 15 Dec to hold the date” |
| The fix went live | “Complete” | “Live 10 Jan; first operating period ends 31 Jan; validation-ready after the second quarterly review” |
| The end date is at risk | “Some risk to the timeline” | “End date at risk by about three weeks; options: (a) interim manual control and a 30-day extension, (b) descoped first release; recommendation (a); decision needed by 20 Dec” |
| Scope is partly done | “Mostly done” | “4 of 6 conflicts removed; 2 compensated by a monthly report (tab 06); permanent fix due 28 Feb” |
| Operation produced an exception | Nothing | “One exception in February: review two days late, reviewer on leave with no delegate; delegate named 3 Mar (tab 06)” |
Dependencies on IT and vendors
In our experience most actions that miss their date miss it on a dependency: a change in another team’s queue, a vendor release, a data feed from HR, a committee that meets monthly. The dependency is rarely the failure; identifying it in week nine is. Log it the day it is recognized, with the date you need it by (critical path minus a buffer) and the named person who owns it on the other side, and tell that person in writing, the same day, that an audit action with a reported due date depends on their deliverable.
| Column | Content | Example |
|---|---|---|
| ID and linked action | Dependency number and the action it serves | D3 for action F1b |
| What is needed | The specific deliverable | Daily leaver feed from the HR system to the ERP |
| From whom | Named person and function | Applications lead, IT (named) |
| Needed by | Critical-path date minus buffer | 15 Dec 2026 (ten-day buffer) |
| Requested on and how | Date and reference | 27 Nov, change request CR-4471 |
| Status | Not started, in progress, blocked, delivered | Blocked: no change-board slot since 30 Nov |
| Working days blocked | Count since the stall began | 7 (at 8 Dec) |
| Escalation | Level and date | Owner to owner 4 Dec; sponsor to IT director 9 Dec |
| Interim mitigation | What covers the gap | Weekly manual leaver reconciliation (tab 06) |
Escalation timing, as practitioner judgment: five working days blocked, owner speaks to owner; ten, sponsor speaks to the counterpart executive; the moment the critical path shows the end date at risk, a date-change request goes to the sponsor and audit is told the same week. Vendor changes carry their own approval chains, so they go on the week-one list; where the vendor cannot deliver inside the window, an interim compensating control plus an early re-plan is a better record than a missed date. A dependency that was logged, chased and escalated is a legitimate reason for a date change. One discovered on day 80 is a planning failure, and the escalation ladder describes what we do with those.
When to ask for a date change
Ask the moment the critical path says the end date will not hold, and always before the date. In most functions a first request supported by a logged dependency, visible progress and an interim measure is granted; a second is reported individually to the audit committee; a third usually becomes a conversation about whether the action will ever be done, which is the territory of risk acceptance by management; under Standard 11.5, if management accepts a risk beyond the organization’s appetite or tolerance, the chief audit executive escalates it to senior management and, if unresolved, to the board. Build the request from the tracker and the binder: original date, new date from the critical path rather than from optimism, what is done with tab references, the cause of the slip, the interim mitigation, and what changed so there is no second request. The template and the decision rules are in missing an audit action due date. One distinction saves a lot of grief: a validation-ready date later than the implementation date is not a slip. A fix live on day 85 for a quarterly control is “implemented, validation scheduled”, not overdue; say it in those words, and confirm that the audit tracker shows both dates.
The hand-off to validation
Validation is a test, with a population, a procedure, evidence and a conclusion, performed by someone independent of the action owner. The validator reads the action as written and the definition of done, confirms the design addresses the cause, selects their own sample from your population listing for the operating period, re-performs a manual control for at least two instances, re-measures the original condition where the finding was about an outcome, and checks that a monitoring hook exists. The sample is theirs, which is why the complete, parameterized listing in tab 06 matters more than any examples you could choose; the logic behind the numbers is in audit sample sizes demystified. Ask for validation when the track record exists, not when the due date arrives. The owner’s side of the request, what goes in the pack and why packs bounce, is the subject of how to get an audit finding closed; the validator’s conclusion follows the issue closure memo template.
Two special cases: SOX key controls and regulatory findings
If the remediated control is a SOX key control, there is a second clock. PCAOB AS 2201 (paragraph .53) lets the external auditor rely on a changed or remediated control without testing the superseded one only where the new control has been in effect for a sufficient period to permit assessment of its design and operating effectiveness, so a fix that goes live in the last weeks of the fiscal year may not help the year-end assessment. Coordinate the go-live date with the SOX team; SOX for control owners explains what the testers will ask for.
For bank regulatory findings the same mechanics apply with sharper edges. As of November 2026, the OCC’s current manual on matters requiring attention (PPM 5400-11, issued 27 August 2026) states that corrective actions must be timely and measurable and have a direct connection to the practice, act or failure to act that gave rise to the concern, that the individuals responsible for implementing the corrective action must be identified, that a bank requests more time in writing and in advance of the due date, that an MRA sits in “Pending Validation” once the bank has taken the corrective action and until validation is complete, and that examiners substantially rely on validation work performed by an internal audit function they rate satisfactory. For a regulated institution, the binder you build for internal audit is the binder behind the bank’s representation to its supervisor; the wider context is in MRAs, MRIAs and consent orders explained.
Why remediation fails validation
The reasons closure requests fail cluster into ten patterns. Each is prevented by something already in this plan.
| Reason | What it looks like | Prevented by |
|---|---|---|
| Symptom fixed, cause untouched | A new review added; the upstream failure continues | Day-10 cause check; design review with audit |
| “Done” meant built, not operating | Closure requested on go-live day | Track record in the definition of done; separate validation-ready date |
| Examples instead of a population | Three screenshots; nothing to sample from | Population listing per period with parameters and counts in tab 06 |
| Evidence assembled at the end | Before-state missing; tickets archived; dates disputed | Capture-at-the-moment rule; binder opened day 0 |
| Scope quietly narrowed | Two of four sites fixed; status says complete | Status lines report scope in numbers; partial named as partial |
| Control performed by the project team | The business-as-usual owner has never performed it | Hand-over by day 75; owner performs from the first live period |
| Reviewer evidence is a tick | A sign-off with no trace of what was checked | Reviewer leaves marks: items checked, questions, follow-ups; see management review controls |
| Action changed without audit | The validator tests the original wording and the new thing fails it | Every conversion recorded with audit against the action ID |
| Dependency discovered late | The IT change still queued on day 80 | Dependency log in week one; escalation at five and ten days |
| Exceptions hidden | The validator’s sample finds what the status never mentioned | Exceptions reported with cause and fix; they are evidence the control works |
Three worked 90-day timelines at Westbrook Components
Westbrook Components is a hypothetical manufacturer with three plants and one ERP. Its procure-to-pay and plant finance audit (report FY27-04, rated Needs Improvement) was issued on 17 November 2026 with three findings on 90-day due dates, so day 0 is 17 November and day 90 is 15 February 2027. The figures are illustrative. The timelines show one method producing three shapes: a quarterly control that cannot be validated inside the window, a monthly control that can if it goes live fast, and a policy finding whose real evidence is behavioral.
F1 (High): ERP access review not performed; leaver accounts active; segregation conflicts
Condition: the quarterly review had not run for two quarters; 23 accounts of people who had left remained active; six users could both create vendors and approve payments. Cause: no leaver feed from the HR system to the ERP, and a procedure that depended on one person who had changed roles. Owner: the Controller as business owner of the ERP, with the IT security lead owning the dependencies. The design points are in how to perform a user access review that actually works.
| Days | Milestone | Into the binder |
|---|---|---|
| 0 to 3 | Owner and sponsor named; tracker and binder opened; baseline access listing pulled (1,284 accounts, parameters and date recorded) | Tabs 01 and 02 |
| 4 to 10 | Definition of done agreed: leaver accounts disabled; leaver feed within one business day; quarterly review with completeness check and reviewer evidence; six conflicts removed or compensated; validation-ready after the second quarterly review | Tab 03 |
| 5 to 12 | Quick win: 23 leaver accounts disabled; tickets filed; re-run shows none active; audit told the same day | Tab 05 |
| 10 to 35 | Leaver-feed change request raised day 10, needed by day 28; design review with audit day 20; reviewer matrix built; conflict ruleset defined; interim weekly manual leaver check starts | Tabs 04, 06 and 08 |
| 35 to 50 | Feed live day 36 after a change-board slot slipped (eight of the ten buffer days used; reported amber, end date held); manual check runs two more weeks to prove the feed, then stops | Tabs 05 and 06 |
| 45 to 60 | Four conflicts removed by role changes; two compensated by a monthly report of payments approved by users who created the vendor, reviewed by the Controller | Tabs 05 and 06 |
| 60 to 75 | First quarterly review on the January listing: completeness check to HR headcount, 41 reviewer sign-offs, 37 removals ticketed; the Controller’s team performs it, not the project lead | Tab 06 |
| 75 to 90 | Second monthly leaver reconciliation clean; monitoring hook: leavers-versus-active-accounts metric in the Controller’s monthly pack; status “implemented, validation scheduled” | Tabs 06 and 07 |
| 90 onward | Closure request drafted, not submitted; audit’s tracker shows implemented, validation-ready late April 2027; not reported as overdue | Tab 10 |
F2 (Medium): plant bank reconciliations late, unreviewed, with aged items
Condition: reconciliations for two plant disbursement accounts were completed 20 to 40 days after month-end, with no independent review and 31 reconciling items older than 90 days. Cause: one preparer with no backup, no close calendar, and a reviewer who was also the preparer’s delegate. Owner: the shared-service reconciliations lead; sponsor and new independent reviewer: the regional controller. The shape comes from one decision: issuing the new procedure fast enough that the November month-end runs under it, which puts three month-ends inside the window.
| Days | Milestone | Into the binder |
|---|---|---|
| 0 to 5 | Owner and sponsor named; baseline: completion dates for the last six months; aged-item listing with count and total | Tabs 01 and 02 |
| 5 to 10 | Definition of done: prepared by business day 8, reviewed by business day 10 with reviewer notes; no item older than 60 days without an approved action; three month-ends before validation | Tab 03 |
| 10 to 14 | Procedure version 2 issued: preparer checklist, five-point reviewer checklist, close calendar, named backup preparer, independent reviewer; audit design review by phone day 12 | Tabs 04 and 05 |
| 10 to 25 | Aged items dispositioned: 22 cleared, 7 written off with approval, 2 under investigation with a named owner and date | Tabs 05 and 07 |
| 14 to 27 | November month-end under the new procedure: prepared business day 7, reviewed business day 9, reviewer notes retained | Tab 06, period 1 |
| 44 to 57 | December month-end: prepared business day 8; reviewed business day 11 at one plant because the reviewer was traveling; logged as an exception, delegate reviewer named | Tab 06, period 2 |
| 60 to 75 | Monitoring hook: aging report of items over 30 days in the regional controller’s monthly pack with a threshold; backup preparer performs the January close under observation | Tab 07 |
| 75 to 88 | January month-end: prepared business day 8, reviewed business day 10, no exceptions | Tab 06, period 3 |
| 88 to 95 | Closure request with three month-ends and the aging trend from baseline; validator tests all three month-ends for both accounts and re-performs one | Tab 10 |
F3 (Medium): purchasing-card policy out of date, no training, receipts missing
Condition: the card policy was last approved in 2019; 31 of 60 sampled transactions had no receipt or business purpose; card limits did not match the authority matrix. Cause: no system enforcement of the receipt and purpose fields, and no training since the card program changed vendors. Owner: the procurement director, with the learning team and the card vendor as dependencies. The trap in a policy finding is to treat the approved document as the fix; the condition was behavioral, so the closing evidence has to be behavioral too.
| Days | Milestone | Into the binder |
|---|---|---|
| 0 to 7 | Owner and sponsor named; dependencies logged; baseline: the 60-transaction sample re-performed with audit’s method; limits compared with the matrix for all 212 cardholders | Tabs 01, 02 and 08 |
| 7 to 10 | Definition of done: policy approved by the CFO and published; mandatory purpose field and receipt upload in the card system; limits aligned; at least 95 percent of cardholders trained within 30 days of launch; monthly exception report with manager follow-up; two statement cycles of exception reporting with documented follow-up, the most recent at or below 5 percent exceptions, before validation | Tab 03 |
| 10 to 33 | Policy redrafted; audit design review day 25 (audit notes the monthly manager review needs evidence of review, so a sign-off with exception notes is added); CFO approval day 33 | Tabs 04 and 05 |
| 20 to 45 | Vendor change request raised day 20 for mandatory fields and receipt upload; delivered day 42 with before and after configuration; limits reset for 212 cards | Tabs 05 and 08 |
| 45 to 60 | Training launched day 48; by day 60, 203 of 212 trained (95.8 percent); the nine on leave have cards suspended until trained | Tab 05 |
| 60 to 75 | Statement cycle 1 under the policy: exception report run with parameters and counts; 7.1 percent missing a receipt; managers follow up; four cards suspended | Tab 06, cycle 1 |
| 75 to 92 | Statement cycle 2: 3.4 percent exceptions; monitoring hook: exception rate in the monthly finance pack with a 5 percent threshold | Tab 06, cycle 2, and tab 07 |
| 92 to 100 | Closure request: policy (level 1), configuration and training (level 2), two cycles of exception reports with follow-up (level 3), and the 60-transaction sample re-performed showing 2 exceptions against the baseline of 31 (level 4) | Tab 10 |
Two things are true of all three timelines. Each owner told audit on day 10 what the validation-ready date would be, so none appears as overdue at day 91 even though only one is ready for a closure request by then. And each tab 06 was filled by the person performing the control, period by period, so the validator’s sample came from a population the owner never had to assemble. Keeping the relationship with internal audit running between audits, so that the next report is shorter, is the subject of living with internal audit year-round. This guide is general and educational; it is not legal or employment advice.
Questions readers ask
What is an audit remediation plan?
It is the owner’s working plan for delivering the actions agreed in an audit report: one accountable person per action, a definition of done in evidence terms, milestones dated from the critical path, a dependency log, and a binder where the evidence of each change is filed as it happens. The report says what will be done by when; the remediation plan says how, by whom each week, and what will prove it.
How long do you get to remediate an audit finding?
It depends on the rating and the organization’s methodology. A common convention, and the one the audit issue tracking guide uses, is around 90 days for a High-rated action, 180 days for a Medium and up to a year for a Low, with longer dates where a system change has a documented timeline. The due date is for implementation; validation and closure follow once the control has operated long enough to be tested.
What should an audit remediation tracker include?
The finding and action IDs from the report, one named owner per action, the agreed definition of done, three to six dated milestones, the original and current due dates side by side, a reference to the dependency log, a one-line status under a stated red-amber-green rule, the binder reference for evidence filed so far, and the validation-ready date. Use internal audit’s IDs and status words so your updates transfer without translation.
Is an audit finding closed once the fix is implemented?
No. Implementation means the control exists; closure means internal audit has validated that it operates and addresses the cause, which requires a period of operation: typically two to three month-ends for a monthly control, eight weeks to a quarter for daily or weekly controls, and one quarter-end for a quarterly one, two where the finding is High. The function’s methodology sets the exact minimum. In between, the correct status is “implemented, validation scheduled” with an agreed validation-ready date, not “closed” and not “overdue”.
How do I report status on audit findings to management?
One page in the same format every time: original and current due dates, an overall red-amber-green status under a stated rule, dated facts done since the last report with evidence references, the next two weeks’ milestones with owners, slippage with its recovery plan, dependencies and the specific ask of the sponsor, evidence status by binder tab, and the validation-ready date. Report a slip the week it becomes visible on the critical path, never after the date.
What if remediation depends on IT or a vendor?
Log the dependency the day you identify it, with the deliverable, the named person on the other side, the date you need it by with a buffer, and the ticket reference, and tell that person in writing that an audit action depends on it. Escalate at five working days blocked (owner to owner) and ten (sponsor to counterpart), cover the gap with an interim measure, and request a date change before the due date if the critical path no longer holds.
Can internal audit help design the fix?
Internal audit can and should review your design before you build it, say whether it addresses the cause and whether its evidence will be testable, and answer questions about what validation will look at. It should not design, build or operate the control, because the function that validates the fix has to stay independent of it. Ask for a short design review in the second or third week.
Related guides
- Being Audited? The hub for people on the receiving end — every auditee guide, in the order the audit unfolds.
- Writing Management Action Plans That Actually Close — the response this guide assumes is already written.
- How to Get an Audit Finding Closed — the closure request, what validators test, why done is not closed.
- Missing an Audit Action Due Date — the extension request template and how audit functions decide.
- Evidence Standards for Issue Closure — the four evidence levels and the exact operating-period minimums.
- Sustainability Testing: Validating That Audit Fixes Stay Fixed — what happens six and twelve months after closure.
- Issue Validation in Internal Audit: Evidence and Closure — the validator’s method, sample sizes and outcomes.
- Audit Issue Tracking: Data Model, Workflow, Metrics — how the audit-side log works and what the committee sees.
- The Finding and Issue Log Template — the fields your definition of done maps to.
- The Issue Closure Memo: An Annotated Template — how the validator’s conclusion is written up.
- Risk Acceptance by Management — the right process when an action should not be done.
- Control Ownership: Making Someone Actually Accountable — why one named person per action is non-negotiable.
- How to Perform a User Access Review That Actually Works — the design behind the F1 timeline.
- Living With Internal Audit Year-Round — the off-season habits that make the next report shorter.
Leave a Reply