"Partially Implemented" Should Change Every Year. Here Is the Benchmark That Makes It.

The questionnaire has forty questions. It has come from a hospital group that wants to send its laboratory work to you.

Question twelve asks whether a second login check is in place on all systems that hold patient data. The compliance head calls the security head. The answer is yes for most systems, and no for the old laboratory application.

They settle on “partially implemented”, and add a note about compensating controls. It is the same note they wrote last year for the insurer, and the year before for the auditor. The plan it mentions has not moved.

What We Found

We looked at what the public record says about the pressure on healthcare organisations’ security, the cost when a basic control is missing, and the dates now set for India’s data protection rules.

The pressure on Indian healthcare is high. One security vendor’s data puts attacks on Indian healthcare organisations at several thousand a week each over six months, more than twice the figure for the average Indian organisation, and the report links this to the use of outdated systems and growing digitisation.

Ransom attacks are rising. In an article about Indian healthcare, the chief executive of a hospital-software vendor is quoted as saying that ransom attacks on the healthcare sector rose by nearly a third in 2025. The sentence does not say whether that figure is for India or for the sector worldwide.

An attack through a missing control can be very costly. After a 2024 ransomware attack on a large US processor of health insurance claims, where the server the attackers used had no second login check, a trade-press article written by a technology vendor’s executive estimated the total financial impact at billions of dollars. This is a very large organisation, and the record does not say why the check was missing.

India’s data protection rules are moving to enforcement. In an article of 11 May 2026, a business-advisory publication writes that 13 and 14 May 2027 “is widely regarded as the ‘hard enforcement’ date” of India’s data protection rules, known as DPDP, and that penalties can reach 2.5 billion rupees for major violations. It lists health data among sensitive data. We are not lawyers, and this article does not say what those rules require of any organisation. Your legal and compliance advisers will tell you that.

What an Answer That Moves Opens Up

A partial answer is usually treated as a form to get through. Our reading is that an answer that moves each year is worth more than the form.

• The partner’s contract. A hospital group choosing where to send its laboratory work reads “partially, with two of five stages complete” very differently from “partially”.
• The insurer’s and auditor’s trust. A reviewer who asks for evidence of progress can be shown a completed stage, not the same sentence again.
• A position before the date. With 13 and 14 May 2027 “widely regarded as the ‘hard enforcement’ date” of India’s data protection rules, an organisation with stages already done is having a different conversation with its advisers from one that has only a note.
• One project in place of many questions. The login, the shared accounts and the missing record of who viewed what are three symptoms of one thing: an old application nobody has read.

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

Three Ways to Answer for the Old Systems, Weighed

Option	When it fits	What it risks
Keep answering “partially”, with compensating controls	The old application is due to move or be retired on a set date	Without a date the note describes an intention, and the people asking grow less willing to accept it
Replace every old application at once, then answer yes	The applications are few, small and well understood	One large project is too frightening to start, so nothing smaller is tried either. When it is tried, every department changes on one date
Assess first, then harden what can take the control, replace what cannot and retire what was left behind, in stages	The old applications are still used every day and hold patient data	It takes stages, the first adds no control at all, and some stages are rebuilds

Where You Are Now, and Where You Should Be

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

Measure	Typical starting point	Where it should be	How it is checked
Systems on the exception list	The same length, or longer, at each review	Shorter after every accepted stage	The exception list beside the staged plan
Applications with a login for each person	Shared logins on the oldest systems	Rising at each stage, until every application that stays can take one	Signed acceptance for each stage
Applications with a record of who viewed what	None on the oldest systems	Rising at each stage, until every application that holds patient data can keep one	Signed acceptance for each stage
Leftover systems with an end date	Not counted	Each listed, with the date it stops	The staged plan
What the answer on the form rests on	A note: “remediation planned”	Named stages, each with a date the organisation set, some already complete	The staged plan and the acceptance records
What changed and how it was checked	Not recorded	Each change linked to what it replaced, 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 staged plan might look like this.

Gap	Stage that closes it	Status
Laboratory application: one shared login for the department	Stage 1: personal logins for the laboratory application	Closed when the stage was accepted
Laboratory application: no record of who viewed a result	Stage 2: results module rebuilt with a record of use	In progress
Old patient system kept after the migration	Stage 3: last two reports moved, system retired	Planned, with a date

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 systems behind your partial answers, and who asks about 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. 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. The first stage is reading, and it adds no control at all. Some stages will be rebuilds. Staff will have to change how they log in, and some will not welcome it. Until a control is in, the old application is as exposed as it is today, and your own team must go on protecting it. We cannot promise that an attack will not happen, or that a partner, an insurer or an auditor will accept a staged plan. Nothing we produce is a statement that an organisation meets the DPDP Act or any other rule; that judgement belongs to the organisation and its advisers. We do not offer a compliance service.

At the end you hold the specification, the matrix, and a staged plan with every closed line dated. What you write on the next form is your decision.

What changes for the business:

Role	What they gain
CEO	Honest answers for the board, partners and insurers, with progress to show each time they ask.
CTO or CIO	Each control goes in as its own checked and accepted stage, so a security fix is tested before it reaches the people using the application.
CFO	A staged, priced plan in place of an open-ended exception.
CISO	The exception list gets shorter at each review, with a record of what was added and how it was checked.
Risk and compliance	Something on paper at every stage for audits and questionnaires, and commitments the organisation can keep.

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

The case	What IOanyT does
After the attack on a large US processor of health insurance claims, where one server had no second login check, a vendor-written article put the cost at billions of dollars.	Our part is narrower than this case. We do not supply or run security controls. We change or replace old applications, in checked stages, so that an organisation’s own controls can be applied to them.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Next year, the note beside “partially” can list what has been done.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →