GDPR, phishing, KSC/NIS2 and board responsibility – why a cyberattack doesn't end with the server that's been attacked.

Let's imagine an SMS message:

"Good morning. Due to your recent visit to the clinic, please log in to confirm your prescription. The link is active for 24 hours."

The name is correct. The facility is correct. The visit actually took place. The patient did indeed recently receive a prescription.

Would you click?

This is precisely the problem with medical data leaks. Cybercriminals no longer have to guess which bank we have an account with, whether we're waiting for a package, or whether we're a customer of a specific carrier. If they have real data about our health, appointments, and prescriptions, they can create a message that doesn't look like a phishing scam.

It looks like reality.

And that's why the MyDr incident is more than just another "data leak." It's an example of the domino effect in cybersecurity.

One element collapses – the IT provider's system. Moments later, patients face problems. Then medical facilities. Then data protection officers, compliance departments, and management boards. Finally, regulators, GDPR regulations, and new obligations arising from the KSC implementing the NIS2 directive appear.

One cyberattack. Several different crises.

First cube: almost 19 million people

The scale of the incident is difficult to grasp. According to information released on August 12, 2026, the MyDr system-related incident may have affected the data of up to 19 million Poles. Media reports indicate a database of approximately 2 TB, which allegedly contained, among other things, PESEL numbers, prescription information, appointment information, and medical history. The system is expected to be used by approximately 12,000 healthcare facilities. The President of the Personal Data Protection Office (UODO) addressed the matter the same day. The UODO refers to reports of a data leak involving "almost 19 million Poles" and reminds administrators who use MyDr of their own responsibilities.

It's worth proceeding with caution. The full scope of the incident is still being determined, so information about the number of people, the scope of data compromised, and the technical course of the attack may still be updated.

But enough is already known to draw a crucial lesson. The biggest mistake would be to treat this incident as a problem for a single tech company.

Because the first domino is already hitting the next one.

Second cube: phishing who knows the truth

Most of us have learned to recognize a basic phishing scam. "Your package cannot be delivered." "Your account will be blocked." "Pay an additional 1.49 PLN.".

The problem begins when the message contains information that actually matches. Imagine a cybercriminal who can link a name, phone number, or PESEL number to information about a specific facility, appointment, or treatment. He doesn't have to write to millions of random people.

He can write to a specific person. And he can use something that builds trust better than a bank logo—a real piece of their life.

Therefore, the consequences of a major leak don't end with the database being copied. The stolen information can be used for months or years to build much more credible social engineering attacks. Referring directly to the MyDr incident, the Personal Data Protection Office (UODO) warned those potentially affected by the leak about text messages and emails that could constitute phishing attempts, and pointed out the possibility of having their PESEL numbers blocked.

This is especially important in healthcare. Medical information has two values. The first is obvious: it's extremely private. The second is less obvious: it's reliable. If a criminal knows the truth about our relationship with a doctor or facility, they can use it as a key to unlocking additional data, online banking, or other services.

Therefore, after such a leak, the question is not just, “What data was exposed?”

You also need to ask, “What can you do with this data?”

It's a completely different way of thinking about risk.

Third Cube: "It's a leak at our supplier" is not a GDPR strategy

This is where the story gets particularly interesting for businesses. A medical facility can, after all, claim that its servers weren't attacked; it's an external system, and the data was stored at the vendor's. In everyday terms, this might sound logical.

However, the GDPR does not end the matter.

The Personal Data Protection Office (UODO) explicitly reminded controllers who entrust MyDr with data processing that they must conduct a risk analysis of the rights and freedoms of natural persons and determine whether a specific breach requires reporting to the relevant authority and notification of affected individuals. In a second announcement, the office expressed this even more simply: the obligation to notify affected individuals rests with controllers using MyDr's services.

This is one of the most important lessons of this case.

Data processing can be entrusted. However, it's not possible to entrust someone with all of your own responsibility. Therefore, the administrator must determine whether their patients are affected by the incident, what information may have been disclosed, what risks this may pose, and what actions should be taken.

And the clock may already be ticking.

The GDPR stipulates that in the event of a breach requiring notification, the controller must notify the supervisory authority without undue delay, and if possible, no later than 72 hours after the breach is discovered. If the risk to individuals is high, the obligation to notify them also arises. In the case of medical data, the assessment can be particularly demanding. The GDPR explicitly mentions, among other things, the potential for discrimination, social ostracism, or violation of personal rights resulting from the disclosure of health data. Therefore, a single breach of a provider's system can trigger thousands of separate decision-making processes on the part of its customers.

And this is the actual domino effect.

Fourth Dice: MyDr Shows Why NIS2 Was Created

The phrase “supply chain security” sounds abstract.

Until something like MyDr happens.

A company can secure its own computers perfectly, hire administrators, implement MFA, and train employees. Then, it hands over a huge portion of its critical data to an external provider. From that point on, its security level no longer depends solely on the company. It also depends on the security of an entity it often doesn't even perceive as part of its own infrastructure. This is precisely why cybersecurity regulations are increasingly focusing on the supply chain, risk management, incident management, and relationships with external providers.

This is of particular importance in Poland today.

The amendment to the National Cybersecurity System Act, implementing NIS2, expanded the scope of entities covered by the regulation. Healthcare is now among the key sectors. Of course, this does not automatically mean that every small medical practice is subject to all KSC obligations – an analysis of the statutory criteria, including the type of activity and size of the entity, is necessary.

For entities that meet the criteria, the deadline is very specific.

Key and important entities that met the criteria on the date the amendment entered into force should be entered into the KSC List by October 3, 2026, and by April 3, 2027, implement the essential obligations arising from the new regulations, including an information security management system and incident management.

It is therefore possible to spend many months explaining to entrepreneurs what supply chain risk is within the meaning of NIS2.

Or you can show them MyDr.

One supplier. Thousands of organizations. Millions of people.

It's hard to find a more specific illustration.

Fifth die: the problem goes to the board table

There's one final step. The CEO gets a call. "We've had an incident at a supplier.".

And then it becomes clear whether cybersecurity in the organization was a real process or a binder of procedures. Management should then have answers to a few simple questions: What data did we provide to this vendor? How many people does it concern? Do we know exactly what happened? When did we learn about it? Who makes the decision to report to the Personal Data Protection Office? Do we have obligations with the National Data Protection Commission? Who contacts the vendor? Does the contract require them to provide us with the information needed for risk assessment? Can we continue operating? What will we tell customers or patients? These aren't IT questions. These are organizational management questions.

And this is where GDPR, compliance and cybersecurity meet in one place.

The problem was visible earlier

The MyDr incident comes in a sector where threats were already growing rapidly.

According to a report by the e-Health Center (CSIRT), 1,441 security incidents were handled in the healthcare sector in 2025 – over 60% more than the previous year. Computer fraud and vulnerable services were the most common, and the CeZ CSIRT also highlighted increasingly sophisticated phishing campaigns targeting medical personnel.

Another number is even more interesting.

About 29% of surveyed facility directors did not regularly review risk assessments, and only 42% participated in cybersecurity training in 2025.

This shows something important.

The biggest risk isn't always that an organization didn't buy a good enough firewall. Sometimes it's that no one at the management level asked the right questions early enough.

Single Vendor Test

Therefore, after a MyDr incident, it's worth conducting a very simple experiment within your organization. Choose one key IT vendor. The one to whom you share the most data or on whom your ability to run your business depends most.

And imagine that tomorrow at 8:00 a.m. you get a message:

"There has been a cyberattack. Your data may have been compromised."

What happens at 8:05?

What about 9:00?

Who makes the decisions?

Who calls the supplier?

Where is the contract?

Who performs the risk assessment?

Do you know what data was actually in the system?

Can you determine the number of people affected by an incident within a few hours?

Does the management know about the case?

Does the IOD know about the case?

Does the security team know what the legal department expects of them?

Does the legal department understand what it needs from IT?

If the answer to most of these questions is “we would have to check,” then you have found your most important compliance gap.

The most important lesson from MyDr

The final assessment of individual entities' liability will depend on the results of the incident analysis. The mere fact of a successful cyberattack does not yet allow us to determine who violated the law or whether the security measures implemented were insufficient.

But one lesson is already evident.

A cyberattack doesn't end with the server that's been attacked.

He moves on.

From the server to the patient's phone.

From phone to phishing message.

From IT provider to data controller.

From the administrator to the Personal Data Protection Office.

From IT to compliance.

From compliance to management.

From GDPR to KSC and NIS2.

One die flips the next.

And that is why the most important question for organizations today is not:

“Can we guarantee that we will never be attacked?”

Such a guarantee cannot be created.

A better question is:

“Are we prepared for what happens five minutes after the first dice is rolled?”

The real resilience of an organization increasingly depends on the answer to this question.

Information as of August 12, 2026. The scope and circumstances of the MyDr incident are still being determined and may be further clarified in subsequent communications from the competent authorities.

This article is for informational purposes only and does not constitute legal advice.

Author: