Applied, and Checked by Your Own Team. Four Ways to Deal With Security Fixes That Keep Waiting, Weighed.

The fix for the activation tool was approved at last. On Tuesday it went onto the test copy. That took an hour.

Then the checking began. Six people were borrowed from activation and customer service. They had a spreadsheet of two hundred and forty steps, written years ago, and four days to click through it, because nobody could say which of those steps the fix might affect.

On Friday afternoon one of them noticed that a confirmation message had a blank where a name should be. Nobody could say whether the fix had touched that screen, or whether the test copy had always done that. The fix went back in the queue.

What We Found

For this article we went through the public record on security fixes that wait: the rules operators in India now work under on security incidents, the US government’s list of flaws known to be used in attacks, and one survey of IT professionals.

Three findings stand out. The rules are set out in the next section.

A fix protects nobody until it is applied, and old flaws stay on the list. The US government keeps a list of flaws known to be used in attacks. On 8 October 2026 it held 1,739 entries. Three entries are flaws in the web language PHP itself, and flaws in it dating from 2012 and 2019 were added to the list in March 2022. These figures are not about telecom, and the counts change.

The worry is widely shared. In one survey of about 500 IT professionals in the US, across industries and company sizes, run by a firm that sells software services and not about telecom, more than four in ten named security weaknesses among the top challenges of their old systems.

Nobody in the public record says how a fix is checked on an operator’s own applications. We found no public account, from any operator, of how it decides what to check after a fix.

Our reading is that, on an old application, the fix is rarely the hard part. Knowing what it touched is. With no written record of which screens, jobs and reports use the part being fixed, a team must check everything by hand or check nothing and hope. Either way each fix is expensive, so fixes are saved up, and saved-up fixes are harder still to check.

What the Rules Say About Reporting Within Hours

In India, the Telecommunications (Telecom Cyber Security) Rules, 2024 (G.S.R. 720(E), 21 November 2024) came into force on publication; an amendment of 22 October 2025 left the rules on the security officer and on reporting unchanged. Under rule 4(4)(a) a telecommunication entity is to “adopt a telecom cyber security policy”, and rule 6(1) reads “Every telecommunication entity shall appoint a Chief Telecommunication Security Officer”. Rule 7 provides that it report a security incident to the Central Government “within six hours of becoming aware of a security incident affecting its telecommunication network or telecommunication service”, and “within twenty-four hours of becoming aware of such incident” furnish, as applicable, “the number of users affected by the security incident”, “the duration of the security incident”, “the geographical area affected by the security incident” and “the remedial measures taken or proposed to be taken”.

Who the rules cover: they define a telecommunication entity as “any person providing telecommunication services, or establishing, operating, maintaining, or expanding telecommunication network”, including authorised entities and persons exempted from authorisation. They set no size threshold. Whether they cover your firm is a question for your own advisers.

These rules speak of incidents affecting a telecommunication network or service. They do not name an old application, and whether an incident in a billing, customer or portal application falls under them is for your advisers to say. Our reading is narrower: an operator whose own applications carry fixes nobody can apply, on software nobody has mapped, will find the questions in that list harder to answer. Which users does the portal reach? What does it stand on? What was the remedial measure, when the fix underneath has waited for years because nobody knew what it would break?

This is our reading of the evidence. It is not a measured market figure, and it is not legal advice.

Four Ways to Deal With Security Fixes That Keep Waiting, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Defer the fixes again	The fix is minor, or the application is about to be switched off	Fixes are saved up for one large release, and each application stays exactly as exposed
Apply the fixes and hope	A small application your team knows well, with a simple way back	Something customers use stops working, nobody knows which fix did it, and the next fix waits longer
Record what each fix would touch and break, then let your own team apply and check it	Many fixes carry “may affect service”, and checking one means clicking through everything	It costs money before any fix is applied; nothing is safer until your team applies the fixes; reading code may miss something
Rebuild the application that cannot take fixes	Part of the estate stands on software with no supported version left	It costs the most and takes months; the old application is exactly as exposed until the last module has moved

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Overdue fixes marked with a reason	”Deferred: may affect service”	Each fix on your security team’s list marked by that team: can go in now, blocked by something named, or cannot be applied, with the reason	The risk register
What each fix would touch	Not known, so everything is checked by hand	The screens, jobs and reports that use the part being fixed, named before your team applies it	The specification
What was checked after each fix	A ticket that says “applied” and one that says “closed”	Your team’s own note of what it checked against the named list	Your team’s change records
Applications on software that gets no more fixes	Mixed in with everything else	Counted, each with a plan, and falling as rebuilt modules are accepted	The risk register, reviewed at each stage

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, 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 telecom operator.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the fixes your team cannot check without a week of clicking. 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. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications your firm built or had built, and the assessment records what each one stands on (framework, libraries, database, versions and support dates) and what a fix underneath would touch or break, naming the screens, jobs and reports your team would check, for each overdue fix on your security team’s list, so that team can mark it. It produces a map of the system as it stands, 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. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means only an application whose underlying software gets no more fixes, rebuilt module by module beside the old one. We never do a single cutover. Each module has a traceability matrix. 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. After each module 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 approach has a price. The assessment costs money, and by itself it applies nothing: every application is exactly as exposed as before until your own team works through the list. Applying and checking each fix is your team’s work; the record tells it where to look, and reading code may not find everything a fix touches. We do not scan or monitor your systems, run your releases, or work on network devices or the systems that run the network. We do not upgrade software in place, and we do not work inside a packaged billing product. We promise no protection from attack. We give no legal advice and do not say what any rule requires of your firm or that any work makes it compliant. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a telecom operator.

What changes for the business:

Role	What they gain
CEO	Applying a known fix stops being something the firm puts off because nobody can say what it would do.
CTO or CIO	Your team applies each fix knowing which screens, jobs and reports to check, from a written record and not from a checklist written years ago.
CFO	Checking a fix is aimed at the parts it touches, so the work can be planned as routine and not as a project each time.
CISO	Fixes can go in one at a time as they become ready, each with a named list of what to check, and fewer exceptions are carried.
Head of regulatory affairs	A record for each fix: what it was expected to touch, when your team applied it, and what they checked.

None of these means an application cannot be attacked.

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

The case	What IOanyT does
India’s Telecommunications (Telecom Cyber Security) Rules, 2024, of 21 November 2024, provide for a report “within six hours of becoming aware of a security incident affecting its telecommunication network or telecommunication service”, and within twenty-four hours the users affected, the duration, the area and the remedial measures “taken or proposed to be taken”.	We give no legal or regulatory advice and do not say what the rules ask of your firm. For applications an operator built, the assessment’s map records what each one stands on and what a fix would touch; your advisers decide what the rules ask.
The US government’s list of flaws known to be used in attacks held 1,739 entries on 8 October 2026.	We do not scan for flaws or apply fixes. For applications an operator built, we record what each fix would touch, so the operator’s own team can apply and check it.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what each fix would touch, so that your own team can apply it on an ordinary Tuesday and know where to look.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →