The management response is the only part of an internal audit report that you write, and it is the part that decides your next twelve months. Every action in it goes into the audit function’s issue log with your name and a date, the audit committee sees the overdue ones by name every quarter, and none of them closes until the auditors have tested that the fix works. A response written to get through the closing meeting produces actions that miss their dates, fail validation and come back as repeat findings rated a level higher. A response written to close produces a quiet year.
This guide is written for the person on the receiving end of a finding: the process owner, manager or director who has to answer it. It covers what a response must contain and why, how to settle the finding’s wording before you commit to anything, how to write an action that fixes the cause rather than the sentence, the test every commitment should pass, how to set dates that hold, what internal audit will test when you say an action is done, twelve weak action plans rewritten, interim measures, extensions, and the honest alternative of accepting the risk. A worked example follows one real-looking action from draft to validated closure. The auditor’s side of the same exchange is in the guide to evaluating management responses; reading it first is the best preparation there is.
In this guide
- What the response is for, and who reads it
- The anatomy of a response that closes
- Settle the finding before you answer it
- Fix the cause, not the sentence
- The ownable-commitment test
- Setting dates that hold
- The validation preview: what internal audit will test at closure
- Twelve action plans, rewritten
- Interim measures
- When the date slips: extensions
- When the right answer is not to fix it
- Worked example: one action from draft to closure
- Questions auditees ask about action plans
- Related guides
What the response is for, and who reads it
Three rules in the Global Internal Audit Standards shape everything you write. Standard 14.4 lets the auditors either make recommendations, ask management for action plans, or work with management to agree actions, and in every case the actions have to resolve the gap between the criteria and what was found, bring the risk to an acceptable level, address the root cause, or improve the activity. Standard 15.1 requires the final report to name the individuals responsible for addressing each finding and the planned date for completing the actions, and to acknowledge any action you have already started or finished before the report is issued. Standard 15.2 requires the auditors to confirm that the actions were actually implemented, by asking about progress, performing risk-based follow-up and tracking status; when actions fall behind, they must get an explanation from you and take it to the chief audit executive, who decides whether senior management has, by delay or inaction, accepted a risk beyond the organization’s tolerance.
Read together, those rules tell you who your readers are. The first is the audit committee, which reads the response as a statement about how your area is managed. The second is the auditor who will validate the action months from now, possibly someone who was not on the engagement, working only from what you wrote. The third is you, in nine months, trying to remember what exactly you promised. A good response serves all three: it is short enough for the committee, specific enough for the validator and realistic enough for you. The acknowledgement rule in Standard 15.1 is worth using deliberately. If you fix something during fieldwork, say so before the report is final, because the report must then record it, and a finding that reads “management has already corrected this” lands very differently from one that does not.
The anatomy of a response that closes
Most audit functions give you a template; the elements below are the ones every template is trying to collect, whether or not it names them. Write each one deliberately. The last two columns are where responses usually go wrong.
| Element | What to write | Common mistake | What it costs you |
|---|---|---|---|
| Position | Agree, partially agree (saying which part), or disagree (saying why, in one paragraph) | “Management acknowledges the observation”, which commits to nothing | The auditors ask again, and the committee reads evasion |
| Action | What will change, stated so that someone else could check it happened | “Will ensure”, “will remind”, “will strengthen” | An action nobody can validate stays open indefinitely |
| Cause addressed | One line linking the action to the cause in the finding | An action aimed at the symptom the finding describes | The problem recurs and comes back rated higher |
| Owner | A named person, with title, who controls the fix | The most junior person in the room, or a committee | The action stalls, and the auditors return to the name on the page |
| Date | A completion date, plus milestones for anything over six months | A date chosen to satisfy the meeting | An overdue action reported to the committee by name |
| Interim measure | What reduces the risk until the fix is in place | Nothing, for a High finding with a long fix | The committee asks what protects the organization in the meantime |
| Evidence of completion | What you will show the auditors when you say it is done | Leaving this to the validator to work out | Validation fails on evidence you did not keep |
| Dependencies | Other teams or systems the action relies on, and their agreement | Committing another department without asking it | A missed date you could not control and still own |
The evidence-of-completion element is the one almost nobody writes, and it is the cheapest insurance in the whole response. Deciding at the start what you will show at the end forces the action to be concrete, tells your team what to keep as they go, and lets the validating auditor agree the evidence before you produce it. It also exposes a weak action immediately: if you cannot say what evidence would prove it is done, it is not an action yet.
Settle the finding before you answer it
The response is written against the finding as the report states it, so the finding’s wording has to be right before you respond to it. The Standards give you the openings. Under Standard 14.3, when the auditors evaluate potential findings, they are required to work with management to identify root causes where possible, determine the potential effects and evaluate significance, which is when wrong facts and weak causes are cheapest to fix. Under Standard 14.4 they must discuss recommendations with you, and if you disagree about recommendations or action plans, the function must have an established method that lets both sides state their positions and reach a resolution. And under Standard 13.1, if you still disagree about the results at the end of the engagement, the auditors must try to reach a mutual understanding, and must let both positions be expressed in the final communication; they are not obliged to change the results without a valid reason.
Use those conversations for three things, in order. Correct the facts, with evidence. Agree the cause, because the cause decides the action. Then discuss the rating against the function’s written definitions. Only when those are settled should you start drafting actions, and the cause matters most of the three: if the finding blames “insufficient review” and the real cause is that nobody independent exists at the site to do the review, an action written to the stated cause will be “review more carefully” and will fail. The site’s guide to disagreeing with a finding covers how to argue each of those points; this guide assumes you have done it.
Fix the cause, not the sentence
An action plan that answers the words of the finding rather than its cause is the single most common reason actions fail validation. The finding says approvals were missing, so the action says approvals will be obtained; the cause was that the approver was on leave for six weeks with no delegate, and six months later the same approver goes on leave again. The discipline is to write the cause down in your own words before writing the action, and then check that the action would have prevented the finding if it had been in place last year. The root cause analysis guide sets out the method auditors use; the table shows the pattern from the auditee’s side.
| Real cause | Action aimed at the symptom | Action aimed at the cause |
|---|---|---|
| No independent person exists at the site to review the work | “Reviews will be performed more carefully” | Move the review to a role outside the site, and remove the preparer’s approval rights in the system |
| The approver was absent and no delegate was named | “Approvals will be obtained for all transactions” | Name a delegate in the approval matrix and configure the workflow to route to the delegate automatically |
| The system report used by the reviewer was incomplete | “Staff retrained on the review” | Correct the report logic, validate it against source, and document the report’s parameters |
| The procedure was written for the old system | “Staff reminded to follow procedure” | Rewrite the procedure for the current system, approve it, and walk the team through the changed steps |
| The target date for the process was impossible in the staffing available | “Deadlines will be met going forward” | Change the deadline or the staffing, with the trade-off approved by the executive who owns the budget |
| An incentive rewarded speed over accuracy | “Accuracy will be emphasized” | Add an accuracy measure to the incentive, approved through the compensation process |
Honesty about cause also protects you. A response that fixes the real cause is short, because the real cause is usually one or two things. A response that fixes only the words tends to sprawl, adding training, reminders and a new checklist in the hope that one of them works, and each extra item is another action to evidence and another date to miss.
The ownable-commitment test
Before a response is submitted, put every action through five questions. An action that fails any of them will cause trouble later, and it is far easier to rewrite it now than to renegotiate it in six months.
| Question | If the answer is no |
|---|---|
| Can the named owner deliver this without needing permission from someone who has not agreed? | Change the owner to the person who controls the fix, or get the dependency’s written agreement before you submit |
| Could someone who was not in the room check that it happened? | Rewrite the action with an observable result: a configuration, a report, a signed document, a system record |
| Would it have prevented the finding if it had been in place last year? | You are fixing the symptom; go back to the cause |
| Is the date based on the work rather than on the meeting? | Rebuild the date from the dependencies and the operating period (next section) |
| Do you know what you will show the auditors when you say it is done? | Write the evidence of completion now, and tell your team to keep it |
The owner question deserves the most care. Ownership defaults to whoever was in the closing meeting, which is usually the manager of the area audited. But if the fix is a system change, the person who controls it is in IT; if it is a policy change, the owner of the policy; if it is a budget decision, the executive who owns the budget. Name that person, get their agreement before the response goes in, and put yourself down as the coordinator if you want to track it. The site’s guide to control ownership covers the difference between the person accountable for a control and the people who perform it.
Setting dates that hold
Dates fail for two reasons: they were chosen to sound committed, or they forgot that the auditors will not close an action until the new control has operated. Padding a date is noticed too: a nine-month date for a policy change invites the question of what else is going on. Build the date from the work instead. Identify the dependencies (release calendars, approval committees, procurement, hiring), estimate each, and then add the operating period the validation will need. The ranges below are typical for mid-sized organizations; your own release calendar and approval cycles decide the real numbers.
| Type of action | Typical time to put in place | Operating period before validation | What usually delays it |
|---|---|---|---|
| Policy or procedure change | 4 to 8 weeks, driven by the approval cycle | Communicated and in use; often one cycle of the process | The approving committee meets quarterly |
| Redesign of a manual control | 1 to 2 months | At least one full cycle: a month for a monthly control, a quarter for a quarterly one | Nobody told the people who perform it |
| System configuration change | 1 to 3 months, set by the release calendar | Usually a month of transactions after go-live | A missed change window, then a frozen period at year-end |
| New report or monitoring analytic | 2 to 4 months, including validating the report | One or two cycles of the report being reviewed and acted on | Report logic not validated against source |
| System or vendor replacement | 6 to 18 months | After go-live, as for a configuration change | Scope, budget and procurement; always needs milestones and interim measures |
| Hiring or reassigning staff | 3 to 6 months | The new person performing the control for a cycle | Approval to hire, then notice periods |
| Training | 1 to 2 months to deliver | Evidence it changed behavior, not only completion | Scheduling across shifts and sites |
| Data clean-up (vendor master, user access, customer records) | 1 to 3 months depending on volume | A re-run of the analytic that found the problem, showing it clean | Records nobody owns |
For any action longer than six months, give milestones with their own dates, and expect to be held to them. Milestones let the committee see progress on a long fix and let you show movement before the final date. They also protect you: an action that misses its final date after meeting three milestones reads as a slip, while one that misses a single distant date reads as nothing having happened.
The validation preview: what internal audit will test at closure
When you report an action complete, the auditors do not take your word for it. How hard they test depends on the finding’s significance, which Standard 15.2 builds in, but the shape of the test depends on the type of action, and knowing it in advance tells you what to keep. The table is the preview. The auditors’ side of it, including how they document the result, is in the guide to issue validation.
| Type of action | What the validator will usually test | Keep this as you go |
|---|---|---|
| Policy or procedure change | Approved by the right body, communicated to the people it affects, and actually followed in a few recent transactions | The approval record, the communication, and attestations or training records |
| Redesigned manual control | A sample of operations after the change, over a period long enough to mean something | Every operation’s evidence from the go-live date, filed where it can be found |
| System configuration change | The configuration itself, the change record that put it in place, and transactions after go-live that show it working | The change ticket with approvals and testing, screenshots of the setting, the go-live date |
| New report or monitoring routine | That the report is complete and accurate, that it ran, and that someone reviewed it and acted on the exceptions | Report parameters, each run with the reviewer’s evidence, and the exception follow-ups |
| Training | Completion by the population in scope, and ideally evidence that the behavior changed | Completion reports, and whatever measure shows the error rate or exception rate moved |
| Staffing or role change | The person in post and performing the control | Appointment date, role description, and their first operations of the control |
| Data clean-up | A re-run of the analytic that found the problem, showing it clean | Before-and-after extracts and the list of records corrected |
| Recovery of money (duplicates, overpayments) | Amounts recovered, written off with approval, or still being pursued | Recovery evidence per item and any write-off approvals |
Two habits save most validations. First, do not report an action complete the day the change goes live; report it once the new control has run for the operating period, with the evidence in hand. An action reported early fails validation, reopens, and counts against you twice. Second, send the evidence with the completion notice, organized by what the validator will test. A validator who receives a tidy package closes the action in hours; one who has to request everything takes weeks and finds more to ask about.
Twelve action plans, rewritten
These are the weak responses auditors see most often, each with a version that would pass the ownable-commitment test. Names, dates and amounts are placeholders; the structure is the point.
| Finding | Weak response | Response that closes |
|---|---|---|
| Quarterly access reviews not performed | “Access reviews will be performed going forward.” | “The finance systems manager will run a quarterly access review of [system] using a system-generated user list, starting with the quarter ending 31 March; reviews are signed off in the ticketing system and removals completed within ten business days.” |
| Duplicate vendor payments | “Staff have been reminded to check for duplicates.” | “IT will enable the duplicate-invoice check on vendor, invoice number and amount, with near-match logic, by [date]. The accounts payable supervisor will review the weekly duplicate report from [date]. The 12 duplicates identified ([amount]) will be recovered or written off with approval by [date].” |
| Outdated policy | “The policy will be updated.” | “The controller will revise the [policy] for the current system, obtain approval at the [committee] meeting on [date], and have affected staff attest by [date].” |
| Late reconciliation reviews | “Reviews will be completed on time.” | “The close calendar will require review by business day 8, with a named backup reviewer, from the [month] close. Late reviews will be reported in the monthly close metrics to the controller.” |
| Leavers with active system access | “IT will disable accounts faster.” | “The 14 active leaver accounts were disabled on [date]. IT will automate disabling from the HR termination feed by [date] (change [ticket]); from then, a daily report of leavers with active accounts will be reviewed by the identity team.” |
| Unapproved vendor bank-detail changes | “Changes will be approved.” | “From [date], bank-detail changes require a second approver in the workflow and a callback to a number already on file, recorded in the change record. The 31 changes made in the period will be re-verified by [date].” |
| Mandatory training not completed | “Staff will be reminded to complete training.” | “From [date], incomplete mandatory training escalates to line managers at 30 days and suspends system access at 60 days. Completion is reported monthly to the department head, with a target of 95 percent by [date].” |
| Segregation of duties conflicts | “Access will be reviewed.” | “Conflicting roles will be removed for the 9 users identified by [date]. Their transactions in the period will be reviewed by the controller by [date]. The role design will be changed so that the conflicting permissions cannot be combined (change [ticket], by [date]).” |
| Management review with no evidence | “Reviews will be documented.” | “The finance director will set review thresholds and a review template by [date]. Each month’s review, with questions raised and their resolution, will be filed in the close folder; the controller will check the first two months.” |
| Service provider’s assurance report not reviewed | “We will obtain the report.” | “The vendor management lead will adopt an assurance report review procedure, including mapping the provider’s complementary user entity controls to our own controls, by [date], and complete the first review of [provider]’s report by [date].” |
| Services continuing on expired contracts | “Contracts will be renewed.” | “The 6 expired contracts will be renewed or terminated by [date]. From [date], the contract repository will produce a monthly expiry report, and renewal decisions will be required 90 days before expiry.” |
| Unprotected spreadsheet used in a key control | “The spreadsheet will be improved.” | “By [date], formulas will be locked, versions controlled and inputs reconciled to source each month with the owner’s sign-off. The calculation will move into [system] by [date], with milestones reported quarterly.” |
Notice what the strong versions have in common: a named role, an observable result, a date that allows for the work, the treatment of the past as well as the future where money or access was involved, and in most cases a monitoring element so the fix does not quietly decay. None of them says “ensure”. The guide to writing audit recommendations shows the same discipline from the auditor’s pen.
Interim measures
Whenever the fix will take more than a month or two and the finding is rated Medium or above, say what reduces the risk in the meantime. An interim measure does not have to be elegant; it has to be real and evidenced. A weekly manual review of the highest-value transactions while a system change waits for its release window, a temporary second approver, a daily report reviewed by someone senior, or a pause on the riskiest activity are all common. Name the owner, the start date and the end condition (usually “until the permanent fix has operated for one full cycle”), and keep evidence of every interim operation, because the committee will ask what protected the organization before the fix, and the validator may test it.
When the date slips: extensions
Dates slip for legitimate reasons: a release is frozen, a key person leaves, a vendor misses its delivery. Ask for an extension before the due date, in writing, with the reason, the new date and what interim protection continues. In most functions one extension requested that way is routine; a second is reported to the audit committee; a third usually brings the chief audit executive to your executive, because Standard 15.2 requires the auditors to document the explanation for any action that has not progressed and take it to the chief audit executive, who has to decide whether the delay amounts to accepting the risk. If the original action no longer makes sense because circumstances changed, propose a different action that addresses the same risk instead of letting the original drift overdue.
When the right answer is not to fix it
Sometimes the honest response is that the organization will live with the risk: the fix costs more than the exposure, the process is being retired, or a compensating arrangement is judged enough. That is a legitimate management decision, and it is better made openly than disguised as an action nobody intends to complete. Say it in the response, name who is accepting the risk (someone with the authority to do so, usually above you), give the reason and, ideally, a date to revisit it. If the chief audit executive concludes that the risk accepted exceeds the organization’s appetite, Standard 11.5 requires a discussion with senior management and, if it is not resolved there, escalation to the board. The guide to risk acceptance by management covers how that record should read.
Worked example: one action from draft to closure
MidState Beverage’s route cash audit (report FY27-01, rated Unsatisfactory, five findings and eleven actions) found that at nine of its twelve depots the depot manager both prepared and approved the daily settlement reconciliation. The site’s guide to what happens during an audit follows the Fort Wayne depot through the engagement; this is the same finding seen from the other side of the response. The operations vice president coordinated the responses for all eleven actions, and the first draft for this one came from the depot managers.
First draft (rejected internally). Management agrees with the finding. Depot managers will ensure that daily settlement reconciliations are reviewed by a second person. Owner: depot managers. Target date: 30 November 2026.
It failed four of the five questions. At a small depot there is no second person independent of the manager, which was the cause of the finding, so the action could not be delivered by the people named. “Ensure” described no observable result. The date allowed three weeks for a change that needed a new reviewer and a system change. And nobody could say what evidence would prove it done. The depot managers were not wrong about the fix they wanted; they simply did not control it. The vice president took the draft to regional finance and IT, and the response that went into the report read differently.
Final response (Central Region version). Management agrees with the finding. Depot settlement reconciliations have been prepared and approved by the depot manager since the route accounting module was implemented, and no independent review has been in place. Action. Regional finance will review daily settlement reconciliations for all depots in the region, with the reviewer’s approval recorded in the ERP workflow. Depot managers will continue to prepare the reconciliation and will no longer hold approval rights in the module. Owner. Regional Finance Manager, Central Region. Target dates. 31 January 2027 for the workflow change; 28 February 2027 for one full month of independent review completed. Interim measure. From 1 December 2026 the regional finance manager will review a weekly sample of ten settlement reconciliations per depot, recorded by email, until the workflow change is live. Evidence of completion. The change record and role configuration showing approval rights removed; February’s workflow approvals; the interim review emails.
Every element of the final version traces to a decision. The owner changed to the person who controlled the reviewer role. The January date came from IT’s release calendar, not from the closing meeting, and the February date added the month of operation the validators would need. The interim measure answered the committee’s obvious question about December and January. And the evidence of completion was written into the response, so regional finance knew from the first day what to keep. The other regions’ finance managers signed equivalent responses for their depots.
| When | What happened | Evidence kept |
|---|---|---|
| Draft report week | First draft rejected by the operations vice president; final response agreed with regional finance and IT before submission | IT’s written confirmation of the January release slot |
| 1 December 2026 | Interim weekly review begins at every affected depot in the region | Weekly review emails with the ten reconciliations named |
| 31 January 2027 | Workflow change live; depot managers’ approval rights removed | Change record with testing and approvals; role configuration screenshots |
| 28 February 2027 | One full month of independent review complete; action reported complete with the evidence package attached | February workflow approval log |
| Next validation window | Internal audit sampled 25 settlement reconciliations from after the change, confirmed from the access listing that depot managers held no approval rights, and read the interim emails | The validator’s workpaper; action closed |
The action closed on its first validation, which in a report of eleven actions is what the audit committee notices: a list of actions validated closed next to the names of the people who owned them. The same finding with the first-draft response would have been overdue by December, extended in January, and failed at validation in the spring.
Questions auditees ask about action plans
Can I just write “management accepts the recommendation”?
No. Accepting a recommendation is a position, not an action. The report has to name who is responsible and by when, and the validator needs to know what will change. Accept the recommendation, then write the action, owner, date and evidence in your own words.
What if I agree with the finding but not with the recommendation?
Propose a different action that addresses the same risk and the same cause, and say why the recommended one does not fit your circumstances. Standard 14.4 allows the auditors to request action plans from management or agree actions with you instead of dictating them, and an alternative that closes the risk is normally accepted.
Who should own an action that needs IT or another department?
The person who controls the change. If you want to keep track of it, put yourself down as coordinator, but get the real owner’s agreement in writing before the response is submitted. An action owned by someone who cannot deliver it is the fastest route to an overdue item with your name on it.
Can I close an action as soon as the change is made?
Report it complete once the new control has operated for long enough to be tested, usually one full cycle, and send the evidence with the notice. Reporting on go-live day invites a failed validation, which reopens the action and counts against you twice.
What if I still think the finding is wrong?
Settle it before you respond, using the facts, the cause and the rating definitions. If you still disagree when the report is final, say so in one reasoned paragraph. Standard 13.1 requires the audit function to have a method that lets both sides state their positions on the final report; a disagreement that reads as reasoned is treated as a legitimate management position. The guide to handling an Unsatisfactory rating covers the case where the disagreement is about the report as a whole.
Related guides
- Being audited? — every guide for auditees and management, by stage of the audit.
- What to expect during an internal audit — the whole engagement from the auditee’s side.
- When you disagree with a finding — settling facts, cause and rating before you respond.
- Failed an internal audit? — what an Unsatisfactory rating means and what to do next.
- The PBC survival guide — handling audit requests without derailing your day job.
- Control ownership — who should own the fix, and the control.
- Evaluating management responses — the same exchange from the auditor’s side.
- Issue validation — what “validated closed” requires.
- Risk acceptance by management — when the answer is not to fix it.
- The life of an audit finding — from exception to closure, stage by stage.
- Root cause analysis — finding the cause your action has to fix.
- Audit issue log template — how your actions will be tracked.
- Internal audit report template — where your response sits in the finished report.
Leave a Reply