MyDr: how a cyberattack on Polish medical software could affect nearly 19 million patients — and what it means for your business?
BLUF (short answer): On August 17, 2026, Polish authorities confirmed a cyberattack on MyDr — a software provider connecting medical facilities to the national P1 e-health platform. Unauthorized access to historical data (up to April 2024) may affect ~19 million people and 12,000+ facilities; authorities (Digital Affairs Minister, NFZ/CSIRT) are investigating, and NFZ is monitoring. No data publication is confirmed. This is potentially Poland's largest data breach and an example of software supply-chain risk, which under NIS2/KSC concerns every company — not just healthcare.
Key facts
- MyDr is a critical link in Poland's digital healthcare — its software connects thousands of medical facilities to the Ministry of Health's P1 platform (e-prescriptions, e-referrals), making it part of the country's critical health infrastructure [1][2][3].
- Scale: up to ~19 million people and 12,000+ facilities — confirmed unauthorized access to historical data (up to April 2024); reports mention even 18.8 million unique PESEL numbers and patient/prescription data [1][4][5].
- Polish authorities are investigating — including Digital Affairs Minister Krzysztof Gawkowski and NFZ/CSIRT; Gawkowski called it one of the largest data breaches in Poland's history [2][3][4].
- No evidence of data publication yet — NFZ is monitoring the situation; public release of the stolen records has not been confirmed [1][2].
- NIS2/KSC lesson: healthcare is an essential entity; the incident illustrates software supply-chain risk (Art. 21(2)(d) NIS2), 24h/72h reporting duties (Art. 23) and business continuity [1].
Decision table — what it means for a B2B/manufacturing firm
| Area | What we know | What it means for B2B/manufacturing | Recommended action 30/90 days |
|---|---|---|---|
| Software supply chain | MyDr is a software provider through which medical data from hundreds of facilities may have leaked | Your software operators (ERP, CRM, cloud, integrators) are the same risk vector | 30 days: map your software vendors and their level of access to your data; 90 days: implement due-diligence controls and security clauses in contracts |
| Personal and sensitive data | Potentially medical data, PESEL, prescriptions — up to April 2024 | Data you do not control directly still creates liability for you | 30 days: check what data your vendors process and where it is stored; 90 days: minimize retention and encrypt sensitive data |
| Incident reporting (NIS2 Art. 23) | Healthcare = essential entity; 24h/72h reporting duties | Everyone in the supply chain should have a clear reporting process | 30 days: implement an incident-response plan and a reporting-obligation map; 90 days: test the reporting process with your team |
| Business continuity (BCP/DR) | A large breach can paralyze a critical provider's services | If a critical vendor goes down, your production/operations stop too | 30 days: identify critical dependencies on single vendors; 90 days: prepare a contingency plan and alternative vendors |
| NIS2/KSC compliance | An incident at your vendor can be your incident | Supply-chain risk is an explicit NIS2 requirement (Art. 21(2)(d)) | 90 days: implement and document vendor security assessments |
Engineer Marcin Białczyk's perspective
From an operational standpoint, MyDr is not a story about "hackers" — it is a story about concentration of risk. When a single software vendor serves thousands of facilities and connects them to a national e-health platform, you create a single point of failure — precisely what NIS2/KSC calls supply-chain risk. In manufacturing companies I see the same mechanism: an ERP system, a cloud integrator or an SCADA vendor holds the data and access that determine business continuity, while the company has no full visibility into how that vendor secures those assets. An incident at your vendor is, in practice, your incident.
The second lesson is about accountability and measurement. "We didn't have the data in our system because the vendor stores it" — that is not a line of defense; it is a statement of lost control. At CHORS.NET we approach this by measuring exposure and doing a passive snapshot before proposing any changes — because numbers, not words, show the real level of supply-chain risk. The key question is not "does the vendor have a certificate" but "what happens to my data and my continuity when the vendor gets attacked."
FAQ
Is my medical data at risk if I use a facility that runs MyDr?
If your medical facility used MyDr software, your historical data (up to April 2024) may have been part of the unauthorized access. NFZ is monitoring the situation, and there is no evidence of data publication yet. Check NFZ and your provider's communications, and consider monitoring your personal data.
Does this affect companies outside healthcare?
Yes, indirectly. MyDr is an example of software supply-chain risk — the exact same vector that applies to any B2B/manufacturing company using ERP, cloud, SCADA or integrators. NIS2/KSC explicitly requires supply-chain risk management (Art. 21(2)(d)).
What are the reporting obligations in such a case?
In the healthcare sector (essential entity), NIS2 requires a preliminary report within 24h and a full report within 72h of an incident (Art. 23). The exact scope depends on the entity's status — detailed interpretation requires consultation with a law firm.
What should we do if our software vendor was attacked?
Do not wait — activate your response plan: identify the impact scope, preserve evidence, notify the appropriate people/bodies (per your reporting-obligation map), consider data monitoring and prepare communication. Critically, do not base security on vendor claims — verify the facts.
CTA
Want to see how exposed your company really is to software supply-chain risk? Learn how CHORS.NET works and what we can do for you:
- Security services — exposure measurement and operational support: /uslugi/
- NIS2/KSC Readiness — preparation for NIS2/KSC obligations, with boundaries: /nis2-ksc/
- AI policy in cybersecurity — how we approach automation: /polityka-ai/
- How CHORS.NET works — our methodology and principles: /o-nas/jak-pracuje-chors-net/
Boundaries and assumptions
- We are not a 24/7 SOC and we do not guarantee detection of every incident.
- We do not certify NIS2/KSC compliance and we do not issue independent legal opinions.
- Facts and results reflect the state as of the article date (17.08.2026) and are based on public reports and NFZ communications.
- On legal interpretation, CHORS works with law firms.
- This material is informational and technical; it is not legal advice.
Last updated: 17.08.2026