GDPR, фішинг, KSC/NIS2 та відповідальність ради директорів – чому кібератака не закінчується на атакованому сервері.

Уявімо собі SMS-повідомлення:

"Доброго ранку. З огляду на ваш нещодавній візит до клініки, будь ласка, увійдіть, щоб підтвердити свій рецепт. Посилання активне протягом 24 годин."

Назва правильна. Заклад правильний. Візит справді відбувся. Пацієнт справді нещодавно отримав рецепт.

Ви б клацнули?

Саме в цьому полягає проблема витоку медичних даних. Кіберзлочинцям більше не потрібно здогадуватися, в якому банку у нас рахунок, чи чекаємо ми на посилку, чи є ми клієнтом певного перевізника. Якщо у них є реальні дані про наше здоров'я, зустрічі та рецепти, вони можуть створити повідомлення, яке не схоже на фішингову аферу.

Це схоже на реальність.

І саме тому інцидент з MyDr — це більше, ніж просто черговий «витік даних». Це приклад ефекту доміно в кібербезпеці.

Один елемент руйнується – система ІТ-провайдера. За мить з проблемами стикаються пацієнти. Потім медичні заклади. Потім співробітники із захисту даних, відділи комплаєнсу та ради директорів. Нарешті, з'являються регуляторні органи, регламенти GDPR та нові зобов'язання, що виникають у зв'язку з імплементацією директиви NIS2 Національною радою інформаційної безпеки (KSC).

Одна кібератака. Кілька різних криз.

Перший куб: майже 19 мільйонів людей

Масштаби інциденту важко осягнути. Згідно з інформацією, опублікованою 12 серпня 2026 року, інцидент, пов'язаний із системою MyDr, міг вплинути на дані до 19 мільйонів поляків. ЗМІ повідомляють про базу даних обсягом приблизно 2 ТБ, яка нібито містила, серед іншого, номери PESEL, інформацію про рецепти, інформацію про призначення прийомів та історію хвороби. Очікується, що системою користуватимуться приблизно 12 000 медичних закладів. Голова Управління захисту персональних даних (UODO) того ж дня звернувся до цього питання. UODO посилається на повідомлення про витік даних, що стосується «майже 19 мільйонів поляків», і нагадує адміністраторам, які користуються MyDr, про їхні власні обов'язки.

Варто діяти обережно. Повний масштаб інциденту все ще встановлюється, тому інформація про кількість людей, обсяг скомпрометованих даних та технічний перебіг атаки може ще оновлюватися.

Але вже достатньо відомо, щоб винести важливий урок. Найбільшою помилкою було б ставитися до цього інциденту як до проблеми однієї технологічної компанії.

Бо перша кісточка доміно вже вдаряє об наступну.

Другий куб: фішинг, хто знає правду

Більшість із нас навчилися розпізнавати прості фішингові схеми. «Вашу посилку неможливо доставити». «Ваш обліковий запис буде заблоковано». «Сплатіть додатково 1,49 злотих».

Проблема починається, коли повідомлення містить інформацію, яка дійсно збігається. Уявіть собі кіберзлочинця, який може пов’язати ім’я, номер телефону або номер PESEL з інформацією про певний заклад, прийом чи лікування. Йому не потрібно писати мільйонам випадкових людей.

Він може написати конкретній людині. І він може використати щось, що зміцнить довіру краще, ніж логотип банку — справжню частинку їхнього життя.

Таким чином, наслідки великого витоку не закінчуються копіюванням бази даних. Викрадена інформація може використовуватися місяцями або роками для створення набагато надійніших атак соціальної інженерії. Посилаючись безпосередньо на інцидент MyDr, Управління захисту персональних даних (UODO) попередило тих, хто потенційно постраждав від витоку, про текстові повідомлення та електронні листи, які можуть являти собою спроби фішингу, та вказало на можливість блокування їхніх номерів PESEL.

Це особливо важливо в охороні здоров'я. Медична інформація має дві цінності. Перша очевидна: вона надзвичайно конфіденційна. Друга менш очевидна: вона надійна. Якщо злочинець знає правду про наші стосунки з лікарем чи медичним закладом, він може використати її як ключ до розблокування додаткових даних, онлайн-банкінгу чи інших послуг.

Тому після такого витоку питання не просто: «Які дані були розкриті?»

Вам також потрібно запитати: «Що ви можете зробити з цими даними?»

Це зовсім інший спосіб мислення про ризик.

Третій куб: «Це витік у нашого постачальника» не є стратегією GDPR

Саме тут історія стає особливо цікавою для бізнесу. Медичний заклад, зрештою, може стверджувати, що його сервери не були атаковані; це зовнішня система, а дані зберігалися у постачальника. У повсякденному розумінні це може звучати логічно.

Однак GDPR не вирішує цю проблему.

Управління із захисту персональних даних (UODO) чітко нагадало контролерам, які довіряють MyDr обробку даних, що вони повинні провести аналіз ризиків прав і свобод фізичних осіб і визначити, чи вимагає конкретне порушення повідомлення відповідному органу та повідомлення постраждалих осіб. У другій заяві управління висловило це ще простіше: обов'язок повідомляти постраждалих осіб покладається на контролерів, які користуються послугами MyDr.

Це один із найважливіших уроків цієї справи.

Обробку даних можна доручити. Однак неможливо довірити комусь усю свою відповідальність. Тому адміністратор повинен визначити, чи постраждали його пацієнти від інциденту, яка інформація могла бути розкрита, які ризики це може становити та які дії слід вжити.

І годинник, можливо, вже цокає.

GDPR передбачає, що у разі порушення, яке потребує повідомлення, контролер повинен повідомити наглядовий орган без зайвої затримки, і, якщо можливо, не пізніше ніж через 72 години після виявлення порушення. Якщо ризик для фізичних осіб є високим, також виникає обов'язок повідомляти їх. У випадку медичних даних оцінка може бути особливо вимогливою. GDPR прямо згадує, серед іншого, про потенціал дискримінації, соціального остракізму або порушення особистих прав внаслідок розкриття даних про здоров'я. Таким чином, одне порушення системи постачальника може ініціювати тисячі окремих процесів прийняття рішень з боку його клієнтів.

І це справжній ефект доміно.

Четвертий кубик: MyDr показує, чому було створено NIS2

Фраза «безпека ланцюга поставок» звучить абстрактно.

Поки не станеться щось на кшталт MyDr.

Компанія може ідеально захистити власні комп'ютери, найняти адміністраторів, впровадити багатофакторну автентифікацію (MFA) та навчити співробітників. Потім вона передає значну частину своїх критично важливих даних зовнішньому постачальнику. З цього моменту рівень її безпеки більше не залежить виключно від компанії. Він також залежить від безпеки об'єкта, який вона часто навіть не сприймає як частину власної інфраструктури. Саме тому правила кібербезпеки все більше зосереджуються на ланцюжку поставок, управлінні ризиками, управлінні інцидентами та взаємодії із зовнішніми постачальниками.

Це особливо важливо в сучасній Польщі.

Поправка до Закону про національну систему кібербезпеки, що імплементує NIS2, розширила коло суб'єктів господарювання, на яких поширюється дія цього регламенту. Охорона здоров'я тепер є одним з ключових секторів. Звичайно, це не означає автоматично, що кожна невелика медична практика підлягає всім зобов'язанням KSC – необхідний аналіз законодавчих критеріїв, включаючи вид діяльності та розмір суб'єкта господарювання.

Для організацій, які відповідають критеріям, термін є дуже конкретним.

Ключові та важливі суб'єкти господарювання, які відповідали критеріям на дату набрання чинності поправкою, повинні бути внесені до Переліку KSC до 3 жовтня 2026 року, а до 3 квітня 2027 року виконати основні зобов'язання, що випливають з нових правил, включаючи систему управління інформаційною безпекою та управління інцидентами.

Тому можна витратити багато місяців, пояснюючи підприємцям, що таке ризик ланцюга поставок у значенні NIS2.

Або ви можете показати їм MyDr.

Один постачальник. Тисячі організацій. Мільйони людей.

Важко знайти більш конкретну ілюстрацію.

П'ятий кубик: проблема переходить на ігровий стіл

Залишається ще один крок. Генеральному директору телефонують. «У нас стався інцидент у постачальника».

І тоді стає зрозуміло, чи була кібербезпека в організації реальним процесом, чи зв'язком процедур. Керівництво повинно мати відповіді на кілька простих запитань: які дані ми надали цьому постачальнику? Скільки людей це стосується? Чи знаємо ми точно, що сталося? Коли ми про це дізналися? Хто приймає рішення про звітування до Управління захисту персональних даних? Чи маємо ми зобов'язання перед Національною комісією із захисту даних? Хто зв'язується з постачальником? Чи вимагає контракт від них надання нам інформації, необхідної для оцінки ризиків? Чи можемо ми продовжувати роботу? Що ми скажемо клієнтам чи пацієнтам? Це не питання ІТ. Це питання управління організацією.

І саме тут зустрічаються GDPR, відповідність вимогам та кібербезпека.

Проблема була помітна раніше

Інцидент MyDr стався в секторі, де загрози вже стрімко зростали.

Згідно зі звітом Центру електронної охорони здоров'я (CSIRT), у 2025 році в секторі охорони здоров'я було оброблено 1441 інцидент безпеки – понад 60% більше, ніж у попередньому році. Найпоширенішими були комп'ютерне шахрайство та вразливі сервіси, а CeZ CSIRT також виявив дедалі складніші фішингові кампанії, спрямовані на медичний персонал.

Інше число ще цікавіше.

Близько 29% опитаних директорів установ не регулярно переглядали оцінки ризиків, і лише 42% взяли участь у навчанні з кібербезпеки у 2025 році.

Це показує щось важливе.

Найбільший ризик не завжди полягає в тому, що організація не придбала достатньо хороший брандмауер. Іноді це те, що ніхто на рівні керівництва не поставив правильних запитань достатньо рано.

Тест одного постачальника

Тому після інциденту MyDr варто провести дуже простий експеримент у вашій організації. Виберіть одного ключового ІТ-постачальника. Того, з ким ви ділитеся найбільше даними або від якого найбільше залежить ваша здатність вести бізнес.

А уявіть, що завтра о 8:00 ранку ви отримаєте повідомлення:

"Сталася кібератака. Ваші дані могли бути скомпрометовані."

Що відбувається о 8:05?

А як щодо 9:00?

Хто приймає рішення?

Хто телефонує постачальнику?

Де ж контракт?

Хто проводить оцінку ризиків?

Чи знаєте ви, які дані насправді були в системі?

Чи можете ви визначити кількість людей, які постраждали від інциденту, протягом кількох годин?

Чи знає керівництво про цю справу?

Чи знає IOD про цю справу?

Чи знає команда безпеки, чого від них очікує юридичний відділ?

Чи розуміє юридичний відділ, що йому потрібно від ІТ-відділу?

Якщо відповідь на більшість цих запитань — «нам довелося б перевірити», то ви знайшли свою найважливішу прогалину у відповідності вимогам.

Найважливіший урок від MyDr

Остаточна оцінка відповідальності окремих суб'єктів залежатиме від результатів аналізу інциденту. Сам факт успішної кібератаки ще не дозволяє визначити, хто порушив закон, чи були вжиті заходи безпеки недостатніми.

Але один урок вже очевидний.

Кібератака не закінчується атакою на сервері.

Він рухається далі.

З сервера на телефон пацієнта.

З телефону у фішингове повідомлення.

Від ІТ-провайдера до контролера даних.

Від адміністратора до Управління захисту персональних даних.

Від ІТ до комплаєнсу.

Від дотримання вимог до управління.

Від GDPR до KSC та NIS2.

Один кубик перевертає наступний.

І саме тому найважливіше питання для організацій сьогодні не полягає в наступному:

«Чи можемо ми гарантувати, що на нас ніколи не нападуть?»

Таку гарантію створити неможливо.

Краще питання:

«Чи готові ми до того, що станеться через п'ять хвилин після кидання першого кубика?»

Реальна стійкість організації дедалі більше залежить від відповіді на це питання.

Інформація станом на 12 серпня 2026 року. Масштаби та обставини інциденту MyDr все ще визначаються та можуть бути додатково уточнені в наступних повідомленнях від компетентних органів.

Ця стаття призначена лише для ознайомлення та не є юридичною консультацією.

Автор: