Jak prowadzić rejestr naruszeń i nie zgubić terminów 72 godzin

Po co w ogóle rejestr naruszeń i skąd się bierze termin 72 godzin

Incydent bezpieczeństwa a naruszenie ochrony danych osobowych

W każdej organizacji zdarzają się awarie, pomyłki i „wpadki”. Nie każda z nich jest od razu naruszeniem ochrony danych osobowych, które trzeba wpisać do rejestru naruszeń RODO i analizować pod kątem zgłoszenia do organu nadzorczego. Rozróżnienie tych pojęć jest kluczowe, żeby nie tworzyć sztucznego szumu ani nie przegapić zdarzeń naprawdę istotnych.

Incydent bezpieczeństwa to szersza kategoria. Może dotyczyć sieci, systemów, infrastruktury, nawet jeśli w ogóle nie wchodzą w grę dane osobowe. Przykład: krótkotrwała awaria sieci w budynku – pracownicy nie mogą się zalogować do systemu, ale nie dochodzi do utraty danych.

Naruszenie ochrony danych osobowych to sytuacja, w której doszło do naruszenia poufności, dostępności lub integralności danych, a jednocześnie dane te są danymi osobowymi i istnieje choćby potencjalne ryzyko dla osób, których te dane dotyczą. Przykład: wysyłka maila z listą uczestników szkolenia i ich PESEL do złego adresata.

Rejestr naruszeń RODO dotyczy wyłącznie naruszeń ochrony danych osobowych. Incydent czysto techniczny (np. restart serwera bez wpływu na dane osobowe) może być istotny dla działu IT, ale niekoniecznie trafia do rejestru naruszeń, choć czasem bywa dobrym sygnałem ostrzegawczym – zwłaszcza jeśli takie incydenty są częste i zwiększają ryzyko poważniejszego zdarzenia.

Podstawa prawna rejestru naruszeń i terminu 72 godzin

RODO nakłada na administratora obowiązek zgłaszania naruszeń organowi nadzorczemu w ciągu 72 godzin od ich stwierdzenia, o ile istnieje ryzyko naruszenia praw lub wolności osób fizycznych. Jednocześnie administrator musi dokumentować wszystkie naruszenia ochrony danych osobowych, niezależnie od tego, czy zostały zgłoszone do organu, czy nie.

W praktyce oznacza to dwa równoległe obowiązki:

• prowadzenie rejestru naruszeń – katalogu wszystkich przypadków naruszenia ochrony danych;
• pilnowanie terminu 72 godzin na zgłoszenie do organu nadzorczego (np. UODO), gdy naruszenie stwarza ryzyko dla osób.

Krajowe przepisy i wytyczne organu nadzorczego uszczegóławiają, jakie informacje powinny znaleźć się w dokumentacji naruszenia, ale nie narzucają jednolitego wzoru rejestru. To dobra wiadomość – organizacja może zaprojektować rejestr naruszeń RODO w taki sposób, aby odpowiadał jej skali i sposobowi pracy, byleby obejmował wymagane elementy.

Dlaczego rejestr naruszeń jest przydatny także dla małej instytucji

Rejestr naruszeń często budzi opór w mniejszych organizacjach: „Przecież mamy kilka incydentów na rok, po co formalizować?”. Tymczasem nieliczne incydenty są argumentem za prostym, ale konsekwentnym rejestrem, a nie przeciwko niemu.

Po pierwsze, rejestr naruszeń RODO to dowód należytej staranności. W razie kontroli urząd spyta: co się wydarzyło, jak oceniono ryzyko, dlaczego podjęto taką a nie inną decyzję co do zgłoszenia. Zapisane decyzje i oceny pokazują, że administrator reaguje, analizuje i wyciąga wnioski, zamiast zamiatać sprawy pod dywan.

Po drugie, nawet w małej jednostce te same typy błędów często się powtarzają: źle zaadresowane e-maile, dokumenty zostawione w drukarce, błędnie nadane uprawnienia w systemie. Rejestr pozwala dostrzec wzorce – obszary, gdzie trzeba wzmocnić szkolenia, zmienić konfigurację systemu, wprowadzić dodatkowe zabezpieczenia.

Po trzecie, rejestr jest wspólnym językiem między administracją, IOD, IT i HR. Zamiast opierać się na pamięci i luźnych mailach, organizacja ma jedno miejsce, w którym opisane są kluczowe informacje o naruszeniu ochrony danych – co się stało, kto był zaangażowany, jakie były odczuwalne skutki.

Rejestr jako narzędzie zarządzania ryzykiem, a nie tylko „papier na UODO”

Różnica między „rejestrem dla UODO” a „rejestrem dla organizacji” jest podobna jak między księgowością „pod urząd skarbowy” a rachunkowością zarządczą. Jedno służy głównie rozliczeniom formalnym, drugie – realnemu zarządzaniu.

Formalne minimum rejestru spełnia wymogi RODO, czyli pozwala w każdym momencie przedstawić UODO informację o:

• charakterze naruszenia,
• kategoriach i liczbie osób, których dane dotyczą,
• kategoriach i przybliżonej liczbie rekordów danych,
• skutkach naruszenia,
• podjętych środkach naprawczych i zapobiegawczych.

Rejestr jako narzędzie zarządcze idzie krok dalej: pozwala śledzić trendy, oceniać, czy działania przynoszą efekt, porównywać działy lub procesy. Wystarczy kilka dodatkowych pól (np. przyczyna źródłowa, zaangażowane działy, koszt obsługi incydentu w czasie pracy), aby materiał z rejestru był użyteczny na spotkaniach zarządu czy w planowaniu szkoleń.

Organizacja, która traktuje rejestr naruszeń RODO jako źródło wiedzy o swoich słabościach, ma realną szansę zmniejszyć liczbę poważnych zdarzeń. Ta, która traktuje go wyłącznie jako wymóg formalny, zwykle wraca do tych samych problemów co kilka miesięcy.

Jak rozpoznać, że doszło do naruszenia – granica między „wpadką” a incydentem RODO

Trzy podstawowe typy naruszeń: poufność, dostępność, integralność

Żeby zdecydować, czy sytuacja jest naruszeniem ochrony danych osobowych, dobrze jest spojrzeć na nią przez pryzmat trzech typów naruszeń: poufności, dostępności i integralności.

Naruszenie poufności – dane trafiają do osób nieuprawnionych lub istnieje uzasadnione podejrzenie, że mogły trafić. Przykłady:

• mail z listą płac wysłany omyłkowo do innego pracownika niż dział kadr;
• wydruk z danymi pacjenta pozostawiony w poczekalni;
• zewnętrzny wykonawca otrzymał dostęp do systemu z szerszymi uprawnieniami niż to konieczne.

Naruszenie dostępności – dane nie są dostępne, gdy powinny być. Może oznaczać ich utratę lub czasową niedostępność. Przykłady:

• awaria serwera z bazą klientów, przez kilka godzin brak możliwości obsługi zgłoszeń;
• usunięcie danych przez pomyłkę bez aktualnej kopii zapasowej;
• szyfrowanie danych przez złośliwe oprogramowanie (ransomware).

Naruszenie integralności – dane zostały zmodyfikowane w sposób nieuprawniony lub błędny. Przykłady:

• zmiana statusu świadczeń pacjenta na „zakończone” przez niewłaściwą osobę;
• nieautoryzowane poprawki w historii zatrudnienia pracownika;
• automat integracyjny błędnie nadpisuje pola w bazie klientów.

Kluczowe pytanie: czy w ogóle w grę wchodzą dane osobowe? Jeśli nie – to nadal może być incydent bezpieczeństwa, ale nie naruszenie ochrony danych w rozumieniu RODO.

Zwykła usterka techniczna a naruszenie ochrony danych

Granica między „awarią IT” a „naruszeniem ochrony danych” bywa w praktyce rozmyta. Dobrym sposobem uporządkowania jest porównanie kilku typowych sytuacji.

W codziennej praktyce przydaje się proste pytanie kontrolne: czy to zdarzenie ma związek z danymi osobowymi i czy może dotknąć kogokolwiek poza naszą organizacją? Jeżeli odpowiedź brzmi „tak” – sygnał, że incydent wymaga przynajmniej wstępnej analizy pod kątem rejestru naruszeń.

Kluczowe kryteria: dane osobowe, ryzyko dla osób, powtarzalność

Żeby nie gubić ważnych naruszeń i nie marnować czasu na drobiazgi, warto oprzeć się na kilku prostych kryteriach:

• Czy przetwarzane były dane osobowe? Jeśli nie – zdarzenie nie jest naruszeniem ochrony danych w rozumieniu RODO. Może jednak sygnalizować problem systemowy (awarie, braki zabezpieczeń), który z czasem doprowadzi do zdarzenia z danymi osobowymi.
• Czy osoby fizyczne mogą być realnie dotknięte? Chodzi o konsekwencje typu kradzież tożsamości, szkoda finansowa, utrata pracy, dyskryminacja (np. ujawnienie danych o zdrowiu, poglądach, karalności). Jeśli ryzyko jest istotne – naruszenie prawdopodobnie trzeba będzie zgłosić w ciągu 72 godzin do organu nadzorczego.
• Czy to zdarzenie jest incydentem jednorazowym, czy elementem szerszego problemu? Jednorazowa pomyłka w adresie mailowym to jedno, ale jeśli takie błędy pojawiają się co tydzień, może to oznaczać niewłaściwą konfigurację systemu lub brak szkoleń. Wtedy każdy przypadek trafia do rejestru, a całość staje się materiałem dowodowym przy planowaniu zmian.

Te kryteria nie zastąpią analizy ryzyka, ale pomagają zorientować się, czy w ogóle uruchomić procedurę naruszenia ochrony danych i zastanowić się nad wpisem do rejestru.

Rola pierwszej reakcji pracownika – zanim zacznie się liczyć 72 godziny

Najlepszy rejestr naruszeń RODO nie pomoże, jeśli pracownik, który jako pierwszy widzi problem, zareaguje po kilku dniach lub przemilczy sprawę. Pierwsza linia reakcji to nie IOD ani zarząd, lecz osoby, które pracują na co dzień z danymi.

Pracownik, który zauważa potencjalne naruszenie, powinien w uproszczeniu zrobić trzy rzeczy:

• Zabezpieczyć sytuację na tyle, na ile to możliwe – np. cofnąć błędnie nadane uprawnienia, przerwać wysyłkę, zabrać wydruk z miejsca ogólnodostępnego, wylogować się z pozostawionego bez nadzoru komputera.
• Nie naprawiać „po cichu” śladów – usuwanie maili z serwera, kasowanie logów czy „dogadywanie się” z odbiorcą bez zgłoszenia do przełożonego tylko pogarsza sytuację. Tracą się dowody, a organizacja nie ma pełnego obrazu zdarzenia.
• Niezwłocznie zgłosić incydent zgodnie z przyjętą w organizacji procedurą (do przełożonego, IOD, na dedykowaną skrzynkę lub przez formularz w intranecie).

Od momentu, gdy incydent wpada w ustalony kanał zgłoszeniowy, można mówić o stwierdzeniu incydentu przez organizację, co ma kluczowe znaczenie dla liczenia 72 godzin. Dlatego dobrą praktyką jest zarówno jasna instrukcja dla pracowników, jak i proste, intuicyjne narzędzie do zgłaszania (formularz, adres e‑mail, numer telefonu).

Kiedy zaczyna biec 72-godzinny termin i kto ma go pilnować

Moment naruszenia a moment jego stwierdzenia

Typowe nieporozumienie: „72 godziny liczymy od chwili, gdy doszło do naruszenia”. W rzeczywistości kluczowy jest moment stwierdzenia naruszenia przez administratora, a nie chwila, gdy faktycznie wydarzyło się zdarzenie. To rozróżnienie ma ogromne znaczenie, gdy np. naruszenie wychodzi na jaw po kilku dniach.

„Stwierdzenie naruszenia” w praktyce – kiedy zegar naprawdę startuje

RODO posługuje się pojęciem „stwierdzenia naruszenia”. W praktyce można wyróżnić trzy poziomy wiedzy organizacji o zdarzeniu, które pomagają ustalić moment startu 72 godzin:

• Podejrzenie incydentu – ktoś sygnalizuje, że „coś jest nie tak”: dziwny e‑mail, nietypowe logowanie, telefon klienta, że dostał cudze dane. Na tym etapie nie ma jeszcze pewności, czy chodzi o dane osobowe i czy doszło do naruszenia.
• Potwierdzony incydent bezpieczeństwa – dział IT, helpdesk lub inna jednostka wstępnie potwierdza, że zdarzenie rzeczywiście miało miejsce (np. logi pokazują nieuprawnione logowanie, raport systemu wykazuje masowe pobranie danych).
• Stwierdzone naruszenie ochrony danych osobowych – osoba odpowiedzialna (zwykle IOD lub zespół ds. bezpieczeństwa/RODO) ocenia, że zdarzenie spełnia definicję naruszenia z art. 4 pkt 12 RODO i dotyczy danych osobowych.

Z perspektywy 72 godzin kluczowy jest ostatni etap – moment, w którym organizacja, działając z należytą starannością, mogła i powinna uznać, że ma do czynienia z naruszeniem danych osobowych. Nie chodzi o to, żeby czekać na pełny raport forensic czy pisemne oświadczenia wszystkich stron, ale o moment, w którym rozsądny administrator powiedziałby: „Tak, to jest naruszenie ochrony danych, trzeba przejść do analizy ryzyka i decyzji o zgłoszeniu”.

Jeżeli zgłoszenie od pracownika krąży tydzień po skrzynkach, a nikt formalnie się nim nie zajmuje, to organ nadzorczy przyjmie, że naruszenie zostało „stwierdzone” w momencie pierwszej wiarygodnej informacji, a nie wtedy, gdy ktoś w końcu otworzył maila. Dlatego procedura reagowania musi jasno określać, kto i w jakim czasie weryfikuje zgłoszenie.

Opóźnione wykrycie naruszenia – jak to udokumentować

Zdarza się, że naruszenie wychodzi na jaw dopiero po czasie – np. administrator logów odkrywa, że trzy tygodnie wcześniej doszło do nieautoryzowanego eksportu danych. Z perspektywy terminu 72 godzin istotne są wtedy dwie daty:

• data faktycznego zdarzenia (np. moment wycieku, nieuprawnionego dostępu, skasowania danych),
• data stwierdzenia naruszenia przez administratora – czyli dzień, kiedy organizacja dowiedziała się lub powinna była się dowiedzieć, że miało miejsce naruszenie ochrony danych osobowych.

W rejestrze naruszeń powinno się osobno odnotować obie daty oraz krótko wyjaśnić, dlaczego naruszenie zostało odkryte z opóźnieniem (np. brak alertów w systemie, ręczna analiza logów, błąd w konfiguracji monitoringu). Taki opis często decyduje, czy ewentualne przekroczenie 72 godzin zostanie uznane za uzasadnione, czy za przejaw zaniedbania.

Jeżeli zgłoszenie do UODO następuje po upływie 72 godzin od stwierdzenia, konieczne jest też uzasadnienie opóźnienia w samym zawiadomieniu. Dobrą praktyką jest, aby to wyjaśnienie było spójne z wpisem w rejestrze – w razie kontroli lub pytań organu nie trzeba wówczas „odtwarzać” historii z pamięci.

Kto pilnuje terminu – rola IOD, działu IT i biznesu

W organizacjach często powstaje pytanie: kto jest „właścicielem” 72 godzin? W uproszczeniu można przyjąć podział odpowiedzialności na trzy role:

• Administrator danych (zarząd lub upoważniony menedżer) – formalnie odpowiada za zgłoszenie naruszenia do organu nadzorczego, poinformowanie osób oraz prowadzenie rejestru naruszeń. To on, a nie IOD czy szef IT, jest adresatem obowiązków z RODO.
• IOD lub osoba pełniąca jego funkcję – zwykle odpowiada za koordynację procesu: przyjmuje lub weryfikuje zgłoszenia, prowadzi analizę ryzyka, doradza co do konieczności zgłoszenia i treści zawiadomień, pilnuje harmonogramu działań. Często to właśnie IOD w praktyce zerka na zegarek przy 72 godzinach.
• Działy merytoryczne (IT, HR, sprzedaż, obsługa klienta) – dostarczają faktów, bez których nie da się podjąć decyzji: co dokładnie się stało, jakie dane, ilu osób, jakie zabezpieczenia, czy są kopie, jak długo trwała ekspozycja. Bez szybkiej reakcji tych jednostek nawet najlepszy IOD nie zmieści się w terminie.

Skuteczny model przypomina raczej sztafetę niż piramidę: pierwszy pracownik zgłasza, dział IT ustala fakty techniczne, biznes określa wpływ na procesy i klientów, a IOD administruje całością i proponuje decyzję administratorowi. Żeby sztafeta działała, każdy musi wiedzieć, w którym momencie przekazać „pałeczkę” dalej i w jakim czasie.

72 godziny kalendarzowe czy robocze – i jak liczyć weekendy

RODO mówi o „bez zbędnej zwłoki, nie później niż w ciągu 72 godzin” i chodzi o godziny kalendarzowe, a nie „robocze”. Nie ma znaczenia, czy naruszenie stwierdzono w piątek o 16:00, czy w poniedziałek rano – zegar biegnie tak samo. W praktyce oznacza to, że część analiz i decyzji będzie musiała zapadać poza standardowymi godzinami pracy, szczególnie w podmiotach o podwyższonym ryzyku (np. medycyna, finanse).

Trzy elementy, które pomagają organizacji utrzymać realną gotowość:

• jasna ścieżka kontaktu poza godzinami pracy – np. dyżurny numer telefonu do osoby odpowiedzialnej za bezpieczeństwo, dyżury IOD w razie poważnych incydentów;
• uprzednio uzgodniona „drabinka decyzyjna” – kto może zatwierdzić zgłoszenie do UODO, gdy zarząd jest niedostępny;
• szablony zgłoszeń – tak przygotowane, by przy braku części danych można było wysłać zgłoszenie wstępne, a później je uzupełnić (RODO dopuszcza wysłanie informacji „na raty”).

Lepsze jest zgłoszenie wstępne w 70. godzinie, z zapowiedzią uzupełnienia informacji, niż dopieszczony raport, który trafia do organu po tygodniu. Rejestr naruszeń powinien odzwierciedlać ten sposób działania – z miejscem na odnotowanie kolejnych aktualizacji.

Jak powinien wyglądać rejestr naruszeń – minimalne i rozszerzone pola

Minimum wymagane przez RODO

RODO wprost nie wylicza pól, które muszą znaleźć się w rejestrze naruszeń, ale wskazuje elementy, które administrator musi móc wykazać przy każdym naruszeniu. Da się to przełożyć na zestaw absolutnego minimum, bez którego rejestr staje się mało użyteczny:

• Data i godzina stwierdzenia naruszenia – baza do liczenia 72 godzin.
• Data i przybliżony czas wystąpienia zdarzenia – potrzebne do oceny skali i ryzyka (jak długo dane były narażone).
• Krótki opis naruszenia – co się wydarzyło, w jakich okolicznościach (bez elaboratów, ale na tyle konkretnie, by osoba z zewnątrz zrozumiała sytuację).
• Rodzaj danych osobowych – dane zwykłe, szczególne kategorie (zdrowie, poglądy, seksualność), dane dotyczące wyroków, dane finansowe, loginy, hasła.
• Szacowana liczba osób, których dotyczy naruszenie – choćby zgrubnie: jednostki, dziesiątki, setki.
• Szacowana liczba rekordów lub zbiorów danych – czy chodzi o jeden plik, bazę, cały system.
• Możliwe konsekwencje dla osób – kilka zdań o potencjalnym wpływie: utrata kontroli nad danymi, wyciek informacji wrażliwych, ryzyko nadużyć finansowych.
• Opis zastosowanych lub planowanych środków naprawczych – co już zrobiono i co jest w planie (np. zablokowano konto, wdrożono 2FA, przeprowadzono szkolenie).
• Decyzja o zgłoszeniu (lub braku zgłoszenia) do UODO – z datą i krótkim uzasadnieniem.
• Informacja o powiadomieniu osób, których dane dotyczą – czy poinformowano, kiedy, jaką drogą; jeśli nie, dlaczego.

Te pola wystarczają, by z jednej strony spełnić wymóg „udokumentowania naruszenia”, a z drugiej – mieć podstawę do ewentualnej obrony przed zarzutem braku reakcji lub spóźnionego zgłoszenia.

Rozbudowany rejestr jako narzędzie zarządcze

Gdy organizacja ma już opanowane minimum, można zacząć traktować rejestr jako źródło wiedzy, a nie tylko obowiązek. Wtedy przydają się dodatkowe kolumny, które pozwalają diagnozować trendy i porównywać obszary:

• Kategoria przyczyny – np. błąd ludzki, błąd systemu, atak zewnętrzny, błąd procesu, brak lub nieadekwatne upoważnienie.
• Proces biznesowy – do jakiego procesu należy incydent (rekrutacja, obsługa klienta, rozliczenia, marketing).
• System lub aplikacja – identyfikacja systemu źródłowego (daje wgląd, czy częściej „psuje się” CRM, system kadrowy, czy może poczta e‑mail).
• Jednostka organizacyjna – dział, oddział, spółka z grupy; przy większych organizacjach umożliwia porównania między jednostkami.
• Szacunkowy czas obsługi incydentu – czas pracy w godzinach (IOD, IT, biznes); to argument przy planowaniu zasobów.
• Ocena ryzyka (np. niski/średni/wysoki) – nawet prostą, trójstopniową skalą, pod warunkiem spójnych kryteriów.
• Informacja o działaniach prewencyjnych – np. „zmieniono procedurę nadawania uprawnień”, „dodano walidację adresu e‑mail”, „przeprowadzono szkolenie e‑learningowe”.

Tego typu dane pozwalają spojrzeć na naruszenia jak na „objawy choroby” w organizacji. Jeżeli 80% zdarzeń w jednym roku to błędne wysyłki e‑maili, problemem nie jest pojedynczy pracownik, tylko konfiguracja systemu lub brak dobrych wzorców pracy z pocztą. Rejestr, który to pokazuje czarno na białym, staje się argumentem przy rozmowie z działem IT lub zarządem.

Poziomy szczegółowości – jedna tabela czy kilka warstw

Organizacje często wahają się, czy rejestr ma być „grubą księgą” z całym opisem, czy prostym spisem z odniesieniem do innych dokumentów. Dają się wyróżnić trzy modele:

• Model minimalistyczny – jedna tabela z krótkim opisem i podstawowymi polami. Plus: łatwy w utrzymaniu, mniejsze ryzyko błędów. Minus: szczegóły incydentu „rozsypują się” po mailach i raportach.
• Model warstwowy – w rejestrze tylko kluczowe dane i sygnatura/ID sprawy, a pełny opis (analiza ryzyka, korespondencja, raport IT) w osobnym pliku lub systemie. Plus: przejrzystość i kontrola nad tym, kto ma dostęp do szczegółów. Minus: wymaga konsekwentnego opisywania „gdzie leży reszta dokumentacji”.
• Model „wszystko w jednym” – rozbudowany rejestr z polami na pełną analizę, listę załączników, przebieg komunikacji. Plus: wszystko w jednym miejscu. Minus: plik lub system szybko robi się ciężki, mniej czytelny przy większej liczbie incydentów.

Przy większych organizacjach dobrze sprawdza się model warstwowy: rejestr zawiera skondensowane informacje, a szczegóły techniczne i analizy pozostają w dedykowanych narzędziach (systemy ticketowe, repozytoria dokumentów, notatki z posiedzeń zespołu incydentowego).

Ochrona danych w samym rejestrze naruszeń

Paradoksalnie, rejestr naruszeń sam w sobie jest zbiorem danych osobowych – często bardzo wrażliwych (opis naruszeń medycznych, finansowych, dane pracowników odpowiedzialnych za błędy). Dlatego przy projektowaniu pól warto zadać kilka pytań:

• Czy potrzebne są pełne dane osób, których dotyczy naruszenie? Często wystarczy liczba osób, identyfikator sprawy lub zakres (np. „klienci z kampanii X”), a szczegółowa lista imion i nazwisk znajduje się w innym, ograniczonym systemie.
• Kto ma dostęp do rejestru? Nie ma powodu, by każdy przełożony znał szczegóły wszystkich incydentów. Typowy poziom dostępu: IOD, wybrane osoby z bezpieczeństwa IT, w razie potrzeby – zarząd.
• Jak długo przechowywać dane? Część organizacji przyjmuje np. 5‑letni okres przechowywania wpisów w rejestrze, po czym pozostawia jedynie zanonimizowane statystyki. Ważne, żeby zasada była spójna i opisana w polityce.

Sam format rejestru (Excel, system) ma drugorzędne znaczenie, jeśli nie zadba się o podstawową higienę: kontrolę dostępu, kopie zapasowe i jasne zasady przechowywania.

Gdzie i w czym prowadzić rejestr – Excel, system ticketowy czy dedykowane narzędzie

Arkusz kalkulacyjny – prostota kontra skalowalność

Najczęstszy punkt startowy to po prostu Excel lub inny arkusz kalkulacyjny. Dla wielu organizacji to w pełni wystarczające rozwiązanie, zwłaszcza gdy:

• liczba incydentów rocznie jest niewielka,

Najczęściej zadawane pytania (FAQ)

Co to jest rejestr naruszeń RODO i czym różni się od rejestru incydentów bezpieczeństwa?

Rejestr naruszeń RODO to zestawienie wszystkich przypadków naruszenia ochrony danych osobowych, czyli sytuacji, w których naruszono poufność, dostępność lub integralność danych osobowych i pojawiło się choćby potencjalne ryzyko dla osób. Zapisuje się tam m.in. co się stało, jakie dane były objęte zdarzeniem, ilu ludzi dotyczyło naruszenie i jakie działania naprawcze podjęto.

Rejestr incydentów bezpieczeństwa jest szerszy – obejmuje również czysto techniczne zdarzenia, które w ogóle nie dotykają danych osobowych (np. restart serwera bez utraty danych). Można prowadzić jeden zbiorczy rejestr incydentów IT plus naruszeń RODO albo dwa rozdzielne – ważne, żeby naruszenia ochrony danych osobowych dało się jasno wyodrębnić i udokumentować zgodnie z wymogami RODO.

Skąd się bierze termin 72 godzin na zgłoszenie naruszenia i od kiedy liczyć ten czas?

Termin 72 godzin wynika bezpośrednio z RODO. Administrator ma obowiązek zgłoszenia naruszenia organowi nadzorczemu (np. UODO) „nie później niż 72 godziny” od momentu stwierdzenia naruszenia, jeśli istnieje ryzyko naruszenia praw lub wolności osób fizycznych. Chodzi o czas od chwili, gdy organizacja zorientowała się, że doszło do naruszenia ochrony danych, a nie od samego zaistnienia błędu czy awarii.

W praktyce liczy się moment, w którym ktoś kompetentny w organizacji (np. IOD, kierownik działu) może racjonalnie ocenić, że mamy do czynienia z naruszeniem ochrony danych, a nie zwykłą usterką. Nie ma obowiązku zgłaszania incydentów czysto technicznych, w których nie występują dane osobowe ani nie widać ryzyka dla osób.

Jakie zdarzenia trzeba wpisać do rejestru naruszeń, a jakich nie trzeba rejestrować?

Do rejestru naruszeń trafiają wszystkie potwierdzone naruszenia ochrony danych osobowych, niezależnie od tego, czy zostały zgłoszone do UODO, czy nie. Typowe przykłady to: wysyłka maila z danymi osobowymi do nieuprawnionego odbiorcy, błędnie nadane uprawnienia w systemie, które umożliwiają wgląd w dane, dłuższa niedostępność systemu skutkująca opóźnieniem w świadczeniu usług dla osób.

Nie ma obowiązku wpisywania do rejestru naruszeń zdarzeń, w których w ogóle nie występują dane osobowe (np. 30-minutowa awaria sieci uniemożliwiająca logowanie, po której nie stwierdzono utraty ani zmiany danych). Tego typu sytuacje można ujmować wyłącznie w rejestrze incydentów IT. Granica bywa płynna, dlatego przy wątpliwościach lepiej takie zdarzenie krótko opisać i ocenić, czy dotyczy danych osobowych i praw osób.

Jakie informacje powinny się znaleźć w rejestrze naruszeń RODO?

Minimalny zakres danych, który wynika z RODO i wytycznych organu nadzorczego, obejmuje w szczególności:

• krótki opis charakteru naruszenia (co się stało, kiedy, w jakich okolicznościach),
• kategorie i przybliżoną liczbę osób, których dane dotyczą,
• kategorie i szacunkową liczbę rekordów/zbiorów danych, których dotyczy zdarzenie,
• opis możliwych lub zaistniałych skutków naruszenia,
• opis zastosowanych lub proponowanych środków naprawczych i zapobiegawczych.

Jako „wersja rozszerzona” (bardziej zarządcza) rejestr może mieć dodatkowe pola, np. przyczynę źródłową naruszenia (błąd ludzki, brak procedury, usterka techniczna), zaangażowane działy, czas poświęcony na obsługę incydentu, czy naruszenie było zgłoszone do UODO i/lub osób, których dane dotyczą. Dzięki temu rejestr staje się narzędziem do analizy trendów, a nie tylko „papierem na wypadek kontroli”.

Czy mała organizacja też musi prowadzić rejestr naruszeń RODO?

Tak. Obowiązek dokumentowania naruszeń ochrony danych osobowych dotyczy każdego administratora – zarówno dużej korporacji, jak i małej fundacji, szkoły czy urzędu gminy. Skala i forma rejestru mogą być jednak dostosowane do wielkości i charakteru działalności. W małej jednostce często wystarczy prosty arkusz z kilkunastoma kolumnami.

Różnica polega na poziomie rozbudowania narzędzia. Większa organizacja wprowadzi rozbudowane kategorie, integrację z systemami IT i raporty dla zarządu. Mniejsza może ograniczyć się do kilku kluczowych pól, ale prowadzić rejestr konsekwentnie. Nawet kilka wpisów rocznie pomaga wykryć powtarzające się błędy, które łatwo przeoczyć, gdy opieramy się tylko na pamięci pracowników.

Jak odróżnić zwykłą awarię IT od naruszenia ochrony danych osobowych?

Podstawowy filtr to pytanie: czy w ogóle mamy do czynienia z danymi osobowymi i czy zdarzenie uderza w poufność, dostępność lub integralność tych danych. Krótkotrwała awaria zasilania, po której system wraca do pracy bez utraty danych i bez realnego wpływu na prawa osób, jest typową awarią techniczną, którą można opisać w logach IT. Natomiast wielogodzinny brak dostępu do systemu kadrowego, przez co pracownicy nie dostają dokumentów na czas, zwykle kwalifikuje się jako naruszenie dostępności danych osobowych.

Praktycznie warto porównać dwa scenariusze: awaria sieci w nocy, gdy nikt nie pracuje – zazwyczaj incydent techniczny; ten sam problem w godzinach przyjęć pacjentów lub klientów, uniemożliwiający realizację świadczeń – duże ryzyko naruszenia praw osób, a więc potencjalne naruszenie RODO. Kontekst (czas, proces, wrażliwość danych) jest tu równie ważny, jak sama przyczyna techniczna.

Czy każde naruszenie z rejestru trzeba zgłaszać do UODO w ciągu 72 godzin?

Nie. Zgłoszenia do organu nadzorczego wymagają tylko te naruszenia ochrony danych osobowych, które wiążą się z ryzykiem naruszenia praw lub wolności osób fizycznych. Jeśli po analizie ryzyka wychodzi, że jest ono małe (np. omyłkowo wysłano dane do stałego, upoważnionego podmiotu przetwarzającego, który natychmiast je usunął), naruszenie pozostaje wyłącznie w rejestrze wewnętrznym.

Każde naruszenie trzeba jednak udokumentować, również takie, które nie zostało zgłoszone do UODO. W rejestrze warto odnotować decyzję o niezgłaszaniu wraz z uzasadnieniem (krótki opis oceny ryzyka). Dzięki temu przy ewentualnej kontroli można pokazać, że organizacja świadomie podejmuje decyzje, a nie ignoruje incydentów.