Wizards | Rodo w IT - Retencja danych

Czy wiesz, w jaki sposób skutecznie zarządzać procesem retencji danych?
Kiedy pomyśleć o automatyzacji tego procesu?
Jak wygląda proces retencji danych od strony IT i jakie wyzwania mogą się z nim wiązać?

W trzecim już artykule z cyklu “RODO w IT” wspólnie z Mirkiem pochylimy się nad tematem wyzwań związanych z retencją danych.

Z artykułu dowiesz się m.in.:

Na co zwrócić uwagę myśląc o wdrożeniu lub usprawnieniu procesu retencji danych zarówno po stronie IT, jak i compliance
Jak poradzić sobie z retencją w sytuacji, w której mamy więcej niż 2 systemy w organizacji
Jak skutecznie usuwać dane zgodnie z wymogami RODO i uwzględnieniem wszelkich podstaw prawnych

Zapraszamy do lektury!

Artur Żórawski, Founder i CTO Wizadrs

Architekt IT z ponad 20 letnim stażem, autor pomysłów na rozwiązania IT do detekcji, anonimizacji i retencji danych.

dr Mirosław Gumularz, Radca Prawny GKK Gumularz Kozik

Audytor wewnętrzny systemu zarządzania bezpieczeństwem informacji wg normy ISO 27001:2013. Członek Grupy Roboczej ds. Ochrony Danych Osobowych przy Ministerstwie Cyfryzacji.

———————————————————

Skuteczne zarządzanie procesem retencji danych

Mirosław Gumularz (MG): W poprzednich dwóch artykułach opowiadaliśmy o tym, co RODO zmieniło w branży IT, a także o anonimizacji, temacie, który do tej pory zdecydowanie był bliższy osobom po tej “technicznej” stronie. Kolejnym z wymogów RODO, z którym mierzy się dziś większość firm, a w szczególności działy compliance, jest ograniczenie przechowywania danych osobowych, czyli retencja danych. Oczywiście łączy się to z omawianą poprzednio kwestią anonimizacji, która jest środkiem realizacji wymogu czasowego ograniczenia przechowywania danych osobowych i alternatywą dla „fizycznego” usunięcia danych.

Faktem jest, że RODO nie pozwala przetwarzać danych osobowych w nieskończoność. Zazwyczaj nie mówi nam też, ile czasu możemy przetwarzać te dane. Nawet tam, gdzie przepisy prawa, co jest raczej rzadkością, definiują jak długo można przetwarzać dane, na ogół jest cała masa wyjątków. To jest zadanie właśnie dla działów compliance. To one znając cele i kategorie danych, określają okresy ich retencji, czyli przechowywania.

Tutaj sprawa zaczyna się komplikować od strony technicznej, a konkretnie w zakresie kontrolowania procesu usuwania danych z systemów zgodnie z zebranymi zgodami. Niezależnie od długości przetwarzania ustalonej przez osoby odpowiedzialne za compliance, osoby techniczne muszą wiedzieć, że bez względu na to, jak długi ten okres będzie, muszą zmierzyć się z tym, że kiedyś dane będą musiały być usunięte.

Przetwarzanie danych przy założeniu, że nie będziemy mieć narzędzi do ich usuwania, może naruszać regułę zawartą w art. 25 ust. 1 RODO, tj. privacy by design. Ciekawy w tym kontekście jest problem usuwania danych przetwarzanych przy wykorzystaniu technologii Blockchain, który właśnie taki przypadek obrazuje. Pojawia się pytanie, czy można przetwarzać dane skoro wiemy, że kiedyś tam w przyszłości może być problem całkowitego ich usunięcia. Polecam w tym zakresie rekomendację CNIL (francuski organ nadzorczy): Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data.

Podsumowując. Chcąc skutecznie zarządzać procesem retencji, trzeba oczywiście dbać o stronę formalno-prawną. To jednak nie wystarczy. Musimy również wiedzieć dokładnie:

w jakich systemach gromadzone są dane,
do jakich celów są wykorzystywane
czy jesteśmy w stanie przypisać ten cel do określonych kategorii danych
i czy, kiedy oraz w jaki sposób zaplanowana jest ich retencja.

W praktyce oznacza to, że trzeba wiedzieć, jak te dane usunąć i mieć pomysł na to, w jaki sposób to robić w zależności od celów ich przetwarzania.

Dlaczego to jest ważne?

Przykładowo może okazać się, że ta sama kategoria danych (np. nr pesel, ID użytkownika) przetwarzana przy wykorzystaniu tego samego systemu, lub różnych systemów, w zależności od celu przetwarzania będzie mieć różny okres retencji (usuwania danych).

Co więcej może być tak, że w ramach jednego procesu różne kategorie dane mogą mieć różne cele i okresy retencji np. dane zbierane poprzez formularz rejestracji użytkownika. Może być tak, że część z tych danych jest niezbędna do realizacji celu zawarcia umowy, a część z nich np. służy do weryfikacji tożsamości co nie zawsze jest niezbędne do zawarcia umowy.

Artur Żórawski (AŻ): Dodatkowo od strony technicznej jest to o tyle wyzwanie, że często w jednej organizacji jest wielu dostawców rozwiązań informatycznych. Wiele osób uczestniczy tym samym w procesie wytwarzania i rozwijania oprogramowania. Z rozmów z naszymi Klientami wiemy, że często w związku z tym problematyczne staje się zlokalizowanie wszystkich danych użytkowników we wszystkich systemach oraz ich kompleksowa retencja zgodnie z wymogami RODO.

MG: Warto jeszcze dodać, że jednym z wymogów RODO jest podanie na żądanie informacji o źródle danych, czy celu przetwarzania danych osobowych, co w wielu przypadkach jest w tym kontekście problematyczne zwłaszcza, jeśli chodzi o podanie źródła. Pojęcie źródła danych jest bardzo szeroko zdefiniowane w RODO i nie można wykluczyć takiego kierunku wykładni, która obejmuje także “narzędzie”, system wykorzystywany do przetwarzania danych. Dla przykładu w kontekście przetwarzania danych medycznych RODO wskazuje, że:

„Do danych osobowych dotyczących zdrowia należy zaliczyć wszystkie dane o stanie zdrowia osoby, której dane dotyczą, ujawniające informacje o (…)

niezależnie od ich źródła, którym może być na przykład lekarz lub inny pracownik służby zdrowia, szpital, urządzenie medyczne lub badanie diagnostyczne in vitro”.

Kiedy warto zacząć myśleć o automatyzacji procesu?

MG: Dochodzimy w tym momencie do pytania: w jaki sposób najlepiej tym procesem zarządzić? Faktem jest, że im większa organizacja, tym większym problemem staje się brak odpowiednich narzędzi ułatwiających zarządzanie retencją danych na przykład poprzez automatyzację procesu.

AŻ: To prawda. Pytanie tylko, kiedy na taką automatyzację się zdecydować. Jeżeli chodzi o retencje danych w większych organizacjach trzeba zauważyć, że problem usuwania danych i retencji rośnie wykładniczo wraz ze wzrastającą ilością systemów.

Jeżeli firma ma jeden system, to retencja jest stosunkowo prosta. Automatyzacja jest niepotrzebna.
Jeżeli natomiast mamy więcej systemów, a do tego dołożymy dużą ilość celów przetwarzania danych, proces retencji zaczyna być wymagający.
Przy bardzo dużych organizacjach, gdy tych systemów mamy powyżej stu, bez automatyzacji retencja danych zdaje się praktycznie niemożliwa. Jest to spowodowane wieloma czynnikami, ale głównym z nich jest fakt, że dane są swobodnie przesyłane między systemami i należy zapewnić spójne usunięcie lub anonimizację danych ze wszystkich zintegrowanych aplikacji.

MG: Mówiąc o tym poruszyłeś tak naprawdę kolejny problem. Nie wystarczy ustalić, że technicznie dane można usunąć np. „ręcznie”. Należy ustalić, czy ten sposób usuwania danych jest wystarczający, czy w praktyce będzie wystarczająco efektywny. Jeżeli ten brak efektywności może zrodzić ryzyko dla ludzi, którego źródłem jest naruszenie wymogu usuwania danych (np. ktoś nie zostanie dopuszczony do określonej usługi, bo system go “rozpozna”), sam w sobie może być naruszeniem zasady privacy by design.

Retencja danych z punktu widzenia działów IT

Retencja danych a kopie systemów

MG: W mojej opinii kwestia retencji, backupu, czy długości przechowywania danych to największe wyzwania na styku IT i compliance. Na ogół prawnicy stawiają bardzo sztywne wymagania. Wszystkie dane kategorii X ze względu na upływ czasu Y mają być usunięte/zaanonimizowane. Niestety w praktyce proces usuwania danych jest dużo bardziej wymagający niż może nam się wydawać.

AŻ: Dokładnie. Stanowisko w tej sprawie zajęło Ministerstwo Cyfryzacji tworząc “RODO – Poradnik dla sektora FINTECH”, gdzie wykazało, że nieusuwanie danych z kopii zapasowych może być uzasadnione:

“W przypadku kopii zapasowych i żądania usunięcia danych na podstawie art. 17 RODO, może realnie zdarzyć się, że nie będzie technicznie możliwe usuniecie danych zawartych w kopii zapasowej lub koszty i wysiłek organizacyjny takiego selektywnego usunięcia danych będą w sposób rażący niewspółmierne do ryzyka naruszenia praw i wolności podmiotu danych. Ponadto selektywne usunięcie danych osobowych z kopii narusza integralność kopii danych a zatem może powodować ryzyko dla praw i wolności innych osób, których dane są przechowywane w ramach tej samej kopii danych.”

Problem, który jednak nadal występuje jest związany z procedurami disaster recovery. Chcąc zobrazować tę kwestię, opowiem o wyzwaniu z zakresu odtwarzania backupu, przed którym stanęliśmy projektując rozwiązanie do retencji danych.

Możemy wyobrazić sobie sytuację, w której dane osobowe Jana Kowalskiego ulegają retencji i są usuwane z bazy danych trzech systemów, w których były przetwarzane. Okazuje się, że jeden z tych systemów już po usunięciu danych ulega katastrofie. W związku z tym musimy odtworzyć jego backup. W efekcie mamy sytuację, w której w systemach dane Jana Kowalskiego zostały usunięte, ale w jednym, tym drugim który uległ awarii dane Jana Kowalskiego nadal istnieją ze względu na konieczność przywrócenia danych sprzed retencji.

Jest to moment, w którym może okazać się, że zapomnimy o konieczności usunięcia danych, które powinny być skasowane.

Projektując rozwiązanie musieliśmy przewidzieć, że takie katastrofy mają szansę się wydarzyć. W takim wypadku, w ramach realizacji procesu retencji danych konieczne jest monitorowanie systemu, a konkretnie sprawdzanie, czy nie rozpoczyna się proces odtwarzania backupu, w wyniku którego przywrócone zostałyby usunięte przez nas dane.

Prawo do zapomnienia

MG: Kolejnym aspektem, który warto w tym kontekście omówić jest prawo do zapomnienia.Mechanizm retencji, z którego korzystamy musi uwzględniać dwa aspekty usuwania danych:

usuwanie niezależnie od żądania osoby – np. gdy kończy się cel przetwarzania to niezależnie od żądania usunięcia musimy dane „wyczyścić” (w ustalonych z góry okresach)
oraz usuwanie ze względu na zgłoszone żądanie usunięcia danych, czy zbliżone do tego (przynajmniej w warstwie konsekwencji technicznych) wycofanie zgody lub zgłoszenie skutecznego sprzeciwu.

AŻ: Tak, wspominaliśmy już o tym nieco powyżej. Jest to wyzwanie zwłaszcza dla dużych organizacji, które w momencie, gdy takie żądanie wpłynie, muszą ustosunkować się do niego i powiedzieć, które dane mogą usunąć zgodnie z prawem, a co do usunięcia których takich podstaw nie ma. Dodatkowo musimy także potwierdzić usunięcie danych.

MG: W przypadku niektórych umów np. umowy o pracę nie jest to takie proste. Dane często nie są ustrukturyzowane.

Dodatkowo dane tej samej osoby mogą znajdować się w innych naszych systemach. Mogą być przetwarzane dla różnych celów i w oparciu o różne podstawy. W jednej sytuacji może to być wspomniana realizacja umowy o pracę, w innej działania promocyjne w oparciu o zgodę dla celów marketingowych, etc. To kolejna sytuacja, w której nasze IT staje przed wyzwaniem.

Co istotne, nie chodzi o to, żeby (tylko) znać cele przetwarzania. Bo to jest stosunkowo proste. Chodzi o to, żeby być w stanie powiązać te cele z konkretnym rekordem. Zwłaszcza, gdy dane nie są przetwarzane w sposób ustrukturyzowany.

Bardzo często zapomina się, że retencji powinny podlegać nie tylko dane podane nam aktywnie np. przez użytkownika systemu ale także te które on wygenerował korzystając z systemu (np. dane w logach) tzw. dane „zaobserwowane” oraz dane które sami wytworzyliśmy na jego temat wnioskując o jego przyszłym zachowaniu (profilowanie).

AŻ: Chcąc zobrazować to wyzwanie wyobraźmy sobie ekosystem połączonych ze sobą wielu systemów informatycznych, które ze sobą współpracują i wymieniają się danymi osobowymi, gdzie jedna osoba może być przetwarzana na wiele sposobów.

Gdzieś w nich są rozsiane te dane, przetwarzane na różnych podstawach, które z kolei są również przechowywane w różnych systemach. Robi nam się z tego całkiem spora sieć zależności. Rozwiązaniem jest jeden, zbiorczy system, który jest w stanie zagregować wszystkie zgody, które dana osoba podpisała.

Podstawy prawne uniemożliwiające retencję danych

MG: Myśląc o procesie retencji powinniśmy także pamiętać o polityce uwzględniającej wyjątki. Może być np. tak, że zgodnie z procedurą retencji dane Y są automatycznie usuwane po okresie X. Jednocześnie w tym czasie wszczęta jest sprawa sądowa wymagająca dłuższego przetwarzania danych.

AŻ: Dokładnie. Taką sytuację mieliśmy podczas jednego z naszych wdrożeń. Pomimo tego, że umowy wygasły i powinna w tym momencie nastąpić retencja danych Klienta, pojawiła się podstawa prawna, która ten proces uniemożliwiła. Okazało się, że podstawą był pozew sądowy i postępowanie wszczęte wobec właściciela danych. W takiej sytuacji dane osobowe były traktowane jako dowód w rozprawie. Jest to przypadek, który pokazuje, że powinniśmy uwzględniać wszelkie podstawy prawne, nie tylko wynikające bezpośrednio ze zgód.

ABC retencji danych

MG: Podsumowując, jeżeli chodzi o retencję, rozporządzenie RODO wymaga od nas, żebyśmy usuwali dane niezależnie od żądania usunięcia na podstawie wewnętrznie określonych okresów retencji, w powiązaniu z:

celami przetwarzania,
kategoriami danych,
podstawami prawnymi,
oraz kategoriami podmiotów (pracownik, użytkownik).

Powinniśmy również uwzględniać możliwość wystąpienia specyficznych przypadków, o których mowa powyżej.

AŻ: Projektując, lub wdrażając u siebie narzędzia do retencji danych osobowych zadbajmy o to, żeby:

łączyły się z wieloma środowiskami i systemami,
potrafiły wykryć miejsca przechowywania danych i umożliwiły ich usunięcie ze wszystkich systemów zgodnie z żądaniem zapomnienia, lub w momencie zakończenia umowy,
dawały możliwość powiązania usunięcia z podstawą prawną, w oparciu o którą dane zostały zebrane.

—————————————————-

Odpowiadasz za techniczny lub prawny aspekt ochrony danych osobowych, ochronę bezpieczeństwa danych osobowych lub wrażliwych w swojej organizacji? A może w obszarze, którym się zajmujesz?

Przed nami ostatni z cyklu “RODO w IT” artykuł, w którym porozmawiamy o tym, jak realizować projekty z zakresu sztucznej inteligencji w kontekście privacy&security.

Masz dodatkowe pytania, chcesz wymienić się doświadczeniami, dowiedzieć się więcej o anonimizacji, detekcji i retencji danych osobowych, cykl życia produktów IT w kontekście RODO, w tym privacy by design, a także posłuchać o ciekawych case studies związanych np. z definicją danych osobowych, lub kolejnych etapach wdrażania RODO w Polsce.

Zapisz się już dziś na nasz webinar RODO W IT.

Śledź nasz profil na LinkedIn.

Do usłyszenia!

Artur i Mirek

Borykasz się z problemem zwiększonego ryzyka wycieku danych osobowych podczas pracy zdalnej?
Chcesz ograniczyć dostęp do wrażliwych danych w swojej firmie?
Chcesz dowiedzieć się więcej na temat procesu anonimizacji danych?
A może zastanawiasz się, czy proces anonimizacji, który masz wdrożony w swojej firmie można usprawnić?

Jeśli tak, ten artykuł jest dla Ciebie. Wspólnie z Mirkiem Gumularzem, Radcą Prawnym zajmującym się zagadnieniami związanymi z RODO, postanowiliśmy poruszyć temat poprawnej, szybkiej i bezpiecznej anonimizacji danych osobowych.

Z artykułu dowiesz się m.in.:

Jakie są różnice między anonimizacją a pseudonimizacją?
Dlaczego warto anonimizować dane z punktu widzenia IT, compliance, czy biznesu?
Jakie są korzyści i ryzyka związane z anonimizacją?

Zapraszamy do lektury!

Artur Żórawski, Founder&CTO Wizards
i Mirosław Gumularz, Radca Prawny w GKK Gumularz Kozik

Zapraszamy,

Artur Żórawski, Founder i CTO Wizadrs

Architekt IT z ponad 20 letnim stażem, autor pomysłów na rozwiązania IT do detekcji, anonimizacji i retencji danych.

dr Mirosław Gumularz, Radca Prawny GKK Gumularz Kozik

Audytor wewnętrzny systemu zarządzania bezpieczeństwem informacji wg normy ISO 27001:2013. Członek Grupy Roboczej ds. Ochrony Danych Osobowych przy Ministerstwie Cyfryzacji.

———————————

Anonimizacja a pseudonimizacja

Mirosław Gumularz (MG): W ostatnim artykule mówiliśmy sporo na temat zmian, które zaszły wraz z RODO w podejściu do zapewnienia zgodności z ochroną danych. Jednym ze sposobów, w jaki możemy o dane dbać jest anonimizacja, lub pseudonimizacja danych, czyli odpowiednio: zerwanie lub ograniczenie identyfikowalności osób fizycznych.

Mówiąc o anonimizacji i pseudonimizacji widzę duży problem w rozróżnieniu obu pojęć. Wiele osób uważa, że zrealizowało wymogi co do ochrony danych (np. ich usuwania), bo zanonimizowało dane. W praktyce okazuje się często, że to nie jest anonimizacja, tylko pseudonimizacja, czyli nie zerwanie, a odwracalne ograniczenie identyfikowalności, ponieważ cały czas istnieje jakiś rodzaj powiązania (chociażby poprzez zebranie dodatkowych danych ze źródeł publicznie dostępnych np. strony rejestrów publicznych, takich jak np. geoportal). Nie wiem, jak to z Waszej perspektywy wygląda, osób technicznych?

Artur Żórawski (AŻ): Mam podobne obserwacje. Jest to związane pewnie z tym, że przeprowadzenie anonimizacji przy zachowaniu odpowiedniej jakości charakterystyki bazy, nie jest taką banalną sprawą. Podstawową wartością anonimizacji jest jej nieodwracalność. Jeśli udało się ją osiągnąć, to to oznacza właśnie dobrze zrobioną anonimizację. Możemy mieszać, maskować, ale rezultat powinien być jeden: brak możliwości zidentyfikowania konkretnej osoby. Z pseudonimizacją jest inaczej. Pseudonimizacja zakłada posiadanie klucza, za pomocą którego możemy odwrócić anonimizację i odzyskać dane. W efekcie nie tracąc ich.

MG: Tak, dokładnie. To, na co warto zwrócić uwagę to fakt, że od strony prawnej nie ma czegoś takiego, jak wymóg anonimizacji/pseudonimizacji. Są to narzędzia do realizacji określonych celów/wymogów np. bezpieczeństwa, czy ograniczenia czasowego przechowywania danych. Oba pojęcia dotyczą identyfikacji osoby fizycznej, czyli najogólniej rzecz ujmując – powiązania informacji z wyodrębnioną osobą fizyczną.

Anonimizacja – służy zerwaniu powiązania pomiędzy informacją a wyodrębnioną osobą fizyczną. Anonimizacja to de facto zmiana informacji i alternatywa dla fizycznego usuwania danych. Informacja zanonimizowana nie jest już daną osobową. Oczywiście prawidłowo zanonimizowana informacja.
Natomiast pseudonimizacja służy ograniczeniu powiązania informacji z wyodrębnioną osobą fizyczną. RODO definiuje pseuodonimizację jako: “Przetworzenie danych osobowych w taki sposób, by nie można ich było już przypisać konkretnej osobie, której dane dotyczą, bez użycia dodatkowych informacji, pod warunkiem, że takie dodatkowe informacje są przechowywane osobno i są objęte środkami technicznymi oraz organizacyjnymi uniemożliwiającymi ich przypisanie zidentyfikowanej, lub możliwej do zidentyfikowania osobie fizycznej.”

W praktyce, dane speudonimizowane są cały czas danymi osobowymi. Oznacza to, że przetwarzając je, musimy zapewnić realizację wszystkich wymogów, o których mówiliśmy w pierwszym tekście, m.in. co do czasu przetwarzania danych, ograniczenia celu i minimalizacji.

Nie mniej RODO traktuje pseudonimizację przede wszystkim jako środek do realizacji wymogu bezpieczeństwa według prostego rozumowania: jak wyciekną dane pseudonimizowane, to ryzyko dla osób fizycznych jest mniejsze, bo identyfikacja będzie utrudniona, lub wręcz niemożliwa (dla uzyskującego dostęp do części danych bez tego “klucza”, o którym mowa w definicji).

Korzyści wynikające z anonimizacji

Rozwiązanie problemu ograniczenia celu przetwarzania

MG: Wiemy już, jaka jest różnica między anonimizacją a pseudonimizacją. Zastanówmy się teraz, po co w ogóle anonimizować dane? Z punktu widzenia RODO anonimizacja ułatwia przede wszystkim „obejście” problemu celu przetwarzania. To z pozoru bardzo ogólny wymóg, który ma bardzo konkretne konsekwencje techniczne. Jeśli w trakcie przetwarzania chcemy zmienić cel przetwarzania, (np. wykorzystać te dane do rozwoju „uczenia” sztucznej inteligencji) to możemy w tym zakresie mieć kłopot z zalegalizowaniem tej zmiany celu. Wprawdzie RODO tego nie wyklucza, ale zawiera szereg obostrzeń m.in. obowiązek informowania o tym osób, których dane dotyczą. Anonimizacja rozwiązuje ten problem. Dane anonimowe nie podlegają RODO.

AŻ: Tak, masz rację. Jakiś czas temu braliśmy udział w projekcie z zakresu sztucznej inteligencji i uczenia maszynowego, w ramach których wnioskowaliśmy i uczyliśmy algorytmy w oparciu o zbiór danych. Jednym z wyzwań była anonimizacja tego zbioru w taki sposób, że dane osób i w efekcie cały zbiór miały zachowywać charakterystykę i swoją tożsamość. Dane miały być w pełni wartościowe. Musieliśmy wymyśleć, jak to zrobić. Biorąc wszystkie te wszystkie wymogi pod uwagę można zażartować, że najlepiej tak naprawdę to tych danych nie mieć, ale w biznesie jest to praktycznie niemożliwe.

Ograniczenie czasu przetwarzania

MG: Masz rację. Trzeba pamiętać że sensie prawnym anonimizacja jest równoznaczna z fizycznym usunięciem danych. W obu przypadkach nie mamy danych osobowych (oczywiście o ile ten proces nastąpił w sposób prawidłowy). Dlatego anonimizacja ma także znaczenie przy realizacji wymogu ograniczenia czasowego przetwarzania, czyli jednego z fundamentów RODO. W tym wypadku anonimizacja oznacza wykonanie pewnego procesu, który powoduje, że informacja, która wcześniej dotyczyła zidentyfikowanej, lub możliwej do identyfikacji osoby, teraz już jej nie dotyczy. Stała się daną anonimową. Dlatego anonimizacja (jako metoda przetworzenia informacji) może być pomocna, gdy fizyczne usuwanie danych zgodnie z terminami przyjętymi w wewnętrznych politykach organizacji nie jest faktycznie możliwe (np. ze względu na realizację pomiędzy bazami danych).

Realizacja wymogów bezpieczeństwa

MG: Anonimizacja pozwala zrealizować także wymogi bezpieczeństwa w zakresie poufności danych. To jest tym bardziej istotne w przypadku:

pracy na urządzeniach mobilnych, które można zgubić, lub które mogą zostać ukradzione,
lub pracy zdalnej, podczas której dane mogą zostać wykradzione przez np. niezabezpieczoną sieć.

Anonimizując dane, ograniczamy ryzyko ich wycieku. Anonimizacja spowoduje, że osoba niepożądana, która zyska dostęp do baz danych, nie zyska tym samym dostępu do danych osobowych, a jedynie do ich zanonimizowanej wersji. Jest to szczególnie gorący temat w kontekście obecnej pandemii COVID-19, który wymusił na firmach wysłanie zdecydowanie większej ilości pracowników na pracę zdalną, niż to było do tej pory. Praca zdalna na danych anonimowych nie rodzi ryzyka związanego z naruszeniem RODO.

AŻ: Anonimizacja z punktu widzenia programisty, architekta w takim przypadku daje możliwość spokojnego skupienia się na tym, na czym znamy się najlepiej – programowaniu i projektowaniu.

Ja widzę jeszcze kilka korzyści z punktu widzenia IT.

Systemy informatyczne nie lubią usuwania danych. Większość systemów preferuje gromadzenie dużych ilości danych, ponieważ w niektórych przypadkach fizyczne ich usunięcie może wpłynąć na efektywność systemu. Konieczność usuwania pojawia się w momencie, w którym użytkownik zażąda usunięcia jego danych osobowych, z których my akurat korzystamy. Z tego też względu tam, gdzie można oczywiście usuwamy te dane. W miejscach gdzie byłoby to kłopotliwe, dane ulegają anonimizacji. Oznacza to, że pod względem RODO dane znikają, ale nie są usuwane fizycznie.

Miejscem, gdzie anonimizacja jest jeszcze stosowana w kontekście systemów informatycznych są testy. Wiemy, że zapewnienie odpowiedniej jakości testów też jest bardzo ważne. Przygotowanie testowych danych osobowych często jest trudne ze względu na ilość oraz charakter tych danych. W tym przypadku można wykorzystać te dane produkcyjne, które przeszły przez proces anonimizacji, dzięki czemu przestają podlegać RODO. Dzięki temu systemy mogą być testowane nie tylko pod względem funkcjonalności, ale mogą być również testowane pod kątem obciążeń – kontroli, czy dany system informatyczny będzie w stanie wytrzymać ruch i obciążenie systemu przez wszystkich użytkowników. Jest to ważne bo przecież nikt nie podpisuje zgód na wykorzystanie jego danych osobowych do testowania systemu.

Wykorzystanie anonimizacji w biznesie

AŻ: Jeżeli chodzi o korzyści biznesowe, to jest ich kilka. Na przykład jedna firma prosi inną firmę o rozwój swojego systemu i w związku z tym dochodzi do przekazania danych osobowych. Ze względu na to, że system już istnieje trzeba go utrzymywać i w takim przypadku może dojść do przekroczenia danych osobowych między dwoma organizacjami. Dzięki anonimizacji baz danych będziemy w stanie przekazać jakościowe dane, lecz bez prawdziwych danych osobowych.

Należy pamiętać, że żadna firma nie są samotną wyspą, dlatego w dzisiejszym biznesie dane dość swobodnie pływają pomiędzy podmiotami bez żadnych dodatkowych umów, czy obostrzeń. Mimo tego świadomość na temat danych osobowych w organizacji jest niska. Z doświadczenia mogę powiedzieć, że jedną z wątpliwości, którą często słyszę podczas spotkań w związku z wdrożeniem narzędzi anonimizacji danych jest brak wiedzy na temat przechowywania i przetwarzania danych osobowych. Dopiero gdy poznamy ten proces, możemy się zastanawiać się nad tym, co powinniśmy zmienić w systemach informatycznych i jakie procedury informatyczne oraz narzędzia powinny zostać wdrożone.

Ryzyka związane z anonimizacją

MG: Anonimizacja to korzyści, ale również ryzyka.Trzeba pamiętać, że proces anonimizacji może rodzić ryzyko dla ludzi, którego źródłem jest błąd i brak zerwania powiązania informacji z osobą fizyczną. W zakresie mierzenia tego ryzyka polecam dwa dokumenty:

Opinia Grupy Roboczej art. 29 6/2013 dostępna pod linkiem: https://archiwum.giodo.gov.pl/pl/1520167/6944
Rekomendacje ICO https://ico.org.uk/media/1061/anonymisation-code.pdf

Oba dokumenty zawierają przykłady błędów, dobre praktyki oraz kryteria szacowania ryzyka, którego źródłem może być nieprawidłowa anonimizacja. Więcej o tych dokumentach będziemy mówić również na webinarium.

W obu dokumentach podkreśla się, że granica pomiędzy danymi prawidłowo zanonimizowanymi jest płynna. Zresztą RODO wskazuje, że te same informacje w zależności od kontekstu (i możliwości zestawienia z innymi danymi przez dany podmiot) mogą być danymi anonimowymi, lub danymi osobowymi.

Zgodnie z motywem 26 rodo:

„(…) aby stwierdzić, czy dana osoba fizyczna jest możliwa do zidentyfikowania, należy wziąć pod uwagę wszelkie rozsądnie prawdopodobne sposoby (w tym wyodrębnienie wpisów dotyczących tej samej osoby), w stosunku do których istnieje uzasadnione prawdopodobieństwo, iż zostaną wykorzystane przez administratora lub inną osobę w celu bezpośredniego lub pośredniego zidentyfikowania osoby fizycznej. Aby stwierdzić, czy dany sposób może być z uzasadnionym prawdopodobieństwem wykorzystany do zidentyfikowania danej osoby, należy wziąć pod uwagę wszelkie obiektywne czynniki, takie jak koszt i czas potrzebne do jej zidentyfikowania, oraz uwzględnić technologię dostępną w momencie przetwarzania danych, jak i postęp technologiczny. Zasady ochrony danych nie powinny więc mieć zastosowania do informacji anonimowych, czyli informacji, które nie wiążą się ze zidentyfikowaną lub możliwą do zidentyfikowania osobą fizyczną, ani do danych osobowych zanonimizowanych w taki sposób, że osób, których dane dotyczą, w ogóle nie można zidentyfikować lub już nie można zidentyfikować”.

Powyższy cytat oznacza, że pojęcie danych osobowych obejmuje informacje o różnym stopniu powiązania z wyodrębnioną osobą fizyczną, a granica pomiędzy danymi osobowymi oraz danymi anonimowymi jest często trudna do wytyczenia.

W związku z tym można wyróżnić następujące sytuacje:

Identyfikacja jest możliwa w oparciu o dane, którymi dysponuje administrator, nawet jeżeli identyfikacja wymaga ich zestawienia (np. dane w różnych bazach danych, przetwarzane lokalnie na urządzeniach, w usługach chmurowych). W tej kategorii mieszczą się także dane spseudonimizowane.
Identyfikacja jest utrudniona (np. wymaga pozyskania dodatkowych danych), ale możliwa bez nadmiernych trudności.
Zidentyfikowanie osoby fizycznej chociaż potencjalnie możliwe, jest nadmiernie uciążliwe (biorąc pod uwagę kryteria z motywu 26 RODO).
Zidentyfikowanie osoby fizycznej nie jest możliwe nawet po uzyskaniu dodatkowych informacji (biorąc pod uwagę kryteria z motywu 26 rodo)

Oznacza to, że ustalenie czy określona informacja jest daną osobową wymaga oceny. Jak wskazują przytoczone dokumenty należy ocenić ryzyko, którego źródłem jest błąd na etapie anonimizacji prowadzący do re-identyfikacji. Chcąc oszacować to ryzyko należy:

znać kontekst przetwarzania m.in. powiązania pomiędzy informacjami przetwarzanymi m.in. w różnych systemach obsługujących różne bazy danych;
ocenić wagę takiego ryzyka (czyli upraszczając – jakie szkody dla ludzi wywoła wystąpienie ryzyka);
ocenić prawdopodobieństwo ryzyka.

Niezwykle trudne jest oszacowanie prawdopodobieństwa ryzyka re-identyfikacji. Jeśli chcemy to zrobić idąc w ślad za rekomendacjami, warto posłużyć się testem tzw. zmotywowanego intruza. Na czym on polega?

Test zmotywowanego intruza

MG: Polega on głównie na rozważeniu, czy „intruz” byłby w stanie dokonać re-identyfikacji, gdyby był do tego zmotywowany. Podejście to zakłada, że „zmotywowany intruz” jest kompetentny i ma dostęp do zasobów współmiernych do motywacji, jaką może mieć do ponownej identyfikacji.

Niektóre rodzaje danych będą bardziej atrakcyjne dla „zmotywowanego intruza” niż inne. Na przykład intruz może być bardziej zmotywowany do re-identyfikacji danych osobowych, jeśli takie dane:

mają znaczącą wartość handlową (w tym na czarnym rynku lub poza Unią Europejską) i dlatego można je kupować i sprzedawać w celu uzyskania korzyści finansowych;
mogą być wykorzystywane do celów egzekwowania prawa lub wywiadowczych;
mogą ujawniać godne uwagi informacje o osobach publicznych;
mogą być wykorzystywane do celów politycznych lub aktywistycznych (np. jako część kampanii przeciwko konkretnej organizacji lub osoby);
mogą być wykorzystywane z osobistych powodów opartych na złych intencjach (np. prześladowania, nękania, zastraszania).
mogą wzbudzić ciekawość.

AŻ: Tutaj poruszyłeś też bardzo ważny temat. Bezpieczeństwo danych to nie tylko RODO. Dane finansowe, tajemnice firmowe to są wszystko kategorie danych, które chcemy ochronić przed osobami nieuprawnionymi. W tym kontekście zabezpieczenie danych za pomocą anonimizacji jest znacznie szersze. Niektóre z naszych projektów bezpośrednio dotyczyły anonimizacji systemów finansowych i przetargowych, gdzie kwestie związane z danymi osobowymi praktycznie nie występowały, aczkolwiek zabezpieczenie danych finansowych oraz informacji powierzonych przez firmy trzecie było kluczowe dla działania całej organizacji.

Jeśli zainteresował Was temat anonimizacji oraz warunków, jakie muszą być spełnione, żeby mówić o dobrej jakości anonimizacji, zerknijcie również na jeden z moich wcześniejszych artykułów: https://wizards.io/2020/02/anonimizacja/

Znajdziecie tam m.in. rozwinięcie każdego z pojęć wykorzystanych przeze mnie w poniższym wykresie:

———————————————

Odpowiadasz za techniczny lub prawny aspekt ochrony danych osobowych, ochronę bezpieczeństwa danych osobowych lub wrażliwych w swojej organizacji? A może w obszarze, którym się zajmujesz?

Przez kolejne 2 tygodnie będziemy publikować na blogu Wizards nowe artykuły z cyklu RODO w IT, z których dowiesz się kolejno:

jak poradzić sobie z wyzwaniem skutecznej retencji danych osobowych
jak realizować projekty z zakresu sztucznej inteligencji w kontekście wymogów RODO

Zapisz się już dziś na nasz webinar RODO W IT.

Śledź nasz profil na LinkedIn.

Do usłyszenia!

Artur i Mirek

Zaczynamy cykl publikacji na temat RODO w IT, który zakończymy webinarem, na który już dziś serdecznie zapraszamy. Skąd taki pomysł?

Z RODO mamy do czynienia na co dzień, w różnych wymiarach. Z jednej strony w zakresie współpracy z firmami od strony prawnej, z drugiej z punktu widzenia wieloletniej pracy w branży IT. Obaj obserwujemy z zupełnie różnych perspektyw to, jak firmy radzą sobie z tematem RODO (ochroną prywatności))i z jakimi wyzwaniami muszą mierzyć się każdego dnia.

Jeśli jesteś osobą techniczną – dzięki naszym artykułom dowiesz się więcej na temat zagadnień prawnych, technicznych związanych z detekcją, anonimizacją i retencją danych, co z kolei przełoży się na Twoje bezpieczeństwo w zakresie realizacji projektów zgodnie z wytycznymi RODO.
Jeśli jesteś prawnikiem, pracujesz w compliance – poszerzysz swoją wiedzę techniczną. Zobaczysz RODO okiem inżyniera IT, dzięki czemu z większą łatwością będziesz rozmawiać o RODO z osobami technicznymi.
Jeśli odpowiadasz za dane osobowe z ramienia biznesu – poszerzysz swoją wiedzę w obu zakresach. Uzyskasz dzięki temu wiedzę, która pozwoli Ci podejmować decyzje w obszarze realizacji projektów zgodnie z wytycznymi RODO.

Zapraszamy,

Artur Żórawski, Founder i CTO Wizadrs

Architekt IT z ponad 20 letnim stażem, autor pomysłów na rozwiązania IT do detekcji, anonimizacji i retencji danych.

dr Mirosław Gumularz, Radca Prawny GKK Gumularz Kozik

Audytor wewnętrzny systemu zarządzania bezpieczeństwem informacji wg normy ISO 27001:2013. Członek Grupy Roboczej ds. Ochrony Danych Osobowych przy Ministerstwie Cyfryzacji.

———————————————

Relacje pomiędzy RODO i IT

Artur Żórawski (AŻ): Wejście RODO wstrząsnęło światem IT i narzuciło nowe reguły gry. Okazało się, że jednym z głównych naszych obowiązków stała się odpowiednia ochrona danych osobowych (prywatności) i jest to coś, za co każdy kto pracuje w branży nowych technologii musi brać odpowiedzialność. Dlaczego?

Ponieważ prawie każdy system informatyczny zawiera dane osobowe w jakiejś postaci,
nowe systemy muszą być projektowane z uwzględnieniem wymagań RODO, w tym bezpieczeństwa danych osobowych,
tysiące systemów istniejących przed RODO musieliśmy i wciąż musimy dostosowywać do nowej rzeczywistości.

Mirosław Gumularz (MG): Zdecydowanie. O tej odpowiedzialności IT za ochronę danych osobowych możemy rozmawiać z punktu widzenia RODO w czterech kontekstach:

Świat usług IT i narzędzi IT musiał dostosować się do wymogów RODO w kontekście przetwarzania danych w ramach produkcji oprogramowania (np. do wymogu wydania kopii danych),
dodatkowo RODO uregulowało także relację prawną pomiędzy dostawcą usług IT, który przetwarza dane w imieniu swojego klienta np. w ramach hostingu. Podmioty te muszą zawierać umowy powierzenia, które określa m.in. obowiązki audytowe oraz odpowiedzialności dostawcy za zapewnienie bezpieczeństwa danym, które przetwarza w ramach realizacji usługi. W ten sposób niejako narzuca uregulowanie wzajemnych praw i obowiązków, które wcześniej były kwestią praktyki rynkowej, a nie standardu prawnego;
świat narzędzi IT zaczął wspierać realizację wymogów RODO (np. systemy antywirusowe znalazły swoje zastosowanie w zakresie realizacji wymogu bezpieczeństwa, podobnie jak systemy do monitorowania stacji roboczych pod kątem bezpieczeństwa),
jednocześnie narzędzia IT (czy może bardziej sposób korzystania z nich) stały się źródłem zagrożeń dla prywatności (np. systemy pozwalające na profilowanie w oparciu o dane biometryczne).

Definicja danych osobowych wg RODO

Artur Żórawski: Co więcej, nie tylko musieliśmy zmienić podejście do ochrony danych osobowych, ale także na nowo zrozumieć to pojęcie. Do tej pory nie było jasnych definicji, także często korzystaliśmy z amerykańskich standardów, takich jak PII (Personal Identifiable Information) oraz PHI, w ramach których definicja danych osobowych była w porównaniu z RODO dosyć ograniczona.

Wszyscy mieliśmy świadomość, że trzeba dbać o podstawowe dane, takie jak imię i nazwisko, adresy, dane przestrzenne. To dbanie sprowadzało się jednak głównie do zapewnienia im bezpieczeństwa. Teraz RODO mówi o danych osobowych znaczenie szerzej, przewidując jak ich postrzeganie może zmienić się w przyszłości.

MG: Tak, to prawda pojęcie danych osobowych w kontekście RODO jest niezwykle szerokie. W zasadzie w ramach każdego narzędzia informatycznego, czy usługi IT dochodzi do przetwarzania danych osobowych. Trudno mi sobie wyobrazić narzędzie, w którego funkcjonowaniu nie trzeba uwzględniać wymogów RODO. Mogłoby to dotyczyć np. danych statystycznych, ale także tutaj z pewnością w jakiejś “warstwie” systemu (np. logów) dane osobowe pojawiłyby się.

Praktycznie każdy system opiera się na jakiś kategoriach użytkowników, dostępów i w każdym systemie odkłada się nasza aktywność w logach.

Cała masa danych w systemie np.:

zostawianych przez nas o nas samych aktywnie np. dane osobowe użytkowników wprowadzane przy tworzeniu konta w usłudze,
“nowych” danych “tworzonych” przez system np. w ramach profilowania tj. przewidywania naszego zachowania,
czy tzw. danych „zaobserwowanych” przykładowo o sposobie korzystania z usługi, np. dane telemetryczne, jeżeli można je przypisać do wyodrębnionej osoby fizycznej,

to są wszystko dane osobowe.

Na tym gruncie dochodzi często do przekłamań. Za dane osobowe uznawane są często jedynie dane zostawiane przez użytkownika (np. stworzony login/username). Prawda jest jednak taka, że wszystkie informacje, chociażby potencjalnie możliwe do przypisania do wyodrębnionej osoby fizycznej, są danymi osobowymi.

Wymogi RODO w pigułce

MG: Co jeszcze warto wiedzieć dziś o RODO pracując w IT? Na pewno to, że można identyfikować wymogi RODO w ramach dwóch głównych obszarów: bezpieczeństwa (security) oraz prywatności (privacy). Nie jest to podział do końca poprawny, bo bezpieczeństwo służy zapewnieniu również prywatności, ale chodzi mi tutaj o podkreślenie, że bezpieczeństwo to tylko jeden z aspektów ochrony danych, który jest naprawdę dobrze rozpoznany przez IT. Często osoby z branży IT wręcz utożsamiają prywatność z bezpieczeństwem. Problem jest z całą sferą pozostałych wymogów (privacy).

AŻ: Tak, to prawda. W tematach security poruszamy się w wielu przypadkach bardzo sprawnie. Potrafimy zabezpieczyć od strony organizacji nasze sieci, systemy, komputery. Potrafimy zapobiec utracie danych i kontrolować dostęp do nich. W tych obszarach mamy jasność i wiemy, co musimy zrobić po naszej stronie.

MG: Omówmy w takim razie pokrótce wszystkie wymogi RODO, a w szczególności ten mniej rozpoznany przez IT obszar prywatności (privacy). Poniżej znajdziecie wykres przedstawiający kluczowe dla zrozumienia RODO obszary z podziałem na te bardziej i mniej rozpoznane przez IT obszary.

BEZPIECZEŃSTWO (security)
- Poufność – musisz chronić dane przed osobami nieuprawnionymi (np. przed kradzieżą danych) np. poprzez szyfrowanie (w IT: mechanizmy oraz polityki bezpieczeństwa, uwierzytelnianie, autoryzacja, zabezpieczanie warstwy transportowej oraz serwera);
- Integralność – dane nie mogą być zmienione w sposób nieautoryzowany (w IT: logi audytowe pozwalające na weryfikację kto, kiedy i jakie dane zmienił, a mechanizmy autoryzacji zapewniają dostęp do danych tylko przez osoby uprawnione);
- Dostępność – chroń dane przed ich utratą (w IT: regularne backupy baz danych, lub całych środowisk, dzięki którym przywracanie danych po atakach nie jest problemem, wdrożone procedury disaster recovery, redundancja środowisk – jeśli jedno zawiedzie, pozostałe działają);

POZOSTAŁE (privacy)
- Legalność – sprawdź, czy masz jedną z przesłanek umożliwiających przetwarzanie np. zgoda, przepis prawa, realizacja umowy o świadczenie usług np. online;
- Rzetelność i transparentność – sprawdź, czy osoba, której dane przetwarzasz wie, co z nimi robisz i dla jakich celów je wykorzystujesz (znane wszystkim klauzule informacyjne RODO);
- Ograniczenie celu – musisz wiedzieć, dla jakich celów wykorzystujesz dane i pilnować, żeby nie były wykorzystane do innych celów;
- Ograniczenie przechowywania – długość przechowywania zawsze musi być dostosowana do celu, w jakim dane są przetwarzane i musi być ograniczona; dane należy systematycznie usuwać;
- Minimalizacja – dane można przetwarzać tylko w zakresie minimalnym; dotyczy to nie tylko danych, które aktywnie nam podano, ale np. danych wynikających z procesu profilowania;
- Prawidłowość – przykładowo wynik profilowania dotyczący przewidywania zachowania użytkownika musi być sprawdzany pod kątem poprawności tj. zgodności ze stanem faktycznym;
- Rozliczalność – musisz wiedzieć nie tylko jak zapewnić, ale też jak wykazać (np. w czasie kontroli) zgodność, np. zbierając zgody online, kto, kiedy i jaką zgodę wyraził.

Oczywiście powyższe obszary nie wyczerpują szczegółowych wymogów RODO, ale moim zdaniem zrozumienie ich jest kluczowe. Dlaczego? Ponieważ obserwuję, często w praktyce, że dyskusja w kontekście zgodności skupia się na szczegółowych wymaganiach, pomijając zupełnie fundamenty, które powinny być brane pod uwagę w pierwszej kolejności.

Wnioski z początków wdrażania RODO

AŻ: Masz rację.Podsumowując.Minęły już prawie dwa lata od czasu wdrożenia RODO. Z mojego punktu widzenia duża zmianą jest to, że jako IT zaczęliśmy bardziej zastanawiać się nad tym, co właściwie przetwarzamy i przechowujemy, a przechowujemy dużo, bo systemy kochają gromadzić dane. Wcześniej nie musieliśmy zadawać pytań o rodzaj danych i cel przetwarzania, na bazie których je przechowujemy. Systemy w jednej organizacji mogły dowolnie wymieniać się danymi, ponieważ nie był dobrze zdefiniowany cel przetwarzania. Jakie wyzwania Twoim zdaniem mamy jeszcze przed sobą?

MG: Z mojej perspektywy pierwszy okres funkcjonowania RODO pokazuje, że o ile środki organizacyjne (np. procedury, szkolenia) są punktem wyjścia realizacji wymogów RODO, to na ogół bez uwzględnienia technologii, czy też zmian w tym zakresie, nie da się w pełni zrealizować wymogów RODO (np. w kontekście usuwania danych).

Moją drugą obserwacją jest to, że identyfikacja ryzyk związanych z funkcjonowaniem technologii wymaga wzajemnego zrozumienia ról pomiędzy osobami technicznymi (np. deweloperami) oraz pracownikami z działu compliance, czy działu prawnego, którego teraz często brakuje.
Punktem wyjścia do wypracowania tego zrozumienia jest dialog i wzajemne przeszkolenie. Z jednej strony w zakresie wymogów i obowiązków stawianych przez RODO, a także metod oraz środków, którymi te wymogi można wdrażać. Z drugiej w zakresie specyfiki pracy IT i zmian w systemach informatycznych, które te ryzyka mogą rodzić.

Co więcej zapewnienie zgodności wymaga czujności przez cały “cykl” życia narzędzia IT (np. aplikacji webowej), a nie tylko na początku (privacy by design). Moim zdaniem kluczem jest zarządzanie zmianą. Bardzo często informacja o istotnych zmianach wymagających oceny prawnej nie dociera do właściwych osób i zamyka się w kręgu speców od IT. Ale o tym, jak sobie poradzić z tymi kwestiami opowiemy więcej na webinarze.

———————————————

Odpowiadasz za techniczny lub prawny aspekt ochrony danych osobowych, ochronę bezpieczeństwa danych osobowych lub wrażliwych w swojej organizacji? A może w obszarze, którym się zajmujesz?

Przez kolejne 3 tygodnie będziemy publikować na blogu Wizards nowe artykuły z cyklu RODO w IT, z których dowiesz się kolejno:

czym jest anonimizacja, a także w jakim celu i w jaki sposób skutecznie anonimizować dane
jak poradzić sobie z wyzwaniem skutecznej retencji danych osobowych
jak realizować projekty z zakresu sztucznej inteligencji w kontekście wymogów RODO

Zapisz się już dziś na nasz webinar RODO W IT.

Śledź nasz profil na LinkedIn.

Do usłyszenia!

Artur i Mirek