Coraz bliżej do RODO, czyli czego się nauczyliśmy, czego nadal nie wiemy i wyzwania, przed którymi stoimy

Część druga

Ostatni post wprowadzał w problematykę RODO. Dziś o tym, co ta regulacja oznacza dla nas i dla naszych pracodawców. Za tydzień refleksje z dotychczasowych wdrożeń, czyli próba znalezienia ścieżki między negowaniem rzeczywistości (oj, Panie, to RODO to tylko wymysł prawników i sprzedawców IT) a hiper entuzjastami (Panie, my to wszystko ogarniemy, będzie Pan na 100% gotowy, a jak kupi Pan nasz software to nawet na 120%).

CO RODO OZNACZA DLA NAS, PODMIOTÓW DANYCH

RODO istotnie wzmacnia nasze prawa jako podmiotów danych („właścicieli danych” – wiem, to nie własność, ale dobrze brzmi). Od maja 2018 roku będziemy mieli nie tylko szerszy katalog praw, ale także – co być może nawet ważniejsze z praktycznego punktu widzenia (już dziś mamy przecież całkiem zacne uprawnienia) – będziemy dysponowali skutecznymi narzędziami nacisku do realizacji tych praw. Jedną ścieżką będą interwencje PUODO (wizja paraliżującej kary 20 mln euro), a dla bardziej biegłych nawet interwencje zagranicznych inspektorów danych, drugą – pozwy cywilne.

Każdy z nas będzie mógł zażądać odszkodowania za nienależyte przetwarzanie danych i naruszenie RODO (pomijam tutaj rozważania cywilistyczne nad szkodą niemajątkową, czy domniemaniem winy przy deliktach). Procedury zostaną uproszczone, od zabezpieczeń roszczeń (nakaz np. wydania określonych danych) po sam proces (korzystny system domniemań prawnych).

Osobiście prorokuję, że to nie PUODO, a właśnie właściciele danych będą skutecznie zmuszać organizacje do wdrożenia RODO – można schować głowę w piasek i uniknąć kontroli, trudniej będzie uniknąć weryfikacji przez tysiące naszych klientów, kontrahentów czy nawet rozeźlonych pracowników.

KATALOG PRAW (TYCH NAJISTOTNIEJSZYCH)

Rozporządzenie przyznaje nam szereg uprawnień, warto przeczytać artykuły od trzynastego do dwudziestego. Na potrzeby artykułu podzieliłem je na dwa obszary.

Pierwszy obszar to prawo do wiedzy o naszych danych. Powinniśmy przed rozpoczęciem przetwarzania naszych danych otrzymać precyzyjny katalog informacji, kto, po co i na jakiej podstawie nasze dane przetwarza, komu je przekazuje lub może przekazać, a także kiedy je usunie. Takie informacje będą nam przekazywane zarówno tam, gdzie wyrażamy zgodę (by wiedzieć, na co wyrażamy) jak i tam, gdzie podstawa przetwarzania będzie np. przepis prawa. W tej grupie uprawnień umieszczam także obowiązek administratora, aby na nasze żądanie powiedział nam, czy i jakie nasze dane posiada, w jakim celu je przetwarza, komu je udostępnił, od kogo je otrzymał (jeżeli nie od nas), kiedy planuje je usunąć i trochę dodatkowych informacji. Z pozoru może brzmieć to niewinnie, ale będzie wymagało dużej wiedzy po stronie zarządzającego danymi i sprawnego systemu pozyskiwania takich informacji

Obszar drugi to zarządzanie naszymi danymi, od decydowania czy dane w ogóle przekazujemy – tam, gdzie wymagana jest nasza zgoda, musi ona być dobrowolna, wyraźna, nie można stosować systemów wymuszających czy zakładających tę zgodę z góry (np. poprzez zaznaczenie w formularzu odpowiednich okienek), musi ona być także łatwo odwoływalna, po prawo bycia zapomnianymi żądanie usunięcia danych.

W tej grupie uprawnień prawdziwym „killerfeature” jest w mojej opinii prawo do „uzyskania dostępu do danych”, czyli obowiązek wydania przez administratora wszystkich danych, które są z nami powiązane. Nie tylko mamy prawo wiedzieć jakie dane są przetwarzane (to grupa pierwsza uprawnień) ale mamy do nich dostęp.

Giganci Internetu proces ten mniej więcej opanowali, teraz czas na innych. Wróże, że właśnie na tym uprawnieniu polegnie szereg administratorów, choćby przy określaniu katalogu jakie dane powinniśmy wydać.

Obok prawa do otrzymania kopii danych mamy prawo do zapomnienia – najbardziej medialne uprawnienie (choć czysto konstrukcyjnie chyba trochę nadmiarowe). Jeśli zażądamy usunięcia danych, administrator powinien te dane usunąć.

Co więcej jak komuś przekazał nasze dane, powinien o naszym żądaniu poinformować takie osoby trzecie. W teorii nasze dane powinny zniknąć.

Brzmi świetnie, ale chyba wiele osób się rozczaruje. Musimy pamiętać, że administrator może nam odmówić usunięcia danych, jeżeli ma podstawy do ich dalszego przetwarzania. Np. nie usunie danych dotyczących umowy co najmniej do momentu, aż minie okres przedawnienia, czyli do chwili, kiedy nie będziemy już mogli go skutecznie pozwać do sądu. W praktyce może okazać się, że takich podstaw przetwarzania (przepisy prawa, umowy, usprawiedliwiony interes) jest sporo i nasza wizja skutecznego wymazywania ze świata realnego i wirtualnego naszych danych może się nie spełnić. Taka tabela podstaw i retencji danych to jedno z głównych ćwiczeń wdrożenia RODO, o czym za tydzień.

Jeżeli administrator nie znajdzie stosownego uzasadnienia (np. w przypadku mailingowej listy reklamowej), prawo do zapomnienia będzie wygodnym środkiem dochodzenia swoich uprawnień. Dla zaawansowanych – wiele danych będzie połączonych. Np. dane które powinny zostać zapomniane z danymi, których nie wolno administratorowi usunąć – np. historia zakupów (retencja po upływie przedawnienia) spięta z danymi do faktury (retencja wynikająca z przepisów fiskalnych, z reguły dłuższa niż przedawnienie). Wiele systemów nie potrafi odseparować tych danych, więc dane nadmiarowe będzie trzymać z danymi legalnie przetwarzanymi, naruszając RODO w tym pierwszym zakresie.

W obszarze zarządzania danymi pozostaje także prawo do przeniesienia danych – dość „technologiczne” uprawnienie, które pozwala nam żądać otrzymania „w ustrukturyzowanym, powszechnie używanym formacie nadającym się do odczytu maszynowego” naszych danych osobowych, które dostarczyliśmy administratorowi (z pytaniem za sto punktów, co oznacza „dostarczyliśmy”) i żądania, aby dane takie „zostały przesłane przez administratora bezpośrednio innemu administratorowi, o ile jest to technicznie możliwe”. W teorii idziemy do banku i mówimy – daj to, co ci przekazałem (np. przy wnioskach kredytowych) innemu bankowi.

Co ciekawe, równie dobrze możemy poprosić bank by przekazał te dane np. sklepowi internetowemu czy administracji publicznej. Pytanie czy jak poprosimy sklep internetowy o przekazanie historii zakupów czy cookies to są to dane, które ‘dostarczyliśmy”. Uprawnienie podobne do prawa przeniesienia numeru telefonicznego, wygodne jako konstrukcja, ale będzie o wiele trudniej je zaimplementować, choćby ze względu na brak standardów przekazywania tych danych.

Podsumowując – otrzymamy szeroki katalog praw i silne narzędzia do ich egzekwowania. Publicystycznie, politycznie i w wielu realnych sytuacjach to dobra zmiana. Z drugiej strony…

CO RODO OZNACZA DLA ORGANIZACJI

Organizacje muszą rozpatrywać RODO co najmniej na trzech poziomach – możliwości realizacji opisanych powyżej praw podmiotów danych (to będzie widział i testował klient), wewnętrznej organizacji i stosowania odpowiednich środków zabezpieczeń (tego nie będzie widział klient, ale kontrola jak najbardziej) oraz najbardziej formalnym – dokumentacji (częściowo będzie widział klient, częściowo kontrola).

Z trochę innej perspektywy mamy (i) front end – styk naszej organizacji z właścicielem danych, umowy, strony www, aplikacje, ale także wywieszki informacyjne przy pobieraniu danych przy wstępie do budynku, (ii) backend, czyli całą organizację i IT która za tym stoi. Front end w 100% musi być zgodny z RODO i w dużej mierze ma wymiar treści i funkcji – zapisu zgód, obowiązków informacyjnych, odpowiednich formularzy nie narzucających z góry zgód etc. Połączenie prawa z UX. Backend to otchłań, im więcej klientów i procesów opartych na przetwarzaniu danych tym więcej analizy, zmian, przemyślenia organizacji, a nawet oferowanych produktów.

Aby przygotować organizację na RODO, powinna ona mieć wiedzę i świadomość procesów oraz danych które przetwarza, celów i podstaw prawnych tego przetwarzania. Z tej wiedzy i świadomości wynika m.in. ocena ryzyka i powiązane z nim obowiązki organizacyjne i techniczne, w zależności od procesów mniejszy lub większy nakład prac z przygotowaniem front endu, ewentualna konieczność usunięcia nadmiarowych danych, okres retencji, konieczność aneksowania umów itd.

Podkreślę, bo brzmi niewinnie i bardzo konsultingowo, ale w praktyce to właśnie blokuje wdrożenia – kluczowym wyzwaniem jest zrozumienie własnych procesów. Trudność wzrasta wykładniczo ze wzrostem danych i procesów przetwarzania. Ekstremalnym przykładem są rozbudowane grupy kapitałowe, które jeden proces (np. obsługę sprzedaży) rozbijają na szereg spółek zależnych i podwykonawców. Każdy z nich z innymi systemami i filozofią organizacyjną, co powoduje, że nie umiemy procesu opisać end-to-end, nie mówiąc o możliwości skoordynowanego i bezzwłocznego wydania kopii danych.

PODSTAWA, CZYLI REALIZACJA PRAW

To, co brzmi ładnie jako uprawnienie dla podmiotów danych, dla administratora może oznaczać spore wyzwanie. Organizacja musi być gotowa – i operacyjnie, i technicznie – do realizacji praw podmiotów danych. Zapewne okaże się, że wiele danych zbieramy nadmiarowo i musimy je usunąć z systemów. Zapewne okaże się też, że dla części operacji nie mamy odpowiedniej podstawy, np. zgód. Że nawet jeśli zbieraliśmy zgody, nie spełniały one przesłanki „privacyby design” (np. zgoda była zaznaczona domyślnie, a nie jako opcja). Może okazać się, że tak naprawdę nie mamy pojęcia, jakie dane przetwarzamy – dla nas ciekawym eksperymentem jest zawsze porównanie audytu procesów biznesowych i audytu systemów informatycznych. To właściwie reguła, że w systemach IT znajdują się dane, których biznes nie wykazuje w swoich procesach – albo o nich zapomina, albo nawet nie jest świadomy ich zbierania. Wiele firm będzie jak niepodległości bronić możliwości przetwarzania danych historycznych (takich, co do których nie ma już podstaw przetwarzania).

Organizacje, które przetwarzają tzw. dane wrażliwe (w RODO „szczególne kategorie danych osobowych”), mają oczywiście jeszcze trudniej, począwszy od rozszerzonego – w stosunku do obecnej ustawy– katalogu danych szczególnie chronionych, przez enumeratywne wyliczenie przypadków, kiedy takie przetwarzanie jest w ogóle możliwe (nie, zgoda już nie wystarczy), po konieczność stosowania adekwatnych (czytaj: bardziej zaawansowanych) środków ochrony.

Jeżeli mamy już wiedzę, możemy zaprojektować system służący realizacji praw podmiotów danych, zarówno od strony front-endu jak i back-endu. Zaprojektować nowe zgody, nowe klauzule informacyjne, przebudować systemy pod te wymagania, zmienić zakres zbieranych danych, zbudować narzędzia, które obsłużą wnioski od właścicieli danych. Systemy, które pobiorą dane, wydadzą je, na żądanie usuną tam gdzie nie będzie podstaw do ich przetwarzania. Musimy także zastanowić się (a nawet przeprowadzić formalne procedury) jak dane naszych klientów chronimy, jakie stosujemy rozwiązania, czy są one właściwe, czy nasi podwykonawcy spełniają wymagania związane z przetwarzaniem tych danych. To wymaga dość kompleksowego systemu zarządzania i szeregu decyzji, nie tylko prawnych.

Podsumowując – aby zrealizować prawa podmiotów danych musisz mieć duża wiedzę o swoich procesach, narzędziach i systemach. Dla wielu firm RODO to pierwsza okazja do tak poważnej analizy – a ona zajmuje czas, zasoby i pieniądze. Bazując na tej wiedzy można coś sensownie projektować i podejmować decyzje, jak zarządzać ryzykiem i zakresem wdrożenia. Nawet jak podejmiemy – dobrowolnie czy z konieczności – decyzje, by pewne prawa realizować w sposób ograniczony, byłoby dobrze, by taka decyzja była elementem całościowego, przemyślanego systemu, który jako całość da się obronić

CO RODO OZNACZA DLA IT

Koniec końców większość procesów i danych znajdzie odzwierciedlenie w systemach IT. Rynek jest przesiąknięty komunikatami w rodzaju „nasz system jest gotowy na RODO”, które z wielu powodów są zazwyczaj niestety blagą. Po pierwsze, jak już wspomniałem, gotowość na RODO definiuje sama organizacja – jeśli np. jako adekwatny środek zabezpieczenia zdefiniuje ona blockchain(zakładając, że wcześniej uporał się z kwestią realizacji prawa do zapomnienia w tej technologii), większość systemów z punktu widzenia tego konkretnego klienta RODO-readynie będzie.

Nie trzeb sięgać do tak wyrafinowanych przykładów, żeby stwierdzić, że w rzeczywistości jest źle – systemy, co oczywiste, nie były projektowane pod RODO. Część np. nie usuwa danych – albo usuwa je ostatecznie, podczas gdy my, jako administratorzy, chcemy np. usunąć tylko część informacji lub wyłączyć dane tylko dla określonych celów (marketing), jednocześnie zachowując je dla innych (faktury). Nawet tak proste w teorii operacje, jak anonimizacjadanych czy nowe pole na obowiązek informacyjny nie zawsze są możliwe do przeprowadzenia w ekonomiczny sposób. Dla IT wdrożenie RODO będzie w wielu wypadkach oznaczać proces o wiele dłuższy niż analiza procesów i podejmowanie decyzji organizacyjnych.

To, co widać na rynku – utożsamianie RODO z zabezpieczeniami technicznymi przed atakami hackerskimi – to wycinek RODO, ważny, ale właściwie najprostszy do rozsądnego wdrożenia. Zmiany architektury systemu, zmiany funkcjonalności, wprowadzenie automatycznej retencji (różnej dla różnych podstaw prawnych) czy polityka backupu i archiwizacji (nieszczęsne usuwanie danych z tasiemek) – to są prawdziwe wyzwania, którym nie da się sprostać samym nabyciem systemu A czy B.

Podsumowując – technologia nie jest RODO-przyjazna. Zmiana systemów może nie być możliwa, może okazać się też nieracjonalnie kosztowna. Wciąż czekamy na to, co pokażą liderzy rynku. Dominuje „podejście oparte na obejściu”, czyli raczej na procedurach i ręcznych ingerencjach niż na kompleksowych rozwiązaniach technologicznych.

CO RODO OZNACZA DLA FIRM USŁUGOWO PRZETWARZAJACYCH DANE

Pozycja organizacji, które usługowo przetwarzają dane ulegnie istotnej zmianie (pamiętajmy, że katalog przetwarzania jest bardzo szeroki i obejmuje np. przechowywanie danych czyli data center. Podmioty przetwarzające (procesorzy) będą bezpośrednio zobowiązane do stosowania RODO, mogą też podlegać sankcjom ze strony organów nadzoru. Klauzula „nasza odpowiedzialność jest ograniczona do trzech miesięcznych opłat” pozostanie skuteczna wobec klienta, ale nie będzie nic znaczyć dla urzędu. Tak więc firmy usługowe muszą zastosować odpowiednie środki ochrony, dysponować własnymi rejestrami i politykami.

Co ciekawe, możliwość powierzenia przetwarzania danych wymaga zawarcia między administratorem a procesorem odpowiedniej umowy. O ile niemal całe RODO jest oparte na zasadzie „wymyśl, jak chcesz chronić dane”, czyli na braku narzucania odgórnej „checklisty”, o tyle w tym przypadku taka lista pojawia się w art. 28 RODO. Jeśli przejrzymy wzorce czołowych dostawców np. usług chmurowych, to firmy dostosowane do tego artykułu policzymy na palcach jednej ręki – i nawet niekoniecznie musimy mieć do tego wszystkie palce.

Dla wielu dostawców taka RODO-zgodna umowa może okazać się zaskoczeniem – np. klient uzyskuje prawo do audytu, a my jako dostawca musimy ten audyt nie tylko umożliwić, ale wręcz w nim pomagać. Musimy też wykazać wszystkich naszych dostawców i poddostawców (viva chmura warstwowa, czyli mechanizm SaaS – PaaS – IaaS), a każda zmiana w tym zakresie wymaga zgody klienta. Serio – jeżeli się sprzeciwi (czego nie musi uzasadniać), nie możemy zmienić poddostawcy. Dla dużych organizacji to logistyczny koszmar, który zapewne będzie prowadził do prawa wypowiedzenia umowy w przypadku sprzeciwu.Na marginesie – ciekawy wątek, jak takie sprzeciw nastąpi w „promocyjnym” okresie umowy – np. przez pierwsze pół roku dajemy ci aplikację saasza darmo, przez kolejne dwa lata płacisz za nią pełną cenę – jak zmienimy dostawcę w ciągu sześciu miesięcy, klient może z usługi zrezygnować i tyle, jeżeli chodzi po promocję.

Czy ucieczka do chmury jest rozwiązaniem problemów? Nie, nie jest. Nie ma żadnego przepisu który zwalniałby administratora z odpowiedzialności w przypadku skorzystania z usług chmurowych. Nie ma ani przeniesienia odpowiedzialności, ani jej „outsourcingu”. To co jest, to duża dojrzałość wielu usług i narzędzi, które w chmurze znajdziemy – i jak najbardziej jest prawdopodobne, że po analizie naszych procesów i ryzyka przetwarzania danych dojdziemy do wniosku, że rozwiązania chmurowe najlepiej spełnia nasze wymagania. Do tego zapewnia nam wiele certyfikatów i norm, które potwierdzają skuteczność takich narzędzi. Ale to będzie zawsze indywidualna ocena danych, procesów i wymagań.

Podsumowując – zmiana reguł gry. Zdecydowanie większe ryzyka prawne dla procesora, zdecydowanie inny model kontraktowania i dal administratora i procesora. W praktyce dla wielu przedsiębiorstw chmura będzie rozsądną odpowiedzią technologiczną na wymagania wynikające z analizy ich potrzeb w świetle RODO.

PODSUMOWANIE

W warstwie praw dla podmiotu danych, RODO zmienia wiele. Czyni świat przyjaźniejszym, nasze dane i nasze prawa powinny być lepiej chronione, będziemy mieli nad nimi zdecydowanie większą kontrolę. W drugiej dekadzie XXI wieku ważny cel, choć można dumać czy rzeczywiście aż tak mocno przez tłumy pożądany.

W warstwie obowiązków dla organizacji RODO też mienia wiele, ale tutaj ocena nie jest jednoznaczna.

Dla firm, które z danych żyją, to rewolucja, która może zahaczać o istotną modyfikację lub likwidację części usług.

Dla większości podmiotów to wysiłek organizacyjny, by przemyśleć swoje procesy, zracjonalizować i zaktualizować przetwarzanie danych, spełnić szereg wymogów dokumentacyjnych i formalnych.

Dla IT to zmiany w systemach. Zderzenie dobrze brzmiących uprawnień z organizacjami i systemami oznacza w istotnej części przypadków koszty, a co gorsza – realnie brak możliwości implementacji wymagań, zwłaszcza do maja 2018. Stąd rozwiązania oparte na obejściach a nie strukturalnych zmianach, decyzje akceptujące ryzyka kar czy pozwów, ale pozwalające organizacjom poczekać i zobaczyć jak realnie RODO będzie wyglądać.

źródło: https://www.linkedin.com/pulse/coraz-bli%C5%BCej-do-rodo-czyli-czego-si%C4%99-nauczyli%C5%9Bmy-nadal-marcin-maruta/


Zobacz podobne artykuły Marcina Maruty