Closed is not the same as fixed: validating remediation before the issue closes

An issue log that shows everything closed on time can look like a healthy control environment. It may not be. If issues are closed because management said they were fixed, rather than because someone confirmed the fix works, the organization is tracking activity, not risk reduction. This article looks at how to validate remediation before an issue closes, so that “closed” means the underlying risk has actually been addressed.

The problem with closure by assertion

Here is how it often goes. An audit or control test identifies a gap. Management agrees an action plan and a due date. As the date approaches, the action owner uploads a document, perhaps a policy update or a screenshot, and marks the issue complete. The issue closes.

Nobody has checked whether the control now operates. Nobody has asked whether the document addresses the cause. Six months later, the same gap appears in the next review.

This is closure by assertion. It is common because it is easy, and because the pressure to show progress on issue counts is real. But it hides risk. The issue log says the problem is solved. The environment says otherwise.

Agree what “done” means before the work starts

The single most useful change I have made in issue management is agreeing closure criteria when the issue is raised, not when it is due.

Closure criteria answer a simple question: what evidence will show this issue is resolved? They should be specific enough that the owner, the second line, and internal audit would all reach the same conclusion when looking at the evidence.

For an illustrative example, take an issue where terminated users kept system access past the required removal window. Weak closure criteria would say: “Update the termination procedure.” Strong criteria would say: “Terminated user access is removed within the defined timeframe for all leavers over a full quarter, confirmed by comparing HR termination records to system access logs.”

The first can be satisfied with a document. The second requires the control to work.

Evidence that addresses the root cause

Remediation evidence should address why the issue happened, not just the symptom that was found. If a finding was caused by a manual process with no backup reviewer, removing the specific bad access does not fix it. The same gap will recur the next time that person is on leave.

When I validate remediation, I look for three things in the evidence:

• Root cause: Does the action address the reason the control failed, not only the instance that was found?
• Design: Is the revised control designed to prevent or detect the problem on an ongoing basis?
• Operation: Is there evidence the revised control has actually run, not just been written down?

A new policy, procedure, or system configuration is often necessary. It is rarely sufficient on its own.

Let the control run before you close

Design changes take effect immediately. Operating effectiveness takes time to show. A control that runs quarterly cannot demonstrate that it works the week after it was redesigned.

For issues tied to recurring controls, I prefer to see an operating period before closure, long enough for the control to run at least once, and ideally more than once, under normal conditions. The length depends on the control’s frequency and the issue’s severity. A daily automated control may need a few weeks of evidence. A quarterly review needs at least one full cycle.

This sometimes means due dates move. That is better than closing an issue on time and reopening it as a repeat finding later.

Risk acceptance is a decision, with an expiry

Not every issue should be fixed. Sometimes the cost of remediation outweighs the risk, or a system is due to be retired. In those cases, the right answer is formal risk acceptance, not an indefinitely extended due date.

A credible risk acceptance has an accountable owner with the authority to accept the risk, a clear statement of what is being accepted and why, any compensating controls, and an expiry date. When the acceptance expires, it should be reviewed, not silently renewed. An acceptance with no end date is how temporary exceptions become permanent gaps.

Repeat findings are the signal to watch

A repeat finding is one of the clearest indicators that remediation is not working. It means an issue was closed and the same problem came back, or it was never truly fixed.

Repeat findings deserve their own attention in reporting and in root cause analysis. One repeat may be bad luck. A pattern of repeats in the same area, or from the same owner, points to closure practices that need to change.

Who does what across the three lines

The IIA Three Lines Model is useful here because it separates ownership from oversight and independent assurance. Each role has a distinct part in getting closure right.

Role	Responsibility in remediation	What good looks like	Common failure
First line (management)	Owns the issue, fixes the root cause, provides evidence	Evidence submitted against agreed closure criteria, with an operating period	Self-certifying closure with a document and no proof of operation
Second line (risk and compliance)	Oversees the process, challenges closure, monitors aging and acceptance	Reviews evidence for high-severity items, tracks expiring acceptances	Tracking dates only, without challenging the substance
Internal audit (third line)	Independently validates remediation of audit findings	Retests the control before closing audit issues, and reports on repeats	Accepting management’s closure without testing, or testing too soon

In my experience, the most important shift is for the second line to act as genuine challenge rather than as a scheduler. Tracking whether a date was met is administration. Asking whether the evidence proves the fix is oversight.

Reporting aging and overdue items honestly

How issues are reported shapes how they are managed. A report that shows only the count of open issues rewards closing them, whether or not they are fixed.

Better reporting shows overdue items by severity and age, how many times each due date has been extended, issues approaching their due date with no evidence submitted, risk acceptances nearing expiry, and repeat findings. It also shows issues that were reopened after failed validation. That last measure is uncomfortable, but it is one of the most honest indicators of remediation quality.

Due date extensions deserve particular care. An extension should need an approval at an appropriate level, with a reason. When an issue has been extended several times, the conversation should move from “when will this be done?” to “should we accept this risk instead?”

A checklist for closure that means something

Before an issue moves to closed, I would want to see each of these:

1. Closure criteria were agreed when the issue was raised, and the evidence meets them.
2. The root cause was identified, and the action addresses it, not only the specific instance found.
3. The revised control is designed to prevent or detect the problem on an ongoing basis.
4. The control has operated for a period appropriate to its frequency and the issue’s severity.
5. Evidence comes from the system or process, not only from a statement by the action owner.
6. Someone independent of the owner reviewed it, whether the second line or internal audit, based on severity.
7. Any risk acceptance is formal, owned at the right level, and has an expiry date.
8. Extensions were approved and explained, and repeated extensions were escalated.
9. The area is flagged for follow-up if it has a history of repeat findings.

Fixed is the only outcome that counts

Closing issues is not the goal. Reducing risk is. When closure criteria are agreed up front, evidence proves the control works, and the three lines each play their part, a closed issue can be trusted. That trust is what lets leadership spend its attention on the risks that are still open, instead of rediscovering the ones it thought were gone.

---

This article reflects my professional perspective and is general information, not legal or regulatory advice. Apply it in light of your organization’s obligations and risk appetite.