Wyciek danych u podmiotu przetwarzającego. Kto zgłasza naruszenie? Wnioski ze sprawy MyDr

Wyciek danych u podmiotu przetwarzającego nie przenosi obowiązku zgłoszenia naruszenia z administratora na dostawcę. Procesor powinien bez zbędnej zwłoki poinformować administratora i przekazać mu informacje potrzebne do oceny zdarzenia. To jednak administrator ustala, czy naruszenie może powodować ryzyko dla praw lub wolności osób, zgłasza je Prezesowi UODO i – w przypadku wysokiego ryzyka – zawiadamia osoby, których dane dotyczą. Sprawa MyDr pokazuje, jak trudny staje się ten proces, gdy jeden incydent może obejmować dane powierzone przez wielu klientów, a pełna skala zdarzenia nie jest jeszcze znana. Wyjaśniamy, kiedy rozpoczyna się termin 72 godzin, czego wymagać od procesora i jak przygotować organizację na podobny scenariusz.

Najważniejsze informacje

• Procesor zgłasza naruszenie administratorowi bez zbędnej zwłoki, ale co do zasady nie zastępuje go w kontakcie z UODO.
• Każdy administrator powinien samodzielnie ustalić, czy incydent objął powierzone przez niego dane i jakie ryzyko powoduje dla osób.
• Termin 72 godzin liczy się od chwili, w której administrator uzyska rozsądny stopień pewności, że doszło do naruszenia danych osobowych.
• Informacja medialna lub ogólny alert od dostawcy powinny uruchomić natychmiastową weryfikację, nawet jeżeli nie przesądzają jeszcze, że dane konkretnego administratora zostały naruszone.
• Administrator nie powinien czekać na zakończenie pełnej analizy informatycznej. Zgłoszenie do UODO może zostać uzupełnione etapami.
• Każde naruszenie trzeba udokumentować, również wtedy, gdy analiza prowadzi do decyzji o braku zgłoszenia.
• Umowa powierzenia powinna szczegółowo regulować raportowanie incydentów, zabezpieczenie dowodów, dalsze aktualizacje i współpracę z administratorem.

Co wydarzyło się w sprawie MyDr?

12 sierpnia 2026 roku Prezes UODO opublikował komunikat dotyczący doniesień o incydencie u dostawcy systemu Elektronicznej Dokumentacji Medycznej MyDr. Organ przypomniał placówkom, które powierzyły spółce dane pacjentów, że powinny przeanalizować wpływ zdarzenia na własne zasoby oraz ustalić, czy zachodzi obowiązek zgłoszenia naruszenia i zawiadomienia osób.

Dzień później UODO poinformował o planowanej kontroli w spółce MyDr. Kontrolerzy mają zweryfikować zastosowane środki techniczne i organizacyjne, regularność ich testowania oraz to, czy analiza ryzyka uwzględniała możliwe zagrożenia, a jej wyniki zostały wykorzystane w praktyce. Organ zaznaczył jednocześnie, że pełna skala zdarzenia nie była jeszcze znana.

Na etapie zapowiedzi kontroli nie należy przesądzać jej wyniku ani ostatecznej odpowiedzialności poszczególnych podmiotów. Sprawa już teraz pokazuje jednak istotny problem organizacyjny. Dostawca systemu może obsługiwać wielu administratorów, ale każdy z nich odpowiada za dane własnych pacjentów, klientów lub pracowników.

W przypadku placówek medycznych znaczenie ma również charakter informacji. Dane dotyczące zdrowia należą do szczególnych kategorii danych osobowych. Ich ujawnienie może prowadzić między innymi do utraty poufności informacji medycznych, dyskryminacji, naruszenia dóbr osobistych, szkody reputacyjnej, phishingu albo wykorzystania danych do dalszych oszustw.

Placówki korzystające z zewnętrznych systemów mogą zweryfikować swój model ochrony danych w ramach audytu RODO BPPZ. Audyt może objąć obieg dokumentacji, dostawców IT, umowy powierzenia, procedury naruszeń, uprawnienia użytkowników i dowody regularnego testowania zabezpieczeń.

Zapraszamy do współpracy

Szczegółowe informacje o ofercie i warunkach współpracy można uzyskać telefonicznie lub wysyłając zapytanie za pomocą formularza kontaktowego.

BPPZ – Biuro Porad Prawnych Zacharski

– Doszło do incydentu u Twojego dostawcy? Pomożemy ocenić ryzyko i przygotować dalsze działania.

• +48 600 784 526
• kontakt@bppz.pl

Zadzwoń Napisz wiadomość

Administrator i procesor — kto za co odpowiada?

Administrator określa cele oraz zasadnicze sposoby przetwarzania danych. Procesor wykonuje operacje na danych w jego imieniu i na podstawie udokumentowanych poleceń. Typowymi procesorami mogą być dostawcy hostingu, systemów medycznych, księgowych, kadrowych, CRM, chmury, platform mailingowych, archiwizacji lub zewnętrznej obsługi IT.

Powierzenie danych nie oznacza przeniesienia całej odpowiedzialności na usługodawcę. Administrator nadal odpowiada za wybór dostawcy zapewniającego wystarczające gwarancje, prawidłową treść umowy, nadzór nad usługą i możliwość wykazania, że ryzyko zostało właściwie ocenione.

Procesor również posiada własne obowiązki wynikające z RODO. Musi między innymi stosować odpowiednie zabezpieczenia, działać zgodnie z instrukcjami, wspierać administratora oraz zawiadomić go o naruszeniu bez zbędnej zwłoki. Nie staje się jednak przez to podmiotem podejmującym za klienta wszystkie decyzje dotyczące zgłoszenia.

Uczestnik	Najważniejsze obowiązki po wykryciu incydentu
Administrator	Ustalenie, czy naruszono jego dane, ocena ryzyka, dokumentacja, zgłoszenie do UODO i ewentualne zawiadomienie osób
Podmiot przetwarzający	Ograniczenie incydentu, zabezpieczenie dowodów, powiadomienie administratora bez zbędnej zwłoki i przekazywanie kolejnych ustaleń
Inspektor ochrony danych	Doradztwo, monitorowanie zgodności, wsparcie oceny ryzyka i kontaktu z organem; IOD nie przejmuje odpowiedzialności administratora
Zespół IT lub bezpieczeństwa	Analiza techniczna, zabezpieczenie systemów i logów, ustalenie wektora ataku, zakresu dostępu oraz działań naprawczych
Zarząd lub właściciel procesu	Zapewnienie zasobów, zatwierdzenie działań, koordynacja decyzji biznesowych i komunikacji kryzysowej

Jeżeli organizacja nie posiada odpowiednich zasobów wewnętrznych, może skorzystać ze wsparcia zewnętrznego Inspektora Ochrony Danych BPPZ. Stałe wsparcie IOD ułatwia wcześniejsze przygotowanie procedur, podziału odpowiedzialności i kanałów eskalacji, zanim wystąpi realny incydent.

Kto zgłasza naruszenie do UODO?

Co do zasady zgłoszenia dokonuje administrator danych. Wynika to z art. 33 ust. 1 RODO. Jeżeli naruszenie może powodować ryzyko dla praw lub wolności osób fizycznych, administrator zgłasza je właściwemu organowi nadzorczemu bez zbędnej zwłoki – w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia.

Procesor ma inny obowiązek. Zgodnie z art. 33 ust. 2 RODO po stwierdzeniu naruszenia powinien bez zbędnej zwłoki zgłosić je administratorowi. Nie musi wcześniej rozstrzygać, czy ryzyko jest niskie, umiarkowane albo wysokie. Tę ocenę przeprowadza administrator, ponieważ zna cel przetwarzania, relację z osobami, pełny zakres danych oraz możliwe konsekwencje zdarzenia.

Procesor może technicznie przekazać zgłoszenie do UODO w imieniu administratora, jeżeli został do tego odpowiednio upoważniony. Nie powinno to jednak zacierać odpowiedzialności. Administrator nadal musi znać treść zgłoszenia, zatwierdzić przyjętą ocenę i potrafić wykazać podstawę swojej decyzji.

W przypadku procesora obsługującego wielu klientów jedno zdarzenie może prowadzić do wielu odrębnych analiz i zgłoszeń. Dostawca może przygotować wspólny opis techniczny, lecz każda placówka lub firma powinna ustalić:

• czy jej dane znajdowały się w objętym incydentem środowisku;
• jakich kategorii osób i informacji dotyczyło zdarzenie;
• czy dane zostały jedynie potencjalnie narażone, czy istnieją dowody dostępu, skopiowania, zmiany albo usunięcia;
• jakie konsekwencje mogą wystąpić wobec osób;
• czy zastosowane zabezpieczenia rzeczywiście ograniczają ryzyko;
• czy potrzebne jest zgłoszenie do UODO i zawiadomienie osób.

Kiedy rozpoczyna się termin 72 godzin?

Termin nie powinien być liczony automatycznie od każdej niepotwierdzonej informacji medialnej. Nie oznacza to jednak, że administrator może biernie czekać na oficjalny raport dostawcy.

Europejska Rada Ochrony Danych wskazuje, że administrator staje się świadomy naruszenia, gdy posiada rozsądny stopień pewności, że wystąpił incydent bezpieczeństwa prowadzący do naruszenia danych osobowych. Pierwszy sygnał może uzasadniać krótki okres intensywnej weryfikacji. Dochodzenie powinno rozpocząć się niezwłocznie i nie może służyć sztucznemu odsuwaniu momentu rozpoczęcia terminu.

W praktyce należy rozróżnić trzy sytuacje:

Etap	Znaczenie dla administratora
Ogólny alert lub doniesienie medialne	Natychmiastowe uruchomienie weryfikacji i kontaktu z procesorem
Informacja, że wystąpił incydent, ale nie wiadomo, czy objął dane administratora	Pilne żądanie potwierdzenia zakresu, zabezpieczenie dokumentacji i przygotowanie zespołu
Rozsądna pewność, że dane administratora zostały naruszone	Rozpoczęcie biegu terminu 72 godzin i ocena, czy wymagane jest zgłoszenie

Wytyczne EROD wskazują również, że co do zasady administrator może zostać uznany za świadomego naruszenia, gdy procesor poinformuje go o zdarzeniu dotyczącym powierzonych danych. Dlatego ogólne sformułowanie w umowie, że dostawca powiadomi klienta „bez zbędnej zwłoki”, warto przełożyć na konkretny proces operacyjny, osoby kontaktowe i zakres pierwszego raportu.

Dokładną ścieżkę formalnego zawiadomienia opisuje poradnik BPPZ Jak zgłosić naruszenie ochrony danych osobowych do UODO.

Czy trzeba czekać na pełny raport procesora?

Nie. Zgłoszenie naruszenia nie wymaga zakończenia całego dochodzenia informatycznego. W rozbudowanych incydentach pełna analiza logów, urządzeń, kopii zapasowych i aktywności napastnika może potrwać znacznie dłużej niż 72 godziny.

Jeżeli administrator posiada wystarczające informacje, aby stwierdzić naruszenie i zidentyfikować ryzyko, powinien dokonać zgłoszenia na podstawie aktualnej wiedzy. Brakujące informacje mogą zostać przekazane etapami. W pierwszym zgłoszeniu należy jasno oddzielić fakty potwierdzone od ustaleń wstępnych i wskazać, jakie działania są nadal prowadzone.

Niebezpieczne jest czekanie na:

• końcowy raport informatyki śledczej;
• zamknięcie działań organów ścigania;
• pełną listę wszystkich rekordów;
• ostateczne ustalenie sprawcy;
• zakończenie przywracania systemów;
• wynik kontroli UODO;
• decyzję procesora, czy administrator powinien dokonać zgłoszenia.

Procesor dostarcza dane techniczne i wspiera analizę, ale nie powinien uzależniać przekazania informacji od ukończenia całego postępowania. Administrator musi jednocześnie dokumentować, kiedy otrzymał poszczególne komunikaty, jakie pytania zadał i na jakiej podstawie podjął decyzję.

Jak ocenić ryzyko naruszenia?

Nie każdy incydent u procesora wymaga zgłoszenia do UODO. Każdy wymaga natomiast udokumentowania i rzetelnej oceny. Administrator powinien uwzględnić rzeczywiste okoliczności, a nie ograniczać się do nazwy zdarzenia albo ogólnej deklaracji dostawcy.

Znaczenie mają w szczególności:

• rodzaj naruszenia: poufności, integralności lub dostępności;
• kategorie danych, w tym dane zdrowotne, biometryczne, finansowe, numery PESEL i dane logowania;
• możliwość bezpośredniej identyfikacji osób;
• liczba osób i rekordów;
• czas trwania oraz zasięg incydentu;
• potwierdzony albo prawdopodobny dostęp osób nieuprawnionych;
• możliwość skopiowania, opublikowania, zmiany albo trwałego usunięcia danych;
• szczególna sytuacja osób, na przykład pacjentów, dzieci lub pracowników;
• skuteczność szyfrowania i bezpieczeństwo kluczy;
• możliwość wykorzystania informacji do phishingu, kradzieży tożsamości, dyskryminacji albo naruszenia tajemnicy;
• działania ograniczające skutki, które zostały już wykonane.

Wynik oceny	Działanie administratora
Naruszenie prawdopodobnie nie powoduje ryzyka	Udokumentowanie zdarzenia i podstaw decyzji o braku zgłoszenia
Naruszenie może powodować ryzyko	Zgłoszenie Prezesowi UODO bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin
Naruszenie może powodować wysokie ryzyko	Zgłoszenie do UODO oraz zawiadomienie osób bez zbędnej zwłoki, o ile nie zachodzi jeden z wyjątków przewidzianych w art. 34 RODO

Dane dotyczące zdrowia nie powodują automatycznie, że każde zdarzenie osiąga najwyższy poziom ryzyka. Ich szczególny charakter jest jednak silnym czynnikiem zwiększającym możliwe konsekwencje. Ocena powinna uwzględniać zarówno treść danych, jak i kontekst leczenia, skalę, możliwość identyfikacji oraz dostępne dowody dotyczące zachowania napastnika.

Jeżeli firma potrzebuje szybkiej kwalifikacji incydentu, przygotowania zgłoszenia albo komunikacji z osobami, może skorzystać z usługi obsługi naruszeń RODO przez BPPZ. Wsparcie może objąć ocenę ryzyka, dokumentację decyzji, kontakt z procesorem, treść zgłoszenia i plan działań naprawczych.

Kiedy należy zawiadomić osoby, których dane dotyczą?

Zgłoszenie do UODO i zawiadomienie osób to dwa odrębne obowiązki. Administrator informuje osoby bez zbędnej zwłoki, jeżeli naruszenie może powodować wysokie ryzyko dla ich praw lub wolności.

Komunikat powinien być napisany jasnym i prostym językiem. Powinien zawierać co najmniej:

• opis charakteru naruszenia;
• dane kontaktowe IOD lub innego punktu kontaktowego;
• opis możliwych konsekwencji;
• informacje o działaniach podjętych lub planowanych przez administratora;
• praktyczne wskazówki pozwalające osobie ograniczyć ryzyko.

Nie wystarczy ogólna informacja, że „doszło do incydentu u dostawcy”. Odbiorca powinien zrozumieć, jakie jego dane mogły zostać objęte zdarzeniem, jakie zagrożenia są realne i co może zrobić. Rekomendacje należy dopasować do rodzaju danych. Mogą obejmować między innymi zastrzeżenie numeru PESEL, zmianę danych logowania, ostrożność wobec wiadomości podszywających się pod placówkę lub wzmożoną kontrolę rachunków i kont użytkownika.

Administrator powinien koordynować treść komunikatu z procesorem, ale nie może uzależniać wykonania własnego obowiązku od zgody dostawcy. W przypadku wielu administratorów warto zachować spójność podstawowych faktów technicznych, jednocześnie dostosowując komunikaty do zakresu danych i relacji z własnymi klientami albo pacjentami.

Jakich informacji trzeba zażądać od procesora?

Pierwszy raport procesora nie musi zawierać wszystkich odpowiedzi, ale powinien umożliwić administratorowi rozpoczęcie własnej analizy. Informacja ograniczona do stwierdzenia, że „trwa wyjaśnianie sprawy”, zwykle nie będzie wystarczająca.

Administrator powinien uzyskać co najmniej:

1. datę i przybliżoną godzinę wystąpienia oraz wykrycia incydentu;
2. opis sposobu wykrycia i aktualny status zdarzenia;
3. potwierdzenie, czy incydent objął dane konkretnego administratora;
4. wskazanie systemów, baz, środowisk i kopii objętych zdarzeniem;
5. kategorie osób i danych;
6. przybliżoną liczbę osób oraz rekordów;
7. informacje o dostępie, skopiowaniu, zmianie, usunięciu lub zaszyfrowaniu danych;
8. dostępne informacje o sprawcy i odbiorcach danych;
9. ocenę skuteczności szyfrowania, pseudonimizacji i kontroli dostępu;
10. opis działań ograniczających incydent i jego skutki;
11. informacje o dalszych procesorach, których systemy mogły zostać objęte zdarzeniem;
12. plan kolejnych aktualizacji oraz dane osoby odpowiedzialnej za kontakt;
13. potwierdzenie zabezpieczenia logów i innych dowodów;
14. wstępne ustalenia dotyczące przyczyny i możliwego czasu trwania naruszenia.

Procesor powinien aktualizować informacje wraz z postępem analizy. Administrator powinien natomiast prowadzić własną chronologię, w której zapisuje czas alertu, odpowiedzi dostawcy, moment uzyskania pewności o naruszeniu, wykonane czynności i uzasadnienie decyzji.

Co powinna regulować umowa powierzenia?

Ogólny obowiązek współpracy może okazać się niewystarczający podczas poważnego incydentu. Umowa powierzenia i powiązana z nią procedura bezpieczeństwa powinny opisywać rzeczywisty sposób działania stron.

Warto uregulować:

• kanał i osoby właściwe do całodobowego zgłaszania incydentów;
• termin pierwszego powiadomienia, pozwalający administratorowi wykonać własne obowiązki w ciągu 72 godzin;
• minimalny zakres pierwszego raportu;
• przekazywanie kolejnych informacji etapami;
• zabezpieczanie logów, obrazów systemów i innych dowodów;
• udział dalszych procesorów w analizie;
• współpracę przy ocenie ryzyka, zgłoszeniu do UODO i zawiadomieniu osób;
• zasady komunikacji z mediami, klientami i organami;
• możliwość przeprowadzenia audytu oraz uzyskania raportu po incydencie;
• działania naprawcze i sposób weryfikacji ich skuteczności;
• wsparcie przy realizacji praw osób;
• odpowiedzialność za aktualność list kontaktowych i testowanie procedury.

Samo wpisanie do umowy obowiązku powiadomienia nie zastąpi weryfikacji dostawcy. Administrator powinien sprawdzić, czy procesor posiada zespół reagowania, rejestruje zdarzenia, zachowuje logi, testuje odtwarzanie danych i potrafi przekazać informacje w formie użytecznej dla klienta.

Praktyczną ocenę relacji z dostawcą można przeprowadzić na podstawie poradnika BPPZ Jak wybrać podmiot przetwarzający dane? 12 punktów, które trzeba sprawdzić. W przypadku bardziej złożonych usług technologicznych pomocne może być również projektowe doradztwo prawne BPPZ, obejmujące analizę ról, umów, zabezpieczeń i podziału odpowiedzialności.

Co powinien zrobić klient MyDr lub innego dostawcy po otrzymaniu alertu?

Organizacja nie powinna ograniczać się do przesłania wiadomości dostawcy do działu IT. Potrzebny jest równoległy proces techniczny, prawny, organizacyjny i komunikacyjny.

1. Sprawdź relację i zakres usługi

Ustal, z których modułów dostawcy korzysta organizacja, jakie dane zostały powierzone, w jakich systemach się znajdują i czy występują dalsi procesorzy. Zweryfikuj umowę, instrukcje, rejestr czynności oraz aktualne dane kontaktowe.

2. Uruchom procedurę naruszeń

Zarejestruj alert, wyznacz osobę koordynującą i włącz IOD, IT, bezpieczeństwo, dział prawny, właściciela procesu oraz osoby odpowiedzialne za komunikację. Nie czekaj z eskalacją do czasu uzyskania pełnego raportu.

3. Uzyskaj potwierdzenie od procesora

Zażądaj formalnej informacji, czy zdarzenie objęło dane organizacji. Pytania powinny dotyczyć zakresu, czasu, rodzaju dostępu, zabezpieczeń, możliwej eksfiltracji i podjętych działań.

4. Przeprowadź własną ocenę ryzyka

Nie kopiuj automatycznie oceny dostawcy. Procesor może nie znać pełnego kontekstu danych ani konsekwencji dla pacjentów, pracowników lub klientów. Udokumentuj metodę, czynniki i wnioski.

5. Podejmij decyzję o zgłoszeniu

Jeżeli naruszenie może powodować ryzyko, przygotuj zgłoszenie do UODO. Gdy część informacji jest niedostępna, zgłoś aktualnie znane fakty i zapowiedz ich uzupełnienie.

6. Oceń obowiązek zawiadomienia osób

Jeżeli ryzyko jest wysokie, przygotuj jasny komunikat oraz realne zalecenia ochronne. Ustal kanały pozwalające skutecznie dotrzeć do zainteresowanych osób.

7. Ogranicz dalsze skutki

Sprawdź konta użytkowników, tokeny, integracje, eksporty, lokalne kopie i inne połączenia z usługą. W razie potrzeby zmień dane dostępowe, wyłącz integrację albo czasowo ogranicz przepływ informacji.

8. Zachowaj dowody i chronologię

Zapisuj wszystkie komunikaty, decyzje, wersje ocen, zgłoszenia i działania. Dokumentacja powinna pozwalać później wykazać, kiedy organizacja dowiedziała się o naruszeniu i dlaczego wybrała określony sposób postępowania.

9. Przeprowadź przegląd po incydencie

Po opanowaniu sytuacji oceń przyczynę, jakość współpracy procesora, adekwatność umowy, skuteczność zabezpieczeń i szybkość wewnętrznej reakcji. Samo zamknięcie zgłoszenia nie kończy obowiązku zarządzania ryzykiem.

Placówki medyczne mogą dodatkowo wykorzystać zasady opisane w artykule BPPZ RODO dla przychodni i aptek, dotyczącym ochrony danych zdrowotnych, dokumentacji, uprawnień i współpracy z podmiotami zewnętrznymi.

Checklista reagowania na naruszenie u procesora

Etap	Działania administratora	Dowód wykonania
Pierwszy alert	Rejestracja zdarzenia, eskalacja, kontakt z procesorem	Wpis w rejestrze i potwierdzenie zgłoszenia
Wstępna weryfikacja	Ustalenie, czy incydent może dotyczyć powierzonych danych	Odpowiedź procesora i notatka ze sprawdzenia
Potwierdzenie naruszenia	Ustalenie momentu uzyskania rozsądnej pewności	Chronologia incydentu
Ocena ryzyka	Analiza danych, osób, skali, skutków i zabezpieczeń	Udokumentowana ocena ryzyka
Decyzja o UODO	Zgłoszenie albo zapisanie podstaw braku zgłoszenia	Formularz zgłoszenia lub notatka decyzyjna
Ocena wysokiego ryzyka	Decyzja o zawiadomieniu osób i przygotowanie komunikatu	Treść komunikatu i dowód wysyłki
Ograniczenie skutków	Działania techniczne, organizacyjne i komunikacyjne	Logi, protokoły i potwierdzenia zmian
Aktualizacje	Uzupełnianie zgłoszenia wraz z nowymi ustaleniami	Kolejne wersje zgłoszenia
Zamknięcie	Raport końcowy, działania naprawcze i kontrola wykonania	Raport po incydencie i plan naprawczy

Procedura powinna zostać przetestowana przed realnym incydentem. Szkolenie RODO BPPZ może obejmować praktyczny scenariusz naruszenia u dostawcy, obieg alertu, podział odpowiedzialności i przygotowanie informacji potrzebnych do oceny ryzyka.

Jak przygotować firmę na incydent u dostawcy?

Sprawa MyDr nie dotyczy wyłącznie sektora medycznego. Podobny problem może wystąpić u dostawcy chmury, hostingu, księgowości, systemu kadrowego, platformy rekrutacyjnej, CRM, call center, archiwum lub usług marketingowych.

Organizacja powinna zawczasu:

• prowadzić aktualną listę procesorów i dalszych procesorów;
• wiedzieć, jakie dane znajdują się w każdym systemie;
• przypisać właściciela biznesowego do każdej usługi;
• okresowo weryfikować zabezpieczenia dostawców;
• posiadać aktualne umowy powierzenia;
• ustalić awaryjne kanały kontaktu;
• przygotować wzory pierwszych pytań, zgłoszeń i zawiadomień;
• określić metodę oceny ryzyka;
• przeprowadzać ćwiczenia obejmujące incydenty zewnętrzne;
• sprawdzać, czy procesor wykonuje działania naprawcze po wcześniejszych zdarzeniach.

Jeżeli procedury, rejestry i umowy nie odpowiadają faktycznym usługom, konieczne może być ich uporządkowanie w ramach wdrożenia RODO z BPPZ. Celem takiego projektu jest nie tylko przygotowanie dokumentów, ale również zaprojektowanie działającego obiegu informacji, odpowiedzialności i dowodów zgodności.

Jak BPPZ może pomóc po naruszeniu u procesora?

Incydent u zewnętrznego dostawcy wymaga szybkiego połączenia informacji technicznych z oceną prawną i organizacyjną. BPPZ może wesprzeć administratora między innymi poprzez:

• pilną kwalifikację zdarzenia i ocenę ryzyka;
• przygotowanie lub weryfikację zgłoszenia do Prezesa UODO;
• opracowanie komunikatu do osób, których dane dotyczą;
• przygotowanie pytań i żądań informacyjnych do procesora;
• koordynację działań IOD, IT, zarządu i komunikacji;
• audyt procesora i umowy powierzenia po incydencie;
• aktualizację procedury reagowania oraz rejestru naruszeń;
• przygotowanie planu działań naprawczych;
• przeprowadzenie ćwiczenia lub szkolenia dla personelu;
• bieżące wsparcie jako zewnętrzny IOD.

Zakres pomocy jest dobierany do rodzaju incydentu, kategorii danych, skali działalności i aktualnego etapu postępowania. Punktem wejścia może być obsługa naruszeń RODO albo audyt RODO obejmujący relacje z dostawcami i gotowość organizacji do reagowania.

Podsumowanie

Wyciek danych u podmiotu przetwarzającego nie zwalnia administratora z odpowiedzialności za ocenę i zgłoszenie naruszenia. Procesor powinien bez zbędnej zwłoki przekazać informację o zdarzeniu, zabezpieczyć dowody i wspierać klienta. To jednak administrator decyduje, czy naruszenie może powodować ryzyko, zgłasza je UODO i ocenia konieczność poinformowania osób.

Sprawa MyDr pokazuje znaczenie wcześniejszego przygotowania. Gdy jeden procesor obsługuje wielu administratorów, jakość umowy, aktualna lista kontaktów, dostępność logów i zdolność przekazywania informacji etapami stają się kluczowe dla zachowania terminu 72 godzin.

Administrator nie powinien czekać na pełny raport, wynik kontroli ani gotową decyzję dostawcy. Powinien aktywnie ustalić, czy jego dane zostały objęte zdarzeniem, przeprowadzić własną ocenę i udokumentować każdą decyzję. Najlepszą ochroną pozostaje proces przygotowany wcześniej: zweryfikowany dostawca, precyzyjna umowa, przetestowana procedura i zespół, który wie, co zrobić po pierwszym alercie.

FAQ

Źródła

1. EUR-Lex – Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679.
2. UODO – Administrator musi zgłosić wyciek, do którego doszło w podmiocie przetwarzającym, 12 sierpnia 2026 r..
3. UODO – Prezes UODO skontroluje spółkę MyDr, 13 sierpnia 2026 r..
4. Europejska Rada Ochrony Danych – Wytyczne 9/2022 dotyczące zgłaszania naruszeń ochrony danych osobowych zgodnie z RODO.