An issue is closed when internal audit has tested that the agreed action was done and works, and not before. Most functions know that sentence and most issue logs contradict it: items closed on an email that says “complete,” items closed because a procedure was reissued whether or not anyone follows it, items closed by the same manager who owned the action, items closed because the original finding was three years old and everyone was tired of it. The committee then reads a page that says 84 percent of actions are closed and believes it. Validation is the control over that page. It is a test, with a population, a procedure, evidence, and a conclusion, performed by someone independent of the person who claims the work is done, and the standard it tests against is the one written in the report the day the finding was issued.
This guide is the validation method: what “done” means for each type of action, the evidence that counts and the evidence that does not, how much to sample, when to validate and how to keep the backlog from becoming audit’s own overdue list, what to do with a partial result, the validation workpaper, three worked validations with different outcomes, the expectations that attach to regulatory issues, and how closure is reported. It was rewritten in September 2026 to reflect the Global Internal Audit Standards, which make confirming the implementation of action plans an explicit requirement under Standard 15.2. It pairs with the issue log template, which holds the fields validation writes to, and with the finding severity ratings that decide how hard the validation has to look.
In this guide
- Validation is a test, and the standard was set in the report
- The validation approach by action type
- What evidence counts
- Sample sizes, timing, and the backlog
- Outcomes: validated, partial, not validated, and re-opened
- The validation workpaper
- Three worked validations at MidState Beverage
- Regulatory issues: MRAs and what examiners expect
- Reporting closure to the audit committee
- Common validation failures
- Adapting the method: small functions, self-identified issues, external findings
Validation is a test, and the standard was set in the report
The Global Internal Audit Standards put follow-up in Domain V: Standard 15.1 requires the chief audit executive to establish a process for monitoring the disposition of findings and action plans, and Standard 15.2 requires confirmation that action plans have been implemented, with the nature, timing, and extent of the confirmation based on the significance of the finding and the risk. Two words in that standard carry the method. “Confirmation” means internal audit establishes it, which excludes management’s say-so. “Implemented” means the action is in place and functioning, which excludes a plan, a draft, a purchase order for the software, or a training session that was scheduled. The Domain V guide traces both through an engagement.
The standard a validation tests against is not “has the problem gone away,” which is a fresh audit, and not “did management do something,” which is a status update. It is the agreed action as written in the report and the evidence of completion agreed at the same time. The report template carries an “evidence of completion” column in the action plan for this reason: when the finding says the action is “an ERP deposit-listing report in bank format, in production, with the interim spreadsheet retired,” validation is a question with a yes-or-no answer, and when the finding says “management will strengthen controls over deposit listings,” validation is an argument. A function that inherits vague actions from old reports should convert them at the first follow-up into a specific action with an evidence standard, agreed with the owner, and record the conversion in the log; otherwise the vagueness is validated along with the action.
Validation is also a test in the technical sense the site’s test of design versus operating effectiveness guide describes. A new control has to be designed to address the risk in the finding and has to have operated for long enough to show that it does; a control implemented last week has a design but no operating history, and the honest conclusion is “implemented, operating effectiveness to be confirmed at the next cycle,” which is a status, not a closure. Functions that skip the operating leg produce the specific failure examiners look for: a control that existed on the validation date and had stopped by the next examination.
The validation approach by action type
Agreed actions fall into a small number of types, and each type has a definition of done, a form of evidence, a procedure, and a sample. The table is the core of the method; the rest of the guide is how to apply it. “Population” in the sample column means the instances of the new control or the corrected records that exist between the implementation date and the validation date.
| Action type | What “done” means | Evidence | Validation procedure | Sample |
|---|---|---|---|---|
| Policy or procedure written or revised | Issued, approved, communicated to the people who perform it, and being followed | The approved document with version and date; the distribution or acknowledgment record; instances of the procedure being followed | Inspect the document against the finding’s criteria gap; inspect distribution; test a sample of transactions after the issue date for compliance with the new step | Document: 1. Compliance: 10 to 25 instances depending on rating |
| New manual control introduced | Performed by the named role at the stated frequency with the stated precision, leaving evidence each time | The control’s own output: signed reviews, exception logs, reconciliations with reviewer sign-off | Design: walk the control once with the performer. Operation: inspect the evidence for each sampled instance; re-perform two | Daily control: 25 instances across at least 6 weeks. Weekly: 10 across a quarter. Monthly: 3 |
| System configuration change | The parameter is set as agreed in production, with the change record, and the behavior follows | Configuration screen in production with date; change ticket with approval and test evidence; a transaction showing the behavior | Inspect the setting with the administrator; inspect the change record; re-perform by attempting the blocked action in test or inspecting a post-change transaction that was blocked | Configuration: 1. Behavior: 5 transactions after the change date |
| New or changed system report used as a control | Report exists, is complete and accurate, reaches the reviewer, and the reviewer acts on it | Report distribution configuration; the reports for the period; reviewer evidence; an exception and its resolution | Test the report’s completeness and accuracy per the IPE method; inspect distribution; inspect reviewer action for sampled periods | Report accuracy: 1 period reconciled. Review: 8 to 12 periods |
| Access or segregation change | The conflicting access is removed in production for every user in the finding’s population, and new grants are prevented | User-role listing from production after the change; the removal tickets; the preventive rule or review that stops recurrence | Re-run the original conflict analysis on a fresh extract; inspect removal tickets for the users named in the finding; test the preventive rule with one request | Full population re-run; tickets for all named users |
| Training delivered | Delivered to the population that performs the process, with attendance recorded, and behavior changed | Attendance against the role list; the material; post-training transactions | Reconcile attendance to the role list; test transactions after the training for the behavior the training addressed | Attendance: full reconciliation. Behavior: 10 to 25 transactions |
| Remediation of a population (corrections, clean-up, re-performance) | Every item in the finding’s population has been corrected and the correction is evidenced | The corrected population with before and after; approvals for the corrections; the reconciliation of the count to the finding | Reconcile the corrected count to the finding’s population; inspect a sample of corrections to source; confirm the root cause fix is in place so the population does not regrow | Count: full. Corrections: 25 or 10 percent, whichever is smaller, minimum 10 |
| Organizational change (role created, reporting line changed, responsibility reassigned) | The role exists, is filled, has the authority in writing, and the activity is happening | Org chart and job description; evidence of the activity being performed by the new role | Inspect the documents; test instances of the activity as for a new manual control | Activity: as for a manual control at its frequency |
| Vendor or third-party action | The vendor has delivered the change and the organization has verified it, not merely been told | Vendor confirmation plus the organization’s own test evidence; contract amendment where the finding required one | Inspect the organization’s verification; re-perform where access allows; confirm the contractual mechanism that keeps it in place | Verification: 1 full re-performance where possible |
| Risk accepted instead of actioned | Not a validation. Acceptance documented by an executive at the level the rating requires and reported to the committee | The written acceptance; the committee minute | Inspect both; confirm the acceptance is re-reviewed annually | — |
Two rows deserve a note. For access and segregation findings, a sample is the wrong tool: the original finding came from a full-population conflict analysis, and validation re-runs the same analysis on a fresh extract, because a sample of users tells you nothing about the user who was missed; the user access review guide and the ERP SoD analysis guide have the queries. For training, “delivered” is the easiest action to claim and the least likely to have changed anything; test behavior after the training, not attendance, and treat attendance as the population definition for the behavior test.
What evidence counts
Validation evidence follows the same hierarchy as any other audit evidence: what internal audit obtained directly from a system outranks what management supplied, what a system generated outranks what a person prepared, and what shows the control operating outranks what describes it. The matrix below is the one to keep beside the log, because the pressure at validation always runs toward accepting the weaker form. Management is busy, the item is old, the email says it is done, and the validator wants the row to go green.
| Evidence type | Sufficiency | Acceptable when | Not acceptable for |
|---|---|---|---|
| Management’s statement that the action is complete (email, log update, meeting) | None on its own | Triggering the validation; never as its basis | Any closure |
| The revised document (policy, procedure, job description) | Design only | Documentation actions, combined with distribution and compliance evidence | Closure of a control-operation finding on its own |
| Screenshots supplied by management | Low | Corroborating evidence you obtained; never as sole evidence of a configuration | Configuration and access findings, where a validator-observed screen is required |
| System reports run by or with internal audit, with parameters visible | High | Populations, configurations, access listings, control outputs | — |
| The control’s own output over a period (signed reviews, exception logs, reconciliations) | High for operation | Manual and review controls, sampled across the period since implementation | Design, which needs a walkthrough of one instance |
| Re-performance by the validator | Highest | Reconciliations, matches, calculations, blocked actions; at least two instances in every validation of a manual control | — |
| Observation of the control being performed | High for that instance | Physical and custody controls; as design evidence for any control | Operation across a period |
| Third-party confirmation (vendor, SOC report, external auditor test) | Medium to high | Vendor actions and outsourced controls, with the organization’s own verification | Replacing the organization’s verification |
| Inquiry of the performer | Low | Understanding how the control is performed; corroborating documents | Anything on its own |
The rule that does the most work is the second row. A reissued procedure closes a finding whose condition was “the procedure did not describe the process as performed”; it does not close a finding whose condition was “the review was not performed,” because the procedure said to perform it before and nobody did. Match the evidence to the condition in the original finding, and if the condition was about operation, the evidence must be about operation.
Sample sizes, timing, and the backlog
Sample sizes for validation come from the finding’s rating and the control’s frequency, using the same ladder the site’s sample-size guide uses for operating-effectiveness tests, with one adjustment: the population is the period since implementation, which is often short. A daily control implemented six weeks ago has a population of about 30 operating days, and a sample of 25 from 30 is close to the whole; that is fine, and it is also why validation of a high-rated finding should not happen in the first two weeks after implementation, because there is nothing to sample. The table below is a working set.
| Control frequency | High finding | Medium finding | Low finding | Minimum operating period before validation |
|---|---|---|---|---|
| Many times daily / automated | 25 items plus configuration and change record | 15 items plus configuration | Configuration and 5 items | 4 weeks |
| Daily | 25 across at least 6 weeks | 15 across 4 weeks | 10 | 6 weeks |
| Weekly | 10 across a quarter | 6 | 4 | 8 weeks |
| Monthly | 3 months | 2 months | 1 month | 2 month-ends |
| Quarterly | 2 quarters | 1 quarter | 1 quarter | 1 quarter-end |
| One-time (configuration, access removal, population clean-up) | Full population re-run or reconciliation | Full population | Full population | None; validate on completion |
Timing is governed by the service level the function publishes, and the issue log template sets 45 days from “implemented” to a validation conclusion. The minimum operating period above can push past 45 days for a weekly or monthly control; when it does, record the item as “implemented, validation scheduled” with the date, so the log shows audit’s reason rather than audit’s delay. The backlog is audit’s own overdue list and belongs in the committee pack with the same prominence as management’s overdue actions. Practically, the way to keep it short is a validation cycle rather than ad hoc validations: a fixed two-week window each quarter in which every item reported as implemented in the prior quarter is validated, staffed as an engagement with hours in the plan. Functions that validate “when someone has time” build backlogs of six months and lose the operating evidence they needed.
Outcomes: validated, partial, not validated, and re-opened
A validation has four possible conclusions, and the discipline is in the middle two. “Validated” means the action as agreed is in place and operating, with evidence on file. “Partially validated” means the action is in place for part of the population or part of the risk, and the residual is defined precisely enough to become a new action with its own date. “Not validated” means the action is not in place, or is in place and does not address the condition, and the item returns to in-progress with its original due date still governing its age. “Re-opened” is a validated item where the control has subsequently stopped, found by a later engagement or a follow-up test; it returns to the log as a new action row referencing the original, and it is reported to the committee as a re-opening, because a control that stops after validation says something about the culture that the original finding did not.
| What the validation found | Conclusion | Log status | What happens next |
|---|---|---|---|
| Action in place as agreed; operating evidence across the required period with no exceptions | Validated | Validated — closed | Closure reported; evidence filed with the log |
| Action in place; one exception in the operating sample with a documented cause and correction | Validated with observation | Validated — closed | Observation noted in the log; re-tested at the next engagement in the area |
| Action in place; exceptions in the sample without cause, or a rate above the finding’s tolerance | Not validated (operation) | In progress | Owner told what failed and what evidence is needed; re-validation scheduled; escalation ladder continues from the original date |
| Action in place for part of the population (some depots, some users, some months) | Partially validated | Validated — closed (partial), plus a new residual row | Residual action row created with the uncovered population, an owner, and a date; original age carried in the finding roll-up |
| Action in place but it does not address the condition in the finding | Not validated (design) | In progress | Action redefined with the owner; if the owner disagrees, the disagreement goes to the sponsor and the committee |
| A different action was taken from the one agreed, and it addresses the condition | Validated (action revised) | Closed — superseded, with the replacement validated | Replacement row inherits the original due date; the change recorded in the Changes sheet |
| Action claimed but no evidence available | Not validated (evidence) | In progress | Item flagged; if evidence cannot exist, the action is redefined so that it produces evidence |
| Control validated previously has stopped operating | Re-opened | New action row referencing the original; original stays closed with a re-open flag | Reported to the committee by name; root cause of the lapse added to the finding |
The partial outcome is the one that protects the log from the laundromat pattern. A 96 percent result is not “validated”; it is validated for 96 percent and open for 4, and the 4 gets a row. The temptation to round up is strongest when the remaining population is small and the owner has worked hard, and the answer is that the residual row is small too, and it will close in a month, and the committee will see a log that told the truth.
The validation workpaper
A validation workpaper is a short test workpaper and follows the site’s workpaper standards: purpose, the standard being tested against, source and population, procedure, results, conclusion, and reviewer. One page is normal; a validation that needs five pages is usually a validation that discovered a new finding, which should be written as one. The template below is the house version, with the evidence-of-completion field copied from the report so that the standard cannot drift.
Validation workpaper V-[action ID]. Finding: [finding ID and title, verbatim from the report]. Rating: [High / Medium / Low]. Agreed action: [verbatim from the report]. Evidence of completion, as agreed: [verbatim from the report’s action plan]. Owner: [name, title]. Original due date: [date]. Date implemented (claimed): [date]. Validator: [name]; independent of the engagement that raised the finding: [yes / no, reason].
Population and period. [Instances of the control or corrected records from the implementation date to the validation date: count, source report with parameters, completeness check performed.]
Procedure. [Design: what was walked or inspected. Operation: sample size and selection basis; what was inspected or re-performed for each item; the exception definition.]
Results. [Items tested, exceptions with identifiers and explanation, re-performance results, population reconciliation for one-time actions.]
Conclusion. [Validated / partially validated with residual defined / not validated with reason.] Residual action, if any: [description, population, owner, due date]. Log updated: [date, status entered].
Review. Reviewed by [name] on [date]. Evidence filed at [reference].
The independence line matters more than it looks. The auditor who raised a finding has an interest in seeing it closed cleanly and an interest in being right that it was serious; where staffing allows, the validator is someone else, and where it does not, the reviewer is. The validation workpaper basics guide is the junior-analyst version of this section, with a filled example.
Three worked validations at MidState Beverage
MidState Beverage is the site’s running example: a three-state distributor with 12 depots and 300 routes, whose FY27-01 route cash report was rated Unsatisfactory with five findings and eleven agreed actions, and whose FY27 warehouse inventory engagement followed later in the year. The three validations below were performed in the function’s September validation window; they were chosen because each ended differently.
Validated: the override listing (FY27-01, action F2a)
The finding: settlement variance overrides were self-approved at every depot, 1,412 of 37,400 settlements in six months, and the daily manager review required by procedure was not performed anywhere because the exception listing had never been configured to distribute after an upgrade. The agreed action F2a: configure the override exception listing to email each depot manager and HQ Route Accounting daily, with a weekly trend report by route. Evidence of completion as agreed: configuration screenshots and the first month of distributed listings. Owner: VP Operations. Due 15 April; implemented 11 April.
The validation, performed 10 June. Design: the validator sat with the ERP administrator and inspected the report distribution configuration in production, twelve depot manager addresses plus the HQ distribution list, schedule daily at 06:00, with the change ticket approved 9 April. Operation: the population was 42 daily listings from 11 April to 5 June; the validator selected 25 at random, obtained each from the HQ mailbox archive rather than from the depots, and inspected each for the depot manager’s initials and the reason-code follow-up the procedure now requires. Three depots were visited on other work in May, and the manager’s initialled copies were observed at each. Re-performance: for two listings the validator re-ran the report from ERP with the same parameters and agreed the override count and total to the distributed copy. Result: 25 of 25 listings distributed and reviewed; one listing (Toledo, 14 May) initialled two days late with a note explaining the manager’s absence, treated as an observation rather than an exception because the backup review was performed. The weekly trend report was inspected for eight weeks. Conclusion: validated; closed 10 June; observation noted for the next route-accounting engagement. Validation lag: 60 days, over the 45-day service level, because the daily control needed six weeks of operation before the sample was meaningful; recorded as such in the log.
Partially validated: customer statements (FY27-01, action F5a)
The finding: monthly statements were emailed only, and 1,130 of 4,200 route customers had no email on file and received no statement, leaving no control over lapping for 27 percent of accounts. The agreed action F5a: reinstate paper statements for customers without email. Evidence of completion as agreed: the July statement run showing 100 percent coverage. Owner: Director of Route Accounting. Due 31 July; implemented 31 July.
The validation, performed 20 August. The population was the August statement run, obtained by the validator from the ERP statement log with parameters visible: 4,200 active route customers; 3,071 emailed, 961 printed and posted through the mail house, 168 with no delivery, because those accounts had neither an email address nor a valid mailing address on file. The mail-house manifest was reconciled to the printed count; a sample of 15 printed statements was traced from the manifest to the customer account and the statement image. The action was done as written: paper statements were reinstated for every customer the system could address. The evidence standard, 100 percent coverage, was not met, and the reason was a population the action had not anticipated. Conclusion: partially validated. F5a closed as validated for the 4,032 covered accounts; residual action F5c created with the 168 uncovered accounts, an owner, and a due date of 31 October, agreed with the Director on the day. Coverage will be re-performed from the October run. The finding stays open in the roll-up until F5c is validated; the committee page for October showed exactly that.
Not validated: the cycle-count module (FY27 inventory engagement)
The finding: the ERP cycle-count module had been disabled at four depots after the FY24 upgrade and counts at those depots were performed on spreadsheets with no system record, so that adjustments could be posted without a count behind them. The agreed action: re-enable the module at the four depots, migrate the count schedules, and retire the spreadsheets. Evidence of completion as agreed: module status in production for the four depots; the first month of system-recorded counts at each; confirmation that the spreadsheet files were archived. Owner: IT Director with the Director of Route Accounting. Due 31 August; reported implemented 28 August with an email from IT: “module enabled at all four sites.”
The validation, performed 22 September. The validator inspected the module configuration with the administrator: enabled for all four depot codes, change ticket approved 21 August. Then the operating evidence. The count log for September showed system-recorded counts at Springfield and Lima, on schedule, 31 and 28 counts respectively. At Toledo and Muncie the log showed zero counts. The depot managers at both, reached by phone, confirmed they were still counting on the spreadsheet because the handheld scanners had not been re-paired to the module and the IT ticket for that was open. The spreadsheets were in use; nothing had been archived. Conclusion: not validated. The action was in place as a configuration and not as an operating control at two of four depots; the item returned to in-progress with the original due date of 31 August governing its age, the owner was told exactly what evidence would close it (September and October count logs for Toledo and Muncie, and the archive confirmation), and re-validation was scheduled for the December window. The escalation ladder continued from 31 August. The IT email that had reported the action complete was filed with the validation as the reason the function does not close on emails.
| Action | Claimed | Population validated | Procedure | Result | Conclusion | Log status |
|---|---|---|---|---|---|---|
| F2a override listing | 11 Apr | 42 daily listings, 11 Apr to 5 Jun | Config inspected; 25 listings inspected; 2 re-performed; 3 depots observed | 25/25 reviewed; one late with backup | Validated with observation | Validated — closed 10 Jun |
| F5a paper statements | 31 Jul | August run, 4,200 accounts | Statement log reconciled to mail-house manifest; 15 traced | 4,032 covered; 168 unaddressable | Partially validated | Closed (partial); residual F5c due 31 Oct |
| Cycle-count module | 28 Aug | September count logs, 4 depots | Config inspected; count logs by depot; managers contacted; spreadsheet status | 2 depots counting in system; 2 still on spreadsheets | Not validated | In progress; age from 31 Aug; re-validate December |
Regulatory issues: MRAs and what examiners expect
In a regulated financial institution, a Matter Requiring Attention or its equivalent carries a validation expectation that is stricter than the function’s own: the regulator expects internal audit, or an independent function, to validate management’s remediation before the institution reports the matter as closed, and to have done so with evidence the examiner can re-perform. The regulatory issue lifecycle guide covers the whole cycle; the validation-specific points are these. The standard is the regulator’s language, not management’s action plan, so the validation tests whether the condition the regulator described no longer exists, which is broader than whether the agreed action was done. Sustainability is explicit: examiners look for a period of operation, commonly two to three cycles of the control, before they accept closure, and a validation performed the week after implementation will be rejected. The validation report is a document the examiner will read, so it is written as one: population, procedure, sample, results, conclusion, and the validator’s independence stated. And the log’s “regulatory” flag means the item is never closed as risk accepted without the CAE and the committee chair, because the regulator has not accepted the risk. Where the institution’s second line performs the first validation, internal audit’s role is to validate the validation, on a sample, with the same standards; the financial services guide sets out how examiners test that.
Reporting closure to the audit committee
Closure is reported through the issue log’s committee cuts, not through prose. The movement reconciliation shows how many items were validated-closed in the period, and the exceptions page shows every partial, every not-validated, and every re-opening by name. Three numbers give the committee a reading on validation itself: the validation backlog (items implemented and awaiting validation, by days waiting), the not-validated rate (the share of claimed implementations that failed validation in the period, which is a measure of how reliable management’s claims are), and the re-open rate (validated controls that later lapsed, which is a measure of sustainability). A not-validated rate above 20 percent means management is reporting implementation to stop the escalation clock; a re-open rate above 10 percent means validations are happening too early. Both belong in the CAE’s commentary. The issue tracking guide covers the tooling for producing the numbers, and the control deficiency evaluation guide the case where a validated remediation still leaves a deficiency to aggregate for financial reporting.
Common validation failures
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Closing on the claim | An email says “done”; the row goes green | The committee is told a risk is addressed on management’s say-so | Only audit closes, only on evidence, only against the agreed standard |
| Validating design, not operation | A new procedure or configuration is inspected; nobody checks whether it runs | Controls that exist on paper are closed; the next engagement re-finds them | Operating sample across the minimum period for every control-type action |
| Validating too early | Validation the week after implementation | No operating history; sustainability unknown; regulators reject it | Minimum operating periods by frequency; “implemented, validation scheduled” as an honest interim status |
| Rounding up partial results | 96 percent coverage recorded as validated | The uncovered population disappears from the log | Partial conclusion with a residual row every time |
| Accepting management’s screenshots | Configuration evidence supplied by the owner, undated | The validator cannot say the setting exists in production today | Validator-observed configuration with the administrator, dated |
| Drifting standard | The action is validated against what management did rather than what was agreed | A weaker action closes a finding written for a stronger one | Evidence-of-completion field copied from the report into the workpaper; changes to the action go through the log’s change process |
| Validator is the finding’s author | The senior who wrote the finding closes it | Independence in appearance and fact | Different validator where possible; independent reviewer always |
| No validation cycle | Validations happen when someone is free | Backlogs of months; operating evidence lost; audit’s overdue exceeds management’s | A quarterly validation window staffed as an engagement, with hours in the plan |
| Silent re-opening | A later engagement finds the control lapsed and writes a new finding with no reference to the old one | The committee never learns that validated controls do not stick | Re-opened status referencing the original; re-open rate reported |
Adapting the method: small functions, self-identified issues, external findings
A small function cannot separate the validator from the author, so it separates the reviewer: the CAE reviews every validation workpaper before closure, and for high-rated findings the audit committee chair is told of the closure with the evidence summary. The method is otherwise unchanged; what a small function should resist is the argument that validation is too expensive, because a validation is a one-page test and a re-found finding is a new engagement. Management self-identified issues, which the issue log template encourages into the log with their own source flag, are validated with a lighter touch, typically inspection of the completed action rather than a full operating sample, unless they are high-rated, in which case they are findings and are validated as such. External auditor management-letter points and regulator findings in the log are validated to the external party’s standard, which is usually stricter, and the validation report is written so it can be handed over; the reconciliation of the log to the external auditor’s own tracking list each quarter is where discrepancies in closure status surface. Advisory-sourced items, the “matters for attention” from advisory memos, are validated exactly like findings, because the log made them findings the day they were entered.
The issue log is the system of record for every conclusion above, the report template is where the evidence-of-completion standard is set, and the severity ratings decide how much validation each item earns. Every guide on the site is indexed at All Guides and by subject on the Topics page.
Related guides
- The finding and issue log template — the fields, statuses, and ageing rules validation writes to
- Issue validation workpaper basics — the junior-analyst version with a filled example
- Finding severity ratings — the ratings that size the validation
- Audit evidence — the hierarchy the evidence matrix is built on
- Test of design vs. operating effectiveness — why a new control needs an operating period
- The lifecycle of regulatory issues — MRAs from identification to closure
- Tracking internal audit issues — tooling from Excel to platforms
- The audit report template set — where the evidence-of-completion standard is agreed
- Control deficiency evaluation — aggregating what validation leaves open
Leave a Reply