Jak rozporządzenie unijne wpłynie na funkcjonowanie IT

Każdy już słyszał o unijnym rozporządzeniu o ochronie danych, w Polsce zwanym RODO (rozporządzenie ogólne o ochronie danych osobowych), a na świecie GDPR (General Data Protection Regulation). 

Wszyscy wiedzą już też, że jest to rozporządzenie, a nie dyrektywa. Dyrektywy europejskie mają moc wiążącą wyłącznie co do rezultatu, dlatego ich rolą jest harmonizacja prawa. Oznacza to, że państwa członkowskie mają obowiązek wdrożyć opisane w dyrektywie przepisy, ale posiadają przy tym swobodę sposobu ich implementacji. Przykładowo, Dyrektywa 95/46/WE weszła do polskiego porządku prawnego przez uchwalenie w 1997 r. ustawy o ochronie danych osobowych. Rozporządzenia europejskie są podobne do polskich ustaw, mają charakter wiążący i — co najważniejsze — obowiązują bezpośrednio. Oznacza to, że do rozporządzenia UE w Polsce należy stosować się tak samo, jakby to była polska ustawa. I podobnie w pozostałych krajach Unii.

Wokół tego rozporządzenia jest dużo szumu. Gdzie się nie spojrzy - wszędzie jest GDPR lub w Polsce - RODO. To akurat wcale nie dziwi - przeszłoby ono zapewne bez większego rozgłosu, gdyby nie to, że wprowadza bardzo wysokie kary, które przemawiają do wyobraźni - ich górna granica to ponad 85 milionów złotych lub 4% rocznego światowego obrotu, w zależności od tego co będzie wyższe. Dla ok. 18% firm niezgodność z rozporządzeniem to nie tylko kary, to także wysokie ryzyko bankructwa bądź likwidacji biznesu (zob. 2017 Veritas GDPR Report). Dlatego zmiany wynikające z rozporządzenia traktuje się bardzo poważnie.

Termin do przygotowania się to 25 maja 2018 - czasu pozostał więc niewiele. W motywie 171 preambuły podkreślono, że:

przetwarzanie, które w dniu rozpoczęcia stosowania niniejszego rozporządzenia już się toczy, powinno w terminie dwóch lat od wejścia niniejszego rozporządzenia w życie zostać dostosowane do jego przepisów

Nie dość, że czasu nie ma zbyt dużo, to sprawy nie ułatwia też to, nie ma jeszcze wszystkich wymaganych przepisów i wytycznych pomagających wdrożyć zasady opisane w rozporządzeniu. Przykładowo w Polsce przepisy dostosowujące polskie prawo do rozporządzenia są dopiero w fazie konsultacji społecznych (dostępne na stronie Ministerstwa Cyfryzacji), w Europie też nie jest wcale lepiej, no może za wyjątkiem Niemiec. Na pewien plus można zaliczyć to, że grupa robocza art. 29 przygotowała niektóre wytyczne (guidelines) jak stosować wybrane aspekty rozporządzenia.

Przedmiotem niniejszego opracowania jest analiza, w jaki sposób rozporządzenie "dotyka" działy IT i w jaki sposób mogą czy też powinny przygotować się na stosowanie jego przepisów.

Jak IT może przygotować się na RODO/GDPR

Unijne rozporządzenie (w polskich przepisach często określane jako rozporządzenie 2016/679, dla uproszczenia dalej będę posługiwał się terminem "rozporządzenie") będzie miało wpływ na bardzo wiele obszarów IT. Firmy informatyczne i integratorzy zacierają ręce, bo w najbliższym czasie nie będą się nudzić.

Wydaje się, że najważniejsze zmiany będą dotyczyć architektury systemów, kontraktów (umów) z dostawcami IT oraz zabezpieczeń danych. Poniżej zamieszczam skrótowy przegląd tych zmian.

Architektura - privacy by design / privacy by default

Bezpieczeństwo i prywatność musi być wkomponowane w proces przetwarzania już na etapie projektowania rozwiązania. Przetwarzanie danych będzie wymagało przygotowania tzw. oceny skutków dla ochrony danych (ang. DPIA - data privacy impact assessment).

DPIA zawiera m.in ocenę ryzyka naruszenia praw i wolności osób oraz "środki planowane w celu zaradzenia ryzyku, w tym zabezpieczenia oraz środki i mechanizmy bezpieczeństwa mające zapewnić ochronę danych osobowych i wykazać przestrzeganie niniejszego rozporządzenia, z uwzględnieniem praw i prawnie uzasadnionych interesów osób, których dane dotyczą, i innych osób, których sprawa dotyczy".

Oznacza to, że już na etapie projektowania procesów przetwarzania trzeba będzie się zastanowić, jakie systemy informatyczne będą potrzebne, i jak ich stosowanie może wpływać na "ryzyko naruszenia praw i wolności osób". W efekcie IT będzie musiało brać udział w ocenie skutków dla ochrony danych.

Podobnie ma się rzecz z privacy by default (można to tłumaczyć jako "domyślna ochrona", chociaż nie za bardzo oddaje to istotę rzeczy). Początkowo twórcy rozporządzenia na myśli mieli serwisy społecznościowe takie jak np. Facebook. Ponoć kiedyś każdy post opublikowany na Facebooku był widoczny dla każdego i aby ograniczyć ich widoczność, trzeba było samodzielnie zmienić ustawienia. Dzisiaj, zgodnie z rozporządzeniem każdy nowy post powinien być widoczny tylko wąskiej grupy odbiorców. Innym przykładem mogą być bezprzewodowe routery - kiedyś tuż po rozpakowaniu i włączeniu zasilania miały wszystkie tę samą domyślną nazwę sieci, otwartą (a więc każdy mógł się podłączyć), numer IP, nazwę użytkownika i hasło. Dzisiaj producenci stosują zasady "privacy by default" i nazwy sieci i hasła do nich są unikalne.

Wydaje się, że dla większych organizacji tego rodzaju wymogi stawiane przez rozporządzenie nie powinny stanowić problemu. Zatrudniają one obecnie ekspertów i/lub analityków bezpieczeństwa, którzy zapewniają, że ochrona jest wkomponowana w każde rozwiązanie.

Privacy by design i privacy by default powinno cieszyć wszystkich, bo zmniejszy amatorkę w rozmaitych rozwiązaniach, a przynajmniej tam, gdzie może to wpłynąć na prywatność. Pośrednio zmniejszy w ten sposób nieuczciwą konkurencję, która dzisiaj dostarcza tańsze rozwiązania kosztem bezpieczeństwa i prywatności.

Warto jeszcze wspomnieć o wykorzystywaniu wyłącznie danych niezbędnych do funkcjonowania danego rozwiązania. Przykładem tego może być ograniczona do kilku miesięcy historia operacji na rachunku dostępna w systemach bankowości elektronicznej. Użycie wyrazu "niezbędny" nie oznacza, że można zbierać tylko niezbędne dane osobowe, chodzi raczej o to, aby w określonych aplikacjach nie przechowywać więcej danych, niż potrzeba. Dotyczyć to będzie głównie aplikacji online i głównie tych udostępnianych klientom.

Na etapie projektowania rozwiązania trzeba będzie decydować się, jakie rozwiązania potrzebne będą do zabezpieczenia danych - tu oczywiście cała gama zabezpieczeń (w szczególności szyfrowanie transmisji danych, szyfrowanie danych "w stanie spoczynku"). Nie sposób nie wspomnieć o takich mechanizmach jak pseudonimizacja i anonimizacja.

Pseudonimizacja jest ciekawą formą ograniczenia ryzyka, warto ją stosować, bo jest to wygodne rozwiązanie, a w razie wycieku danych osoba nieuprawniona nie będzie mogła z nich skorzystać, bo nie będzie wiedzieć co te dane znaczą. Dzisiaj spotykana jest często w szkołach i na uczelniach, gdzie publikuje się wyniki egzaminów w postaci pseudoanonimowej. Dzięki rozporządzeniu będzie stosowane częściej.

Stosując pseudonimizację najlepiej używać nadanego przez organizację unikalnego numeru klienta, pracownika, agenta czy też numeru umowy. Numeru PESEL lub numeru dokumentu tożsamości lepiej nie używać - w końcu sam numer PESEL to dane osobowe.

Na etapie projektowania rozwiązania trzeba będzie zadbać o rzeczy oczywiste, które stosuje się (a przynajmniej powinno) niezależnie od rozporządzenia takie jak m.in. uwierzytelnianie, kontrola dostępu, zarządzanie uprawnieniami, polityka haseł, szyfrowanie danych "in transit" oraz "in rest". itd. To będzie też moment do rozważenia zewnętrznych komponentów takich jak np. SIEM (Security Information and Event Management system), IDS/IPS (Intrusion Detection/Prevention), WAF (firewall aplikacyjny).

Oczywiście wszystko będzie wiązało się też z udokumentowaniem rozwiązań - przepływ informacji między systemami, projekty rozwiązania wysoko i niskopoziomowe (tzw. HLD, LLD), różne analizy - to wszystko trzeba będzie dokumentować, gdyż zgodnie z art. 5 ust 1 i 2 rozporządzenia:

Dane osobowe muszą być: (...) przetwarzane w sposób zapewniający odpowiednie bezpieczeństwo danych osobowych (...) Administrator jest odpowiedzialny za przestrzeganie przepisów ust. 1 i musi być w stanie wykazać ich przestrzeganie.

To wszystko oznacza, że trzeba będzie doinwestować zespoły architektów, upewnić się że rozumieją i znają się na bezpieczeństwie i ochronie danych osobowych, i że wiedzą jakie mechanizmy stosować, aby spełniać wymagania rozporządzenia.

Srodowiska testowe i developerskie

Nierzadko w środowiskach testowych lub rozwojowych (developerskich) spotyka się... kopię danych z systemu produkcyjnego, co oznacza, że są tam dane osobowe. Nie dziwi to, bo odtworzenie bazy produkcyjnej w środowisku testowym jest najszybsze i najtańsze. Wciąż wiele organizacji uważa, że testowanie na nieprawdziwych danych (wygenerowanych albo wymieszanych) jest niewiarygodne. A przecież są tam dane osobowe i są znacznie słabiej chronione, bo w zabezpieczenia takich środowisk inwestuje się znacznie mniej. A to powoduje większe ryzyko nieuprawnionego dostępu do danych czy nawet ich wycieku. Wysokie kary stanowią mocny argument za tym, aby ten obszar uporządkować. 

I tu przyda się anonimizacja. Trzeba pamiętać, że nie ma obowiązku anonimizowania wszystkich danych. Wystarczy jej poddać tylko te informacje, które pozwalają zidentyfikować osobę bądź nawiązać z nią kontakt. Wszystkie pozostałe informacje można pozostawić nienaruszone. Anonimizować można na wiele sposobów. Najbardziej podstawowa to "płaska anonimizacja" (zamiana wszystkich imion i nazwisk na "anonimowy"), bardziej zaawansowana może polegać na wymieszaniu danych (np. zamiana imienia na imię wylosowane z tabeli imion, podobnie z nazwiskiem). Niektóre dane można wygenerować, przykładowo numer PESEL, przy czym trzeba pamiętać, że jest w nim zaszyta data urodzenia i płeć - zatem anonimizując je trzeba pamiętać o zaktualizowaniu daty urodzenia, i płci, aby były z tym numerem zgodne (o ile oczywiście system je jakoś porównuje ze sobą).

W internecie można znaleźć informacje o tym jak generować prawidłowe numery PESEL oraz jak zaimplementować takie procedury w bazach danych.

Usuwanie danych

Zgodnie z art. 13, 14 i 15 każda osoba, której dane są przetwarzane musi zostać poinformowana o tym, jaki jest

okres, przez który dane osobowe będą przechowywane, a gdy nie jest to możliwe, kryteria ustalania tego okresu;

"Biznes" (tak zwykło się w IT mówić o innych departamentach) będzie musiał określić, jakie długo można przechowywać dane od momentu ich zebrania. W szczególnych przypadkach może to być termin nieskończony, np. w przypadku przetwarzania na podstawie zgody - do momentu jej odwołania.

Art. 17 ust. 1 podkreśla, że dane muszą zostać usunięte, gdy "nie są już niezbędne do celów, w których zostały zebrane". Aby zrealizować to wymaganie, trzeba odnotowywać kiedy dane zostały zebrane i sprawdzać, czy termin "przydatności" danych nie wygasł. Pamiętajmy, że to nie powinna być – tak jak było kiedyś – data wprowadzenia danych do systemu, gdyż czas do usunięcia biegnie od momentu zebrania danych, a nie od momentu wprowadzenia danych do systemu.

Trzeba wspomnieć, że prawo do usunięcia danych nie jest niczym nowym, podobne przepisy obowiązywały już wcześniej w polskim prawie (art. 26 ust. 1 pkt 4 ustawy o ochronie danych osobowych). Ale mało kto przykładał się do zapewnienia z nimi zgodności, pewnie dlatego, że nie było takich wysokich kar.

Wracając do tematu - dane związane z umową zawartą z klientem wygasną po rozwiązaniu tej umowy, nie można ich jednak jeszcze usuwać, ponieważ należy je przechowywać przez pewien czas ze względu na potencjalne roszczenia. To by oznaczało, że system powinien jakoś wyróżniać rekordy z danymi osobowymi, których przetwarzanie ograniczone jest do przechowywania – w podobny sposób jak dane, co do których osoba zgłosiła sprzeciw na marketing.

Wygląda więc na to, że z rekordem klienta trzeba będzie przechowywać jeszcze inne informacje, wskazujące na to:

  • że przetwarzanie zostało ograniczone wyłącznie do przechowywania (art. 18).
  • że został wniesiony sprzeciw na przetwarzanie danych w celu marketingu bezpośredniego (własnych towarów i usług)

Jeśli zamiast usuwania danych organizacja zdecyduje się na anonimizowanie danych, to dobrze aby rekord (zapis) dotyczący osoby (klienta) zawierał dodatkowo informację czy zawarte w nim dane są prawdziwe czy też zanonimizowane. W końcu "pomieszane" dane wyglądają tak samo jak prawdziwe.

Odwołanie zgody

Zupełną nowością są warunki odwołania zgody. Zgodnie z art. 7 ust. 3

Wycofanie zgody musi być równie łatwe jak jej wyrażenie.

Obecnie wiele podmiotów pozwala wyrazić zgodę (na różne cele, to akurat tu nie jest istotne) przez internet poprzez zaznaczenie "kwadracika" (check box), ale jej odwołanie już nie jest tak proste bo wymaga wysłania listu poleconego lub wybrania się do firmowego biura bądź oddziału. Od przyszłego roku takie praktyki będą naganne.

Na szczęście coraz więcej firm wdraża od pewnego czasu rozwiązania zgodne z rozporządzenie, w których wycofanie zgody jest równie łatwe jak jej wyrażenie. 

To oczywiście będzie wymagało dostosowania wszystkich aplikacji udostępnionych klientom, w których można wyrazić zgodę, ale w których nie ma (jeszcze) funkcjonalności pozwalających ją wycofać.

Zapasowe kopie danych

Bardzo dużo szumu jest wokół tego, że trzeba będzie usuwać dane z kopii zapasowych. Ten temat już wiele razy był przerabiany i wciąż powraca jak bumerang. Osobiście uważam, że danych z zapasowych kopii danych nie trzeba, a nawet nie wolno usuwać, ale pod warunkiem, że zostaną wdrożone takie mechanizmy, aby:

  • nie odtworzyć z zapasowej kopii tych danych, które w systemach produkcyjnych zostały usunięte bądź
  • aby odtworzone dane z kopii zapasowej zostały natychmiast usunięte, jeśli te dane podlegały "prawu do zapomnienia".

Oczywiście wykładnia przepisów wskazywałaby na konieczność usuwania, ale w przypadku rozporządzenia trzeba kierować się wykładnią celowościową, tym bardziej, że rozporządzenie pisano w języku angielskim i tłumaczono na inne języki, więc wykładnia językowa nie wydaje się słusznym rozwiązaniem.

Prawo do usunięcia danych służy temu, aby dalej nie przetwarzać danych osobowych, i w ten sposób nie wpływać na prawa i wolności osoby, której dane dotyczą. Jeśli zastosuje się mechanizmy natychmiastowego usuwania danych z odtworzonych systemów, to te prawa pozostaną nienaruszone.

Procesy odtwarzania danych z kopii będą wymagały obudowania dodatkowymi procesami - przykładowo trzeba będzie w jakiś sposób gromadzić informacje o tym, jakie dane już zostały usunięte. Jeśli odtwarzać będzie się dane sprzed 6 miesięcy, to potrzebna będzie lista usuniętych danych w tym okresie, a przecież ta lista usuniętych rekordów nie może zawierać danych osobowych, więc trzeba będzie posługiwać się czymś, co pozwoli osiągnąć cel, ale nie będzie wymagało trzymania danych osobowych. Może to być numer klienta w bazie danych. Podobnie ma się rzecz w przypadku ograniczenia przetwarzania do wyłącznie przechowywania danych. A to wszystko może oznaczać dodatkową aplikację, która będzie wspierać procesy związane z odtwarzaniem kopii zapasowych.

Jakby nie patrzeć, na pewno będzie sporo pracy i trzeba będzie bardzo uważać z odtwarzaniem danych z backupów.

Zabezpieczenie danych i raportowanie naruszeń

Rozporządzenie wprowadza obowiązek zgłaszania naruszeń ochrony danych osobowych organowi nadzorczemu, a w niektórych przypadkach zawiadamiania osób, których dane dotyczą (art. 33 i 34). Te zadania nie będą należeć do IT, ale rola IT w tym obszarze będzie znacząca.

Przede wszystkim powinny być wdrożone właściwie zabezpieczenia (a jakie to wyjdzie na etapie analizy ryzka oraz "oceny skutków dla ochrony danych" - art. 32), a oprócz nich (motyw 87):

Należy się upewnić, czy wdrożono wszelkie odpowiednie techniczne środki ochrony i wszelkie odpowiednie środki organizacyjne, by od razu stwierdzić naruszenie ochrony danych osobowych i szybko poinformować organ nadzorczy i osobę, której dane dotyczą.

Nie precyzuje się o jakie rozwiązania może chodzić, jednak w przypadku systemów komputerowych trzeba założyć, że chodzi o rozwiązania klasy SIEM. Same rozwiązania tej klasy mają ceny już znacznie bardziej przystępne niż kilka lat temu. W dużych i średnich organizacjach wraz z SIEM powinien być także zespół SOC (Security Operation Centre) funkcjonujący najlepiej w modelu 24/7/365. W małych organizacjach regularne przeglądanie logów systemowych powinno wystarczyć, ewentualnie można posiłkować się darmowymi rozwiązaniami SIEM o ograniczonej funkcjonalności (przykładowo Splunk Free), pamiętajmy jednak, że rozmiar firmy czy ilość systemów nie powinien być tutaj wyznacznikiem, bo to jakie rozwiązania są "odpowiednie" zależeć będzie od oceny ryzyka.

W przypadku postępowania należy umieć wykazać, że dane przetwarzane były w sposób zapewniający odpowiednie bezpieczeństwo (art. 5 ust. 1), zresztą takiej dokumentacji wymaga się w rejestrze czynności przetwarzania (art. 30 ust. 1):

każdy administrator (...) prowadzą rejestr czynności przetwarzania danych osobowych, za które odpowiadają. W rejestrze tym zamieszcza się (...) ogólny opis technicznych i organizacyjnych środków bezpieczeństwa

Bardzo ważne, aby było wiadomo kto i komu przekazuje informacje w przypadku wykrycia naruszenia.

Wykonywanie oceny skutków dla ochrony danych (DPIA)

Ocena skutków dla ochrony danych (DPIA) to w pewnym sensie spojrzenie na proces przetwarzania danych osobowych oczami klienta (osoby). Wykonuje się ją wówczas, gdy przetwarzanie "z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych" lub gdy operacje znajdują się w wykazie rodzajów operacji podlegających wymogowi dokonania tej oceny (art. 35 ust. 3 -5).

Motywy 89 i 90 rozporządzenia wyjaśniają, że ocena skutków jest jednym z mechanizmów, który pozwala na wyeliminowanie "ogólnego obowiązku zawiadamiania organów nadzorczych o przetwarzaniu danych osobowych" realizowanego kiedyś w postaci rejestracji zbiorów danych osobowych. Rozporządzenie eliminuje ten obowiązek, w którym administrator zgłaszał, zaś GIODO dokonywał oceny, czy przetwarzanie jest zgodne z prawem, czy zabezpieczenia są odpowiednie i czy przetwarzanie nie narusza niczyich praw i wolności.

Idąc tym tropem można założyć, że w organizacji powinno być mniej więcej tyle ocen skutków, ile kiedyś było zarejestrowanych zbiorów danych osobowych, pamiętając że jako zbiór rozumiało się nie system komputerowy czy bazę, ale całokształt czy też system gromadzenia i przetwarzania danych objęty tym samym celem. Na podobieństwa do zbiorów danych wskazuje też konieczność przeprowadzenia oceny "przed rozpoczęciem przetwarzania" - dokładnie tak samo był w przypadku zbiorów, przetwarzanie można było rozpocząć po wysłaniu zgłoszenia.

Jak się dobrze zastanowić, to zgłoszenie zbioru do rejestracji stanowiło prymitywną mieszankę rejestru czynności przetwarzania i oceny skutków).

W moim przekonaniu należy wykonać DPIA dla każdego celu przetwarzania opisanego w rejestrze czynności przetwarzania (art. 30 ust. 1), o ile ten cel (czy też operacje z nim związane) powoduje konieczność wykonania DPIA.

Warto zwrócić uwagę na zapis art. 35 ust. 11:

W razie potrzeby, przynajmniej gdy zmienia się ryzyko wynikające z operacji przetwarzania, administrator dokonuje przeglądu, by stwierdzić, czy przetwarzanie odbywa się zgodnie z oceną skutków dla ochrony danych.

Jeśli do przetwarzania wykorzystuje się systemy informatyczne i coś się w nich zmienia, to będzie konieczność przeglądu (aktualizacji) dokonanych uprzednio ocen. Przykładowo migracja aplikacji do chmury bez wątpienia "wyzwoli" przegląd wszystkich DPIA wykonanych dla procesów przetwarzania, w których ta aplikacja bierze udział.

Rozważmy przypadek w którym organizacja będzie rozważać outsourcing zarządzania systemami do państwa trzeciego - w takiej sytuacji należy przeanalizować wszystkie wykonane wcześniej DPIA. Właściwie to należałoby przyjrzeć się także i tym operacjom, które nie podlegały wcześniej DPIA, gdyż przez taką zmianę może się okazać, że pojawi się "duże prawdopodobieństwo wysokiego ryzyka". Dlatego pewnie może okazać się, że najbezpieczniej będzie dokonywać oceny skutków dla ochrony danych osobowych dla każdego celu przetwarzania.

Bez wątpienia za nieprawidłowe należy uznać wykonywanie DPIA dla pojedynczych aplikacji, rozwiązań technicznych czy zmian. Przykładowo zmiana lokalizacji centrum danych (serwerowni) nie wyzwoli sama w sobie DPIA. Raczej spowoduje przegląd istniejących ocen dla celów przetwarzania.

Co ciekawe, wydawałoby się, że taka ocena powinna być zarządzana przez inspektora ochrony danych (DPO, w polskiej ustawie zwanego ABI - administrator bezpieczeństwa informacji), a jak się okazuje, tak nie jest - art. 35. ust. 2 określa, że "dokonując oceny skutków dla ochrony danych, administrator konsultuje się z inspektorem ochrony danych, jeżeli został on wyznaczony". Zgadzam się że administrator powinien dokonywać oceny skutków, ale uważam też, że moderatorem i zarządcą całego procesu powinien być DPO.

Jeśli organizacja nie wskaże pojedynczego zespołu lub osoby koordynującego oceny i posiadającego informacje o wszystkich ocenach, to powstanie chaos i spowolnienie zmian w obszarze IT.

Partnerzy i dostawcy IT

W obszarze zawieranych umów będzie wyjątkowo dużo do zrobienia. Przede wszystkim trzeba będzie przygotować listę podmiotów, którym powierza się dane osobowe i sprawdzić, czy zgodnie z art. 28 ust. 1 "zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, by przetwarzanie spełniało wymogi niniejszego rozporządzenia i chroniło prawa osób, których dane dotyczą".

Z wszystkimi tymi podmiotami (w rozporządzeniu określanymi mianem podmiotów przetwarzających) umowa musi zostać zawarta na piśmie (dopuszczalna wersja elektroniczna) i w niej muszą być uregulowane takie kwestie jak m.in. (art. 28. ust. 3):

  • bezpieczeństwo danych,
  • zakaz dalszego powierzania przetwarzania danych, no chyba że uzyska na to zgodę - zgoda może być ogólna, ale z możliwością wyrażenia sprzeciwu,
  • udostępnianie wszelkich informacji pozwalających wykazać, że spełnia obowiązki opisane w zawartej umowie,
  • umożliwianie dokonywanie audytów i inspekcji,
  • niezwłoczne informowanie o naruszeniu bezpieczeństwa,
  • rejestr czynności przetwarzania.

W ramach przygotowania do zapewnienia zgodności z RODO trzeba będzie w IT:

  • "popchnąć" partnerów i dostawców przetwarzających dane osobowe na zlecenie, aby także ruszyli z procesami zapewnienia zgodności z RODO - dlatego, że administrator może korzystać wyłącznie z podmiotów dających "wystarczające gwarancje..."
  • przystosować obecne umowy do wymagać rozporządzenia, można to zrobić stosując zapisy, które będą ważne od dnia 25 maja 2018 r. (przykładowo w mniej więcej taki sposób: "zapisy §13-17 stają się ważne z dniem 25 maja 2018r. przy czym z tym dniem tracą ważność zapisy §7-12").
  • utrzymywać listę takich podmiotów, a jeśli one dalej powierzają powierzone im dane osobowe listę całego łańcucha podprocesorów. Przykładowo jeśli powierzamy przetwarzanie firmie A, a ta dalej powierza te dane firmie B, zaś firma B powierza je firmie C, to IT powinno mieć informację o wszystkich tych firmach.

W tworzeniu treści umów pomocne mogą być wytyczne brytyjskiego odpowiednika GIODO - ICO (Information Commissioner's Office).

W przypadku korzystania z dostawców z innych krajów, a szczególnie z tzw. państw trzecich (np. USA, Rosja, Chiny, Indie) należy w umowach (też na piśmie) zastosować tzw. standardowe klauzule umowne (art. 28 ust. 7 i 8). W przypadku USA można korzystać z programu Privacy shield ("Tarcza prywatności"), chociaż bezpieczniej jest mimo wszystko podpisać umowę z klauzulami, dlatego, że w przypadku "tarczy" jest ryzyko, że podczas przeglądu Komisja Europejska może uznać, że program jest nieefektywny.

Cloud computing

Chmury są coraz bardziej popularne, niezależnie od tego czy to jest Iaas, PaaS czy SaaS. Amazon, Microsoft i Google coraz bardziej rozpychają się na rynku. Chmury są wszędzie dookoła nas - Gmail, Office365, Dropbox, Skype, TripIt, Slack, Salesforce - to tylko niektóre przykłady takich najbardziej popularnych i zauważalnych. Nawet takie usługi jak Cisco Email Security to też przetwarzanie w chmurze.

Korzystanie z chmur w świetle rozporządzenia może okazać się... sporym wyzwaniem. Spójrzmy na zapisy art. 28 ust. 2 rozporządzenia:

Podmiot przetwarzający nie korzysta z usług innego podmiotu przetwarzającego bez uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora. W przypadku ogólnej pisemnej zgody podmiot przetwarzający informuje administratora o wszelkich zamierzonych zmianach dotyczących dodania lub zastąpienia innych podmiotów przetwarzających, dając tym samym administratorowi możliwość wyrażenia sprzeciwu wobec takich zmian.

W umowie z dostawcą można zapisać, że ma prawo dalej powierzać przetwarzanie (danych osobowych) pod warunkiem, że będzie o tym informował. I załóżmy, że nawet będzie informować np. publikując listę podwykonawców na swojej stronie internetowej. Ale w przypadku usług chmurowych sprzeciw najczęściej będzie tożsamy z wycofaniem się z zawartej umowy.

Konstrukcja tego zapisu przypomina wymagania stawiane przez Komisję Nadzoru Finansowego w serii dokumentów stanowiących "Wytyczne dotyczące zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego". Można założyć z pewnym prawdopodobieństwem, że działy IT w branży finansowej umowy mają w dużym stopniu zgodne.

IT musi poznać właścicieli danych

Jednym z najważniejszych zagadnień związanym z dostosowaniem do rozporządzenia jest identyfikacja danych tj. jakie dane są w organizacji, gdzie się znajdują, kto za nie odpowiada i kto ma do nich dostęp. Zadanie to będzie należało do inspektora ochrony danych, ale w przypadku jego braku kierownictwo będzie musiało wyznaczyć odpowiedzialną osobę.

Zidentyfikowanie właścicieli przyda się w IT do ustalenia (o ile wcześniej nie ustalono) właścicieli biznesowych informacji. Będzie też pomocne w procesach zarządzania dostępami - bo to właściciel informacji jest jej gestorem (dysponentem).

Biometria

W dużych centrach danych stosuje się biometrię w przypadku dostępu do pomieszczeń. Do niedawna dane biometryczne nie znajdowały się w katalogu danych wrażliwych. Rozporządzenie to zmienia - dane biometryczne stanowią tzw. "szczególną kategorię danych osobowych" i można je przetwarzać dopiero po spełnieniu pewnych warunków. Jeśli chodzi o pracowników, przetwarzanie innych danych, niż wymienione w art. 22 (także danych biometrycznych) "jest dopuszczalne tylko wtedy, gdy dotyczą one stosunku pracy i osoba ubiegająca się o zatrudnienie lub pracownik wyrazi na to zgodę w oświadczeniu złożonym w postaci papierowej lub elektronicznej". A to oznacza, że pracownik może nie zgodzić się na biometrię, a brak jego zgody nie może spowodować żadnych negatywnych konsekwencji.

W tej sprawie warto śledzić zmiany w polskich przepisach publikowane na stronach Ministerstwa Cyfryzacji.

Lista kontaktów na wypadek awarii

Skoro jesteśmy przy kwestiach pracowniczych, to warto wspomnieć, że po zmianach w Kodeksie pracy prywatny numer telefonu i adres e-mail pracownika będzie można przetwarzać tylko wówczas, gdy dotyczą stosunku pracy i pracownik wyraził na to zgodę (w postaci papierowej lub elektronicznej). Utrzymywanie listy kontaktów na wypadek awarii bądź katastrofy (niezbędnej w przypadku planów zachowania ciągłości) będzie wymagało zebrania takich zgód.

Przenoszenie danych

Przenoszenie danych (data portability) to absolutna nowość. To prawo w przepisach dotyczących ochrony danych osobowych mocno zaskakuje, bo nie bardzo wiadomo, jak ma się ono do prywatności. Wydaje się, że po prostu upieczono dodatkową pieczeń na tym samym ogniu.

Z wytycznych grupy roboczej dotyczących prawa do przenoszenia (WP242) dowiadujemy się, że:

głównym celem przenoszenia danych jest ułatwienie zamiany jednego dostawcy usług na innego,

To jakie dane podlegają przenoszeniu określa art. 20 ust. 1 rozporządzenia

osoba, której dane dotyczą, ma prawo otrzymać w ustrukturyzowanym, powszechnie używanym formacie nadającym się do odczytu maszynowego dane osobowe jej dotyczące, które dostarczyła administratorowi

Dane wywnioskowane z przekazanych danych jak np. profil kredytobiorcy czy wynik oceny zdrowia nie stanowią danych "przekazanych przez" osobę.

Zgodnie z art. 12 ust. 3 mówi, że "bez zbędnej zwłoki" ewentualnie w terminie do jednego miesiąca od otrzymania żądania udziela informacji o tym, jakie podjął działania w związku z żądaniem danych. Termin ten można wydłużyć o dodatkowe dwa miesiące, uprzednio o tym informując osobę i wyjaśniając powody tego przedłużenia. Ust. 3 stanowi natomiast, że w przypadku gdy administrator nie podjął żadnych działań, do miesiąca musi wyjaśnić tego powody i przekazać informacje o prawie skargi do organu nadzorczego (GIODO, w przyszłości do Prezesa Urzędu Ochrony Danych Osobowych). Nie jest jasne czy wspomniane 3 miesiące są na przekazanie danych czy też na informowanie o podejmowanych działaniach, bezpieczniej będzie założyć, że w tym czasie żądanie powinno zostać zrealizowane

Prawo to jest wolne od opłat, no chyba że dana osoba żąda jego realizacji zbyt często, co będzie dla administratora uciążliwe.

W zasadzie pewnie najlepszym rozwiązaniem byłoby, aby osoby (klienci) mogli online wygenerować sobie i ściągnąć żądane dane.

Więcej wskazówek jak to prawo realizować można znaleźć w dokumencie "Wytyczne dotyczące prawa do przenoszenia danych (WP 242)" opublikowanym na stronach GIODO, a przygotowanym przez grupę roboczą art. 29.

Prawo do przenoszenia danych można zostawić sobie na później, gdyż wydaje się, że przez pewien czas żądania osób można będzie obsługiwać ręcznie. To będzie być może pracochłonne, ale i tak mniej kosztowne niż przerabianie systemów już teraz. Pozwoli też zapewne rozpoznać się w skali takich żądań.

Dostosowanie obecnych aplikacji

Oprócz prawa do przenoszenia, obecne aplikacje należy głównie dostosować do wymagań dotyczących usuwania danych oraz ich zabezpieczenia. Dlatego w IT na najbliższe miesiące warto (i trzeba) zaplanować więcej zasobów.

W systemach dużo zmian będą generować wszystkie te formularze, gdzie zbierane są zgody, gdzie osobom przekazuje się informacje o przysługujących im prawach, o celu przetwarzania danych, o tym kim jest administrator, dane kontaktowe inspektora ochrony danych, etc.

Uporządkowanie IT poza IT (tzw. "Shadow IT")

W wielu firmach występuje tzw. shadow IT. Są to rozwiązania zamawiane lub rozwijane z pominięciem działu IT. Najczęściej są to aplikacje działające w modelu SaaS (Software as a Service), bo są niedrogie i dostępne w zasadzie dla każdego. W dzisiejszych czasach chyba nie jest niczym niezwykłym to, że jakiś dział w firmie kupuje sobie platformę online do współpracy czy biznesową aplikację.

Zgoda na „IT w cieniu” niesie za sobą zwiększone ryzyko dla organizacji w postaci np. wycieków informacji. A każdy taki wyciek musi zostać udokumentowany w rejestrze naruszeń, a niektóre z nich nawet zgłaszane do regulatora (w Polsce do Prezesa Urzędu Ochrony Danych Osobowych, dzisiaj jeszcze nazywającego się GIODO).

Zapewne po każdym większym incydencie dyrektor IT będzie musiał tłumaczyć Zarządowi, że "to nie nasza wina", to ktoś inny korzysta z oprogramowania, o którym nie wiedzieliśmy, a skoro nie wiedzieliśmy, to nie byliśmy go w stanie dostarczyć odpowiednich zabezpieczeń.

Warto zidentyfikować obecną "szara strefę" i wdrożyć takie procedury, aby ona nie powiększała się (przykładowo przekonać finanse i prawny, zanim umowę podpiszą bądź dokonają płatności upewnili się, że zakup rozwiązania informatycznego został uzgodniony z IT)

Podsumowując

Mimo że w internecie są tony rozmaitych opracowań na temat GDPR, to nie udało mi się do tej pory znaleźć opracowania, które całościowo określa w jaki sposób rozporządzenie wpłynie na dział IT, na co zwrócić uwagę, jakie są potencjalne problemy i wyzwania. Dlatego podjąłem próbę takiej analizy, podejrzewam jednak, że przeanalizowałem zaledwie czubek góry lodowej.

Mam jednak nadzieję, że ten artykuł przybliżył chociaż trochę problematykę wpływu GDPR na IT.