The Old System Outside Your Controls Is the Question You Cannot Answer Yes To.

The migration to the new patient system finished two years ago. There was a small celebration, and the project was closed.

This week an engineer finds a server nobody recognises. It is the old patient system. It was kept “for a few months” because one clinic’s old records had not moved, and a monthly report still came from it.

It is still receiving that clinic’s data. It has the passwords it had two years ago. It is on none of the security team’s lists.

What We Found

We looked at what the public record says about old systems that sit outside a health organisation’s controls: those kept after a migration, those that came with older technology, and what reviews and inspectors say about them.

Old servers waiting for a move can be a way in. According to a trade-press article written by a technology vendor’s executive, a large US supplier of health record systems said that an attacker used stolen login details to reach old migration servers that had not yet been moved to its cloud, and copied data out. The article gives no year and no figure for the damage. In that account, the servers reached were ones waiting for a move to finish.

Older technology was named at the top. At a congressional hearing in 2024 on the ransomware attack on a large US processor of health insurance claims earlier that year, its parent company’s chief executive described it as an older company with older technologies, and said the server the attackers used did not have MFA on it, meaning no second login check.

Reviews keep finding old systems kept in use. After the attack on one European national health service in 2021, reporting of the review records that it was still using older systems with known security weaknesses. This is an older case, from a very large organisation.

Inspectors name the same limit. A news summary, in January 2026, of a report by the US health department’s inspector general lists “the sector’s reliance on legacy technology” among the limits on improving cybersecurity. The words are the news site’s summary, not a quotation of the report.

What a System Left Outside the Controls Holds Back

A system kept “for now” is usually seen as a small loose end. Our reading is that it holds back more than it seems.

The honest yes. A partner that wants to send its laboratory work to you, an insurer and an auditor will each ask whether every system that holds patient data has a second login check, personal accounts and a record of who viewed what. One system outside the controls turns that yes into “partially”. Each “partially” is a conversation, a note and a delay.

The cost of two systems. The old system does a fraction of its former work at much of the cost of keeping it: hosting, support, and the staff time of the few who still know it.

The acquisition that never quite joined. A hospital group that buys a clinic chain, or a pharma company that buys a smaller one, inherits systems built to another organisation’s rules. Until they are brought in or retired, the group’s own security rules stop at the old boundary.

Every new control. A control can be applied only to a system that is on the list. The old system misses every improvement made since the day it was meant to go.

This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own organisation.

Four Ways to Deal With a System Outside the Controls, Weighed

Option	When it fits	What it risks
Put compensating controls around it: cut it off from most of the network, limit who can reach it	It will be retired soon, on a set date	It does not give personal logins or a record of who viewed what. Without a date it becomes permanent, and it can break the jobs the system still does
Harden the old application’s code so it can take the controls	The system is still needed for real work, and its code can be read and changed safely	Changing code nobody understands can stop a department. It needs tests around the application first
Replace the parts it still does, module by module	It still does several jobs that people rely on every day	It takes stages, and for a time two systems run side by side
Finish the move and retire it	It does a few leftover jobs that can move to the new system or a small replacement	Somebody, somewhere, still depends on it. Every remaining use has to be found before it can go

Where You Are Now, and Where You Should Be

Before the next questionnaire is answered, we would set a benchmark for the decision.

Measure	Typical starting point	Where it should be	How it is checked
Leftover systems with an end date	Not counted, or found by accident	Each one listed, with what it still does and the date it stops	The staged plan
What each leftover system still does	Remembered by a few people	Every remaining use written down, with an owner for each	The specification
Systems on the exception list	Renewed each year	Each one tied to the stage that removes it, and shrinking	The exception list beside the staged plan
Applications with a login for each person	Shared logins on the systems left behind	Every system that stays able to take a personal login	The specification, then each accepted module
Applications with a record of who viewed what	No record on the systems left behind	Every system that stays and holds patient data able to keep one	The specification, then each accepted module
The cost of keeping two systems	Hidden in hosting and support lines	Set beside the price of finishing the move	The cost comparison

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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the systems you meant to switch off, the ones that came with an acquisition, and the questions you are being asked about them. You leave with a short written note of what we found.
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. 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. We never do a single cutover. A traceability matrix links every old function to where it now lives. 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. 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.

When the matrix has no empty lines, the old system has nothing left to do. Switching it off, and dealing with its data, is your team’s decision. What you need to bring: a search for the systems everyone believes are gone; read-only access to the code once the assessment begins; and the people who still use each system, however few.

What changes for the business:

Role	What they gain
CEO	Systems that came with an acquisition or an unfinished project are brought into view and given an end date.
CTO or CIO	Half-finished migrations are completed. The last functions move, and the old servers can be switched off.
CFO	The organisation stops paying to run two systems, and the unfinished project gets a priced end.
CISO	Fewer systems sit outside the security programme, and each one that remains has an owner and a retirement stage.
Risk and compliance	The list of systems that hold personal data is complete, including the ones everyone had stopped counting.

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

The case	What IOanyT does
A large US claims processor was described at a congressional hearing as an older company with older technologies, and the server the attackers used had no second login check.	Our part is narrower than this case. We do not supply or run security controls. For an organisation’s own applications, we write down what each old system does and move or change it, so the organisation’s own controls can reach it.
One European national health service was still using older systems with known security weaknesses.	Our part is narrower. We do not secure old systems. Our assessment gives the organisation a map and a ranked list of risks for the old systems it holds, and a staged plan to retire or replace them.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. A system you meant to switch off can be switched off on a date you choose.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →