Termin 72 godzin na zgłoszenie naruszenia do UODO liczy się od stwierdzenia naruszenia przez administratora — nie od pierwszego artykułu w mediach i nie od samego faktu, że „coś było u vendora”. Przy wycieku u procesora EDM placówka musi najpierw ustalić, czy i w jakim zakresie dotyczy to jej danych. Model zależności od vendora sprawia, że ten zegar startuje często później i chaotyczniej, niż się wydaje.
TL;DR
- 72h = od stwierdzenia przez administratora, gdy zgłoszenie jest wymagane.
- Komunikat medialny to sygnał do weryfikacji u procesora, nie automatyczne „start”.
- Dokumentuj: co wiecie / czego nie wiecie / dlaczego tak / nie / wstępnie.
Jak myśleć o zegarze 72h
- Sygnał — media, mail od vendora, alert security, pacjent.
- Weryfikacja — czy korzystacie z systemu; czy tenant w zakresie; jakie kategorie danych.
- Stwierdzenie — moment, w którym administrator ma wystarczającą pewność, że doszło do naruszenia dotyczącego jego przetwarzania (albo że ryzyko tego jest realne w rozumieniu obowiązków RODO).
- Decyzja — zgłoszenie tak / nie / wstępne + uzupełnienie; uzasadnienie na piśmie.
O co pytać procesora (żeby w ogóle móc ocenić incydent)
- Czy nasz identyfikator klienta / baza jest w zakresie (tak / nie / nieustalone)?
- Jakie kategorie danych mogły zostać ujawnione?
- Jaki jest timeline: detection → containment → powiadomienie administratorów?
- Jaki materiał dostaniecie do oceny ryzyka i ewentualnych zawiadomień osób?
Czego nie robić
- Nie mylić „nie mamy jeszcze maila od vendora” z „nic się nie stało”.
- Nie zgłaszać „na zapas” bez dokumentacji — i nie milczeć „bo media jeszcze nie doprecyzowały”.
- Nie opierać decyzji wyłącznie na zastrzeżeniu PESEL (to inny wektor ryzyka).
Operacyjna lista kroków: Checklista 72h · PDF do druku.
Powiązane materiały
Jak cytować
Zgłoszenie do UODO w 72h przy wycieku u vendora, Bezpieczny Blog, https://bezpiecznyblog.pl/zgloszenie-uodo-72h-vendor/
Stan: 21.08.2026 · nie stanowi porady prawnej · bez pitchu usług