The Issues Log Is Where Findings Go to Age

Category: Operating Models Tags: issues management, audit findings, remediation, root cause, corrective action, aging, closure evidence

The most damaging question I have watched an examiner ask took about four seconds. They did not ask to test a control or walk a process. They asked for the issues log, sorted it by age, and said, out loud, that the oldest open item was older than the program that found it. Nobody in the room had a response, because the number was correct. There were a few hundred open findings, the median age ran past a year, several had been extended four times, and every extension had been approved by the person who requested it. We had spent that year producing assessments, and the log was the receipt showing what happened to their output: it aged.

That is the quiet failure mode of issues management. Programs invest enormous effort in finding things, through audits, control tests, risk assessments, incident reviews, and regulatory exams, and comparatively no effort in the machinery that turns a finding into a fixed thing. Detection gets the budget and the headcount. Remediation gets a spreadsheet column called Status, and Status is a word people type.

An Issue Is a Control Failure, Not a To-Do

The first problem is definitional, and it looks pedantic until you see what it costs. Most issues logs are a mixed bin. They hold genuine control failures next to improvement ideas, someone's preferred tooling upgrade, an observation the auditor did not think rose to a finding, and three items that are actually the same problem written by different people. Once a log contains everything, its aging tells you nothing, its severity ratings are incomparable, and nobody can be held to it, because half the population was never a commitment in the first place.

The tighter definition is worth defending. An issue is evidence that a control did not work as designed, or that a control the risk requires does not exist. That is it. Improvement ideas are a backlog, and backlogs are fine, they just belong somewhere else with no severity rating and no due date pretending to be an obligation. This connects directly to the argument I made in a control that isn't tested is a hope: testing is what generates honest issues, and if your testing produces no findings, that is not a healthy program, it is an untested one. A log with too few issues and a log with too many undifferentiated ones fail the same way. Neither can tell you where the control environment is actually weak.

The Date Nobody Negotiated

Then there is the due date, which in most programs is fiction from the moment it is written. It gets set at the end of fieldwork, by the assessor, usually as a round number of days keyed to severity: high is thirty days, medium is ninety, low is a hundred and eighty. Nobody asks the person who has to deliver whether thirty days is achievable given what else is committed. Nobody checks whether the fix needs a vendor release, a change freeze to end, or a budget cycle that does not open for two quarters. The date is an output of the severity rating rather than a plan, so it is wrong on the day it is set, and everyone involved knows it.

What follows is predictable. The date arrives, the work is not done, and an extension is requested and granted, usually by the same function that owns the remediation. Do that three times and the original date has no meaning, but the more corrosive effect is cultural: the organization learns that dates on the issues log are aspirational, which makes the next date less real than the last. The fix is not stricter dates, it is honest ones. Let the owner propose the date with the constraint stated, hold the first date as the commitment, and put extension authority one level above the person asking. An extension approved by the requester is not governance, it is paperwork. When the extension has to be defended to someone who did not want it, the dates get realistic quickly, which is the actual goal.

Write the Closure Standard When You Open It

The other end of the lifecycle is worse, because closure is where an issues program either means something or does not. In most logs, closed means the owner said it was closed. There is a comment, sometimes a link to a ticket, occasionally a screenshot, and the item leaves the population. Nobody re-tested the control. The evidence that would prove the fix works was never specified, so whatever the owner produced becomes the evidence by default, judged by the person with the strongest interest in the item going away.

The correction is small and almost nobody does it: write the closure standard at open time, not at close time. When the issue is raised, while the assessor still has the failure fresh, record what specifically will have to be true for this to be closed and what artifact will demonstrate it. A re-performance of the failed test. A configuration export showing the setting enforced. A sample of thirty transactions with no exceptions. Deciding that up front costs ten minutes and removes the negotiation entirely, because closure stops being an opinion and becomes a comparison against a standard written before anyone was under time pressure. It also kills the most common form of false closure, where the remediation addressed the specific instance the auditor sampled and nothing else.

Aging Is the Number That Cannot Be Spun

Most issues reporting leads with counts, and counts are the easiest metric in the program to game. Open items went from 300 to 240 this quarter, which sounds like progress and may simply mean sixty low-severity items were closed because they were easy, while the hard ones sat. Counts reward volume, and volume is available on demand.

Aging resists that. The distribution of how long issues have been open, segmented by severity, tells you whether the organization actually fixes things or merely processes them, and the single most useful number on the whole report is the age of the oldest open high-severity item. It cannot be improved by closing easy work. The second most useful is the repeat rate, meaning findings raised again in an area that had already closed a finding for the same cause, which is the clearest evidence available that closure standards are too weak or root cause was never reached. I argued in risk appetite, thresholds, and KRIs that a threshold matters only if breaching it triggers a decision, and issues aging is a natural place to apply that: a defined age at which an item stops being an owner's problem and becomes an executive's, automatically, without anyone having to volunteer bad news.

Five Issues, One Cause

The last failure is treating each issue as its own project. A log accumulates items that look unrelated because they were found in different audits by different teams, and each gets its own owner and its own remediation plan. Then you sort by cause instead of by source and discover that eleven of them are the same thing: an access review process that nobody runs on time, a change process with an emergency path that has become the normal path, an onboarding step that was automated for one platform and not the other four. Fixed individually, each gets a local patch and the cause survives to generate the next finding. This is why repeat findings are the metric examiners care about most.

Root cause is also where issues stop being an administrative function and connect back to risk. An open issue on a control means that control is weaker than the register claims, which means residual risk on every risk that control supports is understated until the issue closes. That relationship is the reason issues belong in the same model as risks and controls rather than in their own tracker, exactly as I laid out in the connected GRC model. Kept separate, an issues log is a list of chores. Connected, it is the mechanism that keeps your risk ratings honest between assessments, because a finding automatically degrades the thing it was found in.

The program in that exam room did eventually fix its log, and the work was less about discipline than about design. Definitions narrowed so the population meant something. Owners set their own dates and defended their own extensions upward. Closure criteria got written at open time, and a sample of closed items was re-tested each quarter, which found enough false closures in the first pass to justify the practice permanently. Reporting led with aging and repeat rate rather than counts. None of that made the organization faster at remediation in the first quarter. What it did was make the log true, and a true log is the thing you can actually manage. The examiner's question never got easier to hear, but it stopped being unanswerable.