MyDr May Have Exposed Data on Half of Poland. The Concentration Risk Is the Bigger Story.
MyDr has confirmed a cyberattack and says the affected information is probably historical, but it cannot yet define the exact scope. Polish officials describe a possible exposure involving nearly 19 million people. The incident shows how a platform serving many healthcare organisations can concentrate risk at national scale.
What MyDr has confirmed
MyDr provides electronic medical-record and patient-service technology used across the Polish healthcare sector. On 12 August 2026, the company confirmed that it had been the target of a cyberattack.
In a company statement reported by Onet on 13 August, MyDr said the information involved was most likely historical, largely from 2024 and earlier. It cautioned that the incident might not cover every MyDr customer or every patient of those customers.
The company also said it could not yet determine the precise scope. At that stage, it had no evidence that the information had been made public, and specialists were monitoring the dark web. MyDr said it would contact affected customers when it could identify the organisations and data involved, and would support regulatory notifications and communications with patients where required.
That is the confirmed corporate position. It is materially narrower than some headlines about the event.
The largest number comes from the government assessment
Polish deputy prime minister and digital-affairs minister Krzysztof Gawkowski said the possible exposure concerned data on close to 19 million people and amounted to approximately two terabytes. Onet reported that officials described the material as including PESEL national-identification numbers, prescription information, details of medical visits and medical histories.
Gawkowski also said the data was not publicly available or offered for sale at the time of his statement. He said investigators understood where the software and system-management failures had occurred and that those weaknesses had been addressed. Prosecutors and security services were working on the case.
These statements do not establish that 19 million unique people had all of those data types exposed. The number is a government estimate of possible scope while the company is still identifying affected customers, people and records. A large archive can contain duplicates, multiple records per person and data held on behalf of different healthcare providers.
The most accurate description is therefore cautious: MyDr confirms an incident affecting historical information; the Polish government says the potential population is close to 19 million; the exact number of unique affected people and the data attributable to each person were not yet confirmed when this article was prepared.
Historical medical data is not stale risk
Calling data historical helps define the period of exposure. It does not make the information harmless.
A password can be changed. A bank card can be replaced. A diagnosis, treatment history, disability, prescription pattern or national identifier may remain sensitive for a lifetime.
Medical information can support highly credible phishing, impersonation and extortion. A message that names a real clinic, refers to an old appointment or mentions a plausible prescription can be more convincing than a generic lure. Identity data can also be combined with information from unrelated breaches to pass knowledge-based checks or create fraudulent applications.
The age of the record changes some details of the threat. It does not remove the privacy consequence or the value of the data to an attacker.
The platform is a concentration point
Healthcare risk is often assessed one hospital or clinic at a time. Shared platforms break that model.
When many independent providers use one system for documentation, scheduling, prescriptions or patient administration, they gain consistency and scale. They also create a common dependency. One platform incident can force thousands of separate organisations to answer the same questions at once: which patients were affected, which records were involved, who must notify regulators, and how should people be contacted without creating more confusion?
This is not an argument against shared healthcare platforms. It is an argument for treating them as critical concentration points.
The security boundary follows the data and the authority to process it. A clinic can maintain strong local controls and still inherit exposure from a processor that aggregates its records with those of many other customers.
Processor and customer responsibilities meet during the incident
MyDr said it would support customers with notifications to data-protection authorities and communications with patients. That assistance is necessary, but it also reveals the coordination problem.
The platform operator may possess the forensic evidence. Individual healthcare providers may hold the legal relationship with the patient and the context needed to explain what a record means. Government services may provide identity-protection tools and a safe way for people to check whether their data appears in the affected set.
If those parties wait to design the workflow until after a breach, the response will be slow and inconsistent. Patients may receive conflicting advice, duplicate notices or no notice at all.
Contracts and incident plans should therefore define more than a notification deadline. They should specify how the processor will identify affected tenants, how records will be mapped to unique people, what evidence customers will receive, who approves public language, and how corrections will be issued as confidence improves.
Scope must be measured in people, records and organisations
A single number cannot describe a platform breach.
Security leaders should track at least three denominators:
- Unique people whose information is present.
- Records, documents or objects involved, including duplicates and historical versions.
- Customer organisations whose data or workflows were affected.
Those measures answer different questions. People need to know their personal risk. Regulators need to understand legal responsibility and data categories. Healthcare organisations need to know whether their patients and operations are in scope.
Publishing only the largest available number can overstate certainty. Publishing only the percentage of customers can understate human impact. Good incident communication carries both scale and confidence.
Controls for healthcare platforms and their customers
Healthcare organisations should use this incident to test the shared controls around their platforms:
- Maintain a current inventory of every processor that stores clinical, identity or appointment data.
- Record which data categories, retention periods and patient populations each service covers.
- Require tenant-level logging and export records so a platform can identify which customer data was accessed.
- Monitor bulk reads, archive creation and unusual administrative access, not only service availability.
- Use phishing-resistant authentication and time-limited privilege for support, engineering and database administration.
- Minimise historical data when legal and clinical obligations no longer justify retention.
- Pre-agree an incident data format that customers and government services can use to match records to people safely.
- Exercise communications across processor, clinic, regulator and patient-support teams.
- Prepare specific advice for medical-data phishing, impersonation and identity abuse.
Polish authorities recommended reserving a PESEL number through the mObywatel service. The government also directed concerned people to Bezpieczne Dane, its service for checking exposed datasets. Those are useful individual protections, but they do not replace the platform-level work required to establish scope.
National scale changes the response
An incident that may concern close to half a country’s population is not merely a vendor breach with many notifications. It becomes a national coordination problem.
The response needs a reliable matching process, a safe public checking mechanism, consistent instructions and protection against criminals exploiting the uncertainty. Attackers do not need the stolen database to be public before they can send fake breach notices, impersonate clinics or direct people to fraudulent checking sites.
That means communication channels themselves become part of the security control. Official domains, clear language and repeated warnings about lookalike messages matter while the investigation is still moving.
The exact count can wait. The concentration lesson cannot
MyDr’s caution about scope is appropriate. The investigation should distinguish confirmed access from attacker claims, records from unique people, and historical holdings from current systems.
Security leaders do not need to wait for the final count to recognise the architectural lesson.
A healthcare platform can serve as an efficient shared service and a shared point of failure at the same time. Its incident readiness must be designed for the combined population of its customers, not for the size of the software company operating it.
The data may be historical. The trust, privacy and coordination risk is current.
Sources and further reading
- Onet: MyDr company statement and current scope
- Onet: Polish government update on the MyDr investigation
- MyDr: healthcare-platform overview
- Polish government: Bezpieczne Dane checking service
Continue the series: European National Cyber & Digital Law Series index
