On 12 August 2026 the e-Health Centre confirmed that the cybersecurity incident involving MyDr remains under the monitoring of the state services, while stating at the same time that there has been no breach of the security of the central e-health services. That distinction is central and must be maintained throughout all further communication. The security of the central layer and the security of data processed on the software supplier’s side are two different things. Conflating them leads either to false reassurance or to panic — and both reactions make it harder for facilities to do what they actually need to do today.

What we know, and what we do not

The Coalition does not repeat figures without attribution and does not treat the attackers’ declarations as findings. Until the authorities complete their work, the proper basis for a facility’s action is the possiblerather than the confirmed scope of the breach — and that is sufficient to trigger the obligations set out below.

Mechanism: the risk has migrated into the supply chain

The event did not take place in a hospital or a clinic. It took place at a supplier of a medical records system — that is, at a point where a single technical vulnerability translates into the exposure of data from many thousands of independent entities at once. The difference is qualitative, not quantitative: in an attack on a single hospital the risk is bounded by that hospital’s patient population; in an event at a supplier of the application layer, the multiplier is that supplier’s entire deployment base.

The vector described publicly combines an application vulnerability with the exposure of credentials to API interfaces. We do not comment on technical detail at a level that would allow the attack to be reproduced. At the level of risk class, however, the conclusion is unambiguous and applies to every supplier of medical software, not to this one alone: secrets hygiene, API key rotation and environment separation are today a control of clinical rank, not an internal matter for the supplier’s IT department.

The President of the Personal Data Protection Office stated this expressly in a communication to controllers using MyDr: it is on them, and not on the processor, that the obligation rests to analyse the risk, to notify the supervisory authority within 72 hours of becoming aware, and — where there is high risk to rights and freedoms — to notify the data subjects. The basis is Articles 33 and 34 of the GDPR.

Recommendations — in sequence, not in parallel

“Everything at once” is the absence of a recommendation. Below is the sequence the Coalition considers appropriate for a healthcare provider using a system affected by the incident.

Systemic recommendations

For suppliers of medical systems. Product security ceases to be a commercial argument and becomes a condition of admission to the public market. We recommend as a minimum: a documented process for managing secrets and rotating credentials; security testing before every production release; a contractual undertaking to notify the controller within a period measured in hours; and readiness to make the results of post-breach analysis available to client controllers.

For founding bodies and owner entities. A single hospital will not build monitoring and response capability on its own. A regional security operations centre shared by the entities of one founding body is cheaper and faster than multiplying individual teams — and remains the Coalition’s recommendation, unchanged since 2024.

For the regulator. We propose extending supply chain oversight in healthcare to the layer that is today the least regulated: software suppliers serving thousands of healthcare providers simultaneously. An event at such a supplier has a systemic effect, while regulatory responsibility disperses across hundreds of controllers, each of which individually has limited ability to enforce a standard. This is an asymmetry that requires correction at the level of legislation, not of contract.

For patients

We endorse the e-Health Centre’s recommendations: place a block on your PESEL number, use strong and unique passwords, enable multi-factor authentication, treat with caution any unexpected message invoking a medical facility or the incident itself, and monitor account activity. Access to care and to the central e-health services is — according to the e-Health Centre’s statement — not disrupted. A wave of fraud attempts exploiting the publicity around the case is, however, a highly probable scenario and should be expected.