"Accepted Again" Is Not a Plan. A Shrinking Register Is.

One line on the risk register is three years old.

It records a flaw in the software under the agent portal. The status reads: no fix available, maker’s support ended. The security team has put controls around it. Every quarter the remaining risk goes to the committee, and every quarter it is accepted again.

The form has a box for the next review date. It has no box for the date the risk will end, and nobody could fill one in.

What We Found

We looked at what happens to security flaws in software past its end of support, and at what the public record says about the cost of gaps that stay open.

A flaw found after the end date stays open for good. On a supported version, the maker issues a fix and the team applies it. Past the end date, no fix comes. The only remaining options are to fence the component in, or to move what runs on it.

These flaws are used, not theoretical. As of 11 October 2026, the US government’s list of flaws known to be exploited held 9 entries for Apache Struts, a framework many business applications were built on, and 13 for WebLogic Server, an application server. Each entry is a flaw attackers have used. On a version past its end date, the next one will not be fixed.

Controls reduce the risk and never remove it. A firewall rule, a separate network segment, closer monitoring: each makes the gap smaller. None closes it. So the same line comes back to the committee every quarter, and each renewal makes the temporary measure more permanent.

When a gap is used, the cost lands twice. In June 2023 the RBI imposed a penalty of 65 lakh rupees on Andhra Pradesh Mahesh Co-operative Urban Bank, a mid-size Indian bank, finding that “the bank had failed to put in place certain mandated controls which led to the cyber security incident.” A bank in that position pays once in the incident and again in the penalty.

What a Shorter Register Opens Up

A risk that is accepted every quarter is usually seen as the security team’s burden. Our reading is that it costs the business more widely, and that ending it frees more than the security team.

• Management time comes back. Every renewal takes a committee’s time, a security review and a signature. Each module that moves takes those away for good.
• New work stops inheriting old risk. A new product or connection built beside an unsupported component inherits its exposure. Once the component has moved, the new work starts clean.
• The board can see progress. “Accepted again” reports a position. A register that is shorter at every review reports a direction.

This is our reading. It is not a measured market figure.

Three Ways to Handle a Flaw With No Fix, Weighed

Option	When it fits	What it risks
Contain it and accept the rest, each quarter	The component is due to move soon, and the date is set	Without a set date, the measure becomes permanent and the line never closes
Isolate the component from everything that can reach it	It serves few users and needs few connections	Isolation often breaks the work the component exists to do. It still needs a date to end
Move the module that runs on it, most exposed first	The component sits under a system the business still needs	The work takes stages, and the containment must hold until each module moves

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Accepted risks with an end date	None; each has only a next review date	Every one tied to the stage that removes it	The risk register beside the staged plan
The order of work	Whichever system complains loudest	Ranked by what each component holds and who can reach it	The ranking, agreed by the risk committee
Exposed components reachable from outside	Not counted	Listed, and in the first stages	The risk register
The length of the register	The same, or longer, at each review	Shorter after every accepted module	Reported at every review
Who signs each renewal	A different person each quarter, on the same form	Nobody, once the module has moved	Signed acceptance for each module
What moved and how it was checked	Not recorded	Each module linked to its replacement, with how it was checked	The traceability matrix

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a lender.

A small part of the finished register might look like this.

Accepted risk	Stage that removes it	Status
Flaw in the framework under the agent portal, no fix available	Stage 1: agent portal module	Closed when the module was accepted
Old application server under the collections screens	Stage 2: collections module	Contained; closes at stage 2
Old operating system on the reporting server	Stage 3: reporting module	Contained; closes at stage 3

The rows above are an illustration, not taken from a real system.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the system, the risks being accepted each quarter, and who signs for them. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a written specification of what the system does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology that is still supported. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This has a price. Containment has to hold for longer than anyone would like while the stages run. Some components cannot move first, because too much depends on them. And the first assessment will list exposures nobody had counted. That is slower than accepting the line again. It is also the first time the line has an end date.

At the end you hold three things: the specification, the matrix, and a register with every closed line dated.

What changes for the business:

Role	What they gain
CEO	Less chance that old software is the reason the firm is in the news or in front of the regulator.
CTO or CIO	The most exposed parts move first, onto technology where fixes still arrive. Tickets that could never be closed begin to close.
CFO	Less exposure to losses and penalties that no budget holds, and a clear price for removing each risk.
CISO	Findings are closed, not accepted again. Each module that moves takes its open gaps off the register.
Risk and compliance	Every accepted risk carries an end date, and there are fewer of them at each review.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
The RBI penalised Andhra Pradesh Mahesh Co-operative Urban Bank (June 2023) for failing to put in place mandated controls which led to a cyber security incident.	Our narrower part: we move the modules that sit on software nobody fixes, in the order that removes the most exposure first. Security controls such as firewalls are the firm’s own security team’s work, not ours.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next time the line comes to committee, it comes with the date it closes.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →