Cyberincydent u dostawcy IT: kto odpowiada za zawiadomienie organu i kiedy biegną terminy

Opracowanie: Zespół redakcyjny WILIŃSKI LEGAL

Atak na firmę hostingową, dostawcę CRM lub usługę kadrową nie przestaje być problemem administratora tylko dlatego, że do naruszenia doszło poza jego serwerownią. Z drugiej strony nie każdy alarm bezpieczeństwa jest naruszeniem ochrony danych osobowych. Decydują ustalenie roli podmiotów, charakter naruszonych danych oraz udokumentowana ocena ryzyka dla osób fizycznych.

Podział obowiązków w RODO

Art. 33 ust. 2 RODO nakłada na podmiot przetwarzający obowiązek powiadomienia administratora bez zbędnej zwłoki po stwierdzeniu naruszenia. Natomiast art. 33 ust. 1 dotyczy zgłoszenia organowi nadzorczemu przez administratora — co do zasady bez zbędnej zwłoki i, gdy jest to wykonalne, nie później niż 72 godziny po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, aby powodowało ono ryzyko dla praw lub wolności osób. Termin nie jest automatycznym „czasem dla procesora plus kolejnymi 72 godzinami dla administratora”. Istotne jest, kiedy administrator rzeczywiście uzyskał wiedzę pozwalającą stwierdzić naruszenie.

Co trzeba ustalić w pierwszych godzinach

Zespół powinien oddzielić potwierdzone fakty od hipotez: jakie systemy objęto incydentem, czy nastąpiła utrata poufności, integralności lub dostępności danych, ilu osób problem może dotyczyć i jakie środki podjęto. Gdy informacji nie da się zebrać jednorazowo, RODO dopuszcza przekazywanie ich etapami bez zbędnej zwłoki. Równolegle należy badać obowiązek zawiadomienia osób, jeżeli naruszenie może powodować wysokie ryzyko, oraz inne reżimy sektorowe, o ile obejmują dane przedsiębiorstwo.

Umowa powierzenia musi działać w praktyce

W umowie zgodnej z art. 28 RODO warto określić punkt kontaktowy 24/7, maksymalny wewnętrzny czas eskalacji, zakres pierwszego raportu, obowiązek zabezpieczenia logów i wsparcie w ocenie ryzyka. Nie należy jednak wpisywać, że procesor „sam przejmuje wszystkie obowiązki administratora”; outsourcing działań technicznych nie znosi odpowiedzialności za prawidłową decyzję o zgłoszeniu. Po incydencie trzeba także ocenić, czy przyjęte środki ochrony z art. 32 były adekwatne do ryzyka.

Przykład zastosowania: ransomware u firmy księgowej

Dostawca usług księgowych informuje, że w wyniku ataku część danych klientów była niedostępna przez kilkanaście godzin, ale nie potrafi jeszcze wykluczyć kopiowania plików. Administrator nie powinien automatycznie zgłaszać każdej awarii jako wycieku ani czekać bezczynnie na końcowy raport techniczny. Musi zidentyfikować posiadane fakty, ocenić ryzyko dostępności i poufności oraz dokumentować podstawę decyzji o zgłoszeniu lub jego braku. Jeżeli brak informacji nie pozwala na pełne ustalenia, właściwą praktyką jest dalsze badanie i przekazywanie aktualizacji bez nieuzasadnionej zwłoki.

Nie każdy cyberincydent to zgłaszalne naruszenie ochrony danych

Przerwa techniczna, próba ataku lub błąd konfiguracji nie zawsze oznaczają naruszenie ochrony danych osobowych. Trzeba zbadać, czy doszło do zdarzenia prowadzącego do przypadkowego lub niezgodnego z prawem zniszczenia, utraty, zmodyfikowania, nieuprawnionego ujawnienia lub uzyskania dostępu do danych. Następnie administrator ocenia ryzyko dla praw i wolności osób. Obowiązek zgłoszenia organowi według art. 33 RODO nie występuje w każdym incydencie bez względu na skutki, choć prawidłowe dokumentowanie i analiza bywają konieczne.

Dwa odrębne zegary: procesor i administrator

Procesor ma zawiadomić administratora bez zbędnej zwłoki po stwierdzeniu naruszenia ochrony danych. Administrator zasadniczo zgłasza kwalifikujące się naruszenie organowi bez zbędnej zwłoki i, w miarę możliwości, nie później niż w ciągu 72 godzin od stwierdzenia, chyba że prawdopodobieństwo ryzyka dla praw i wolności jest małe. Początku tego terminu nie można automatycznie przesuwać do daty ukończenia analizy informatycznej ani utożsamiać z chwilą otrzymania pierwszego anonimowego alertu. Liczy się moment uzyskania rozsądnej pewności co do zaistnienia naruszenia.

Umowa powierzenia musi obsługiwać sytuację kryzysową

Przed incydentem należy uzgodnić kanał alarmowy działający poza godzinami pracy, minimalny pakiet danych zgłoszenia, czas kolejnych aktualizacji i procedurę zabezpieczenia logów. W kontrakcie warto uregulować zakres współpracy przy zgłoszeniu do organu, informowaniu osób, analizie podmiotów podprzetwarzających oraz utrzymaniu ciągłości usług. Nie można przerzucić na procesora ustawowej odpowiedzialności administratora za własną ocenę ryzyka poprzez samą klauzulę umowną.

Kiedy zawiadamia się osoby, których dane dotyczą

Art. 34 RODO wymaga odrębnego zbadania wysokiego ryzyka; poziom oceny jest inny niż przy obowiązku zgłoszenia organowi. W dokumentacji należy wykazać rodzaj danych, zakres ekspozycji, możliwość identyfikacji osób, środki ograniczające skutki oraz powody podjętej decyzji. Równolegle mogą występować dodatkowe obowiązki z przepisów o cyberbezpieczeństwie, lecz trzeba je analizować osobno, według statusu konkretnego podmiotu.

Konkluzja

Rzetelny proces nie kończy się na wysłaniu formularza do organu. Wymaga szybkiej informacji od dostawcy, własnej klasyfikacji naruszenia i kompletnego śladu decyzyjnego. Największym błędem bywa założenie, że skoro incydent wystąpił „u zewnętrznego IT”, to prawny zegar administratora nie ma znaczenia.

Podstawa i źródło: art. 28, 32–34 RODO; https://eur-lex.europa.eu/legal-content/PL/ALL/?uri=CELEX:32016R0679

Powiązane analizy

• Zmiana dostawcy chmury po Data Act: koniec kontraktowego zamknięcia klienta w jednym systemie?
• Pochodzenie danych treningowych AI: zgodność zaczyna się przed pierwszym uruchomieniem modelu

Źródła pierwotne i dokumenty urzędowe

• Podstawowy akt lub dokument: art. 28, 32–34 RODO;
• RODO, art. 33

Bibliografia sprawdzana 12 października 2026 r. Tekst ma charakter ogólny; właściwy stan prawny ustala się na datę zdarzenia.