W Inowrocławiu, w Odwykowo-Psychiatrycznym Ośrodku Leczniczym Terapia, personel dowiedział się o drugim w tym roku wycieku danych swoich pacjentów z artykułu w serwisie Zaufana Trzecia Strona, opublikowanego wieczorem 24 września 2026 roku. Pierwszy raz padli ofiarą przy okazji afery MyDr. Tym razem winne było oprogramowanie Medyc olsztyńskiej spółki Qbusoft — system, w którym rejestruje się każdego pacjenta trafiającego na terapię uzależnień albo w kryzysie psychicznym. Atak miał miejsce w nocy z 22 na 23 sierpnia. Napastnik posługujący się pseudonimem „fingerprint" — ten sam, który wiosną tego roku ujawnił dane 18 milionów Polaków z systemu MyDr — wykorzystał lukę SQL injection, żeby wyeksportować bazę obejmującą rekordy z okresu od 1 lipca 2024 do 23 sierpnia 2026 roku. Ponad dwa lata historii leczenia setek tysięcy ludzi w jednym pliku.

Dwadzieścia dziewiątego sierpnia sprawca zapowiedział publicznie, że ma dane i zamierza je ujawnić. Qbusoft przyznał się do wykrycia incydentu dopiero 8–9 września — czternaście, piętnaście dni po ataku. Lukę załatał tego samego dnia. Na tym jednak, według dostępnych relacji, jego aktywność się skończyła. Dziennikarze wysłali pytania 22 września. Firma nie odpowiedziała. Wieczorem 25 września minister cyfryzacji Krzysztof Gawkowski powiedział wprost, że Qbusoft nie zgłosił incydentu ani do CERT Polska, ani do CSIRT CeZ, i zapowiedział „bezwzględne konsekwencje" wobec firm, które naruszają procedury bezpieczeństwa. Ta zapowiedź, choć mocna medialnie, nie zastępuje tego, czego prawo wymagało już 12 września — trzy dni po tym, jak administrator dowiedział się o naruszeniu.

Fingerprint wraca — i tym razem trafia w bardziej wrażliwe miejsce

Powtarzalność tego ataku jest sama w sobie wiadomością. Fingerprint nie zniknął po MyDr, nie zmienił metody i nie zmienił branży. Wybrał kolejnego dostawcę oprogramowania dla polskiej ochrony zdrowia, znalazł tę samą klasę podatności — wstrzyknięcie SQL — i powtórzył scenariusz niemal jeden do jednego: cichy dostęp, zapowiedź publikacji, potem ujawnienie danych, gdy firma nie zareagowała wystarczająco szybko lub przejrzyście. To wzorzec, nie przypadek, a wzorce w cyberbezpieczeństwie oznaczają, że kolejny dostawca już jest na liście.

Medyc to nie niszowy produkt. Qbusoft dostarcza go do rejestracji pacjentów, harmonogramowania wizyt i dokumentacji medycznej w setkach placówek — przychodniach, poradniach specjalistycznych, ośrodkach leczenia uzależnień, oddziałach psychiatrycznych. Centrum e-Zdrowia szacuje, że z systemami zasilanymi przez infrastrukturę, do której podłączony jest Medyc, korzysta ponad pół miliona pacjentów. Prasa, licząc po około dziesięciu tysiącach wizyt dziennie obsługiwanych przez system, mówi ostrożnie o „ponad milionie osób". Sami sprawcy twierdzą, że mają dane pięciu milionów. Prawda leży prawdopodobnie gdzieś pomiędzy, ale nawet dolna granica tych szacunków czyni z tego jeden z większych wycieków sektora zdrowia w tym roku — mniejszy niż MyDr, ale dotykający ludzi w sytuacji znacznie bardziej wrażliwej niż zwykła wizyta u internisty.

Co istotne dla każdego administratora korzystającego z zewnętrznego oprogramowania: ten sam ośrodek w Inowrocławiu ucierpiał w obu wyciekach — MyDr i Medyc — mimo że to dwaj różni dostawcy, dwa różne systemy i dwie różne umowy powierzenia. Placówka nie zrobiła nic złego w sensie operacyjnym. Padła ofiarą dlatego, że powierzyła dane dwóm różnym firmom, z których żadna, jak się okazuje, nie miała procesu bezpiecznego programowania odpornego na klasyczną, znaną od dekad podatność.

Anatomia ataku: jak SQL injection otworzył bazę Medyc

Wstrzyknięcie SQL to jedna z najstarszych i najlepiej opisanych klas podatności w informatyce — figuruje na szczycie list OWASP od ponad dwudziestu lat, a mechanizmy jej zapobiegania (zapytania parametryzowane, ORM-y z bezpiecznym escapowaniem, walidacja wejścia) są standardem w każdym poważnym kursie programowania. To właśnie dlatego wiadomość o kolejnym takim incydencie w systemie obsługującym dane medyczne budzi więcej niż zwykłe zaniepokojenie — sugeruje, że proces wytwarzania oprogramowania u dostawcy nie przechodził przez żaden systematyczny przegląd bezpieczeństwa kodu.

W przypadku Medyc atakujący uzyskał dostęp do mechanizmu eksportu danych pozbawionego ograniczeń czasowych — mógł pobrać rekordy sprzed dwóch lat równie łatwo jak te z bieżącego tygodnia. Część pól była wprawdzie szyfrowana, ale — jak ustalili dziennikarze Zaufanej Trzeciej Strony na podstawie własnej analizy wycieku — struktura szyfrowania okazała się na tyle słaba, że dane dawało się odtworzyć w postaci jawnej stosunkowo niewielkim nakładem pracy. To rozróżnienie ma znaczenie prawne: RODO w art. 34 ust. 3 lit. a przewiduje zwolnienie z obowiązku zawiadamiania osób, których dane dotyczą, jeżeli administrator wdrożył odpowiednie środki techniczne — w tym takie, które czynią dane niezrozumiałymi dla nieuprawnionych, na przykład silne szyfrowanie. Szyfrowanie, które można złamać w rozsądnym czasie, tej przesłanki nie spełnia. Qbusoft nie może więc powoływać się na nią, żeby uniknąć powiadomienia pacjentów wprost.

Skradzione dane obejmują imię, nazwisko, numer PESEL, adres zamieszkania, numer telefonu, adres e-mail oraz karty informacyjne leczenia szpitalnego — dokumenty, które w polskim systemie ochrony zdrowia zawierają rozpoznanie, przebieg leczenia i zalecenia. W przypadku placówek psychiatrycznych i odwykowych to dane szczególnej kategorii w rozumieniu art. 9 RODO w najbardziej wrażliwej postaci, jaką ten przepis w ogóle przewiduje.

Dwa lata bez alarmu: co mówi o rynku fakt, że nikt tej luki nie zauważył

Najbardziej niepokojącym elementem tej sprawy nie jest sama podatność, tylko czas, przez jaki pozostawała niezauważona. Eksport bez ograniczeń czasowych, pozwalający pobrać dane sprzed dwóch lat, oznacza, że mechanizm ten działał od dawna, zanim ktokolwiek go wykorzystał w złych intencjach — a przynajmniej zanim ktokolwiek to zauważył i zgłosił. W dojrzałym procesie wytwarzania oprogramowania medycznego testy penetracyjne i systematyczny przegląd kodu pod kątem podatności wstrzyknięcia SQL są elementem podstawowym, nie opcjonalnym — dokładnie to zakłada norma ISO 27001 w załączniku A, w obszarach dotyczących bezpiecznego cyklu wytwarzania oprogramowania (A.8.25), zarządzania podatnościami technicznymi (A.8.8) oraz testowania bezpieczeństwa (A.8.29). Jeżeli Qbusoft rzeczywiście nie prowadził regularnych testów penetracyjnych swojego produktu, to znaczy, że setki placówek medycznych przez dwa lata ufały systemowi, którego bezpieczeństwa nikt niezależnie nie zweryfikował.

To pytanie ma też wymiar regulacyjny wykraczający poza RODO. Unijne rozporządzenie Cyber Resilience Act, które opisywaliśmy przy okazji obowiązków producentów produktów z elementami cyfrowymi, nakłada na producentów oprogramowania obowiązek raportowania aktywnie wykorzystywanych podatności do odpowiednich zespołów CSIRT w ściśle określonych terminach — a docelowo także obowiązek utrzymywania procesu zarządzania podatnościami przez cały cykl życia produktu. Sprawa Medyc pokazuje dokładnie ten scenariusz, przed którym CRA ma chronić: dostawca oprogramowania krytycznego dla funkcjonowania sektora ochrony zdrowia, u którego podatność klasy szkoleniowej pozostaje aktywna przez lata, a proces reagowania na jej wykorzystanie — powiadomienie właściwych służb — zawodzi w praktyce, mimo istnienia przepisów, które nakazują to zrobić.

Piętnaście dni ciszy: co Qbusoft miał obowiązek zrobić, a czego nie zrobił

Artykuł 33 ust. 1 RODO nie zostawia miejsca na interpretację. Administrator, który dowiedział się o naruszeniu ochrony danych osobowych, zgłasza je organowi nadzorczemu „bez zbędnej zwłoki — jeżeli to wykonalne, nie później niż w terminie 72 godzin po stwierdzeniu naruszenia". Zegar startuje w momencie powzięcia wiedzy o incydencie, nie w momencie ustalenia jego pełnej skali. Jeśli Qbusoft dowiedział się o ataku 8 lub 9 września, termin na zgłoszenie do Prezesa UODO minął najpóźniej 12 września. Dziś, 25 września, mija już trzynasty dzień zwłoki wobec tego obowiązku — a według słów ministra Gawkowskiego zgłoszenia wciąż nie ma, ani do CERT Polska, ani do CSIRT CeZ, właściwego dla sektora ochrony zdrowia zespołu reagowania na incydenty.

Trzeba tu rozdzielić dwie role, które w tej sprawie łatwo pomylić. Qbusoft dostarcza oprogramowanie placówkom medycznym — w większości przypadków działa więc jako podmiot przetwarzający w rozumieniu art. 28 RODO, a administratorami danych pozostają same przychodnie, ośrodki i szpitale, które zawarły z nim umowę powierzenia. To administrator, czyli placówka lecznicza, ma pierwotny obowiązek zgłoszenia naruszenia do UODO z art. 33. Ale art. 33 ust. 2 nakłada równoległy obowiązek na podmiot przetwarzający: musi on zgłosić naruszenie administratorowi „bez zbędnej zwłoki po stwierdzeniu naruszenia". Jeśli Qbusoft rzeczywiście nie poinformował placówek korzystających z Medyc o tym, że ich dane wyciekły, każda z nich straciła własny zegar 72-godzinny bez swojej winy — i każda z nich, gdy w końcu się dowie, i tak będzie musiała zgłosić naruszenie UODO, tłumacząc się z opóźnienia, którego nie spowodowała.

To dokładnie ten sam mechanizm odpowiedzialności, który opisywaliśmy przy okazji kary UODO dla operatora logistycznego korzystającego z podwykonawcy bez odpowiedniego nadzoru nad umową powierzenia — administrator odpowiada za wybór i nadzór nad przetwarzającym, nawet jeśli to przetwarzający zawinił operacyjnie. Kara może więc spaść na placówkę medyczną, mimo że błąd popełniono w kodzie napisanym przez zewnętrzną firmę programistyczną.

Dane szczególnej kategorii: dlaczego ten wyciek to inna liga niż PESEL z rejestracji

Nie każdy wyciek PESEL-u znaczy to samo. Artykuł 9 RODO wprowadza podwyższony reżim ochrony dla danych dotyczących zdrowia, a orzecznictwo i wytyczne Europejskiej Rady Ochrony Danych od dawna podkreślają, że informacja o leczeniu psychiatrycznym czy terapii uzależnień niesie ryzyko krzywdy nieporównywalne z ujawnieniem samego numeru identyfikacyjnego. Osoba, której dane z karty informacyjnej leczenia w ośrodku odwykowym trafią w niepowołane ręce, może stracić pracę, zostać wykluczona towarzysko, stać się celem szantażu albo dyskryminacji przy ubieganiu się o kredyt czy ubezpieczenie. To nie jest ryzyko teoretyczne — to konkretna, przewidywalna szkoda, którą RODO każe administratorowi brać pod uwagę już na etapie oceny ryzyka z art. 32.

Właśnie dlatego przy naruszeniach dotyczących danych szczególnej kategorii próg do zwolnienia z obowiązku zawiadomienia osób fizycznych z art. 34 jest wyższy niż przy zwykłym wycieku danych kontaktowych. Administrator musi wykazać, że naruszenie „nie skutkuje wysokim ryzykiem naruszenia praw i wolności" — a trudno o silniejszy kontrprzykład niż baza obejmująca dokumentację z leczenia uzależnień i zaburzeń psychicznych, wyeksportowana w całości przez nieuprawnioną osobę i już zapowiedziana publicznie przez atakującego jako gotowa do ujawnienia. W tym stanie faktycznym zwolnienie z obowiązku zawiadomienia pacjentów praktycznie nie wchodzi w grę — placówki korzystające z Medyc, gdy tylko potwierdzą zakres własnych danych w wycieku, powinny przygotować się na indywidualne zawiadomienie każdej dotkniętej osoby, nie tylko komunikat zbiorczy na stronie internetowej.

Kto tu naprawdę odpowiada: umowa powierzenia i łańcuch dostawców w ochronie zdrowia

Największym błędem, jaki może dziś popełnić dyrektor przychodni czy kierownik ośrodka terapeutycznego korzystającego z Medyc, jest założenie, że skoro to Qbusoft napisał wadliwy kod, to Qbusoft poniesie konsekwencje. Prawo działa inaczej. RODO pozwala UODO ukarać zarówno administratora, jak i podmiot przetwarzający bezpośrednio — ale to administrator odpowiada wobec pacjentów, wobec opinii publicznej i w pierwszej kolejności wobec organu nadzorczego za to, że w ogóle powierzył dane firmie, która nie zapewniła „wystarczających gwarancji wdrożenia odpowiednich środków technicznych i organizacyjnych", jak wymaga tego art. 28 ust. 1 RODO.

Ta gwarancja nie jest formalnością podpisywaną raz i odkładaną do szuflady. Prawidłowa umowa powierzenia powinna zawierać konkretne zobowiązania dostawcy do testowania bezpieczeństwa kodu, zarządzania podatnościami i — kluczowe w tej sprawie — natychmiastowego informowania administratora o każdym podejrzeniu naruszenia, bez czekania na pełne ustalenie skali incydentu. Powinna też dawać administratorowi realne prawo audytu, a nie tylko papierowe oświadczenie dostawcy o zgodności. Placówki, które dziś sięgną po swoje umowy z Qbusoft i innymi dostawcami oprogramowania medycznego, w wielu przypadkach odkryją zapisy ogólnikowe, bez konkretnych terminów powiadomienia i bez mechanizmu weryfikacji. To dokładnie ten typ luki, który UODO karze niezależnie od tego, czy sam wyciek nastąpił z winy administratora, czy jego dostawcy.

Warto też pamiętać, że łańcuch odpowiedzialności w ochronie zdrowia rzadko kończy się na jednym poziomie. Centrum e-Zdrowia, jako operator krajowej infrastruktury teleinformatycznej systemu ochrony zdrowia, samo pełni funkcję zbliżoną do centralnego węzła, przez który przepływają dane z wielu systemów dziedzinowych, w tym Medyc. Posiadanie własnego zespołu CSIRT CeZ pokazuje, że regulator dostrzega ten problem strukturalnie — ale struktura nadzoru nie zastąpi podstawowej higieny bezpiecznego programowania po stronie każdego pojedynczego dostawcy.

Minister grozi, ustawa czeka: luka wokół dostawców oprogramowania medycznego

Zapowiedź ministra Gawkowskiego o „bezwzględnych konsekwencjach" brzmi stanowczo, ale w polskim porządku prawnym brakuje dziś dedykowanego, twardego mechanizmu sankcyjnego wobec dostawców oprogramowania medycznego jako takich — poza ogólnym reżimem RODO i przepisami o ochronie danych w systemie informacji medycznej. Co ciekawe, CSIRT CeZ wspólnie z Ministerstwem Zdrowia wydały zalecenia bezpieczeństwa dla dostawców systemów medycznych już 16 września 2026 roku, na dziewięć dni przed ujawnieniem sprawy Medyc — dowód, że regulator widział rosnące ryzyko w tym segmencie rynku jeszcze zanim wybuchła kolejna afera.

Tu wchodzi w grę nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS-2. Sektor ochrony zdrowia figuruje wprost wśród sektorów kluczowych objętych reżimem UKSC, a duże podmioty lecznicze korzystające z systemów takich jak Medyc mają dziś obowiązek — do 3 października 2026 roku — dokonać samoidentyfikacji jako podmiot kluczowy lub ważny w wykazie prowadzonym przez ministra właściwego do spraw informatyzacji. Konsekwencją tego wpisu jest między innymi obowiązek zarządzania ryzykiem w łańcuchu dostaw — czyli formalnej oceny bezpieczeństwa dostawców IT, w tym producentów oprogramowania medycznego, zanim dojdzie do incydentu, a nie po nim. Placówka, która dziś rejestruje się w wykazie KSC, powinna od razu potraktować sprawę Medyc jako gotowy materiał dowodowy na to, dlaczego ocena dostawców nie może być formalnością.

Sam Qbusoft — jako spółka dostarczająca oprogramowanie krytyczne dla funkcjonowania sektora zdrowia — również może podlegać obowiązkom UKSC, jeśli skala jego działalności lub charakter świadczonych usług kwalifikuje go jako podmiot ważny w kategorii usług ICT. To pytanie, na które odpowiedzi jeszcze nie znamy, ale które Ministerstwo Cyfryzacji z pewnością już sobie zadaje, skoro minister osobiście zabrał głos w tej sprawie.

Dopóki jednak nie zapadnie ostateczna kwalifikacja Qbusoft w wykazie, cała odpowiedzialność regulacyjna i tak spoczywa na placówkach medycznych jako administratorach. To one, nie ich dostawca oprogramowania, muszą do 3 października zdecydować, czy podlegają samoidentyfikacji jako podmiot kluczowy lub ważny, i to one poniosą pierwsze konsekwencje opóźnionego zgłoszenia naruszenia — niezależnie od tego, czy winny jest kod napisany w Olsztynie, czy procedura wewnętrzna w konkretnej przychodni.

Co powinny zrobić placówki korzystające z Medyc — i co powinien zrobić każdy administrator

Placówka, która korzysta z systemu Medyc, powinna dziś działać na dwóch torach jednocześnie, bez czekania na oficjalne stanowisko dostawcy. Pierwszy tor to potwierdzenie zakresu własnej ekspozycji: należy wystąpić do Qbusoft z formalnym pisemnym zapytaniem o to, czy dane konkretnej placówki znalazły się w wyeksportowanym zbiorze, z żądaniem odpowiedzi w określonym, krótkim terminie i z zastrzeżeniem, że brak odpowiedzi zostanie potraktowany jako potwierdzenie naruszenia obowiązku z art. 33 ust. 2 RODO. Drugi tor to własne zgłoszenie do UODO — niezależnie od tego, czy dostawca odpowie. Jeśli placówka poweźmie uzasadnione podejrzenie, że jej dane mogły zostać naruszone, termin 72 godzin biegnie od tego momentu, nie od potwierdzenia przez Qbusoft.

Warto też od razu przejrzeć umowę powierzenia pod kątem trzech elementów: czy zawiera konkretny, liczony w godzinach termin powiadomienia administratora przez przetwarzającego; czy przewiduje prawo do audytu bezpieczeństwa kodu i infrastruktury dostawcy; oraz czy określa odpowiedzialność finansową dostawcy za szkody wynikłe z jego zaniedbań, w tym za kary nałożone na administratora z powodu opóźnionego zgłoszenia. Brak któregokolwiek z tych elementów to sygnał, że umowę należy renegocjować, zanim dojdzie do kolejnego incydentu — a przy tempie, w jakim fingerprint atakuje kolejnych dostawców oprogramowania medycznego, „kolejny incydent" nie jest pytaniem retorycznym.

Placówki, których dane nie znalazły się w tym konkretnym wycieku, nie powinny czuć fałszywego spokoju. Ten sam mechanizm — słabo zabezpieczony eksport danych, podatność klasy SQL injection, brak systematycznego testowania bezpieczeństwa kodu — najprawdopodobniej występuje w dziesiątkach innych systemów dziedzinowych używanych w polskiej ochronie zdrowia, administracji publicznej i sektorze prywatnym. Różnica między Medyc a bezpiecznym systemem nie leży w tym, czy podatność istnieje, tylko w tym, czy ktoś ją znalazł i zgłosił, zanim znalazł ją ktoś taki jak fingerprint.

Warto również zapytać dostawcę wprost, kiedy ostatni raz jego produkt przechodził niezależny test penetracyjny i czy raport z tego testu jest dostępny do wglądu administratora. To pytanie, które jeszcze rok temu mogło brzmieć jak nadmierna podejrzliwość, dziś — po MyDr i po Medyc — jest elementarną należytą starannością. Administrator, który go nie zadał, a potem tłumaczy się przed UODO brakiem wiedzy o stanie zabezpieczeń dostawcy, usłyszy odpowiedź znaną już z wcześniejszych decyzji Prezesa UODO: brak dowodu na należytą weryfikację dostawcy traktowany jest tak samo surowo, jak brak własnych zabezpieczeń.

Lekcja, która wykracza poza ochronę zdrowia

Historia Medyc jest pouczająca dla każdego administratora, nie tylko dla dyrektorów przychodni. Pokazuje trzy rzeczy, które w praktyce audytowej Fib.Code powtarzają się z uderzającą regularnością. Po pierwsze, bezpieczeństwo danych osobowych nie kończy się na własnej infrastrukturze — jest tak silne, jak najsłabszy dostawca w łańcuchu, a większość organizacji nie ma dziś realnej wiedzy o tym, jak wygląda proces bezpiecznego programowania u swoich dostawców IT. Po drugie, umowa powierzenia napisana pod kątem zgodności formalnej, a nie realnej egzekwowalności, nie chroni administratora przed karą — chroni go najwyżej przed roszczeniem regresowym, i to pod warunkiem, że w ogóle da się wykazać winę dostawcy. Po trzecie, zegar 72 godzin z art. 33 RODO nie czeka na wygodny moment ani na potwierdzenie przez dostawcę — biegnie od chwili, w której administrator sam poweźmie uzasadnione podejrzenie, i to administrator ponosi ryzyko, jeśli zwleka, tłumacząc się brakiem informacji od podwykonawcy.

Dlaczego z Fib.Code

Zajmujemy się dokładnie tym przecięciem kompetencji, które ujawnia sprawa Medyc: bezpieczeństwem informacji rozumianym jednocześnie jako zgodność z RODO i jako realny stan techniczny systemów, z którymi pracuje nasz klient. Nasi audytorzy przeglądają nie tylko treść umów powierzenia, ale i praktykę ich wykonywania — sprawdzają, czy zapisy o powiadamianiu w określonym terminie mają odpowiednik w procedurze operacyjnej dostawcy, czy prawo do audytu jest realnie wykonalne, i czy administrator w ogóle wie, jakie dane i w jakim zakresie powierzył konkretnemu podmiotowi.

Pracujemy według trzech zasad, które w tej sprawie widać jak na dłoni: po pierwsze, odpowiedzialność za bezpieczeństwo danych nie kończy się na granicy własnej organizacji, więc łańcuch dostaw trzeba oceniać tak samo rygorystycznie jak systemy wewnętrzne; po drugie, procedura zgłoszenia naruszenia musi być przećwiczona, zanim będzie potrzebna, bo w chwili kryzysu nikt nie czyta procedur po raz pierwszy; po trzecie, zgodność formalna bez weryfikacji technicznej to iluzja bezpieczeństwa, którą UODO rozpoznaje równie szybko jak my.

Efektem naszej pracy dla placówek medycznych, spółek komunalnych i administracji samorządowej jest zawsze konkretny dokument, a nie ogólna rekomendacja: zaktualizowana umowa powierzenia z twardymi terminami i sankcjami, procedura reagowania na naruszenie z przypisanymi rolami i gotowymi wzorami zgłoszeń do UODO, oraz rejestr dostawców IT z oceną ryzyka każdego z nich — dokładnie to, czego zabrakło w łańcuchu Qbusoft–placówki medyczne–pacjenci.

Co zrobić w ten weekend i poniedziałek

W ten weekend warto zrobić jedną rzecz: wypisać na kartce wszystkich dostawców oprogramowania, którym powierza się dane osobowe — od systemu medycznego czy kadrowo-płacowego, przez narzędzia księgowe, po dostawców poczty elektronicznej i chmury. W poniedziałek rano skonfrontować tę listę z umowami powierzenia i sprawdzić w każdej z nich jedno pytanie: w ilu godzinach dostawca zobowiązał się poinformować nas o naruszeniu, i czy w ogóle to zrobił choć raz w ostatnim roku. Jeśli odpowiedź brzmi „nie wiadomo" albo „umowa tego nie precyzuje", to jest dokładnie ten sygnał, po którym warto zwołać spotkanie z inspektorem ochrony danych i osobą odpowiedzialną za IT — najpóźniej w tym tygodniu, nie przy okazji następnego audytu.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: wyciek danych z systemu MyDr, kara UODO za umowę powierzenia bez nadzoru nad podwykonawcą, wykaz KSC — termin 3 października 2026.