Ze względu na fakt, że rozwiązania informatyczne wspierają działanie większości organizacji i procesów biznesowych w nich zachodzących, coraz trudniej jest zapanować nad przechowywaniem, przetwarzaniem oraz usuwaniem danych osobowych.
Złożoność systemów informatycznych i ich wzajemne powiązania nie pozwalają na ręczną obsługę procedur retencji, obsługę prawa do zapomnienia czy też uzyskanie informacji o celu i miejscu przetwarzania danych osobowych w całym ekosystemie organizacji.
Czym jest retencja danych
Warto zauważyć, że jako organizacje jesteśmy odpowiedzialni za właściwe przetwarzanie danych osobowych, a także po ustaniu celu ich przetwarzania, za ich usunięcie. Wszystkie przetwarzane przez nas dane osobowe powinny mieć określony „niezbędny” dla siebie okres przechowywania. Ten „niezbędny” czas na przechowywanie danych nazywamy retencją danych.
Z gromadzeniem danych oraz ich przechowywaniem radzimy sobie całkiem dobrze. Problemy pojawiają się w momencie, gdy kończy się cel ich przetwarzania i zgodnie z wymogami RODO powinniśmy je usunąć.
Konieczność obsługi retencji danych w ramach poszczególnych procesów biznesowych wynika bezpośrednio z RODO i wymogu ograniczenia przechowywania danych (art. 5 ust. 1 lit. e)). Zgodnie z treścią tego przepisu:
Dane osobowe muszą być przechowywane w formie umożliwiającej identyfikację osoby, której dane dotyczą, przez okres nie dłuższy, niż jest to niezbędne do celów, w których dane te są przetwarzane; dane osobowe można przechowywać przez okres dłuższy, o ile będą one przetwarzane wyłącznie do celów archiwalnych w interesie publicznym, do celów badań naukowych lub historycznych lub do celów statystycznych na mocy art. 89 ust. 1, z zastrzeżeniem że wdrożone zostaną odpowiednie środki techniczne i organizacyjne wymagane na mocy niniejszego rozporządzenia w celu ochrony praw i wolności osób, których dane dotyczą („ograniczenie przechowywania").
Niemożliwe „ręczne” zarządzanie?
Zarządzanie retencją (rozumianą jako przechowywanie i usuwanie danych w sposób planowany) wymaga na ogół współpracy pomiędzy osobami właściwymi do kwestii prawnych (np. IODO, compliance, etc.) i technicznych. W przypadku większych organizacji bardzo trudne (lub wręcz niemożliwe) jest „ręczne” zarządzanie retencją, np. przekazując cyklicznie informacje o potrzebie usuwania danych do pracowników – na ogół nie dochodzi do faktycznego usuwania.
Oznacza to konieczność zaangażowania osób technicznych – administratorów baz danych, systemów, tak aby zidentyfikować:
- Gdzie dane są przetwarzane?
- Jakie zasoby są wykorzystywane do przetwarzania danych?
- Jak długo powinny przetwarzane?
- W jaki sposób je usuwać / anonimizować?
Osoby techniczne nie są jednak w stanie samodzielnie podjąć decyzji o usuwaniu danych – długość przetwarzania danych nie jest immanentnie powiązana z określoną kategorią danych (np. nr pesel) tylko z celem przetwarzania danych. Gdyby długość przetwarzania danych była powiązana wyłącznie z ich kategorią, sprawa byłaby dużo łatwiejsza. Oczywiście w dalszym ciągu problemem byłoby przefiltrowanie bazy danych w celu ich identyfikacji, niemniej po dokonaniu tego zadania wystarczyłoby usuwać je zgodnie z przyjętymi zasadami.
Tak jednak nie jest – długość przetwarzania danych powiązana jest z celem przetwarzania danych – jest to więc głównie problem prawny. To w ramach rejestru czynności (repozytorium procesów przetwarzania danych) należy zdefiniować, jaki jest cel przetwarzania danych i jednocześnie okres ich wykorzystania.
Jak zarządzać retencją danych
Punktem wyjścia prawidłowego (pod kątem technicznym) zarządzania retencją jest prawidłowo wypełniony rejestr czynności. Jednak nawet najlepiej wypełniony rejestr wskazujący procesy, cele i zasoby, które ich dotyczą (aktywa IT), nie jest wystarczający, aby zarządzać konkretnymi rekordami w bazach danych czy informacjami zawartymi w pojedynczych plikach, np. doc, xls, pdf, ponieważ:
- Te same kategorie danych mogą być przetwarzane jednocześnie w różnych celach (np. ten sam rekord – adres e-mail – w celu zawarcia umowy i dochodzenia roszczeń).
- Na poziomie tej samej bazy danych poszczególne kategorie danych mogą przetwarzane w różnych celach.
- Te same kategorie danych przetwarzane w tych samych celach mogą znajdować się w różnych zasobach np. różnych systemach / bazach danych/plikach.
- Dane często przetwarzane są w sposób rozproszony / nieustrukturyzowany na stacjach roboczych pracowników, w pojedynczych plikach.
- Na poziomie baz danych „nie widać” celów przetwarzania danych – trzeba je dopiero przypisać do poszczególnych pól, zależą one od kontekstu biznesowego.
- Zasoby „żyją”, tj. pojawiają się nowe systemy, bazy, pliki, nowe kategorie danych w ramach tych samych baz danych i nowe dane w ramach tych samych kategorii.
W związku z powyższym prawidłowe zarządzanie retencją pod względem prawnym, ale i technicznym wymaga:
- Zdefiniowania procesów przetwarzania danych: celów i zasobów, które ich dotyczą.
- Identyfikacji poszczególnych kategorii danych w poszczególnych zasobach (systemy, bazy, zasoby lokalne, etc.).
- Przypisania celów do zidentyfikowanych kategorii.
- Określenia długości przetwarzania danych oznaczonych określonymi celami.
Autor: Piotr Medyński
Architekt oprogramowania, przedsiębiorca, działacz społeczny. Absolwent Wydziału Cybernetyki Wojskowej Akademii Technicznej na kierunku Informatyka specjalność Systemy Informatyczne. Posiada ponad 20 lat doświadczenia w realizacji złożonych projektów informatycznych dla klientów z branży bankowej, ubezpieczeniowej, telekomunikacyjnej, energetycznej i finansowej. Wspótworzył kilka firm technologicznych: Softwarehouse ISOLUTION, NewOps, eSignaller, Wizards, Teamtoolbox. Zbudował społeczność meetupu Management 3.0, która zorganizowała ponad 90 wydarzeń i skupiła wokół siebie ponad 5000 osób.
