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.
| Stage | Exit criterion | Where the expectation comes from |
|---|---|---|
| 1. Intake and agreement | Finding logged with criteria, condition and severity; management response agreed or disagreement recorded | IIA Standard 14.4 (disagreement methodology); Green Book 17.02 to 17.04 (reporting issues) |
| 2. Root cause analysis | Documented cause that explains the condition, distinguished from symptoms | IIA Standard 14.3; OMB A-123 Section V |
| 3. Ownership and plan | Named owner with authority, resources, critical path milestones and a date certain | OMB A-123 Section V; Green Book 17.05; NIST SP 800-53 CA-5 |
| 4. Interim risk treatment | Compensating control or formal risk acceptance in place while the fix is built | IIA Standard 15.2 (risk beyond tolerance); organisational risk policy |
| 5. Implement the fix | Control redesigned or re-performed; change record linked to the finding | Green Book 17.06 |
| 6. Evidence of operation | Enough occurrences of the control to support testing | PCAOB AS 6115 .33 (period depends on risk) |
| 7. Validation and retest | Independent test passes; validation documented in writing | OMB A-123 (validated by Senior Accountable Official); IIA Standard 15.2 |
| 8. Closure and lessons | Closure record retained; trend and recurrence data updated | NIST 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 category | Typical evidence | Fix that addresses it |
|---|---|---|
| Design gap: the control as written cannot meet the criterion | Control covers the HR system feed but not contractors or service accounts | Redesign scope; add the missing population to the control |
| Population gap: assets or identities outside the control | Applications not onboarded to the review tool; non-human identities with no owner | Reconcile inventory to source systems; onboard and assign owners |
| Operating failure: the control exists but was not performed | Reviewer absent, queue not worked, ticket closed without action | Backup performers, escalation timers, workload rebalancing |
| Evidence gap: control operated but cannot be shown | Approvals in chat or email, screenshots without timestamps | System-generated evidence, retained logs, standard evidence format |
| Automation failure: a job or integration silently stopped | Connector errors, failed provisioning runs not alerted | Job monitoring and alerting; reconciliation report |
| Ownership gap: no accountable person | Control owner left; shared mailbox as owner | Named 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.
| Option | When it fits | What to document |
|---|---|---|
| Compensating control | A 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 acceptance | The fix is costly or long and residual risk sits within appetite | Approver at the right authority level, rationale, expiry and review date |
| Accelerated fix | Severity is high and no adequate compensating control exists | Escalation 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 severity | Typical validation | Who performs it |
|---|---|---|
| Low, design-only or documentation finding | Inspect the updated control description and one occurrence | Second line or GRC team |
| Deficiency in operation | Re-test a fresh sample from the post-fix period | Internal audit or independent tester |
| Significant deficiency | Full re-test of design and operating effectiveness over the evidence window | Internal 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 6115 | Management, 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
| Framework | Reference | Relevance to remediation |
|---|---|---|
| NIST SP 800-53 Rev 5 | CA-2 Control Assessments; CA-5 Plan of Action and Milestones; CA-7 Continuous Monitoring; PM-4 Plan of Action and Milestones Process | Assessment produces findings; CA-5 and PM-4 track them; CA-7 supplies evidence of operation |
| NIST CSF 2.0 | GV.OV-03; ID.IM-01; ID.IM-02; ID.IM-03 | Performance review and improvement from evaluations, tests and operations |
| ISO/IEC 27001:2022 | Clause 10.2 Nonconformity and corrective action | React, evaluate the need to remove causes, implement, review effectiveness, retain documented information |
| IIA Global Internal Audit Standards | Standards 14.3, 14.4, 15.2 | Evaluating findings and root cause, action plans, confirming implementation |
| GAO Green Book | Principle 17, paragraphs 17.02 to 17.06 | Reporting, evaluating and correcting deficiencies on a timely basis |
| PCAOB | AS 6115 | Reporting 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
- The IIA: Global Internal Audit Standards
- GAO: Standards for Internal Control in the Federal Government (Green Book)
- OMB: Circular A-123, Management's Responsibility for Enterprise Risk Management and Internal Control (M-16-17)
- PCAOB: AS 6115, Reporting on Whether a Previously Reported Material Weakness Continues to Exist
- NIST: SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations
- NIST: Cybersecurity Framework 2.0
- ISO: ISO/IEC 27001:2022 Information security management systems
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