Wszystkie teksty umieszczane na Linkedin lub naszych stronach internetowych są naszą opinią. Prosimy nie traktować ich jako porady prawnej w konkretnej sprawie, ponieważ konkretna sprawa zawsze wymaga indywidualnej analizy.
Podczas spotkań z klientami dość często padają pytania o przetwarzanie danych osobowych poza terytorium Polski – czy to w chmurze, czy podczas realizowania umów serwisowych. Zagadnienie o dość dużym znaczeniu praktycznym, dlatego pozwalam sobie opisać algorytm, jak należy tę kwestę badać. Celem artykułu jest pokazanie podstawowych zasad, a nie opisanie prawd uniwersalnych – jak mawiają doświadczeni adwokaci „bez obejrzenia akt porad prawnych nie udziela się”. Tym niemniej dla części z Państwa a nuż okaże się to pomocne.
Na samym wstępie wniosek podstawowy – dane osobowe można przetwarzać za granicą. Może to wymagać zachodu, możemy potrzebować kooperacji ze strony partnera zagranicznego, ale rzadko kiedy definitywnie się nie da. Natkniemy się na zaskakujące przypadki, serwis zdalny przyprawi nas o ból głowy, ale się da.
Kilka zastrzeżeń wstępnych:
Disclaimer pierwszy, czyli dane osobowe jako takie – poniższy artykuł traktuje o danych osobowych, które mają swoje własne regulacje. Oznacza to, że w pierwszej kolejności musimy przesądzić, czy w ogóle mamy do czynienia z danymi osobowymi. To temat nieprosty (np. szyfrowanie), ale poza niniejszymi rozważaniami. Kwestia druga – czasami dane osobowe będą podlegać pod jeszcze dalej idące regulacje, jak prawo bankowe i tajemnica bankowa. W takich sytuacjach poniższe wskazówki mogą być niewystarczające. Kwestia trzecia – zakładam, że w ogóle mamy prawo przetwarzać dane, jeżeli nie, to oczywiście nie ma co dumać nad ich przekazywaniem gdziekolwiek. A w wielu przypadkach to wcale nie jest takie oczywiste założenie.
Disclaimer drugi, czyli dane w chmurze – chmura bywa podstępna, ponieważ rzadko kiedy kontrolujemy cały ciąg dostawców chmury. Bardzo często mamy do czynienia z chmurą warstwową (cloud layering): dostawca SaaS jest dostawcą europejskim, ale jego aplikacja jest posadowiona na PaaSie lub infrastrukturze w państwie trzecim. Na pierwszy rzut oka (umowa z dostawcą) wszystko zgodnie z wytycznymi, jak się zagłębimy w temat, nic nie jest OK. Zagadnienie „warstwowej chmury” należy badać zawsze, tę kwestię ułatwi nam RODO, które wymusi m.in. podawanie informacji o podwykonawcach oraz gwarantowanie przez głównego dostawcę warunków ochrony danych nie mniej restrykcyjnych niż te ustanowione w umowie między użytkownikiem a głównym dostawcą.
Disclaimer trzeci, czyli serwis – pisząc o serwisie mam na myśli sytuację, gdy na mocy stosownej umowy jeden podmiot (administrator danych, klient) dopuszcza drugi podmiot (dostawcę) do własnego systemu, przy czym to dopuszczenie wymaga zezwolenia i technicznego umożliwienia dostępu przez klienta. Jednym słowem bez działania klienta (zestawienia łącz, podanie loginów) dostawca nie miałby jak zapoznać się z danymi osobowymi.
Przebieg weryfikacji powinien wyglądać następująco:
Brzmi prosto? No to posłuchajcie …
Najprostszy przypadek – jeżeli dane osobowe nie opuszczają naszej ojczyzny – powinien być oczywisty. Ale nie jest, bo mamy Internet. Co robić, jeżeli dane umieścimy na serwerze w Polsce, ale są osiągalne dla każdej osoby poprzez Internet – np. dane naszego zespołu? Czy fakt, że każdy Hindus może te dane obejrzeć, oznacza że przekazaliśmy je do Indii? Jeżeli uznamy że tak, de facto oznaczałoby to – w skrajnej wersji – zakaz umieszczania jakichkolwiek danych w Internecie. W świetle niezbyt precyzyjnych definicji samego transferu, jak i przetwarzania były takie głosy.
Na szczęście Trybunał Sprawiedliwości Unii Europejskiej (Lindqvist case z 2003 r.; C-101/01) zachował rozsądek i nie uznał tej czynności za przekazanie danych do państwa trzeciego, co oczywiście nie zmienia obowiązku weryfikacji, czy w ogóle możemy dane opublikować w Internecie. Ale to przypadek szczególny – zamieszczenie danych w Internecie. Z serwisem jest trudniej.
Jeżeli dane trzymamy „zamknięte” w naszych serwerach, możemy czuć się bezpiecznie. Do momentu, gdy zawrzemy umowę serwisową, a serwis będzie świadczony spoza EOG. Czyli obsługa 24/7 vendorów, którzy przerzucają centra serwisowe w ciągu doby lub IV linia wsparcia, która z definicji jest np. w Indiach. Prosta recepta: należy zbadać każdy przypadek bardzo dokładnie. Technicznie i prawnie. Jak wygląda sytuacja – czy udostępniając serwisowi nasze systemy, wprost udostępniamy dane czy też dane nie mają znaczenia dla serwisu, ale serwisant (np. zalogowany jako administrator) może teoretycznie je podglądnąć. Czy serwis dokonuje operacji na danych, np. przeglądając je, modyfikując lub usuwając (błędy migracji), odtwarzając z kopii? Czy następuje powielenie dla celów testowych? Czy to powielenie następuje na naszym środowisku czy też w środowisku serwisanta? Każda ta sytuacja musi być poddana analizie – nie ma jednej uniwersalnej odpowiedzi.
W przypadku gdy formalnie nie udostępniamy danych i nie są na nich dokonywane operacje istnieje szereg argumentów, żeby dowodzić, że nie doszło do ich przekazania (transferu). Jeżeli dane nie opuszczają naszych serwerów, ale są na nich wykonywane operacje, sytuacja jest sporna. W mojej opinii mamy tu do czynienia z transferem (uzasadnienie na osobny artykuł) i każde takie udostępnienie danych wymaga zachowania ścieżki opisanej w artykule. W przypadku powielenia danych na środowisku serwisu lub wręcz przekazania danych mailem do testów to ewidentny transfer. W świetle przepisów RODO będzie jeszcze trudniej, ponieważ „przeglądanie danych” jest wprost wpisane jako forma przetwarzania (choć po prawdzie nasze GIDO tak też uważa i dzisiaj, ale przepis to przepis). Jeżeli budujemy strategię pod nowe rozporządzenie, ta strategia powinna objąć także dostawców usług serwisowych.
Na marginesie: pracując kiedyś na opinią dla klienta dotyczącą serwisu w Indiach zrobiliśmy stres test (a dokładnie zrobiła go Karolina Alama). Weszliśmy na czat dostawców usług outsourcingowych serwisu IT w Indiach i zadaliśmy im pytanie, czy zawierają umowę powierzenia przetwarzania danych i czy regulują kwestie transferu do państwa trzeciego.
Na pierwsze pytanie jeden (!) respondent przekierował nas na ich wzorce umowy o powierzenie przetwarzania, na drugie nikt wprost nie odpowiedział, większość się rozłączyła ?
W ramach EOG przekazujemy dane na tych samych zasadach jak wewnątrz kraju. Czyli nie ma żadnych przeszkód, poza oczywiście ogólnymi obowiązkami, jak stosowne umowy o powierzeniu przetwarzania danych. Ale to nie kwesta terytorium. Tyle teoria. W praktyce poszczególne firmy czy organizacje wyznaczają polityki przetwarzania danych. Stąd całkowicie możliwy jest wymóg zamawiającego, by dane były przez wykonawcę trzymane tylko na terytorium RP. To wymagania kontraktowe i jeżeli dane będziemy przetwarzać w EOG, ale sprzecznie z umową, nie złamiemy przepisów o danych osobowych, ale naruszamy umowę. Tendencja do określenia lokalizacji danych w danym kraju jest widoczna w szczególności w sektorze publicznym i bywa wpisywana do SIWZ/RFP. Trend ten wpisuje się m.in. w zasady przetwarzania danych o statusie niejawnym w chmurze.
Ta „certyfikacja” to mój wymysł, nie ma wprost takiej formuły. Przepis mówi tyle: „przekazanie danych osobowych do państwa trzeciego może nastąpić, jeżeli państwo docelowe zapewnia na swoim terytorium odpowiedni poziom ochrony danych osobowych”.
Ten poziom jest weryfikowany przez Komisję Europejską i KE określa katalog krajów, które zapewniają odpowiednią ochronę. To w dużej mierze prawna weryfikacja – KE bada m.in. czy dane państwo przyjęło u siebie stosowne ustawy i zawarło stosowne umowy międzynarodowe.
Niestety, sam fakt umieszczenia kraju na wykazie KE nie zwalnia z dalszej analizy – trzeba sprawdzić dokładnie stanowisko KE, czy na pewno „certyfikacja” obejmuje nasz przypadek (a nie np. dotyczy wyłącznie danych pasażerów linii lotniczych). Po drugie – być czujnym, bo jest to proces dynamiczny. USA miało wspomniany już wcześniej sławny „Safe Harbour”, ale jak wszyscy wiemy Trybunał Sprawiedliwości Unii Europejskiej uznał ten poziom ochrony za niewystarczający i Safe Harbour – nomen omen – odpłynął. Teraz mamy do czynienia z jego następcą w postaci Privacy Shield, które jest mocno krytykowane przez część środowisk i jej los wcale taki pewny nie jest (szczególnie, że ostatnio zabrał się za nie Max Schrems, człowiek który zatopił Safe Harbour).
Żeby móc przetwarzać dane w pozostałych krajach, potrzebujemy podstawy prawnej. Wyjścia są dwa – (a) przesłanka opisana ustawą, albo (b) zastosowanie tzw. standardowych klauzul lub wiążących reguł korporacyjnych (BCR).
Przesłanek ustawowych jest kilka, najistotniejsza z praktycznego punktu widzenia to zgoda osoby zainteresowanej na takie przekazanie – ale wyraźna zgoda na to, że dane będą przetwarzane w państwie, które nie gwarantuje odpowiedniej ochrony.
„Zwykła” zgoda nie wystarcza. Pomocny może być także przepis, pozwalający przekazać dane, gdy „przekazanie jest niezbędne do wykonania umowy pomiędzy administratorem danych a osobą, której dane dotyczą, lub jest podejmowane na jej życzenie” (w praktyce nieoczywista przesłanka, począwszy od kwestii „niezbędności’). Tych przesłanek jest jeszcze kilka i trzeba je przejrzeć pod kątem konkretnego stanu faktycznego. Gdy uda się którąś dopasować – podmiot może przekazać dane do kraju „niecertyfikowanego”. Z tym, że zawsze takie działanie należy konsultować, ponieważ tutaj głęboka wiedza o praktyce stosowania ustawy o ochronie danych osobowych jest niezbędna.
To nie koniec algorytmu. Jeżeli nie możemy skorzystać z przesłanek ustawowych, przekazanie jest możliwe, jeżeli skorzystamy z jednego z dwóch rozwiązań: (a) standardowych klauzul umownych ochrony danych osobowych, zatwierdzonych przez Komisję Europejską, albo (b) wiążących reguł korporacyjnych, które zostały zatwierdzone przez GIODO.
Opcji wyboru wśród standardowych klauzul jest kilka i warto skonsultować, które z nich należy użyć. W skrócie działają tak – bierzemy ten tekst, wklejamy do umowy i mamy problem rozstrzygnięty (w praktyce aż tak proste to nie jest, ale jak ktoś dojdzie do tego poziomu algorytmu i tak już będzie miał prawników do pomocy). Ważne – nie możemy ich modyfikować – kontrahent po prostu musi się na nie zgodzić.
Wiążące reguły korporacyjne działają podobnie, ale są stosowane wewnątrz korporacji. Główna różnica polega na tym, że nie ma oficjalnego wzoru do kopiowania – każda grupa kapitałowa ustala swój tekst, przekazuje GIODO (lub odpowiednikowi w Unii), GIODO zatwierdza i można stosować. Dla zainteresowanych uwaga, że o ile nie ma wzorca wiążących reguł, mamy „listę kontrolną” opracowaną przez Grupę Roboczą Art. 29, z którą zainteresowani powinni się zapoznać.
Jak już nic z powyższych się nie udało, dane musimy powierzyć do państwa trzeciego, a kontrahent odmawia podpisania standardowych klauzul lub z innych powodów nie jest to możliwe, pozostaje nam wniosek do GIODO. Ale to indywidualna decyzja, więc nigdy nie można być jej pewnym.
Zasadniczo się nic nie zmieni, poza oczywiście wymiarem sankcji za niestosowanie tych reguł. Zmienia się definicja przetwarzania, która może mieć znaczenie w poszczególnych sytuacjach, jak serwis. Uprawnienia KE będą bardziej elastyczne, będzie mogła ona np. zawiesić dany kraj w przypadku gdy przestanie on zapewniać odpowiedni poziom ochrony. Co ciekawe w Rozporządzeniu nie ma definicji państwa trzeciego, i nie można wykluczyć, że jakieś zamieszanie wokół tego nastąpi.
W praktyce jak analizujemy procesy przetwarzania danych wychodzi na to, że kwestie transferu są zabezpieczane ad casum bez całościowej polityki. Jeżeli wdrażamy RODO w organizacji, musimy taką politykę opracować. I przewidywać transfer lub powierzenie podmiotom zagranicznym już na początku operacji biznesowych. Pracy więc może być wbrew pozorom sporo, zwłaszcza jak trzeba będzie przekonać partnerów do standardowych klauzul (jeśli dziś ich nie mamy). W szczególności analizie powinniśmy poddać cykl umów serwisowych.
Jak to często bywa – nie jest tak źle, jak się mówi. Jeżeli mamy czas i środki, możemy doprowadzić do zgodnego z prawem przetwarzania danych praktycznie w każdym kraju świata. Problem w tym, że często nie przygotowujemy całej operacji od samego początku – np. nie uzyskujemy zgód wtedy, gdy jest to najprostsze (np. podpisanie umowy). Lub nie analizujemy dokładnie rozwiązania chmurowego i nagle okazuje się, że dane – bez naszej świadomości – umieszczane są na infrastrukturze np. gdzieś w Azji.
Jeżeli zachowamy odpowiednią kontrolę (słynne „privacy by design”) – proces przekazywania danych jest do opanowania.