An Exception List That Only Grows Is Not a Plan. One That Shrinks Is.

The security scan has finished. The report lists forty-one flaws rated serious.

Twenty-six can be patched this month. The other fifteen sit on four old servers, and beside each the scanner prints three words: no fix available.

The servers run the laboratory and pharmacy applications, and cannot be upgraded without breaking both. So the fifteen go on the exception list as accepted, as they did last quarter. The form has a box for the next review date, and none for the date the risk will end.

What We Found

We looked at what happens to flaws on machines past their end of support, and at health organisations whose systems went down.

A flaw found after the end date stays open. On a supported system, the maker issues a fix and the team applies it. Past the end date, and once any paid updates have run out, no fix comes. Where the operating system cannot be upgraded, what is left is to fence the machine in, or to move what runs on it.

When an estate goes down, much of it goes down together. In 2021 ransomware hit one European national health service. Tens of thousands of its machines ran an operating system out of support since January 2020, and reporting describes older systems with known security weaknesses. Most of its IT estate was affected, and more than half of its acute hospitals cancelled services. It took months to decrypt all of its servers and restore almost all of its applications, and the cost was reported as likely to reach hundreds of millions of euros. This is an older case, from a very large organisation.

Recovery is measured in weeks. The attack on a large public hospital in India in 2022 took dozens of its servers out of use, left its hospital information system unavailable for weeks, and sent staff back to paper records. This is also an older case. The record does not say what those servers ran.

The pressure is not easing. One security vendor’s data puts attacks on Indian healthcare organisations at more than 8,000 a week each over six months, against just over 3,000 for the average Indian organisation, and links this to outdated systems and growing digitisation.

What a Shorter Exception List Opens Up

An exception renewed every quarter is usually seen as the security team’s burden. Our reading is that ending it frees more than the security team.

• Management time comes back. Every renewal takes a review, a justification and a signature. Each application that moves takes those away for good.
• New work stops inheriting old risk. A new portal built beside an unsupported machine inherits its exposure. Once the application has moved, new work no longer inherits that machine’s exposure.
• The board can see progress. “Accepted again” reports a position. An exception list 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 Machine With No Fixes, Weighed

Option	When it fits	What it risks
Contain it and accept the rest, each quarter	The application on it is due to move soon, and the date is set	Without a set date, the measure becomes permanent and the exception never closes
Isolate the machine from everything that can reach it	It serves few desks and needs few connections	Isolation often breaks the work the machine exists to do, such as sending results. It still needs an end date
Move the application on it, most exposed machines first	The machine runs an application the organisation still needs every day	The work takes stages, and containment must hold until each application has moved

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
Machines kept old only because of an application	Not counted	Each listed with the application that keeps it there	The record beside the server list
Exceptions with an end date	None; each has only a next review date	Every one tied to the stage that removes it	The exception list beside the staged plan
The order of work	Whichever department complains loudest	Ranked by what each machine holds, who can reach it and what stops if it stops	The ranking, agreed with your security and operations heads
The length of the exception list	The same, or longer, at each review	Shorter after every accepted module	Reported at every review
Who signs each renewal	Someone new each quarter, on the same form	Nobody, once the application 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 healthcare organisation.

A small part of the finished exception list might look like this.

Exception	Stage that removes it	Status
Server under the laboratory application, operating system out of support	Stage 1: laboratory results module	Closed when the module was accepted and the machine retired
Server under the old pharmacy system	Stage 2: pharmacy stock module	Contained; closes at stage 2
Database server under billing reports	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 old machines, the exceptions renewed 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. Where a module touches clinical work, accepting it is your clinicians’ decision.
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. It does not make an old server safe: until its application has moved, the machine is as exposed as it was, and your own team must go on protecting it. Some applications cannot move first, because too much depends on them. The first assessment will list exposures nobody had counted. We cannot promise that an attack will not happen in the meantime. It is slower than accepting the line again, and it is the first time the line has an end date.

At the end you hold three things: the specification, the matrix, and an exception list with every closed line dated. Retiring each emptied machine is your team’s decision.

What changes for the business:

Role	What they gain
CEO	Less chance that an old server is the reason services are cancelled or the organisation is in the news.
CTO or CIO	The riskiest machines lose their applications first, so the team can switch them off one by one.
CFO	Less exposure to recovery costs that no budget holds, and a clear price for removing each risk.
COO	The applications that registration, laboratory and billing depend on are the first to leave the most fragile machines.
CISO	Findings are closed, not accepted again. Each machine retired takes its open flaws off the register.

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

The case	What IOanyT does
One European national health service was attacked while tens of thousands of its machines ran an unsupported operating system.	Our part is narrower than this case. We do not secure, upgrade or replace machines. We move the applications that keep such machines in use, most exposed first, so the organisation’s own team can retire them.
A large public hospital in India lost its hospital information system for weeks and went back to paper.	The record does not say what its servers ran. Our narrower part: a written record of what each old application does, and a staged plan to move it. Security controls and recovery are the hospital’s own team’s work.

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 an exception comes up for renewal, it comes with the date it closes.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →