What happened

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.

Why roles in the processing chain decide everything

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:

• The obligation to notify UODO (Article 33 GDPR) and to communicate the breach to patients (Article 34 GDPR) rests with the controller, i.e. the facility. The processor is merely required to inform the controller “without undue delay” (Article 33(2) GDPR). In practice, thousands of healthcare providers had to assess risk and communicate with patients on the basis of fragmentary information from the supplier.
• Liability for damages (Article 82 GDPR) is joint and several: a patient may sue the facility, the supplier, or both. The processor is liable where it has failed to comply with obligations specifically imposed on processors by the GDPR or acted contrary to the controller’s instructions – but the facility is liable for having entrusted data to an entity that did not provide sufficient guarantees (Article 28(1) GDPR).
• Sector-specific requirements under the Act on Patients’ Rights (Article 24(4)) impose on any entity entrusted with the processing of medical records a duty of confidentiality and data security – this is precisely the provision now slated for extension to include certification and minimum technological standards.

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.

How a healthcare service provider can protect itself

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.

AI-enabled attacks

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.

How we support institutional clients

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

Artykuł The MyDr Data Breach – Lessons for Healthcare Service Providers and e-Health Platforms pochodzi z serwisu KIELTYKA GLADKOWSKI LEGAL | CROSS BORDER POLISH LAW FIRM RANKED IN THE LEGAL 500 EMEA SINCE 2019.

The Act amending the Act on the National Cybersecurity System aims to implement Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS Directive 2) and the partial application of Commission Delegated Regulation (EU) 2024/1366 of 11 March 2024 supplementing Regulation (EU) 2019/943 of the European Parliament and of the Council.

The amendment to the KSC Act significantly expands the scope of the regulations and introduces new obligations in the field of cybersecurity management. The changes include, among other things, the implementation of risk management systems and expanded incident reporting requirements. The new regulations also strengthen the powers of supervisory authorities and significantly increase the maximum amount of financial penalties. It also introduces liability for the management staff (manager) of an entity. In practice, this requires certain entities to take steps to comply with the new regulations.

The first experiences of entrepreneurs after the amendment came into force – practical conclusions

The few months that the amended Act on the National Cybersecurity System has been in effect demonstrate that the biggest challenge for businesses is no longer the analysis of the new regulations, but their practical implementation. For many organizations, the adaptation process began with a seemingly simple task: determining whether a given entity is even subject to the new regulations. In practice, this step proves to be one of the most problematic.

Under the previous legal framework, many businesses awaited a formal administrative decision confirming their status as an essential service operator. This approach is no longer appropriate. The status of a key or important entity stems directly from the Act, and obligations arise regardless of whether the business has already been entered on the register. This means that the responsibility for properly assessing their own situation rests primarily with the business itself.

Practice also shows that many companies focus solely on the issue of being entered into the register of key and important entities. However, entry itself is not the purpose of the regulation. The greatest challenges remain the actual implementation of an information security management system, conducting a risk analysis, developing incident response procedures, and adequately documenting the actions taken. In the future, supervisory authorities will primarily assess an organization’s actual level of compliance with the Act, not merely the formal fulfillment of registration obligations.

Another significant change is the significant increase in management responsibility. Management can no longer treat cybersecurity as a matter solely within the purview of IT departments. The Act requires active management involvement in the organization of the cybersecurity management system, oversight of its operation, and provision of adequate organizational and financial resources. In practice, this requires regular reporting on cybersecurity issues at the management level and documentation of decisions made.

Supply chain security is also becoming increasingly important. Businesses are required not only to secure their own IT systems but also to consider the risks arising from collaboration with IT service providers, cloud computing operators, software vendors, and outsourcing providers. In practice, this means reviewing supplier contracts, verifying the security measures in place, and implementing appropriate provisions for incident management and crisis cooperation.

It’s also noticeable that a growing number of businesses are choosing to conduct internal compliance audits before the statutory deadlines expire. This approach allows for early identification of organizational and technical gaps, reducing the risk of subsequent violations and costly remedial actions.

In practice, the best solution is to treat the implementation of the Act’s requirements not as a one-time project, but rather as a process encompassing regular risk analysis, procedure updates, employee training, and ongoing oversight of the organization’s security. This approach not only increases compliance but also significantly reduces the risk of cybersecurity incidents.

It’s worth emphasizing that the current transition period should be used to calmly prepare organizations for the full application of the new regulations. Postponing implementation until the final months before the statutory deadlines expire can be risky, especially for large organizations where implementing information security management systems requires the involvement of multiple departments and adequate time to prepare procedures and documentation.

Change in the circle of entities to which the Act applies.

Under the previous wording of the Act, an administrative decision was required to recognize an entity as an essential service operator (Article 5 of the Act before the amendment). Currently, the group of key and important entities is determined automatically (ex lege). The criteria for qualifying an entity as essential are found in Article 5, Section 1, and as an important entity in Article 5, Section 2 of the Act. It is possible that an entity meets the criteria for both key and important entities; such an entity is considered a key entity under Article 5, Section 4. When attempting to qualify entities, the Act also refers to EU regulations, particularly Regulation 651/2014/EU, which defines SMEs. Therefore, the primary criteria taken into account will be the number of employees and annual turnover. It is also necessary to refer to Annexes 1 and 2 of the Act, which precisely define the categories of entrepreneurs in specific sectors and subsectors.

The added Article 5a in paragraph 1 provides that key and important entities are subject to the obligations arising from the Act if they reside in the territory of the Republic of Poland or conduct their business in the territory of the Republic of Poland.

Articles 7 et seq. regulate matters related to the list of key and important entities. Before the amendment, the list contained only operators of essential services; now it includes key and important entities. Unlike the previous legal status, in which entry was made at the request of the authority responsible for cybersecurity (former wording of Article 7, paragraph 3 of the Act), entry is now made at the request of a key or important entity within six months of the occurrence of the conditions (Article 7c, paragraph 1 of the Act). Ex officio entry will generally only apply to existing operators of essential services, trust service providers, telecommunications companies, and public entities. This means that for entities meeting the conditions on the date the amendment comes into force, the deadline for submitting an application is October 3, 2026. Pursuant to the Announcement of the Minister of Digitization of April 8, 2026, regarding the schedule for submitting applications for entry in the register of key and important entities and for key or important entities to commence using the ICT system , self-registration on the list is possible from May 7, 2026, to October 3, 2026. The platform operating in the S46 system is available at https://wykaz-ksc.gov.pl/ . By April 3, 2027, key and important entities are required to commence using the ICT system specified in Art. 46 sec. 1 of the Act. This deadline begins depending on whether the entities were parties to agreements regarding the use of the ICT system referred to in Art. 46 sec. 1 of the Act concluded before April 3, 2026. For the former, the possibility of using the system was opened on April 8, 2026, and for the latter, this possibility will be available from June 12, 2026 (point 2 of the Communication of the Minister of Digital Affairs).

If an entity that meets the criteria for being considered a key or important entity fails to submit an application for entry, the authority responsible for cybersecurity may enter the entity on the list ex officio (Article 7j, paragraph 1 of the Act). Failure to comply with certain obligations related to the list (failure to timely complete missing data on the list or failure to correct data despite a request or failure to submit an application for entry) may result in the imposition of a substantial fine (Article 73, paragraph 1, point 1 and Article 73, paragraph 1a, point 1 of the Act). The catalogue of data to be included on the list has also been changed (expanded) (Article 7, paragraph 2).

In practice: The expansion of the scope of entities and the shift from administrative decision-making to automatic regulation mean that many entities may be subject to the Act without formal confirmation of this status. In practice, independent qualification analysis and continuous monitoring of compliance with statutory criteria become crucial. An incorrect assessment (or failure to comply) may result in exposure to sanctions (severe fines).

New responsibilities for cybersecurity management.

Duties

Chapter 3, which governs the obligations of key and important entities, has been expanded, and Chapters 3a and 3b have been added, addressing domain name registration service providers and public entities. Article 8 of the Act governs obligations related to the implementation of an information security management system. Compared to the previous legal framework, numerous obligations have been added. The responsibility of the manager of a key or important entity for the performance of its cybersecurity obligations has been introduced (Article 8c of the Act), and the manager’s responsibilities have also been defined (Articles 8d–8f of the Act).

The regulations regarding incident reporting have also changed. A key or important entity classifies a given incident as serious (after meeting the requirements of Article 2, Section 7 of the Act), then issues an early warning, reports the incident, and finally submits a final report on the handling of the serious incident to the CSIRT (a three-step reporting model instead of the previous one-step model – Article 11 of the Act).

Deadlines

Pursuant to Article 15 of the Act, key entities must conduct a security audit of the information system used in the service provision process at least once every three years. For key entities that were not previously classified as key service operators, the first audit should be conducted within 24 months of the date the conditions are met (Article 16, point 2, therefore, for these entities, the deadline for conducting the audit is April 3, 2028).

The Act amending the KSC Act establishes a 12-month transition period during which key and important entities have time to fulfill the obligations specified in Chapter 3 of the Act (except for the obligation to conduct the first audit, which entities have 24 months to conduct). Therefore, with respect to obligations such as implementing an information security management system, risk assessment, implementing technical and organizational measures, reporting and managing incidents, and verifying personnel’s criminal records, the deadline for compliance with these regulations expires on April 3, 2027.

In practice: The imposed obligations require the implementation of an information security management system. Furthermore, the single-tier incident reporting system has been changed, replaced by a more complex three-tier system. Essential entities will be required to conduct audits. Importantly, entities that were not previously considered essential service operators will be required to conduct an audit within two years of the amendment’s entry into force. However, most of the new obligations will have to be implemented by April 3, 2027. Failure to comply with these obligations will result in the manager of the relevant entity being held liable.

Change in the amount and grounds for imposing fines.

Until April 2, 2026, the maximum amount of the fine imposed on entities (only for the most serious violations) was PLN 1 million (former wording of Article 73, paragraph 5 in fine). Currently, the maximum amount of the fine is, as a rule, EUR 10 million (Article 73, paragraph 3 of the Act), and for the most serious violations, up to PLN 100 million (Article 73, paragraph 5 in fine of the Act).

With the imposition of a large number of obligations on key and important entities, the list of violations for which a fine may be imposed has also been expanded (Article 73 of the Act).

The new provisions on fines come into force only two years after the entry into force of the Act (i.e. from April 3, 2028).

In practice: Increasing the amount of fines disciplines key entities and important entities to take their cybersecurity obligations very seriously. It is worth emphasizing, however, that the amended regulations on fines will not enter into force until April 3, 2028.

Changes in the supervision and control of key and important entities.

Chapter 11 of the Act, which deals with the supervision and control of key and important entities, has been significantly expanded. Some provisions remain unchanged (the requirement to apply the provisions of the Entrepreneurs’ Law or the Act on Audit in Government Administration, the powers of the person conducting the audit, most of the obligations of audited entities, and provisions regarding audit protocols and post-audit recommendations).

Important changes

The most important changes in the scope of supervision include a significant expansion of Article 53, which describes the powers of the authority responsible for cybersecurity regarding supervision and oversight of key entities. It empowers the competent authority to issue various types of administrative decisions aimed at enforcing the provisions of the Act. This article also contains a number of procedural provisions defining the nature of the proceedings. Generally, the regulations contained in this article apply only to key entities, but as stated in Article 53, paragraph 17, certain provisions also apply to inspections of important entities. Article 53, paragraph 3 states that supervision of key entities is both post-empty and preventive, while for important entities, supervision is only post-empty.

A new obligation for both key and important entities is the information obligation specified in Article 53c, which requires a key or important entity to provide certain data at the request of the authority responsible for cybersecurity.

A new institution is the ad hoc review added in Article 59c, which may be carried out only if the conditions specified in the cited Article are met.

In practice: Strengthening the powers of supervisory authorities and introducing ad hoc inspections means increased risk of inspections and the need to maintain constant readiness to demonstrate compliance with regulations. Entities should also prepare for more frequent requests for information from authorized bodies.

Minor changes

Chapter 10 has been amended and Chapters 10a – 10c have been added, but they do not contain any standards addressed to entities and are therefore not relevant from a practical point of view.

Several changes concern Chapter 12 concerning the Government Plenipotentiary for Cybersecurity and the Cybersecurity Board, but these changes do not have any significant impact on the entities.

Article 12a has been added, addressing specific measures to ensure cybersecurity at the national level. It primarily contains provisions on recommendations from the Government Plenipotentiary for Cybersecurity (Article 67a), the procedure for designating a supplier as a high-risk supplier (Articles 67b–67f), and a safeguarding order in the event of a critical incident (Articles 67g–67i).

Minor changes also apply to the Cybersecurity Strategy of the Republic of Poland (Articles 68–72). The changes primarily concern the content and method of developing the strategy, as well as the frequency of strategy reviews (2.5 years instead of the previous 2 years).

The amendment to the Act on the National Emergency Response Plan creates the basis for the adoption of the National Emergency Response Plan (Articles 72a – 72f of the Act).

Recommended actions.

In light of the amendments to the Commercial Companies Code, entities subject to the new regulations should take steps to ensure their operations are in compliance with the law. It is recommended that:

1)      Self-identification in order to determine whether a given entity qualifies as a key or important entity within the meaning of the Act.

2)      Implementation or update of an information security management system.

3)      Development of procedures for identifying and reporting incidents, taking into account the new procedure.

4)      Ensuring the involvement of management staff, e.g. the manager’s implementation of the obligations under Article 8d or 8e.

5)      Preparing the organization for potential supervisory activities, e.g. inspections.

• Action:

ex officio entries carried out by the Minister of Digital Affairs (current key service operators, trust service providers, telecommunications companies and public entities)

• Deadline:

April 13 – May 6, 2026

• Action:

self-registration in the list of key and important entities

• Deadline:

May 7 – October 3, 2026

• Action:

launching the possibility of using the S46 system for new entities

• Deadline:

June 12, 2026

• Action:

end of the deadline for starting to use the S46 system and implementing obligations (end of the adjustment period)

• Deadline:

April 3, 2027

• Action:

the first ISMS audit (for key entities that were not key service operators) and the beginning of the application of the provisions on penalties

• Deadline:

April 3, 2028

Artykuł NIS2 in Poland: Practical Implications of the New Cybersecurity Framework for Businesses pochodzi z serwisu KIELTYKA GLADKOWSKI LEGAL | CROSS BORDER POLISH LAW FIRM RANKED IN THE LEGAL 500 EMEA SINCE 2019.