Cyberatak na dostawcę usług informatycznych może w ciągu kilku godzin stać się problemem setek albo tysięcy jego klientów. Coraz więcej przedsiębiorstw nie przechowuje danych wyłącznie we własnej infrastrukturze, lecz korzysta z zewnętrznych systemów SaaS, hostingu, usług chmurowych, platform do obsługi klientów, systemów księgowych, medycznych, CRM, ERP i rozwiązań dostarczanych przez software house’y. Taki model pozwala ograniczyć koszty i korzystać z technologii, których przedsiębiorca nie musiałby samodzielnie rozwijać. Jednocześnie powoduje jednak koncentrację ryzyka. Jeżeli atakujący uzyska dostęp do infrastruktury jednego dużego dostawcy, może uzyskać informacje należące do bardzo wielu niezależnych administratorów danych.

Dobrym przykładem skali takiego ryzyka stał się cyberatak na systemy firmy MyDr, dostawcy oprogramowania wykorzystywanego przez placówki ochrony zdrowia. Ministerstwo Cyfryzacji poinformowało 12 sierpnia 2026 r., że doszło do nieuprawnionego dostępu do historycznych danych gabinetów lekarskich przechowywanych w systemach spółki. Według informacji przekazanych przez administrację publiczną zdarzenie mogło dotyczyć około 18,8 mln osób i ponad 12 tys. placówek medycznych. Jednocześnie wskazano, że incydent nie naruszył centralnych usług e-zdrowia i nie zakłócił bieżącej możliwości świadczenia opieki zdrowotnej.

Sprawa MyDr jest interesująca nie tylko ze względu na skalę. Pokazuje przede wszystkim problem prawny, który będzie pojawiał się coraz częściej również poza sektorem medycznym. Jeżeli dane klienta wyciekają z infrastruktury zewnętrznego dostawcy IT, kto właściwie odpowiada za zdarzenie? Czy odpowiedzialność ponosi wyłącznie software house lub operator SaaS, skoro atak nastąpił na jego serwery? Czy klient nadal odpowiada wobec osób, których dane zostały ujawnione? Czy dostawca może ograniczyć odpowiedzialność w umowie do wartości kilku miesięcznych abonamentów? Czy klient może żądać zwrotu kosztów obsługi incydentu, zawiadamiania osób, doradców prawnych i informatyki śledczej? Odpowiedzi zależą od konstrukcji konkretnej relacji, ale jedną rzecz warto podkreślić od początku: cyberatak na podwykonawcę nie powoduje automatycznie, że klient przestaje odpowiadać za bezpieczeństwo powierzonych danych.

Atak na dostawcę nie oznacza automatycznego przeniesienia odpowiedzialności

W praktyce biznesowej często pojawia się intuicyjne założenie, że skoro incydent wydarzył się „u dostawcy”, to właśnie dostawca powinien odpowiadać za wszystkie konsekwencje. Z technicznego punktu widzenia może to być zrozumiałe. To przecież jego infrastruktura została zaatakowana, jego konto administracyjne przejęto albo jego zabezpieczenia zostały ominięte. Prawo ochrony danych osobowych nie opiera się jednak na tak prostym podziale.

W typowym modelu SaaS przedsiębiorca korzystający z systemu pozostaje administratorem danych swoich klientów, pacjentów, pracowników albo użytkowników, natomiast dostawca technologiczny działa jako podmiot przetwarzający. To administrator decyduje, po co dane są przetwarzane i w jakim podstawowym celu. Procesor przetwarza je natomiast w jego imieniu i zgodnie z instrukcjami wynikającymi między innymi z umowy powierzenia.

W przypadku MyDr UODO jednoznacznie wskazał, że placówki ochrony zdrowia korzystające z aplikacji były administratorami danych pacjentów, natomiast MyDr występował jako podmiot przetwarzający. Urząd przypomniał jednocześnie, że to placówki jako administratorzy powinny dokonać oceny ryzyka i zdecydować o konieczności zgłoszenia naruszenia oraz zawiadomienia osób, których dane dotyczą.

Jest to jedna z najważniejszych lekcji płynących z tej sprawy. Administrator nie może po wystąpieniu cyberataku ograniczyć się do komunikatu: „to nie nasze serwery zostały zhakowane”. Z punktu widzenia osoby, której dane dotyczą, znaczenie ma to, komu dane zostały powierzone i kto pierwotnie decydował o ich wykorzystaniu.

Nie oznacza to oczywiście, że dostawca pozostaje bez odpowiedzialności. RODO nakłada bezpośrednie obowiązki również na podmiot przetwarzający, w tym w zakresie zapewnienia bezpieczeństwa, przestrzegania umowy powierzenia oraz informowania administratora o naruszeniu. Relacja pomiędzy administratorem i procesorem jest więc znacznie bardziej złożona niż proste przypisanie całej odpowiedzialności jednej ze stron.

Co musi zrobić dostawca IT po wykryciu naruszenia?

Jeżeli dostawca IT działa jako podmiot przetwarzający i stwierdzi naruszenie ochrony danych osobowych, powinien poinformować o nim administratora bez zbędnej zwłoki. Nie musi wcześniej przeprowadzać pełnej oceny, czy naruszenie powoduje niskie, średnie albo wysokie ryzyko dla osób. Ostateczna ocena w tym zakresie należy do administratora. UODO i Europejska Rada Ochrony Danych podkreślają, że procesor powinien przede wszystkim możliwie szybko przekazać administratorowi informacje pozwalające mu wykonać własne obowiązki.

Ma to ogromne znaczenie praktyczne. Administrator ma bowiem zasadniczo do 72 godzin od stwierdzenia naruszenia na jego zgłoszenie do Prezesa UODO, jeżeli występuje ryzyko naruszenia praw lub wolności osób fizycznych. Jeżeli występuje wysokie ryzyko, może powstać dodatkowo obowiązek bezpośredniego poinformowania osób, których dane dotyczą.

Dostawca, który przez kilkadziesiąt godzin próbuje samodzielnie ustalić pełną skalę ataku, zanim poinformuje klienta, może więc uniemożliwić administratorowi terminowe wykonanie obowiązków. Z tego powodu umowy IT powinny przewidywać bardzo krótkie terminy powiadamiania o incydentach. W praktyce kontrakt może wymagać pierwszego powiadomienia w ciągu kilku godzin od wykrycia potencjalnego zdarzenia, a następnie sukcesywnego uzupełniania informacji w miarę postępu analizy.

Pierwszy komunikat nie musi zawierać pełnego raportu forensic. Znacznie ważniejsze jest szybkie przekazanie informacji, jakie systemy zostały zaatakowane, czy istnieje możliwość dostępu do danych klienta, kiedy zdarzenie wykryto, jakie kategorie danych mogły zostać objęte atakiem oraz jakie działania zabezpieczające zostały już wykonane.

Kto zgłasza naruszenie do UODO?

Typowy błąd w umowach powierzenia polega na założeniu, że dostawca IT „załatwi RODO” za klienta. Owszem, procesor może technicznie pomagać w przygotowaniu zgłoszenia, dostarczać dane oraz współpracować z inspektorem ochrony danych. Nie zmienia to jednak podstawowego podziału odpowiedzialności.

Jeżeli klient jest administratorem, to właśnie on dokonuje oceny ryzyka i decyduje, czy powinien zgłosić naruszenie Prezesowi UODO. W sprawie MyDr Urząd wyraźnie przypomniał placówkom medycznym, że powinny dokonywać takich zgłoszeń po otrzymaniu od procesora potwierdzenia, że incydent obejmuje dane pozostające pod ich administracją.

Problem komplikuje się w przypadku dużego incydentu u dostawcy obsługującego tysiące klientów. Jeden cyberatak może prowadzić do tysięcy odrębnych analiz i zgłoszeń, ponieważ każdy administrator musi ustalić, czy jego dane znalazły się w naruszonym zbiorze oraz jakie ryzyko powstało dla konkretnych osób.

Dlatego już na etapie podpisywania umowy trzeba przewidzieć sposób współpracy po incydencie. Dostawca powinien posiadać możliwość szybkiego ustalenia, którego klienta dotyczą konkretne dane. Jeżeli po ataku przez kilka dni nie jest w stanie odpowiedzieć na podstawowe pytanie, jakie informacje należące do danego administratora zostały naruszone, administrator może zostać postawiony w bardzo trudnej sytuacji prawnej.

Czy sam cyberatak oznacza naruszenie RODO przez dostawcę?

Nie. Sam fakt skutecznego cyberataku nie przesądza automatycznie o tym, że dostawca naruszył przepisy.

Nie istnieje system informatyczny gwarantujący absolutne bezpieczeństwo. Nawet przedsiębiorstwo stosujące zaawansowane zabezpieczenia może stać się ofiarą nowego rodzaju ataku, podatności zero-day, działania osoby wewnętrznej albo skomplikowanej kampanii ukierunkowanej.

Kluczowe pytanie brzmi więc nie tylko, czy doszło do ataku, ale jakie środki bezpieczeństwa były stosowane przed zdarzeniem i czy odpowiadały poziomowi ryzyka.

Właśnie na tym koncentruje się kontrola Prezesa UODO w MyDr. Urząd poinformował, że bada zastosowane przez spółkę środki techniczne i organizacyjne, regularność ich testowania oraz to, czy przeprowadzona analiza ryzyka uwzględniała możliwe zagrożenia i czy jej wyniki zostały rzeczywiście wykorzystane. Według komunikatu UODO kontrola nadal trwała we wrześniu 2026 r.

To bardzo ważny punkt również dla innych dostawców SaaS. Posiadanie dokumentu zatytułowanego „Analiza ryzyka” nie wystarczy, jeżeli ustalone w nim zabezpieczenia nigdy nie zostały wdrożone. Podobnie certyfikat, audyt przeprowadzony kilka lat wcześniej albo polityka bezpieczeństwa nie zwalniają z konieczności regularnej aktualizacji środków ochrony.

Jak ocenia się bezpieczeństwo dostawcy IT?

Nie można stworzyć jednej listy zabezpieczeń właściwej dla każdej aplikacji. Inne wymagania powinny dotyczyć systemu przechowującego publicznie dostępne dane marketingowe, a inne platformy zawierającej dokumentację medyczną milionów pacjentów.

Ocena musi wynikać z ryzyka. Znaczenie mają między innymi charakter danych, ich ilość, możliwość identyfikacji osób, skutki wycieku, liczba klientów, architektura infrastruktury, poziom dostępu administratorów oraz potencjalna atrakcyjność systemu dla cyberprzestępców.

W przypadku dostawcy przechowującego dane medyczne poziom wymaganej ochrony jest naturalnie bardzo wysoki. Dane dotyczące zdrowia należą do szczególnych kategorii danych osobowych, a ich ujawnienie może prowadzić do konsekwencji wykraczających daleko poza zwykły spam. Mogą być wykorzystane do phishingu, oszustwa, dyskryminacji, szantażu albo budowania bardzo wiarygodnych scenariuszy socjotechnicznych.

W sprawie MyDr Prokuratura Okręgowa w Warszawie wskazała, że dochodzenie dotyczy nieuprawnionego dostępu do systemu i informacji obejmujących między innymi imiona, nazwiska, numery PESEL, numery telefonów, adresy e-mail oraz informacje dotyczące zdrowia, w tym notatki z wizyt i dane o receptach. Postępowanie dotyczy dostępu uzyskanego nie później niż 6 sierpnia 2026 r., natomiast pierwsze czynności CBZC zostały podjęte 10 sierpnia.

Klient również powinien sprawdzać zabezpieczenia dostawcy

Cyberatak na podwykonawcę ujawnia jeszcze jeden problem. Administrator ma obowiązek świadomie wybierać podmiot, któremu powierza dane. Nie powinno to sprowadzać się do zaakceptowania standardowego formularza DPA znajdującego się na stronie dostawcy.

Im większe ryzyko związane z danymi, tym dokładniejsza powinna być weryfikacja dostawcy.

W przypadku krytycznego systemu klient powinien interesować się architekturą bezpieczeństwa, kontrolą dostępów, szyfrowaniem, kopiami zapasowymi, procesem zarządzania podatnościami, testami bezpieczeństwa, reagowaniem na incydenty, podwykonawcami oraz procesem odbierania uprawnień pracownikom.

Nie oznacza to oczywiście konieczności przeprowadzania samodzielnego pentestu infrastruktury każdego dostawcy SaaS. Weryfikacja powinna być proporcjonalna do ryzyka i możliwości organizacji. Może obejmować certyfikaty, raporty audytowe, ankiety bezpieczeństwa, dokumentację zabezpieczeń, prawo do audytu albo przedstawienie wyników niezależnych testów.

Istotne jest natomiast to, aby firma potrafiła później wykazać, dlaczego uznała konkretnego dostawcę za odpowiedniego.

Umowa powierzenia nie wystarczy

W praktyce wielu przedsiębiorców uważa, że podpisanie DPA kończy temat cyberbezpieczeństwa. To błąd.

Umowa powierzenia jest ważna, ale odpowiada tylko za część relacji. W poważnym kontrakcie IT bezpieczeństwo powinno być regulowane również w głównej umowie, SLA, załączniku security oraz procedurze incydentowej.

Należy określić wymagania dotyczące uwierzytelniania, dostępu uprzywilejowanego, szyfrowania, tworzenia kopii zapasowych, aktualizacji, zgłaszania podatności, testów, podwykonawców oraz przechowywania danych.

Szczególnie istotna jest procedura incydentowa. Umowa powinna określać, kiedy dostawca musi poinformować klienta, komu przekazuje zgłoszenie, jak aktualizuje informacje i jakie działania musi wykonać w celu zabezpieczenia dowodów.

Bez takich postanowień po ataku zaczyna się improwizacja.

Kto zapłaci za obsługę cyberincydentu?

To jedno z najważniejszych zagadnień kontraktowych.

Poważny cyberatak generuje koszty znacznie wykraczające poza naprawienie serwera. Potrzebna może być informatyka śledcza, analiza logów, prawnicy, dodatkowy personel, infolinia dla klientów, przygotowanie komunikacji, wysyłka zawiadomień, monitoring bezpieczeństwa oraz działania PR.

Jeżeli incydent dotyczy tysięcy albo milionów osób, same koszty komunikacji mogą być bardzo wysokie.

Umowa z dostawcą powinna zatem określać, kto ponosi koszty incydentu spowodowanego naruszeniem jego obowiązków.

Brak odpowiedniej klauzuli nie oznacza, że klient pozbawiony jest roszczeń. Może dochodzić odszkodowania na zasadach ogólnych, jeżeli wykaże niewykonanie albo nienależyte wykonanie zobowiązania, szkodę i związek przyczynowy. Problem polega jednak na tym, że umowy IT bardzo często zawierają limity odpowiedzialności.

Limit odpowiedzialności dostawcy SaaS

Typowa umowa SaaS może przewidywać, że całkowita odpowiedzialność dostawcy nie przekracza wysokości opłat zapłaconych przez klienta w ostatnich trzech, sześciu albo dwunastu miesiącach.

Przy zwykłej awarii systemu takie ograniczenie może być ekonomicznie uzasadnione. Problem pojawia się wtedy, gdy ten sam limit obejmuje wyciek danych.

Wyobraźmy sobie system kosztujący klienta 1 000 zł miesięcznie. Dostawca przechowuje w nim dane kilkudziesięciu tysięcy osób. Jeżeli limit odpowiedzialności odpowiada sześciu abonamentom, potencjalna odpowiedzialność kontraktowa dostawcy wynosi 6 000 zł, mimo że koszt obsługi naruszenia po stronie klienta może wynieść kilkaset tysięcy złotych.

Z tego powodu warto tworzyć odrębne limity odpowiedzialności. Inny może dotyczyć zwykłej niedostępności systemu, inny naruszeń bezpieczeństwa, poufności czy danych osobowych.

Przy najbardziej poważnych naruszeniach strony mogą również całkowicie wyłączyć określone przypadki spod ogólnego limitu.

Czy dostawca może całkowicie wyłączyć odpowiedzialność za cyberatak?

Ogólna klauzula mówiąca, że dostawca „nie odpowiada za ataki hakerskie” powinna budzić dużą ostrożność.

Atak cybernetyczny nie jest automatycznie zdarzeniem siły wyższej. Dla przedsiębiorstwa technologicznego cyberatak stanowi jedno z podstawowych ryzyk prowadzonej działalności. Jeżeli atak był możliwy z powodu braku aktualizacji, słabego hasła administratora, braku MFA albo nieprawidłowo skonfigurowanego serwera, trudno uznać, że dostawca powinien zostać całkowicie zwolniony z odpowiedzialności.

Inaczej można oceniać niezwykle zaawansowany atak wykorzystujący nieznaną wcześniej podatność, przed którą nie istniało racjonalne zabezpieczenie.

Dlatego umowa powinna odwoływać się raczej do dochowania uzgodnionego standardu bezpieczeństwa i należytej staranności niż do prostego wyłączenia każdej odpowiedzialności za działanie osób trzecich.

SLA nie zastępuje odpowiedzialności za bezpieczeństwo

SLA reguluje zazwyczaj dostępność systemu i czas reakcji na awarie. Nie oznacza automatycznie odpowiedzialności za ochronę danych.

Dostawca może spełnić SLA na poziomie 99,99%, a mimo to dopuścić do bardzo poważnego naruszenia poufności. System przez cały czas może działać prawidłowo z punktu widzenia użytkownika, podczas gdy atakujący niezauważenie kopiuje dane.

Dlatego poza SLA potrzebne są osobne wymagania dotyczące cyberbezpieczeństwa.

Należy rozróżniać dostępność, integralność i poufność. System może być dostępny, lecz jednocześnie niebezpieczny.

Backup również wymaga uregulowania

Kopie zapasowe są często przedstawiane jako oczywista część usługi SaaS, mimo że w umowie nie ma żadnych szczegółów.

Tymczasem po ataku ransomware znaczenie ma nie tylko fakt istnienia backupu, lecz także jego separacja od środowiska produkcyjnego, częstotliwość wykonywania, retencja oraz możliwość skutecznego odtworzenia.

Kopia wykonywana codziennie na zasób dostępny tymi samymi poświadczeniami administratora może zostać zaszyfrowana razem z systemem produkcyjnym.

Umowa powinna określać podstawowe parametry kopii i procedury odtwarzania. Przy krytycznych danych warto również wymagać okresowych testów przywracania.

Podwykonawca dostawcy może być kolejnym elementem ryzyka

Współczesny software house rzadko działa samodzielnie. Może korzystać z AWS, Azure, OVH, Cloudflare, dostawców poczty, monitoringu, helpdesku, narzędzi analitycznych i zewnętrznych programistów.

Cyberatak może nastąpić nie na głównego dostawcę, lecz na któregoś z jego podwykonawców.

Dlatego administrator powinien wiedzieć przynajmniej, w jakim modelu procesor korzysta z dalszych podmiotów przetwarzających i w jaki sposób informuje o ich zmianach.

Sam fakt outsourcingu nie zwalnia głównego dostawcy z obowiązków wobec klienta. Dostawca nie powinien móc odpowiedzieć po incydencie: „to była awaria naszej chmury, więc nie ponosimy odpowiedzialności”.

To właśnie on wybrał określoną architekturę i dostawcę infrastruktury, chyba że klient sam narzucił konkretną usługę.

Co z odpowiedzialnością wobec osoby, której dane wyciekły?

Cyberincydent może prowadzić nie tylko do sporu pomiędzy klientem a dostawcą IT. Roszczenia mogą zgłaszać również osoby, których dane dotyczą.

RODO przewiduje możliwość dochodzenia odszkodowania za szkodę majątkową i niemajątkową wynikającą z naruszenia rozporządzenia. To, który podmiot będzie ostatecznie odpowiadał i w jakim zakresie, zależy od jego udziału w naruszeniu i podstawy odpowiedzialności.

Z perspektywy przedsiębiorcy ważne jest więc, aby kontrakt z dostawcą regulował również możliwość regresu. Jeżeli administrator poniesie określone koszty lub zapłaci odszkodowanie z powodu zawinionego naruszenia zabezpieczeń przez procesora, powinien posiadać podstawę do dochodzenia odpowiedniej kwoty od dostawcy.

Nie można jednak zakładać, że każda odpowiedzialność wobec osób automatycznie przejdzie na software house. Jeżeli klient wybrał nieodpowiedniego dostawcę, ignorował ostrzeżenia, nieprawidłowo skonfigurował system albo przechowywał w nim informacje, których nie powinien tam umieszczać, odpowiedzialność może zostać podzielona.

Ubezpieczenie cyber nie zastępuje dobrej umowy

Coraz więcej dostawców i klientów posiada cyberubezpieczenie. Może ono pokrywać część kosztów forensic, obsługi prawnej, przywracania systemów, przerw w działalności i odpowiedzialności wobec osób trzecich.

Nie powinno jednak zastępować prawidłowego podziału odpowiedzialności.

Polisa może zawierać wyłączenia, limity, franszyzy albo warunki dotyczące stosowania określonych zabezpieczeń. Ubezpieczyciel może odmówić wypłaty, jeżeli firma deklarowała korzystanie z MFA, podczas gdy w rzeczywistości nie było ono wdrożone na kontach administracyjnych.

W umowie IT warto więc ustalić, czy dostawca powinien utrzymywać ubezpieczenie cyber oraz minimalną sumę gwarancyjną odpowiednią do ryzyka świadczonej usługi.

Incydent powinien być ćwiczony przed atakiem

Najgorszym momentem na ustalanie, kto ma zadzwonić do UODO, jest noc po wykryciu ransomware.

Procedura powinna zostać przygotowana i przetestowana wcześniej.

Klient powinien wiedzieć, kto w jego organizacji otrzymuje zgłoszenie od dostawcy, kto podejmuje decyzję o kwalifikacji naruszenia, kto kontaktuje się z zarządem, kto odpowiada za komunikację oraz kto posiada dostęp do formularza UODO.

Dostawca powinien natomiast wiedzieć, który klient korzysta z naruszonego środowiska, gdzie znajdują się jego dane i jaki jest właściwy kontakt awaryjny.

Europejska Rada Ochrony Danych rekomenduje, aby organizacje posiadały określone osoby odpowiedzialne za obsługę zdarzeń, ocenę ryzyka oraz proces zgłoszeniowy, a przebieg naruszenia był dokumentowany wraz z rozwojem sytuacji.

Cyberatak jako test całego kontraktu IT

Dopiero poważny incydent pokazuje, czy umowa została dobrze przygotowana.

W spokojnym okresie mało kto zwraca uwagę na różnicę pomiędzy obowiązkiem poinformowania klienta „niezwłocznie” a obowiązkiem poinformowania go w ciągu czterech godzin. Po ataku kilka godzin może jednak zdecydować o możliwości wykonania obowiązku zgłoszeniowego.

Podobnie wygląda kwestia logów. Ogólny obowiązek współpracy może okazać się niewystarczający, jeżeli po incydencie klient potrzebuje konkretnych zapisów z ostatnich sześciu miesięcy, a dostawca przechowuje je jedynie przez siedem dni.

Problematyczny może być również exit plan. Klient może chcieć natychmiast zmienić dostawcę, ale nie posiada kompletnego eksportu danych ani dokumentacji umożliwiającej migrację.

Dlatego cyberbezpieczeństwo powinno być częścią projektu umowy IT od samego początku.

Czego sprawa MyDr uczy klientów usług IT?

Najważniejszą lekcją jest to, że outsourcing systemu nie oznacza outsourcingu całego ryzyka.

Placówka medyczna, firma księgowa, sklep internetowy albo przedsiębiorstwo korzystające z CRM może powierzyć dane profesjonalnemu dostawcy, ale nadal musi interesować się sposobem ich ochrony.

Nie chodzi o to, aby każdy przedsiębiorca stał się specjalistą od cyberbezpieczeństwa. Powinien jednak wiedzieć, jakie dane przekazuje, jak istotny jest system oraz co stanie się po jego przejęciu.

Im poważniejsze mogą być skutki, tym wyższy powinien być standard due diligence dostawcy i zabezpieczeń kontraktowych.

Sprawa MyDr pokazuje też znaczenie koncentracji danych. Dostawca obsługujący tysiące niezależnych podmiotów staje się szczególnie atrakcyjnym celem ataku. Klient powinien uwzględniać to ryzyko przy wyborze rozwiązania.

Czego sprawa MyDr uczy software house’ów i SaaS?

Z perspektywy dostawcy najważniejszy wniosek jest odwrotny. Firma IT nie powinna zakładać, że wystarczy zamieścić w regulaminie niski limit odpowiedzialności.

Poważny incydent oznacza nie tylko ryzyko roszczeń klientów. Może prowadzić do kontroli UODO, postępowań organów, utraty reputacji, odpływu klientów i wielomiesięcznego zaangażowania zespołu w analizę zdarzenia.

W sprawie MyDr działania prowadzą między innymi UODO, CBZC oraz Prokuratura Okręgowa w Warszawie. UODO rozszerzył ponadto działania kontrolne na inne podmioty sektora ochrony zdrowia, wskazując, że incydent ujawnił potrzebę szerszego sprawdzenia sposobu zabezpieczania danych medycznych.

Bezpieczeństwo nie może być więc wyłącznie domeną administratora infrastruktury. Powinno być elementem decyzji zarządczych, budżetowania, developmentu, procedur HR i umów z podwykonawcami.

Jak powinna wyglądać dobra umowa z dostawcą IT?

Dobra umowa powinna zaczynać się od właściwego określenia zakresu usługi i roli dostawcy. Jeżeli przetwarza dane osobowe w imieniu klienta, potrzebne jest prawidłowe powierzenie. Jeżeli posiada dostęp administracyjny do systemów, umowa powinna określać sposób nadawania i odbierania uprawnień. Jeżeli przechowuje dane, powinny zostać ustalone zasady backupu, retencji i usuwania.

Następnie należy uregulować cyberincydenty. Klient powinien otrzymywać informacje wystarczająco szybko, aby samodzielnie wykonać obowiązki prawne. Dostawca powinien zobowiązać się do zabezpieczenia dowodów, współpracy przy analizie i regularnego aktualizowania informacji.

Umowa powinna również regulować koszty incydentu, limity odpowiedzialności, podwykonawców, prawo audytu i exit plan.

Nie każda usługa wymaga kilkudziesięciostronicowego załącznika security. Zakres powinien być proporcjonalny. Innych postanowień potrzebuje mała aplikacja do zarządzania listą zadań, a innych system przechowujący dane medyczne milionów ludzi.

Co zrobić bezpośrednio po informacji o ataku na dostawcę?

Najważniejsze jest szybkie ustalenie faktów. Klient powinien natychmiast ustalić, czy jego dane mogły znajdować się w zaatakowanym środowisku, kiedy doszło do zdarzenia, jakie systemy zostały objęte i jakie działania wykonał dostawca.

Następnie trzeba przeprowadzić ocenę ryzyka dla osób, których dane dotyczą. Nie można automatycznie zgłaszać każdego incydentu ani automatycznie uznawać, że zgłoszenie nie jest potrzebne. UODO przypomniał 5 października 2026 r., że obowiązek zależy właśnie od rzetelnej oceny ryzyka.

Równolegle należy zachować całą korespondencję i dokumentację. Może ona później mieć znaczenie przy kontroli albo dochodzeniu roszczeń wobec dostawcy.

Ważne jest także powstrzymanie dalszego naruszenia. Może być konieczna zmiana kluczy API, certyfikatów, haseł albo tokenów. Po incydencie MyDr Centrum e-Zdrowia podjęło przykładowo działania prewencyjne obejmujące stopniową wymianę certyfikatów P1, mimo że ówczesne ustalenia nie wskazywały na ich naruszenie lub nieuprawnione wykorzystanie.

Nie każdy cyberatak kończy się tak samo

Nie należy na podstawie jednej głośnej sprawy tworzyć zasady, zgodnie z którą każdy dostawca IT odpowiada za każdy wyciek danych.

Cyberbezpieczeństwo wymaga analizy konkretnego przypadku. Znaczenie będzie miał sposób ataku, stan infrastruktury, zabezpieczenia, wcześniejsze audyty, analiza ryzyka, reakcja po wykryciu zdarzenia, obowiązki kontraktowe oraz zachowanie samego klienta.

W przypadku MyDr nie ma jeszcze podstaw, aby przesądzać ostateczną odpowiedzialność spółki lub poszczególnych placówek. Kontrola UODO obejmuje właśnie ustalenie, czy środki techniczne i organizacyjne były odpowiednie oraz czy analiza ryzyka prawidłowo odzwierciedlała zagrożenia.

Dlatego sprawa powinna być traktowana jako studium problemu, a nie gotowy wyrok dotyczący odpowiedzialności konkretnych podmiotów.

Podsumowanie

Cyberatak na dostawcę IT może być jednym z najpoważniejszych zdarzeń, z jakimi zetknie się jego klient. Outsourcing systemu nie usuwa bowiem odpowiedzialności administratora za dane, podobnie jak status procesora nie zwalnia dostawcy technologicznego z obowiązku zapewnienia odpowiednich zabezpieczeń.

W modelu administrator–procesor obie strony mają własne obowiązki. Dostawca powinien chronić powierzone dane, szybko wykrywać incydenty i bez zbędnej zwłoki informować klienta. Administrator musi natomiast dokonać oceny ryzyka oraz zdecydować o zgłoszeniu naruszenia UODO i zawiadomieniu osób.

Dlatego bezpieczeństwo powinno zostać uregulowane przed rozpoczęciem współpracy, a nie dopiero po ataku. Umowa powinna obejmować nie tylko DPA i standardowy regulamin SaaS, ale również procedurę incydentową, zabezpieczenia, podwykonawców, backup, logi, limity odpowiedzialności, koszty reakcji i zasady migracji.

Sprawa MyDr pokazuje skalę, jaką może osiągnąć incydent u jednego dostawcy obsługującego tysiące klientów. Pokazuje również, że prawna odpowiedzialność za bezpieczeństwo nie kończy się w momencie przeniesienia danych do zewnętrznego systemu.

Dla klientów najważniejszym wnioskiem powinno być odpowiednie sprawdzanie dostawców oraz negocjowanie umów adekwatnych do wartości i wrażliwości danych. Dla software house’ów i operatorów SaaS podstawowym zadaniem powinno być natomiast zbudowanie takiego systemu bezpieczeństwa, który nie tylko istnieje w dokumentacji, ale jest regularnie testowany, aktualizowany i możliwy do wykazania podczas kontroli.

W analizie odpowiedzialności pomocne są również obowiązki RODO w projektach IT oraz postanowienia umowy wdrożeniowej dotyczące odbiorów, SLA i odpowiedzialności.