Konsultacje projektu zakończyły się 5 sierpnia o godz. 23.59 czasu środkowoeuropejskiego letniego. EROD zapowiada, że dopiero po konsultacjach ustali harmonogram praktycznego wdrożenia formularza przez krajowe organy ochrony danych. To oznacza, że dokument nie zastąpił jeszcze polskiego formularza i nie zmienił terminów wynikających z RODO. Dziś administrator w Polsce nadal zgłasza naruszenie zgodnie z procedurą UODO, między innymi przez usługę na biznes.gov.pl.

127 wierszy nie oznacza 127 obowiązkowych pytań

Projekt jest jednak ważny, bo pokazuje, jak europejscy regulatorzy chcą ujednolicić język incydentów. Jego główna tabela ma wiersze oznaczone od 0 do 126 i siedem zasadniczych części: typ zgłoszenia; dane administratora i osoby zgłaszającej; informacje początkowe; dalszy opis naruszenia; komunikację z osobami; inne kwestie, w tym charakter transgraniczny; oraz załączniki. Część pól pojawia się tylko po wybraniu określonej odpowiedzi.

Wbudowane katalogi są rozbudowane. Projekt wymienia 25 rodzajów incydentu, od nadużycia uprawnień pracownika i phishingu po błędnego odbiorcę wiadomości, złą konfigurację, utratę papierów, ransomware i niezamierzoną publikację. Oferuje 21 typów naruszonych danych oraz 15 możliwych skutków dla człowieka, takich jak kradzież tożsamości, strata finansowa, dyskryminacja, szkoda dla reputacji lub utrata kontroli nad danymi.

Takie listy mogą ograniczyć nieporównywalne opisy. Ransomware szyfrujące kartoteki pacjentów, arkusz wysłany złemu odbiorcy i publiczny link do dokumentów nie powinny trafiać do organu jako ten sam ogólny „incydent informatyczny”. Formularz wymusza rozróżnienie poufności, integralności i dostępności danych, a także wskazanie przyczyny, systemów, zabezpieczeń oraz prawdopodobnych skutków.

Cztery wymagania RODO rozpisane na pełną chronologię

RODO wymaga w zgłoszeniu co najmniej czterech grup informacji: opisu charakteru naruszenia wraz z kategoriami i przybliżoną liczbą osób oraz rekordów; danych kontaktowych inspektora lub innego punktu kontaktowego; opisu możliwych konsekwencji; oraz środków zastosowanych albo proponowanych w celu zaradzenia zdarzeniu i ograniczenia szkód. Projekt EROD rozwija te cztery grupy w znacznie dokładniejszą chronologię.

Pyta między innymi o datę zdarzenia, moment stwierdzenia naruszenia, sposób wykrycia, przyczynę opóźnienia po przekroczeniu 72 godzin, dowody wyprowadzenia danych, działające wcześniej zabezpieczenia, metodę oceny ryzyka, środki zapobiegające powtórce, informowanie poszkodowanych oraz zgłoszenia do policji lub innych organów. Pozwala też dołączyć ocenę ryzyka, raport z badania incydentu, wiadomość phishingową, żądanie okupu i kopię komunikatu do osób.

To więcej niż wygodny formularz. Układ dokumentu podpowiada, jakie dowody organizacja powinna umieć szybko odnaleźć. Jeżeli po ataku nikt nie zna właściciela systemu, zakresu logów, kategorii danych ani treści umowy z dostawcą, gotowe listy odpowiedzi nie skrócą dochodzenia. Firma będzie jedynie szybciej widziała, których informacji nie ma.

Zegar rusza po uzyskaniu rozsądnej pewności

Najbardziej mylący moment przychodzi na początku. Zegar nie musi ruszać od każdej anomalii technicznej. Wytyczne EROD uznają administratora za świadomego naruszenia, gdy ma rozsądny stopień pewności, że doszło do incydentu bezpieczeństwa i że dane osobowe zostały naruszone. Dopuszczalne jest krótkie postępowanie wstępne. Nie można jednak rozciągać go tylko po to, aby odsunąć moment stwierdzenia naruszenia.

Po uzyskaniu tej pewności administrator powinien bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin, zgłosić naruszenie właściwemu organowi, chyba że jest mało prawdopodobne, by wywołało ryzyko dla praw lub wolności ludzi. UODO podkreśla, że decyzję musi poprzedzać analiza, a jej wynik należy zapisać również wtedy, gdy firma postanawia nie zgłaszać zdarzenia.

Trzy poziomy reakcji, których formularz nie wybierze

W praktyce powstają trzy poziomy reakcji. Każde stwierdzone naruszenie danych trzeba udokumentować wewnętrznie. Gdy naruszenie może powodować ryzyko, dochodzi zgłoszenie do organu. Gdy prawdopodobne jest wysokie ryzyko, administrator powinien dodatkowo, bez zbędnej zwłoki, zawiadomić osoby, których dane dotyczą, chyba że zachodzi jeden z wyjątków określonych w art. 34 RODO. Formularz rejestruje wynik tej oceny, ale go nie wylicza.

Sama liczba rekordów nie przesądza wyniku. Jeden błędnie ujawniony dokument medyczny może stworzyć poważniejsze zagrożenie niż większy zbiór danych technicznych. Znaczenie mają rodzaj danych, łatwość identyfikacji osoby, możliwe wykorzystanie informacji, liczba odbiorców, czas ekspozycji, skuteczność szyfrowania, podatność osób oraz to, czy dane da się odzyskać lub trwale usunąć.

Niepełne zgłoszenie jest lepsze niż czekanie na pełny obraz

Projekt EROD uczciwie dopuszcza odpowiedzi „do ustalenia” i zgłoszenie niepełne. Tak samo UODO wskazuje, że gdy w terminie nie ma wszystkich informacji, należy przekazać to, co już wiadomo, zaznaczyć zgłoszenie wstępne, a dane uzupełniać później. Niepewność nie jest więc automatycznie powodem do czekania do siedemdziesiątej drugiej godziny.

Pierwsze 72 godziny trzeba zaprojektować przed incydentem

Na podstawie formularza i wytycznych można ułożyć praktyczną kolejność pracy. W pierwszej fazie organizacja powinna zabezpieczyć logi i dowody, ograniczyć trwający incydent, zapisać źródło pierwszej informacji oraz moment osiągnięcia rozsądnej pewności. Musi też ustalić, kto jest administratorem, a kto procesorem, bo procesor ma zawiadomić administratora bez zbędnej zwłoki, a nie prowadzić własny kalendarz do 72 godzin.

W drugiej fazie trzeba zmapować systemy, kategorie danych, grupy osób i przybliżoną liczbę rekordów. Równolegle należy sprawdzić, czy ucierpiała poufność, integralność lub dostępność, jakie zabezpieczenia działały w chwili zdarzenia i czy nieuprawniony odbiorca mógł faktycznie odczytać albo wykorzystać dane.

Dopiero na tej podstawie powinna powstać ocena prawdopodobieństwa i wagi skutków. Projekt formularza wymaga nie tylko końcowej etykiety ryzyka, ale także opisu metodologii i uwzględnionych czynników. To istotna zmiana jakościowa: odpowiedź „ryzyko niskie” bez pokazania przesłanek będzie łatwiejsza do zakwestionowania niż udokumentowany tok rozumowania.

Przed upływem terminu administrator wybiera właściwą ścieżkę: zapis wewnętrzny z uzasadnieniem braku zgłoszenia albo zgłoszenie kompletne bądź wstępne do organu. Osobno rozstrzyga, czy wysokie ryzyko wymaga komunikatu do ludzi. Redakcyjny podział na fazy nie tworzy nowych terminów prawnych; ma zapobiec sytuacji, w której cała ocena zaczyna się dopiero pod koniec trzeciej doby.

Największa luka pozostaje poza formularzem. Dokument może sprawdzić, czy zaznaczono kategorię danych i wpisano liczbę osób, ale nie wie, czy szacunek jest oparty na pełnych logach, czy na przypuszczeniu. Nie oceni też, czy dostawca chmury przekazał administratorowi informacje wystarczająco szybko. Uporządkowany rekord może więc opisywać zarówno rzetelne dochodzenie, jak i pozorną pewność.

Dla małej firmy wspólny formularz może być realnym ułatwieniem, zwłaszcza bez własnego inspektora ochrony danych. Największy zysk pojawi się jednak przed incydentem. Lista systemów i dostawców, role decyzyjne, całodobowe kontakty, zasady zachowania logów, wzór oceny ryzyka oraz ścieżka zatwierdzania zgłoszenia skracają reakcję bardziej niż sama zamiana jednego formularza na drugi.

Po zakończeniu konsultacji trzeba obserwować dwie decyzje: ostateczny kształt projektu i termin wdrożenia przez organy krajowe. Do tego czasu przedsiębiorca nie powinien czekać na europejskie narzędzie ani traktować wersji 1.0 jak nowego prawa. Najlepszym zastosowaniem projektu już dziś jest potraktowanie jego 127 wierszy jako testu gotowości: czy organizacja potrafiłaby udzielić rzetelnych odpowiedzi, zanim skończy się termin na pierwsze zgłoszenie.