Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

Poland's Medyc health-data breach may affect five million people: what patients and providers should do

Poland's data protection authority plans to inspect the Medyc software vendor while cybercrime police investigate. Here is what is known and what to do next.

PUBLIC RESEARCH
AUTHOR
/ CEO of Breachroad · OSCP · PNPT
PUBLISHED
29 September 2026
READING TIME
10 min read
TOPIC
Threats and Incidents
Poland's Medyc health-data breach may affect five million people: what patients and providers should do

Poland’s Personal Data Protection Office, UODO, has reported a potential breach involving Medyc, an application used by healthcare providers. According to reports cited by the authority, the incident may involve medical data relating to as many as five million people in Poland. The Central Bureau for Combating Cybercrime is investigating, and UODO’s president has announced an inspection of Qbusoft, the company that develops the software.

That is a significant figure, but it is not yet a confirmed list of five million victims. The public notice does not provide a complete catalogue of exposed fields, name every affected healthcare provider or establish the final scope. Patients should take the risk seriously without assuming that criminals possess every document and password associated with them.

What has been officially confirmed

UODO published its notice on 25 September and updated it on 28 September. The authority says the incident resulted from an attack on the Medyc application and may involve the medical data of up to five million people. Poland’s cybercrime police are acting as part of a broader investigation, while the regulator intends to inspect the company behind the system.

The digital affairs minister’s statement quoted by UODO also says that the e-Health CSIRT and the Ministry of Health sent security recommendations to medical-software vendors on 16 September. At the point described in the notice, Qbusoft had not reported the incident to CERT Polska or the e-Health CSIRT.

That final point should not be turned into a legal conclusion before the investigations are complete. UODO has announced an inspection, and law enforcement is conducting its work. Their findings will have to establish which controls were in place, when each organisation became aware of the event and which obligations arose.

What a patient should do

First determine whether your provider used Medyc and whether it has sent you an individual notification. Find the provider’s website or phone number independently instead of using contact details in an unsolicited breach message. Reception staff may not yet know the full scope, so ask for an official update channel rather than pressing them to speculate.

Do not provide a text-message code, password, payment-card data or an identity-document scan to someone who calls and claims to be “securing your medical record”. Genuine knowledge of an appointment, doctor or clinic makes fraud more persuasive, but it does not prove the caller’s identity.

If an official notification establishes that a national identity number or identity-document data was affected, use the protective controls available in your country and monitor attempts to obtain services in your name. A person in Poland should consider restricting their PESEL when that identifier is involved. If email addresses or phone numbers are affected, watch for messages tailored to a real healthcare relationship. The public announcement alone does not prove that an online-banking or patient-portal password was exposed.

Unique passwords and strong authentication remain important. Change a password where it was used in the affected system, stored in a document or reused elsewhere. Our practical guides explain the first 72 hours after a data breach and how to reduce identity-theft risk.

Healthcare providers cannot wait solely for the vendor

A clinic or treatment centre using Medyc should quickly determine its own dependency scope. It needs an inventory of instances, integrations, service accounts, exports, data copies and devices used to access the service. It must also identify which information it sent to the platform and the period covered.

The vendor is analysing its infrastructure, but each provider remains responsible for its own decisions about patient data. It should preserve correspondence, logs and configuration, begin its breach assessment and consult its data protection officer and legal counsel. Where regulatory notification or communication to individuals is required, the clock should not wait for a convenient public-relations moment.

Do not delete accounts, logs or integrations before preserving evidence. Nor should every connection be restored merely because the main application responds again. Providers should first agree with the vendor which elements have been verified, which credentials need rotation and which indicators they should search for in their own environment.

How to communicate with patients

A useful notice separates four things: what is confirmed, what remains under investigation, who may be affected and what the recipient should do. “We are investigating” without instructions transfers the cost of uncertainty to the patient. An overly categorical assurance can become inaccurate just as quickly.

The provider should publish a verifiable contact channel and prepare reception and call-centre staff for questions. Staff must not request a full medical history in an unencrypted email merely to check whether a person is on a list. A controlled identity-verification procedure and a consistent update format are safer.

The communication should also warn about follow-on phishing. Criminals do not need a stolen database to exploit a widely reported breach. A mass message about compensation, urgent prescription confirmation or a new patient account may be enough. The provider should state what it will never request by phone or text.

The lesson for healthcare-software vendors

A platform holding records for many independent providers concentrates risk. One privileged account, shared component or poorly protected backup can affect multiple data controllers and millions of people. Vendors need separated environments, least privilege, strong authentication, export controls, tamper-resistant logs and a rehearsed method for securely sharing indicators with customers.

Contracts must cover more than service availability. They should define incident-notification timing, interim information for customers, log retention, participation in investigations and communication with public authorities. A clinic needs enough information to perform its own risk assessment instead of waiting indefinitely for a final report.

This scenario cannot be prepared through documents alone. Clinical staff, IT, management, privacy, legal and communications teams should rehearse decisions together in an incident-response tabletop exercise.

Source facts and Breachroad conclusions

The UODO notice is the source for the potential scale of up to five million people, the cybercrime-police activity, the planned Qbusoft inspection, the recommendations sent to vendors and the reporting status described by the authority. It does not publish a complete list of data fields, providers or confirmed victims.

The patient checklist, provider response plan, communication model and contractual controls are Breachroad recommendations. We do not infer the attack’s root cause, legal responsibility or a final number of affected people.

SHARE / COPY