Publication date: September 07, 2026
On 10 August 2026, MyDr, one of Poland’s largest providers of electronic medical records software, confirmed that it had been the target of a deliberate criminal attack on its systems. Two days later, the Ministry of Digital Affairs announced that the incident may affect close to 19 million individuals and more than 12,000 healthcare facilities, and that the exfiltrated database exceeds 2 terabytes.
The attackers supplied the security portal Zaufana Trzecia Strona with a data sample suggesting that they hold PESEL numbers (Polish national identification numbers) and at least fragments of prescription information.
To date, the company has not publicly confirmed the full scope and nature of the compromised data, referring instead to a pending forensic analysis. The investigation is being conducted by the Central Bureau for Combating Cybercrime under the supervision of the Warsaw Regional Prosecutor’s Office, and the President of the Personal Data Protection Office (UODO) has opened an inspection covering the technical and organisational measures applied and the underlying risk analysis. Since 29 August, the dataset from the incident has been available on the government portal bezpiecznedane.gov.pl, where anyone can check whether their data was affected.
The scale of the incident prompted the Ministry of Digital Affairs to announce, within three weeks, a legislative package branded the “Cyber Five”. Its key elements include certification of entities processing medical data within the existing national cybersecurity certification framework; a mandatory risk assessment before processing begins and at least every two years thereafter; new obligations for entities serving more than 100 controllers or processing data of more than 100,000 individuals (including rapid transfer of affected persons’ data to CSIRT NASK and a duty to inform client facilities about the level of their own security); and notifications of medical events via the mObywatel and mojeIKP applications. The amendments are to cover the Act on Patients’ Rights and the legislation governing the National Cybersecurity System.
From a legal standpoint, the critical point is that, in relation to medical records, MyDr acts as a processor, while each facility – from a large clinic network to a single-doctor practice – remains the controller. The consequences of this structure became fully apparent after the incident:
Deputy Minister of Digital Affairs Dariusz Standerski stated openly that in this case, liability under the contract remained entirely with the controllers, i.e. small medical practices. This is the most important lesson of the incident: a data processing agreement is not a formality but the document that, on the day of a breach, determines who pays.
1. The data processing agreement and the main contract as risk-allocation tools. Standard DPA templates offered by software vendors focus on satisfying the minimum requirements of Article 28(3) GDPR. A healthcare provider should negotiate further: a precise deadline and format for incident notification (e.g. 24 hours, with a defined scope of information enabling a risk assessment); audit and penetration-testing rights; an obligation to maintain specified certifications (ISO 27001 and, in future, certification under the National Cybersecurity System Act); a duty to cooperate in communications with patients and the supervisory authority; liability and recourse clauses not capped at the annual fee; and a requirement that the vendor hold cyber insurance with a defined sum insured, with the facility named as a co-insured or beneficiary.
2. Cyber and liability insurance. Standard professional liability policies for healthcare providers typically do not cover the cost of notifying patients, crisis management, administrative fines or claims arising from data breaches. A dedicated cyber policy covers these elements, but its exclusions must be read carefully: insurers increasingly condition cover on the implementation of MFA, system patching and backups, and an incident at an external supplier (a so-called third-party breach) is often covered only under an express extension. It is also worth verifying whether the software vendor’s own policy actually exists and what its limit is – given the number of facilities relying on a single system, such amounts may prove illusory.
3. A map of relationships between entities. In a real-world e-health ecosystem, patient data flows between the facility, the EMR vendor, the hosting or cloud provider, the e-prescription and e-referral operator, laboratories, IT subcontractors and billing companies. Each link is a distinct legal relationship: processing on behalf of the controller, sub-processing (Article 28(2) and (4) GDPR) or joint controllership (Article 26 GDPR). A facility should maintain an up-to-date register of these entities, know where the data is physically located and control the chain of sub-processors – a “general” consent to sub-processors without a list and without a right to object is, in practice, an abdication of control.
4. Anonymisation, pseudonymisation and data minimisation. Data that is not in the system cannot leak. Healthcare providers and vendors should separate identifiers (PESEL numbers, contact details) from clinical data, apply pseudonymisation (Article 4(5) and Article 32(1)(a) GDPR) in test, analytical and research environments, and store statistical data exclusively in anonymised form. It should be remembered that anonymisation is an irreversible process and only such a process removes data from the scope of the GDPR; pseudonymisation remains processing of personal data, but it significantly limits the consequences of a breach and is a valuable argument both in proceedings before UODO and in litigation over damages.
5. Internal obligations and incident readiness. A breach response procedure should be tested, not merely written down: who decides on notifying UODO within 72 hours, who communicates with patients, who with the media, who secures the evidence. Regular risk analysis and a data protection impact assessment (DPIA) for EMR systems – which, given their scale and the categories of data involved, almost always meet the criteria of Article 35 GDPR – is an obligation already today, and once the “Cyber Five” enters into force it will additionally become a sector-specific requirement with a prescribed frequency.
The healthcare sector is particularly exposed to a new generation of AI-supported attacks. Large language models enable the mass generation of credible phishing messages in flawless Polish, personalised on the basis of data from previous breaches – a PESEL number, a surname and information about a prescription are enough to construct a convincing message “from your clinic” or “from the National Health Fund”. AI tools also automate the discovery of vulnerabilities in systems and the generation of malicious code, shortening the window between disclosure of a vulnerability and its exploitation. There is a growing number of cases involving voice deepfakes used to impersonate medical staff or IT administrators in order to obtain access credentials.
For vendors and facilities, this means that traditional “don’t click suspicious links” training is no longer sufficient. Technical mechanisms are required (phishing-resistant MFA, network segmentation, AI-assisted anomaly monitoring on the defensive side), together with identity verification procedures for every request for data access or a change of permissions. Regulatory risk should also be kept in mind: AI systems deployed in healthcare facilities – including tools supporting diagnostics or triage – fall under the AI Act, and their integration with EMR systems constitutes yet another link in the processing chain that must be reflected in contracts and in the risk analysis.
KG Legal advises healthcare providers, medical networks, telemedicine platform and e-health software vendors, and investors in this sector on managing liability for data. Our support includes auditing existing data processing agreements and IT supplier contracts for risk allocation; negotiating liability, recourse and insurance clauses; mapping the chain of processors and vetting subcontractors; preparing and testing breach response procedures; handling notifications to UODO and communications with patients; and representation in inspection proceedings and in damages litigation. For medical technology vendors, we prepare documentation and contract templates meeting the requirements of the GDPR, the Act on Patients’ Rights, NIS2 and – once enacted – the “Cyber Five” provisions, and we assess the compliance of AI-based solutions with the AI Act and the MDR. Our aim is that, on the day an incident occurs, the client knows exactly who is responsible for what and has evidence of having exercised due diligence.
Facts as at 2 September 2026, based on statements by MyDr, the Ministry of Digital Affairs and UODO, and press reports. This article is for information purposes only and does not constitute legal advice.
#MyDr #DataBreach #HealthcareCybersecurity #HealthcareData #DataProtection #GDPR #Cybersecurity #HealthTech #eHealth #DigitalHealth #MedicalRecords #EMR #PatientData #PatientPrivacy #UODO #Poland #CyberRisk #CyberInsurance #IncidentResponse #DataPrivacy #NIS2 #CyberFive #ISO27001 #AIAct #AIinHealthcare #AICybersecurity #MedTech #Telemedicine #CyberResilience #DataSecurity