Issue Remediation: Closing a Finding Properly

An issue is the commitment a finding produces: a named owner, an agreed action, a due date, the evidence that the action happened, and a retest confirming the control now works. Closing an issue without a retest records an intention rather than a result. Age and overdue are two different measures, and only one of them is a promise anybody made.

Somebody finds that a control did not work. Finding it ends one job, and the ending feels like a conclusion. It is not. The finding has produced unfinished business, and that business has to be carried by somebody, done by a date, proved with something a stranger could look at, and tested again before anybody is allowed to say it is over. One idea sits under all of it: a finding is a statement about the past, an issue is a promise about the future, and the two need completely different machinery. Get that separation wrong and an institution ends up with a large, tidy, well maintained register of promises that nobody has checked.

There is a second idea sitting underneath, and it is the one that surprises people. Two clocks run on every open item, and only one of them is a promise. The first counts how long the item has existed. The second counts whether the date somebody actually committed to has passed. Institutions report the first and manage on the second. The first is computable from a single date field and needs nobody to agree anything. The two populations barely overlap, and the arithmetic below proves how little.

What is issue remediation, and when does it start?

An issueThe tracked item of unfinished business that a finding produces, carrying a person, a task, a date and a way of proving it was done. is the object a finding turns into once somebody accepts it. RemediationDoing the agreed thing and proving it happened, as distinct from recording that it was agreed. is the doing of it, together with the proving. Both words get used loosely, and the looseness costs real money. The register that lists issues and the work that closes them are handled by different people, and a register in good order is very easily mistaken for work in good order.

The shape is identical in a leaking tap, where there is nothing to learn. The tap drips. Somebody notices the drip, and noticing is the finding. Nobody has said who will fix it or when, so nothing has been remediated and nothing is late. The moment somebody in the house undertakes to fix it by Sunday, three things come into existence at once: a person, a task and a date. Only now can the tap be late. Only now is there anything to chase. Remediation does not begin when a problem is discovered, it begins when a person, a task and a date are written down together, and until that happens there is no clock and there is nothing to be behind on.

The distinction sounds like a technicality until it plays out at scale. Inside Vindhya Commercial Bank Limited, an invented bank of Rs 96,000 crore whose every figure here is illustrative, there is a feed that carries collateral valuations into the loan book. In month 6 that feed went stale for 2 working days and a data quality check caught it. Nobody raised it as an issue. No person, no task, no date, therefore no clock, therefore nothing overdue, therefore nothing on any report anywhere. In month 10 the same feed went stale for 11 working days, 340 loans were wrongly marked, and no monitoring control noticed at all. The record of that year, near miss N3 in month 6 and incident I10 in month 10, is one feed seen twice.

Notice what the empty middle box rules out. The empty box does not mean somebody missed a deadline. There was no deadline. Nor does it mean a remediation programme was slow. There was no remediation, and nothing to remediate: the stale feed existed as a memory and a log entry and never as a commitment. An unraised near miss is the most common way an institution loses an early warning. Raising an issue is clerical work rather than an expensive control, so the fix costs almost nothing in principle.

So the first question to ask of any organisation that says it manages issues well is not how many are open or how quickly they close. The question is what gets turned into an issue in the first place, and what quietly does not. An issue register is a claim about which problems somebody accepted responsibility for, and the things that never entered it are invisible to every measure computed from it. Nothing that follows, including the ageing chart, the overdue count and the queue arithmetic, can see the month 6 near miss at all.

What are the five things a closable issue has to name?

Five, and they are not a checklist somebody invented to make a form longer. Each one exists because a specific thing becomes impossible without it, and the whole list can be worked out from first principles by asking what breaks if the box is blank. The owner, the agreed action, the agreed dateThe date the person carrying the work committed to, which is the only date anybody actually promised anything about., the evidenceA trace somebody outside the work can check later, rather than an assertion that the work was done. and the retestA fresh test of the control after the fix, performed by somebody who did not do the fixing.. An issue missing any one of the five can be marked closed, and cannot be closed, and the difference between those two phrases is the whole subject.

Take them one at a time. Without a named owner there is a task and nobody carrying it. In practice a department carries it, and a department is nobody. Finished is defined by the agreed action and by nothing else, so without an agreed action there is no way to tell whether the work is finished. Without an agreed date nothing can ever be late, and an item that cannot be late cannot be chased, escalated or reported on. Without evidence, closure rests on somebody saying it is done. An earlier version of that same statement turned out to be wrong. The issue exists for that reason. And without a retest there is a completed action rather than a working control. The difference between those two is what closure turns on.

Two of the five deserve a warning label. Both are often filled in with something that looks right and is not. The agreed date is frequently a date somebody in a reporting function typed in to make the record complete, rather than a date the owner committed to out loud in front of other people. A date nobody agreed to has all the appearance of a commitment and none of the force of one, and it is the reason overdue counts sometimes fall apart under questioning. The evidence field is frequently a sentence rather than a trace. Both failures produce a register that passes inspection and cannot support a single conclusion.

There is a household version of this too, and it is worth keeping in mind because it makes the fifth row obvious. Suppose the electrician comes to fix a socket that had been sparking. He says it is fixed and leaves. There is an action and there is his word, and between them they cover four of the five rows: him, the job, the day, and his statement standing in for evidence. The missing row is a socket that works. Switching it on settles that, and switching it on is the retest.

Why does the owner sit in the process rather than in audit?

Because the owner is the person who can change what happens, and that is the only qualification the job has. The people who found the problem cannot change the process, cannot instruct the people in it, and cannot make a new step happen every day. Writing is all they can do. Somebody inside the work has to carry the action, and if the action is carried anywhere else it will either not happen or it will happen as an outsider bolting something onto a process that quietly routes around it within a month.

The second reason is harder and matters more. If the people who confirm a control also fix it, there is nobody left to confirm the fix. Independence is a property of the person, and a person who has taken on an action about a control has acquired an interest in that control being found effective afterwards. Independence is not a suspicion about anybody's honesty. The reason is structural, and it survives everyone involved being careful, conscientious and completely straight. The three lines model of the Institute of Internal Auditors, restated in 2020, exists to keep that reason visible rather than to imply anybody is untrustworthy.

Watch how quietly this happens in practice. Nobody proposes to dismantle independence. The proposal is that the audit team drafts the new procedure, or configures the new report, or runs the new check for a few months until the process can take it. The audit team understands the problem better than anyone and has spare capacity this quarter. Each of those is helpful. Each of them also converts a temporary resourcing gap into a permanent hole in the arrangement. No version of the retest is left that anybody outside the work performed. The test to apply is simple and it is worth saying out loud in the meeting: after this fix, who is left who can say no.

What separates an action aimed at the cause from one aimed at the condition?

One question, and it takes five seconds to put to anybody's agreed action: if this action is performed exactly as written, could the same thing happen again next week for the same reason? An action aimed at the condition puts right what went wrong this time. An action aimed at the cause changes whatever let it go wrong. Both are legitimate work and an institution needs both, and the mistake is not doing one of them. The mistake is closing an issue on a condition action and recording it as though the cause had been dealt with. The register then holds a promise nobody made.

Take the stale collateral feed at this invented bank. Correcting the 340 loans that were wrongly marked is a condition action and it is necessary: the book is currently wrong and somebody has to make it right. Correcting them does nothing whatever about the fact that the feed can stop arriving and nothing is defined to happen. Building a check that fires when the feed has not arrived by a stated time, and naming who it goes to, is a cause action. Do the first and the book is right today. Do the second and the book is right the next time the feed stops. Here is the same shape in three ordinary places, so the pattern sticks:

Now a hard fact from this invented bank's own year, and it is the reason the question is worth asking every time. Independent testing produced 42 findings in the twelve months, and 9 of those 42 findings carry no recorded cause at all. The 9 causeless findings are 21.4 per cent of the 42, so for roughly one finding in five nobody wrote down why the gap existed. The case has several nines, so the number needs care. The 9 in question is the count of causeless findings. The 9 issues sitting in the oldest ageing bucket AG5 below are a different set, and so are the 9 named processes PR1 to PR9. A finding with no recorded cause can still be given an action, a date and an owner. The condition is the only thing anybody wrote down, so the action it gets will almost always be aimed at the condition.

There is a boundary worth stating plainly here. How a cause is looked for, what techniques exist for it and how far back the search is supposed to go is covered separately under operational risk. The practical question is narrower: an agreed action is read for what it would prevent, and if the honest answer is nothing, the issue can still close and the register should not be read as saying the problem has gone.

What counts as evidence that an action actually happened?

Evidence is anything a person outside the process can go and look at a year later and form their own view from. The definition is the whole of it, and every practical rule follows from that one sentence. A dated system record showing the change went live. A report with a run time printed on the face of it. An approval carrying a person's name rather than a role. The result of the retest and who performed it. Each of those is a thing. None of them is a sentence about a thing.

The counterfeit is easy to recognise once the definition is in hand, and it is what most closed issues actually carry. The counterfeit is a memorandum from the process owner stating that the new procedure is now embedded and operating. Read closely, that is a claim, made by the person accountable for the work, that the work is now fine. The memorandum is precisely the claim the issue was opened to test, so accepting it as evidence closes the loop by assuming the answer.

A useful habit, and it takes one sentence: for anything offered as evidence, ask who would have to be believed for this to be true. If the answer is a system, a timestamp, a report that ran whether anybody wanted it to or not, then it is evidence. If the answer is a person, and specifically the person whose work is being examined, then it is an assertion and it may still be perfectly accurate. Accuracy is not the point. Evidence is not evidence because it is true, it is evidence because somebody other than the interested party can check it.

One more distinction, and it catches people out. A screenshot is weaker than the record it is a picture of, and a spreadsheet extract is weaker than the query that produced it. In both cases the interested party chose the moment and the frame. Weakness does not make them worthless. A screenshot is a rung down, and a rung matters exactly where the issue was serious.

Why is closing without a retest only a claim?

Because an action performed and a control effective are statements about two different objects. The action is a thing a person did. The control is a thing that has to keep happening, reliably, on days when nobody is watching, for as long as the process runs. Evidence that the action happened is evidence about the action. Such evidence records that a procedure was written, a system change went live, a new report was scheduled. None of that is a statement about whether the control now does what it was supposed to do, and the only thing that produces such a statement is a fresh test of the control.

Remember why the issue exists in the first place. A control was tested and it failed. The failure was not a failure of intent, and nobody opened the issue because the process team wanted the control to fail. The issue exists because the belief that the control worked turned out not to survive testing. Closing that issue on evidence of an action, without testing again, replaces the failed belief with a new belief of exactly the same kind. The instrument that broke has been reinstalled.

Who performs the retest matters as much as whether it happens, and for the reason already established two sections ago. A retest run by the person who performed the fix is the same instrument as the memorandum, dressed up in the vocabulary of testing. Such a retest has all the appearance of a fresh look and none of the property that makes a fresh look worth anything. The retest belongs with whoever gave the original conclusion, or with somebody equally outside the work.

There is a fair objection, and it is worth answering rather than ignoring. Retesting everything is expensive, and an institution with a long list of open items cannot send an independent tester back to every one of them within days of the fix. The objection is true, and the honest response is not that everything must be retested immediately. The honest response is that until the retest happens the issue is not closed, whatever the register says. An institution that wants a shorter list has to choose between paying for the retests and admitting that its closed count is measuring something else. The cost of retesting is a real constraint and it is an argument about how fast issues can close, never an argument about what closing means.

What is the difference between the age of an issue and whether it is overdue?

Here is the distinction that most changes how any issue report is read. AgeingHow long something has existed, measured from the day it was recorded. It needs nobody to have agreed to anything. measures how long an item has existed, counting from the day it was raised. OverduePast the date the owner committed to. A broken commitment rather than a long wait. measures whether the date somebody committed to has gone by. The first clock starts on its own and nobody ever agreed to it; the second starts only when a person makes a promise, and it is the only clock on which anybody has broken anything.

Everyone already understands this outside work and forgets it inside. A parcel ordered six weeks ago with a delivery date next Tuesday is old and not late. A parcel ordered on Monday for delivery on Tuesday, arriving on Thursday, is new and late. Nobody looking at those two parcels would rank them by how long ago they were ordered. Yet ranking by how long ago it was raised is exactly what an issue ageing report does, and the ageing report is the one that reaches most committees. Age can be computed from one date field with no human agreement anywhere in it.

The two clocks disagree on two issues invented here. The first was raised 19 days ago with an agreed date of 14 days ago. At 19 days old the first issue sits in the youngest ageing bucket, and it is two weeks past a commitment somebody made. The fix on the second needs a system change and the owner said so at the time, so it was raised 300 days ago with a twelve month agreed date. At 300 days old the second issue sits deep among the elderly, and it is entirely on track with 65 days still to run.

Neither clock is wrong. Age is a real quantity and it is worth knowing: an item that has existed for a long time has usually been re-agreed at least once, and a long queue of old items says something about capacity. The problem is not accuracy. The problem is that only one of the two measures has a person attached to it. An overdue item can be escalated: a named person made a commitment and the commitment has been broken. There is nobody to escalate an old item to, and nobody ever undertook that it would be young.

There is a second consequence that shows up whenever somebody tries to fix the ageing profile directly. If old items look bad, the cheapest response is to re-agree the dates. Re-agreeing makes nothing late and leaves everything exactly as old as it was. The reverse manoeuvre also exists: closing and immediately reopening an item resets its age to zero while changing nothing about the control. Both moves are visible to anybody watching the right measure and invisible to anybody watching the other one. A report should carry both measures for that reason.

What do this bank's 92 open issues look like on both clocks?

Vindhya Commercial Bank Limited, invented throughout, carries 92 open issues at month 12, its reporting date. The bank ages them from the date each was raised, in five buckets of its own choosing, numbered AG1 to AG5. Every count below is that one bank's own working number rather than a norm anybody should expect elsewhere.

Two things about that table before the picture. The counts tie exactly: 28 plus 22 plus 18 plus 15 plus 9 is 92. So do the shares, and the tie is worth a sentence because it is not always true. Rounded to one decimal place these five shares add to 100.0 exactly, and that is a property of these five particular numbers rather than a rule; five other counts rounded to one decimal can easily land the column on 99.9 or 100.1, and a table that presents such a column has to say so rather than quietly adjusting a share to force it.

Now add the buckets above 90 days. AG3, AG4 and AG5 together hold 18 plus 15 plus 9, making 42 issues, being 45.7 per cent of the 92. Four different objects in this invented case wear the number 42, so the number needs care. All four are named now. There are 42 control findings from the year's independent testing. There is Rs 42.0 crore of gross loss on incident I2, the settlement instruction that went out twice. There are 42 of the bank's 147 risk data elements that carry all eight of the attributes T1 to T8. And there are these 42 open issues older than 90 days. Four objects, one number, and only one of them is the subject of this section.

Now switch clocks entirely. The same 92 issues have a second reading, and the second reading is different. Thirty one of the 92 are past their agreed remediation due date, being 33.7 per cent, and that leaves 61 on track at 66.3 per cent. The oldest of the overdue ones is 412 days past the date its owner committed to. Nothing in the ageing table above carries any of that, and nothing in the overdue count says how old anything is.

How much do the old population and the late population actually overlap?

The overlap cannot be known in this case, and not knowing it turns out not to matter, the nicest kind of result. The invented record does not say how the 31 overdue issues are distributed across the five ageing buckets. Nobody measured the overlap. A bound is available instead, and a bound needs no measurement at all: it follows from two counts that are both already on the table.

Here is the whole argument in three steps. Every issue more than a year old sits in bucket AG5. AG5 is defined that way. AG5 holds 9 issues in total. Therefore at most 9 of the 31 overdue issues can be more than a year old. At least 22 of them are a year old or less. At least 22 of the 31 broken commitments in this invented bank, being 71.0 per cent of them, sit on issues that are no more than a year old, and most of those will be sitting in the two bars that read as healthy. The floor holds whatever the true overlap turns out to be, and no further evidence could weaken it.

Take a moment on what kind of statement that is. The statement is stronger than it looks. The bound is not an estimate, so there is no assumption anybody can argue away. Nor is it a modelled figure, so there is nothing to validate. The bound is a floor produced by two counts and the definition of a bucket, and the only way to move it is to change one of the counts. Unlike an estimate, a floor survives every objection anybody in the room can raise. A floor is therefore the most useful number anybody can put in front of a committee.

And note which nine that is. The invented case has several. The 9 in the argument above is the count of issues in ageing bucket AG5. The AG5 count is not the 9 of the year's 42 control findings that carry no recorded cause, not the 9 named processes PR1 to PR9, and not the 9 hours the vendor payment gateway was down in incident I9. Naming the set every time is not pedantry here; it is the only way a case with this many small counts stays checkable.

What does the oldest issue at 412 days past due actually settle?

One thing, and it is settled by arithmetic rather than by investigation. The settlement is a useful little demonstration of how far careful work can get from a single number. The oldest overdue item in this invented bank is 412 days past the date its owner committed to. The case runs over twelve numbered months, month 12 is the reporting date, and a year is counted here as 365 days.

Now do the subtraction. 412 is 47 more than 365. The agreed date on that issue therefore fell 47 days before month 1 of this twelve month record began, so the commitment was already broken before the period anybody is reporting on had started. The moment is outside the twelve months, so no amount of reading them will find it.

A second thing follows, and it needs one extra step that is worth spelling out because it is easy to skip. An agreed date cannot fall before the day the issue was raised: nobody commits to a remediation date for something that has not been raised yet. So the age of an issue is always at least as large as the number of days it is past due. The oldest issue is 412 days past due, so it is at least 412 days old. Being more than 365 days old puts it certainly in bucket AG5. The record settles genuinely nothing else. The record does not name the subject of the issue, the process it sits in, the person who carries it, or how many times its date has been re-agreed.

Pause on how modest that conclusion is. Modesty is the point. A single number, correctly handled, gave two facts and refused to give any others. The temptation with an item like this is to build a story around it, and the story writes itself: somebody stopped chasing, the owner moved on, the fix needed a system nobody funded. Every one of those is plausible and none of them is in the record. An honest reading stops where the record stops, and the discipline of stopping there is what makes the two facts it did produce worth anything.

How fast does a backlog of 92 issues actually clear?

Much more slowly than anybody expects, and the reason is arithmetic that everybody knows and almost nobody applies to their own list. A backlogThe stock of things still open. It moves only when the rate of finishing exceeds the rate at which new ones arrive. does not shrink at the rate at which things are closed. A backlog shrinks at the closing rate minus the rate at which new ones arrive. The two sentences sound almost identical and they produce completely different answers.

A sink full of washing up, where somebody keeps adding plates, has the same shape. Four plates a minute are being washed, and the washing feels productive. Four plates a minute are also arriving. The evening passes and the pile ends exactly the size it was at the start. The arrangement is the problem rather than the effort, so no amount of working harder inside it changes anything.

Putting numbers on the bank needs an arrival rate, and the invented record does not supply one, so one is assumed here. Independent testing produced 42 findings over the twelve months. If one finding becomes one issue, that is 3.5 new issues a month. The invented record never says that the year's 42 findings became 42 of the 92 open issues; the 3.5 is a working assumption, and every reading below depends on it. With that stated, the whole relationship is one line: the number open after t months is 92 plus 3.5 less the monthly closure rate, all multiplied by t.

Work the crossings. At 3.5 closures a month the population never moves at all: twelve months of effort, and 92 issues still open. At 7 a month, double the arrival rate, the net drain is 3.5 and it takes 92 over 3.5, being 26.3 months, to clear. At 10 a month the net drain is 6.5 and it takes 14.2 months. At 15 a month the net drain is 11.5 and 11.5 times 8 is 92, so it clears in exactly 8.0 months. And to be rid of it inside twelve months the rate has to be at least 3.5 plus 92 over 12, being about 11.2 a month. Over a full year that is 134 closures, being the 92 already open plus the 42 that arrive, and 134 is more than three times the 42 findings the year's independent testing actually produced.

The reason this matters more than it looks is that the closing rate is a capacity, and capacity has to be paid for. Every closure needs an owner to do the work, evidence to be assembled and an independent retest to be scheduled and performed. Trebling the rate means trebling all three, and the third one lands on the same testing function that produced the findings in the first place. A backlog that looks like a scheduling problem is almost always a capacity problem wearing a scheduling problem's clothes, and the queue arithmetic is the fastest way to tell which one is in hand.

Where do the Indian duties around a control weakness sit?

Remediation is almost entirely jurisdiction free. Nothing about naming an owner, agreeing a date or retesting a control is Indian, and an institution anywhere would recognise the five rows and the two clocks. The jurisdiction enters at reporting: what an institution has to report, to whom, and with what independent opinion attached, once a control weakness has been found and not yet remediated. The duty comes from statute and from professional standards, and the bodies that hold the text are named below.

A rule number, a threshold, an applicability test or a date is exactly the kind of thing that changes, and anything carrying one goes quietly wrong without anybody noticing. Naming the body and the duty stays true, and knowing where to look survives the next amendment.

What can closing an issue never do?

Two things, and both of them are limits rather than defects. Both limits are simply how the instrument works, and knowing them stops anybody asking closure for something it was never able to give. Closing an issue changes what a control does from tomorrow, and it changes nothing whatever about what the control did yesterday. The loss stays booked. The wrong marks stay in the record of having been wrong. The customers who were affected were affected.

Look at what actually happened at this invented bank. The control over collateral valuation in process PR3 did not operate for 11 working days, and no monitoring control detected it. 340 loans were wrongly marked, no customer lost money, and Rs 1.4 crore of net loss was booked as incident I10. The collateral valuation control sits on a book of Rs 8,640 crore of secured advances. The book is 15.0 per cent of net advances of Rs 57,600 crore and 9.0 per cent of total assets of Rs 96,000 crore, and the base has to be named because both of those figures land on a suspiciously round number. Now suppose the issue arising from it is remediated perfectly: an owner, a defined action, a date met, an evidence pack a stranger could audit, and an independent retest that passes. Every one of those 11 days is still in the record.

The second limit is quieter and it is the one that catches careful people. A closed issue is a statement about a control at the moment it was retested, and it says nothing about the control next month. The same limit sits inside every conclusion about controls: the test looked at named days and it looked at them in the past. None of that is an argument for retesting forever. The argument is for reading a closed issue as a control that passed a fresh test once, rather than as a problem permanently removed from the institution.

One connection is worth making, and it shows why the size of the book under a control matters even when nothing on it went wrong. The bank's largest single-name exposure is to Nirjhar Industries Limited, also invented, secured by a charge over inventory and receivables. Inventory and receivables are precisely the kind of balance a valuation control has to keep current. The invented record does not say whether that name was among the 340 loans wrongly marked. The record does settle the size of the book the control sits on, and that size is a statement about how much depends on the control rather than about how much went wrong.

How does somebody outside a risk function ever use this?

Most readers will never own an issue in a control register. Sentences of the form it has been dealt with arrive instead, several times a month, from landlords, suppliers, schools, contractors, employers and institutions of every size. The same five rows and two clocks turn any such sentence into a short set of questions.

Practise on something small. The building manager says the lift fault has been dealt with. Who specifically dealt with it, what exactly did they do, by when did they say it would be done, what is there to look at, and has anybody used the lift since. The last question is the retest, and it is the only one of the five that produces a statement about the lift rather than about the work. The fifth question, asked first, settles in one sentence whether the other four are worth asking.

Now scale it. Somebody reading an institution from outside, whether they are lending to it, analysing it, sitting on a small board or deciding where to put a deposit, will meet a statement that control weaknesses identified during the year have been remediated. Four questions turn that into something that can be weighed. How many were identified and how many are still open. How many of the open ones are past a date somebody agreed, rather than merely old. Which evidence closure rested on, and who performed the retest. And what the closing rate is against the rate at which new ones arrive, given that a stable count with heavy activity is a queue standing still.

A member of an audit committee has a sharper version of the same move available, and it costs one sentence in a meeting. Ask for the overdue count and the retest column beside the ageing chart, permanently, in the same pack. The chart will keep arriving because it is automatic and free. The two columns that carry a person and a promise are the ones somebody has to build on purpose, and an institution that has never been asked for them will not have them. At this invented bank the two numbers would read 31 past an agreed date out of 92 open, and at least 22 of those 31 no more than a year old, and neither figure appears anywhere on the chart the committee currently gets.

There is one habit worth taking away above everything else here. When somebody says a problem is closed, the question is what was tested afterwards and by whom. If the answer describes work rather than a test, or names the same person who did the work, what has been reported is an intention. The intention may be a completely sincere one. An intention is still not a result, and that difference is the one thing here worth remembering.