Your Security Fixes Are Waiting in a Queue. Here Is the Benchmark We Would Set.

The security head opens the monthly report. Forty-one fixes are overdue.

Each has been available from the software’s maker for weeks or months. Each has the same note: deferred, regression risk. The team is afraid that applying the fix will break something else.

They may be right. The last time a fix was applied to the server under the loan system, a report stopped working, and it took three days to find out why.

What We Found

We looked at the public record on known flaws in common business software, what the regulator has said about patching, and what weak basics have cost a lender.

The flaws are used, and the fixes exist. 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. On a supported version, a fix exists for each. A fix protects nobody until it is applied.

The regulator names patching. In April 2024 the RBI barred Kotak Mahindra Bank from taking new customers online and from issuing new credit cards, for about ten months. Patch and change management was among the areas it cited.

When basics are missing, 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.

Fixes wait because nobody can see what they break. On an old system, a fix is a change like any other. With no automated tests, checking it takes people weeks. So fixes queue behind business changes, pile up, and are finally applied in bulk: the least checkable change of all.

What a Shorter Queue Opens Up

An overdue fix looks like the security team’s burden. Our reading is that clearing the queue frees more than that team.

• The argument ends. Security and technology look at the same test result, not at each other.
• Weekends come back. A fix tested automatically does not need operations staff clicking through the system on a Sunday.
• The exceptions stop. Every fix applied in time is one less exception to sign each quarter.

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

Four Ways to Handle the Patch Queue, Weighed

Option	When it fits	What it risks
Accept the exception each quarter	The system is due to retire soon, and the date is set	Without a date, the exception becomes permanent and the exposure stays
Apply the backlog in bulk, once or twice a year	Never by choice; it is where deferral ends	Forty fixes at once are a large, unchecked change. If something breaks, nobody knows which fix did it
Rebuild the system to escape the queue	The system has to be replaced for other reasons	The largest change of all, and fixes for the old system still have to go in while it runs
Add tests and a routine release, then let your own team apply fixes one at a time	The system is still needed and its software is still supported	The foundation takes time to build, and the backlog stands while it is built

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the work starts, and fill in as it goes.

Measure	Typical starting point	Where it should be	How it is checked
How long a security fix waits	Measured in the first review	Applied as it arrives, after the tests pass	The patch record, from published to applied
Key functions covered by automated tests	None; people check by hand after each fix	Every function on the money paths, run on a copy with the fix applied	The test run, against the list of key functions
Release steps done by hand	A long checklist, at a weekend	None, apart from a person’s approval	The release record
Fixes applied per release	Many at once, in bulk	One fix, or a small set, at a time	The release record
Changes rolled back	Undone by hand, if at all	Any fix can be withdrawn by the release itself	Rehearsed on a copy, then recorded
A written record of what the system does	In people’s heads	Written down, and confirmed by your own experts	The specification

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 patch record might look like this.

Fix	Tests on a copy	Released	Status
Application server update	All key functions unchanged	The same week	Applied
Framework library update	One report changed; fixed and re-run	The following week	Applied
Operating system update	All key functions unchanged	The same week	Applied

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 fixes that are waiting and why. 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 establishes what the system does today: a written specification of what it 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 add automated tests and an automated, repeatable release, strengthen the weak points, and hand the system back to your team, who apply the fixes from then on. Where a module has to be replaced, we replace a system one module at a time while the old one keeps running. We never do a single cutover. 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 the work goes on 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. The tests and the release have to be built first, and the backlog stands meanwhile. Clearing it is slow, because it should be done a few fixes at a time.

At the end you hold the specification, the tests, the release process and a patch record your own team keeps.

What changes for the business:

Role	What they gain
CEO	Less chance that a known flaw with a published fix is the cause of an incident.
CTO or CIO	Patching becomes routine work, not a project to be planned and feared.
CISO	The time between a fix being published and applied gets shorter, with fewer exceptions to carry.
COO	Security updates stop costing operations a weekend of downtime and a Sunday of testing by hand.
Risk and compliance	A patch record that shows fixes applied in time, and fewer overdue items to explain.

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

The case	What IOanyT does
The RBI cited patch and change management at Kotak Mahindra Bank among its reasons for restricting the bank (April 2024).	We put tests and a routine release around the system, so the firm’s own team can apply security fixes as they arrive. Answering the regulator is the firm’s own job.
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 part is narrower than this case. We do not supply security controls such as firewalls. We build the foundation that lets a firm’s own team keep its software up to date.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The fixes are yours to apply; we make sure your team can see what each one does.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →