Join our Newsletter — 33% off our NHI Course
Home› Guides› Audit Finding Remediation Guide: Taking Findings From Root…
Guide Audit, Assurance & Compliance

Audit Finding Remediation Guide: Taking Findings From Root Cause to Verified Closure

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 14 November 2026 15 min read
On this page

Most audit findings are not closed because the fix was hard, they stay open, or come back next year, because nobody proved the fix worked. Once an auditor has graded a finding, the work shifts to management: find the real cause, give it one owner, change the control, gather evidence that the changed control operated over time, get it retested and close it formally. This guide covers that remediation lifecycle end to end, with the requirements that shape it in the IIA Global Internal Audit Standards, the GAO Green Book, OMB Circular A-123, PCAOB AS 6115 and NIST SP 800-53. It is written for control owners, GRC teams and internal auditors who manage findings from SOC 2, SOX, ISO/IEC 27001 and internal audits. How an exception becomes a deficiency, and how severity is graded, is covered in the Audit Exception vs Control Deficiency guide; this page starts where that one ends.

Key takeaways

  • Root cause is management's job, not the auditor's. OMB Circular A-123 states that identifying root causes is management's responsibility and that relying only on audit findings may leave corrective actions incomplete.
  • A finding is closed by evidence, not by a ticket status. The GAO Green Book (paragraph 17.06) treats audit resolution as complete only when action corrects the deficiency, produces improvements or shows the finding does not warrant action.
  • Operating effectiveness needs a run of time. PCAOB AS 6115 ties the testing period to the control's risk: a daily control can show effectiveness sooner than a pervasive entity-level control, so plan closure dates around the evidence window.
  • Follow-up is a duty for internal audit too. IIA Standard 15.2 requires internal auditors to confirm implementation with an established methodology and a tracking system, scaled to the finding's significance.
  • Slipped dates are a risk decision. Under Standard 15.2, when management falls behind, the chief audit executive decides whether delay amounts to accepting risk beyond tolerance; record it as such rather than quietly extending the date.

The remediation lifecycle at a glance

Every regime words it differently, but the stages are the same. The table shows each stage, what must exist before moving on, and the source that sets the expectation.

StageExit criterionWhere the expectation comes from
1. Intake and agreementFinding logged with criteria, condition and severity; management response agreed or disagreement recordedIIA Standard 14.4 (disagreement methodology); Green Book 17.02 to 17.04 (reporting issues)
2. Root cause analysisDocumented cause that explains the condition, distinguished from symptomsIIA Standard 14.3; OMB A-123 Section V
3. Ownership and planNamed owner with authority, resources, critical path milestones and a date certainOMB A-123 Section V; Green Book 17.05; NIST SP 800-53 CA-5
4. Interim risk treatmentCompensating control or formal risk acceptance in place while the fix is builtIIA Standard 15.2 (risk beyond tolerance); organisational risk policy
5. Implement the fixControl redesigned or re-performed; change record linked to the findingGreen Book 17.06
6. Evidence of operationEnough occurrences of the control to support testingPCAOB AS 6115 .33 (period depends on risk)
7. Validation and retestIndependent test passes; validation documented in writingOMB A-123 (validated by Senior Accountable Official); IIA Standard 15.2
8. Closure and lessonsClosure record retained; trend and recurrence data updatedNIST SP 800-53 CA-5 and PM-4; CSF 2.0 ID.IM-01

Where the system is subject to NIST SP 800-53, FedRAMP or CMMC, the finding also lives on a formal Plan of Action and Milestones with prescribed fields and time limits. See the Plan of Action and Milestones (POA&M) Guide. The stages here apply whether or not a POA&M is mandated.

Stage 1: intake and the management response

The IIA glossary defines a finding as the gap between the evaluation criteria and the condition of the activity under review. Remediation starts by restating that gap precisely, because a vague finding produces a vague fix.

  • Criteria: the requirement, quoted: the control description, policy clause, SOC 2 criterion or ISO/IEC 27001 Annex A control.
  • Condition: what the auditor found, with the sample size and the exceptions (for example, 3 of 25 leavers retained active directory accounts beyond the 24-hour standard).
  • Scope boundary: which systems, business units and period the finding covers. Agree this up front; scope argued at retest time delays closure.
  • Management response: agree, partially agree or disagree. IIA Standard 14.4 requires internal auditors to discuss recommendations with management and to follow an established methodology when the two sides disagree, so both positions and the rationale are on the record.

Avoid committing to a closure date in the response before the root cause is known. A common pattern is "agreed, owner X, root cause and plan due in 30 days", followed by a dated plan.

Stage 2: root cause analysis that holds up

IIA Standard 14.3 asks auditors to work with management to identify root causes where possible, and the IIA glossary defines root cause as the underlying reason for the gap between criteria and condition. OMB A-123 is blunter: root cause analysis is management's responsibility, so corrective plans address the underlying problem rather than symptoms. Re-performing the failed samples (disabling the three leaver accounts) fixes the condition, not the cause.

Cause categories that recur in IT and identity findings

Cause categoryTypical evidenceFix that addresses it
Design gap: the control as written cannot meet the criterionControl covers the HR system feed but not contractors or service accountsRedesign scope; add the missing population to the control
Population gap: assets or identities outside the controlApplications not onboarded to the review tool; non-human identities with no ownerReconcile inventory to source systems; onboard and assign owners
Operating failure: the control exists but was not performedReviewer absent, queue not worked, ticket closed without actionBackup performers, escalation timers, workload rebalancing
Evidence gap: control operated but cannot be shownApprovals in chat or email, screenshots without timestampsSystem-generated evidence, retained logs, standard evidence format
Automation failure: a job or integration silently stoppedConnector errors, failed provisioning runs not alertedJob monitoring and alerting; reconciliation report
Ownership gap: no accountable personControl owner left; shared mailbox as ownerNamed owner and deputy in the control register

Use a structured method rather than a meeting: a five whys chain recorded in the finding, or a cause and effect diagram for multi-team findings. Test the stated cause against every exception in the sample. If one exception is not explained, the analysis is incomplete. For the analysis format, the Post-Incident Review and Root Cause Analysis Template adapts well to audit findings.

Check also for the same cause elsewhere. A deprovisioning failure in one application usually exists wherever the same manual process is used. Fixing only the sampled application invites a repeat finding against the next one.

Stage 3: ownership, plan and dates

OMB A-123 lists the elements of a corrective action plan: communicate corrective actions to the right level and delegate authority to the people doing the work, identify resources (including senior leadership support), set critical path milestones that lead to a date certain, require testing to validate the fix, and keep accurate status records. Those elements make a good template for any sector.

  • One accountable owner: a named person with authority over the process, not a team or mailbox. Green Book paragraph 17.05 expects management to assign responsibility and delegate authority for corrective action.
  • Milestones, not a single date: design complete, change deployed, first evidence period complete, ready for retest. Each milestone is a check that slippage is visible early.
  • Date set from the evidence window: work back from when retest can happen. A quarterly access review cannot show operating effectiveness until at least one full cycle has run after the fix.
  • Cost and options considered: OMB A-123 asks management to weigh alternative mitigation strategies and choose the most cost-effective solution. Record the options rejected and why.

Public sector timelines are explicit: OMB A-123 expects agencies to decide on Inspector General recommendations within six months of the report and implement within one year where practicable. Private organisations should set their own targets by severity, for example in the audit charter or GRC policy, and apply them consistently.

Stage 4: managing risk while the fix is built

Between agreement and closure the risk still exists. Decide explicitly how it is treated.

OptionWhen it fitsWhat to document
Compensating controlA different control can reduce the same risk for the interim (for example, a weekly detective report of active leaver accounts while automated deprovisioning is built)Control description, operator, frequency, evidence, end date
Formal risk acceptanceThe fix is costly or long and residual risk sits within appetiteApprover at the right authority level, rationale, expiry and review date
Accelerated fixSeverity is high and no adequate compensating control existsEscalation record, resources released, revised milestones

See the Security Exceptions and Risk Acceptance Guide for approval levels and expiry. Distinguish carefully between mitigating and remediating; the Mitigation vs Remediation guide explains why a compensating control should not be reported as closure.

Stages 5 and 6: implementing the fix and building evidence

Implementation should go through normal change management, with the change record referencing the finding ID so the auditor can trace cause to fix. Then the control has to run.

  • Define the evidence before the fix goes live: agree with the auditor what population, report and fields will be tested. System-generated reports with parameters and run timestamps are stronger than screenshots.
  • Prove population completeness: show how the report population reconciles to the source of truth (HR records, the CMDB, the cloud account inventory). An incomplete population is itself a finding.
  • Let enough occurrences accumulate: PCAOB AS 6115 paragraph .33 says the testing period must be adequate to show operation as of the asserted date and depends on the control's risk, with daily controls needing less time than pervasive entity-level controls. Apply the same logic outside SOX: a handful of occurrences for a daily control, at least one full cycle for monthly or quarterly ones.
  • Keep evidence where the auditor can retrieve it: the Audit Evidence Request Tracker Template helps keep requests, files and status in one place; continuous controls monitoring can generate the evidence automatically for automated controls.

Stage 7: validation and retest

Validation must be independent of the person who built the fix. OMB A-123 says correction is determined only after actions are taken and validated by the Senior Accountable Official, in writing and supported by documentation. IIA Standard 15.2 requires internal auditors to confirm implementation through inquiry, risk-based follow-up assessments and a tracking system, with the depth of follow-up reflecting the finding's significance.

Choosing the level of retest

Finding severityTypical validationWho performs it
Low, design-only or documentation findingInspect the updated control description and one occurrenceSecond line or GRC team
Deficiency in operationRe-test a fresh sample from the post-fix periodInternal audit or independent tester
Significant deficiencyFull re-test of design and operating effectiveness over the evidence windowInternal audit; external auditor where it will rely on the control
Material weakness (public company ICFR)Management testing over a sufficient period; optional auditor engagement under AS 6115Management, then the external auditor

For a previously reported material weakness, AS 6115 describes a voluntary engagement in which the auditor reports whether the weakness continues to exist as of a date management specifies. The conditions include management asserting that the specified controls are effective, supporting the assertion with sufficient evidence including documentation, and presenting a written report. The date must fall after management's most recent annual assessment. Most companies instead show remediation through the next annual assessment, but the conditions are a useful bar for what "remediated" means.

Stage 8: closure, follow-up and recurrence

Close a finding with a record that a stranger could audit: the original criteria and condition, the root cause, the fix and change reference, the evidence period, the validation result and the validator, and the closure date. NIST SP 800-53 CA-5 requires the POA&M to be updated from assessment and monitoring results, and PM-4 requires an organisation-wide process for it, so closure records should feed that register rather than live in email.

  • Slipped dates: IIA Standard 15.2 requires auditors to obtain and document management's explanation and discuss it with the chief audit executive, who decides whether senior management has, through delay or inaction, accepted risk beyond the organisation's tolerance. Escalate with that framing.
  • Repeat findings: tag any finding that matches a previously closed one by control and cause. A repeat means the earlier root cause analysis or validation failed; reopen that analysis rather than starting fresh.
  • Lessons: CSF 2.0 ID.IM-01 expects improvements to be identified from evaluations. Review closed findings each quarter for themes that justify a programme change, for example moving a family of manual controls to automation.

Where identity fits

Access control findings dominate IT audit reports: leavers with active accounts, incomplete access reviews, shared or unowned privileged accounts, and service accounts and API keys nobody can explain. The Top 10 Identity Audit Findings lists the patterns. Their root causes are usually population and ownership gaps: the joiner, mover and leaver process covers employees but not contractors, and non-human identities sit outside the access review entirely. Remediation that adds those populations to the control, with a named owner per identity, closes the cause. See Audit Readiness for AI Agents and NHIs for evidence that non-human identity controls operated.

Detection and measurement

Track remediation as a portfolio, not finding by finding.

  • Overdue rate: percentage of open findings past their committed date, split by severity.
  • Median time to closure: from report date to validated closure, by severity and by business unit.
  • Repeat finding rate: share of new findings matching a previously closed finding on control and cause. This is the clearest signal that root cause or validation is weak.
  • Retest failure rate: findings submitted for closure that fail validation. A high rate points to closure requests made before the evidence window has run.
  • Date revisions per finding: how often committed dates move; more than one revision should trigger escalation.
  • Interim treatment coverage: percentage of open high-severity findings with a documented compensating control or risk acceptance.

Framework mapping

FrameworkReferenceRelevance to remediation
NIST SP 800-53 Rev 5CA-2 Control Assessments; CA-5 Plan of Action and Milestones; CA-7 Continuous Monitoring; PM-4 Plan of Action and Milestones ProcessAssessment produces findings; CA-5 and PM-4 track them; CA-7 supplies evidence of operation
NIST CSF 2.0GV.OV-03; ID.IM-01; ID.IM-02; ID.IM-03Performance review and improvement from evaluations, tests and operations
ISO/IEC 27001:2022Clause 10.2 Nonconformity and corrective actionReact, evaluate the need to remove causes, implement, review effectiveness, retain documented information
IIA Global Internal Audit StandardsStandards 14.3, 14.4, 15.2Evaluating findings and root cause, action plans, confirming implementation
GAO Green BookPrinciple 17, paragraphs 17.02 to 17.06Reporting, evaluating and correcting deficiencies on a timely basis
PCAOBAS 6115Reporting whether a previously reported material weakness continues to exist

For ISO/IEC 27001 programmes, findings from internal audit feed management review; see the ISMS Internal Audit and Management Review guide.

Common failure patterns

  • Fixing the samples, not the control: the failed items are corrected, the process is unchanged, and the next audit finds new exceptions from the same cause.
  • Closing at deployment: the finding is marked closed the day the change goes live, before any occurrence of the control has run. Validation then fails or the auditor rejects closure.
  • Auditor-written root cause: management adopts the auditor's description of the condition as the cause. OMB A-123 warns that relying only on audit findings may leave corrective actions incomplete.
  • Silent date extensions: dates move in the tracker without escalation, so a long-delayed fix is never recognised as an accepted risk.
  • Narrow scope: the fix covers the sampled application or business unit only, and the same weakness is found elsewhere the following year.
  • Compensating control reported as remediation: an interim detective report becomes permanent, and the underlying control is never repaired.

Practitioner checklist

  • Restate each finding as criteria, condition, scope and severity before agreeing a response.
  • Require a documented root cause that explains every exception in the sample.
  • Search for the same cause in other systems and units before fixing.
  • Assign one named owner with authority, plus milestones that end in a date certain.
  • Set closure dates from the evidence window the control needs, not from the deployment date.
  • Document a compensating control or formal risk acceptance for every open high-severity finding.
  • Agree evidence and population with the auditor before the fix goes live.
  • Have someone independent of the fix validate it, in writing, before closure.
  • Escalate any second date revision as a risk acceptance decision.
  • Report overdue, repeat and retest failure rates to the audit committee or equivalent each quarter.

Standards and references

Related NHI Mgmt Group resources: Audit Exception vs Control Deficiency · Plan of Action and Milestones (POA&M) Guide · Top 10 Identity Audit Findings · Internal Audit for Cybersecurity Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 14 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org