Jak RODO może zabić projekty informatyczne

Zalew niepotrzebnych próśb o zgodę, wadliwych klauzul informacyjnych czy umów o powierzenie przetwarzania pokazuje, że nie umiemy się odnaleźć w nowej sytuacji po RODO. Jak podchodzić do zarządzania i powierzania danych osobowych w projektach informatycznych?

Zalew niepotrzebnych próśb o zgodę, wadliwych klauzul informacyjnych czy umów o powierzenie przetwarzania pokazuje, że nie umiemy się odnaleźć w nowej sytuacji po RODO i stosujemy nieadekwatne środki. Zachowawcze podejście do przepisów prowadzi do absurdów, które mogą sparaliżować każdą firmę. Jak podchodzić do zarządzania i powierzania danych osobowych w projektach informatycznych?

Chciałbym wskazać kilka możliwości przełamania tego impasu, koncentrując się na umowie o powierzenie przetwarzania danych.

Zobacz również:

Historia

Kilka dni po 25 maja brałem udział w posiedzeniu zarządu mojego klienta. Rozpatrywano właśnie wniosek o zawarcie umowy na wdrożenie i utrzymanie dość skomplikowanego systemu IT. Umowę oparto na wzorcach dostawcy, co budziło sporo kontrowersji, ale mapa ryzyk była jasna i projekt dostał zielone światło. Przynajmniej tak nam się wydawało. Na koniec, po dwóch godzinach dyskusji, wstał milczący do tej pory inspektor ochrony danych (IOD) i zgłosił zastrzeżenie do protokołu, że „projekt jest niezgodny z RODO”. Wszystkich zmroziło.

Korporacja na wskroś korporacyjna, pełna komplajansu, więc zarząd pyta się grzecznie: dlaczego? Dostaje odpowiedź, że umowa powierzenia przetwarzania danych przygotowana przez dostawcę nie spełnia wymagań rozporządzenia oraz wymagań komórki ochrony danych osobowych. A ponieważ dostawca odmówił jakichkolwiek zmian (wzór był jeszcze bardziej korporacyjny niż sama korporacja), to wszelkie odstępstwa wymagałyby błogosławieństwa centrali w Stanach Zjednoczonych.

Akurat w tym projekcie nasza kancelaria nie zajmowała się danymi osobowymi, ale umowę znałem. Faktycznie, idealna nie była, ale bywają znacznie gorsze i literalnie dało się obronić jej zgodność z GDPR. Tyle tylko, że IOD literalnie niczego bronić nie chciał i miał ku temu zasadne argumenty, pokazał zresztą swoją listę wymagań (zawierającą m.in. wymóg notyfikacji w ciągu 12 godzin od zdarzenia), których dostawca nie spełniał.

Zarząd próbował delikatnie inspektora naciskać, inspektor delikatnie odmówił i ostatecznie projekt został odrzucony (z pewnych powodów nie dało się go odłożyć w czasie). Magiczne słowo: RODO i wizja kary zmieniły z dnia na dzień optykę firmy. Przyznaję, że byłem w szoku. Nie tyle nawet ze względu na samą decyzję, ale przez to, jak szybko i zero-jedynkowo ją podjęto. Strach regulacyjny okazał się tak silny, że nikt nie chciał podejmować najmniejszego ryzyka związanego z danymi osobowymi. Kiedy wróciłem do kancelarii, zespół RODO podzielił się podobnymi historiami – łącznie z tymi o wypowiadaniu już zawartych umów, jeżeli dostawca nie zaakceptował warunków powierzenia danych.

Nieprecyzyjne przepisy i nadmierna ostrożność

Jestem prawnikiem, więc konieczność zgodności z regulacjami jest dla mnie oczywista. Zdarzało mi się napisać negatywne opinie co do możliwości zawarcia umów sprzecznych z RODO, ale zasadniczo były to wyjątki (głównie amerykańskie, izraelskie czy azjatyckie spółki nieobecne na szerszą skalę w Europie, jakie faktycznie nie zauważyły GDPR, czasem mniejsi polscy dostawcy, których właściciele walczą z rzeczywistością i „nie zgadzają się” na RODO). Miażdżąca większość umów to jednak „szara strefa” – nie ma problemu, żeby je zakwestionować, ale nie są one bezwzględnie nieważne czy sprzeczne z prawem.

Sytuacja jest o tyle poważna, że RODO wywiera wpływ na każdą organizację. Większość z nich nie ma doświadczenia z prawem regulacyjnym i wobec tego woli zachowywać się ostrożnie. Trudno je za to winić: GDPR to akt wyjątkowo nieprecyzyjny, nieżyciowy i nie do wdrożenia w całości. Jeżeli zaczniemy traktować jego przepisy zachowawczo, będziemy co krok natykać się na absurdy, a IOD, gdy tylko zechce, będzie w stanie storpedować prawie każdą umowę. Jednocześnie wszyscy się zgadzają, że nie da się wstrzymywać projektów w nieskończoność, czekając na ustabilizowanie praktyki i orzecznictwa.

Chciałbym wskazać kilka możliwości przełamania tego impasu, koncentrując się na nieszczęsnej umowie o powierzenie przetwarzania danych. Impasu, który wynika także ze zwykłego niezrozumienia rozporządzenia i konstrukcji w nim zaszytych. Przyznaję, że to słaby akt prawny, a zawarte w nim sformułowania są często nieprecyzyjne. Niemniej zalew niepotrzebnych próśb o zgodę, wadliwych klauzul informacyjnych czy właśnie umów o powierzenie przetwarzania pokazuje, że nie umiemy się w tej nowej sytuacji odnaleźć i stosujemy nieadekwatne środki.

GDPR to akt nieprecyzyjny, nieżyciowy i nie do wdrożenia w całości. Jeśli zaczniemy traktować jego przepisy zachowawczo, natkniemy się na absurdy, a IOD, gdy zechce, może storpedować prawie każdą umowę. Nie da się jednak wstrzymywać projektów w nieskończoność, czekając na ustabilizowanie praktyki i orzecznictwa.

Jak więc podchodzić do zarządzania i powierzania danych osobowych w projektach informatycznych?

Czy na pewno w danym projekcie dane osobowe będą udostępnione dostawcy?

W części przypadków istotą usługi nie są operacje na danych osobowych. Jeżeli dane osobowe nie znajdą się w posiadaniu dostawcy (np. niektóre umowy serwisowe skupione na dostarczaniu łatek i nowych wersji czy chmurowe obliczanie modeli matematycznych na danych zanonimizowanych), to zarówno w teorii, jak i w praktyce nie będą potrzebne żadne umowy. Causa finita. To zresztą wcale nie taka rzadka sytuacja.

Rynek jednak zachowuje się po swojemu i widoczna jest tendencja, by umowę powierzenia danych zawierać zawsze z automatu, na wszelki wypadek. Co ciekawe, często to sami dostawcy narzucają takie podejście. Wydaje się to działaniem trochę na wyrost, budującym złą praktykę – zmusza inspektorów ochrony danych do ujednolicenia podejścia poprzez rozszerzenie katalogu przypadków, które umów wymagają.

Bardziej problematyczna jest sytuacja, w której dostawca dysponuje dostępem do danych, choć operacje na nich nie są przedmiotem jego umowy, a możliwość dostępu wynika tylko z okoliczności faktycznych (np. kolokacja serwera rozumiana wyłącznie jako najem i obsługa serwerowni, bez ingerencji w oprogramowanie). Teoretycznie dostawca może więc dane wynieść lub zniszczyć (np. niszcząc dysk) – wbrew umowie, ale może. Przypomina to trochę dylemat znany z pierwszych lat outsourcingu bankowego: czy sprzątacz/sprzątaczka ma dostęp do tajemnicy bankowej, bo może podejrzeć bankowy monitor? Wiele podmiotów przyjmowało wtedy zachowawczo, ze wystarczy sama teoretyczna możliwość. Osobiście broniłbym stanowiska przeciwnego – jeżeli dostęp do danych nie wynika z umowy i nie jest, nawet incydentalnie, częścią usługi, przetwarzanie danych nie zachodzi.

Piszmy umowy spełniające wymagania z art. 28, ale poczekajmy z maksymalizacją żądań. Odpuśćmy sobie wielomilionowe kary, „automatyzm zwrotu nałożonej przez organ grzywny” czy jednostronne prawo do żądania zmiany standardu zabezpieczeń w trakcie umowy. Może minimalistyczna klauzula o audycie okaże się wystarczająca.

Jeżeli jednak przekazujemy dane, czy zawsze mamy do czynienia z ich przetwarzaniem?

Niestety, raczej tak, a przynajmniej na dziś bezpieczniej będzie tak przyjąć. Biorąc pod uwagę definicję przetwarzania znajdującą się w rozporządzeniu, nieustabilizowaną praktykę, zachowawcze podejście do tematu regulatorów czy rodzącej się doktryny, powinniśmy założyć, że każda operacja na danych będzie ich przetwarzaniem. Oczywiście od tej reguły znajdą się wyjątki, ale należy traktować je właśnie jak wyjątki.

Na rynku pojawiła się też teza (propagowana m.in. przez niektórych dostawców data center) głosząca, że część czynności technicznych, przy których nie dochodzi do zapoznania się z danymi, np. backup, nie stanowi przetwarzania. W odróżnieniu od sytuacji opisanej powyżej występują tu jednak działania wprost na danych, w tym ich powielanie czy przechowywanie. Przedmiotem świadczenia dostawcy nie jest bowiem zapewnienie prądu i maszyny, ale realizacja usług, które dotyczą bezpośrednio danych osobowych. Niestety (albo stety), czynności te mieszczą się w definicji z rozporządzenia.

Przetwarzanie nastąpi także w bardziej zaawansowanych modelach, takich jak analiza danych (w tym Big Data), migracje, duża część umów serwisowych, RPA, machine learning itp.

Czy przetwarzanie zawsze wiąże się z powierzeniem przetwarzania i koniecznością umowy?

Podsumowując dotychczasowy ciąg myślenia, nie zawsze dochodzi do przekazywania danych. Jeżeli nie dochodzi, nie ma sensu rozważać umów o powierzenie przetwarzania. Jeżeli dostawca ma dostęp do danych, ale operacje na nich nie są przedmiotem umowy, zachodzi przypadek pośredni. Musimy przeanalizować go indywidualnie, ale jest duże prawdopodobieństwo, że ani powierzenia, ani umowy nie będzie.

Jeżeli przekazujemy dane, a dostawca dokonuje czynności z nimi związanych (nawet czysto technicznych, np. przechowywanie na swoich serwerach czy tworzenie kopii zapasowych), takie czynności będą co do zasady – ulubione zastrzeżenie prawników – przetwarzaniem. W praktyce to chyba większość umów. Jeżeli wiemy, że przetwarzanie nastąpi, musimy rozważyć, na jakiej podstawie. I tu właśnie najczęściej dochodzi do nadinterpretacji. Wiele osób zrównuje bowiem przetwarzanie z koniecznością zawarcia umowy na powierzenie przetwarzania, czyli DPA (Data Processing Agreement). Niesłusznie, nie samym powierzeniem RODO stoi.

Kolejna sprawa, niby oczywista, ale ginąca trochę w szumie. Pracodawca nie powierza przetwarzania danych własnym pracownikom – wystarcza upoważnienie. Dane pozostają pod kontrolą pracodawcy, a konkretny pracownik dokonuje na nich określonych czynności na mocy upoważnienia i na polecenie pracodawcy. Nie ma potrzeby zawierania DPA. W przypadku wielu relacji B2B jest podobnie.

Należy zawsze przyglądać się konkretnemu stanowi faktycznemu i projektowi – zastanowić się, czy rzeczywiście dane są przekazywane, czy są przetwarzane i czy do tego przetwarzania konieczna jest DPA, czy może wystarczy upoważnienie.

Oczywiście, jak to bywa z RODO, nie ma pewności, gdzie dokładnie przebiega granica między udostępnieniem a powierzeniem. To ona decyduje, czy zachodzi konieczność zawarcia umowy, opiszę więc kilka modeli:

1. Wszelkie dane znajdują się pod kontrolą administratora, w jego przedsiębiorstwie. Dostawca wykonuje np. serwis, ale to klient kontroluje zakres dostępu do danych, możliwość ich skopiowania czy usunięcia. Nikt nie przekazuje danych na zewnątrz. Tak działa np. część body leasingu. W mojej ocenie wystarczy tu upoważnienie. Sytuacja komplikuje się, gdy dostawca wchodzi np. z własnym sprzętem i nie jest monitorowany; w tym przypadku raczej potrzeba DPA, ponieważ znika kontrola (choć to zależy także od umów, procedur kontroli itp.).

2. Dane wędrują do dostawcy. Albo dostawca przetwarza je bezpośrednio (czyszczenie danych przy migracji), albo stanowi to element, choć nie cel, wykonywania przez niego usługi. Zdarza się tak również przy umowach serwisowych, kiedy część danych jest kopiowana do środowiska dostawcy w celu zbadania błędu. W mojej ocenie dochodzi tu do powierzenia, potrzebne będzie więc zawarcie DPA.

3. Częściowa (choć mocna) kontrola. To model trudny, pośredni. Przypadek zdalnego serwisu za pomocą VPN – dostawca loguje się do systemu administratora, administrator to nadzoruje, nagrywa sesję itp., ale technicznie dane są nadal powielane poza przedsiębiorstwem i np. dostawca może je nagrywać bez wiedzy administratora. Bardzo chciałbym bronić tezy, że przy tak daleko posuniętej kontroli i zobowiązaniach kontraktowych mamy do czynienia z upoważnieniem, a nie powierzeniem, ale trochę się boję. Znam za mało przykładów z praktyki, żeby coś zalecać – każdy przypadek wymagałby osobnej analizy. Większość znanych mi IOD zażądałoby mimo wszystko DPA. Obecnie ja chyba też.

Kilka przykładów

• Serwis ATiK, w którego przypadku może się zdarzyć, że dane zostaną pobrane na zewnątrz przy weryfikacji zgłoszenia błędów – DPA.

• Outsourcing – zależy czego, większość znanych mi modeli będzie wymagać DPA (a na pewno wszelkie powierzenia całych procesów na zewnątrz).

• Chmura – praktycznie zawsze DPA, choć bywają chmury (zwłaszcza SaaS), gdzie po prostu danych osobowych nie ma (np. modele matematyczne).

• Serwis on-site komputerów – upoważnienie, jeśli zachodzi kontrola administratora.

• Body leasing – również zależy od konkretnego przypadku, ale często wystarczy upoważnienie.

• Audyt licencyjny – często okazuje się, że np. audytor bierze logi do siebie, a w nich znajdują się dane osobowe, tak więc z reguły DPA. Jeżeli przekazanie danych jest wykluczone (konieczny dobry opis procedury audytowej) lub audytowany zgodzi się na anonimizację danych przed ich przekazaniem, to nie zachodzi przetwarzanie, nie ma więc potrzeby zawierania DPA.

Podsumowując, decyduje kontrola administratora. Dziś z ostrożności przyjąłbym, że pełna.

Rynek

Rynek zaakceptował umowy DPA jako zjawisko (a nawet więcej, stosuje je także wtedy, kiedy nie musi). Dostawcy mają swoje wzorce – część z nich nie spełnia wymagań RODO, nic więc dziwnego, że działy prawne czy compliance mówią: nie. To poważny problem, gdyż – przy całej sympatii do elastycznego podejścia do RODO – brak pewnego minimum jest nie do przeskoczenia. Zwłaszcza że w odróżnieniu od całej filozofii GDPR akurat umowy powierzenia przetwarzania muszą spełniać wymagania opisane w checkliście z art. 28. W zakresie wspomnianego minimum nie ma co się wiele zastanawiać, szacować ryzyk itp., po prostu trzeba wpisać do umowy m.in. prawo do audytu czy listę podwykonawców.

To zła wiadomość dla dostawców; muszą oni te audyty umożliwić i liczyć się z tym, że zmiana podwykonawcy spotka się ze sprzeciwem lub wręcz doprowadzi do rozwiązania umowy głównej (zabójcze dla modeli promocyjnych). Zauważalna część graczy próbuje być sprytna i niejasnymi zapisami rozmydlić art. 28, ale to przy zawodowym IOD się nie uda (nie mówiąc już o organie nadzorczym). Wtedy odmowa zawarcia umowy będzie realna.

Trudne do zaakceptowania mogą być też twórcze postanowienia dodatkowe. Jeden z najważniejszych światowych vendorów wpisał np. obowiązek udostępnienia wyników audytów przez klienta. Gdybym był prawnikiem tego klienta, zdecydowanie nie zgodziłbym się na taki zapis. Audyt na nasze zlecenie może zawierać np. tajemnice przedsiębiorstwa (podatności) i dostawca nie ma prawa oczekiwać jego kopii. Trudne mogą okazać się też limity odpowiedzialności, ale to już klasyka biznesu technologicznego.

Pisałem wyżej o wzorcach dostawców, swoje wzorce mają również zamawiający. Niektóre z nich są szalone. Dlatego część dostawców, z przyczyn biznesowych, także mówi: nie („nie wezmę na siebie ryzyka 20 mln euro kary”). Zderzenie jednych wzorców z drugimi zamraża projekt; uzgodnienie zabiera za dużo czasu, a liczba takich projektów jest niewiarygodna (większość naszych klientów dostała po kilkaset różnych wzorców; rekord to wysłane kilkadziesiąt tysięcy egzemplarzy umowy). Uzgodnienie odstępstwa od standardu z centralą zagraniczną również okazuje się niemożliwe w przewidywalnym czasie. Efekt? Chaos.

Skąd ratunek?

Z jednej strony należy zawsze przyglądać się konkretnemu stanowi faktycznemu i projektowi – zastanowić się, czy rzeczywiście dane są przekazywane, czy są przetwarzane i czy do tego przetwarzania konieczna jest DPA, czy może wystarczy upoważnienie. Mam nadzieję, że z czasem rynek (w tym decyzje PUODO) wypracuje bardziej jednolite stanowisko w tej sprawie i nie będzie się żądać DPA od pana, który przychodzi odkurzyć komputery (przykład z życia wzięty).

Operacyjnie największym wyzwaniem są i będą umowy. Dopracowanie standardu, który oczywiście będzie się różnił w zależności od firmy, wymagań, rodzaju powierzanych danych, planowanych czynności itp., zajmie trochę czasu. Podobnie jak z licencjami czy wdrożeniami – jest wiele rzeczy do omówienia podczas negocjacji, ale duża część z nich to zagadnienia projektowe czy komercyjne. Standardy odstąpienia częściowego istnieją, konstrukcje kar się powtarzają, limity odpowiedzialności także, ochrona przed wypowiedzeniem licencji jest rynkowo uzgodniona. W przypadku DPA tego wszystkiego nie ma, a strach jest większy, gdyż regulacyjny.

Dlatego rada (prośba?) na koniec. Piszmy umowy spełniające wymagania z art. 28, ale poczekajmy – o ile nie jest to naprawdę niezbędne i dobrze uzasadnione – z maksymalizacją żądań. Odpuśćmy sobie wielomilionowe kary, „automatyzm zwrotu nałożonej przez organ grzywny” (pisownia oryginalna) czy jednostronne prawo do żądania zmiany standardu zabezpieczeń w trakcie umowy. Może minimalistyczna klauzula o audycie okaże się wystarczająca (czy na pewno chcemy osobiście audytować Google czy Microsoft?).

Z drugiej strony musimy mieć wypracowane procedury wyboru i oceny dostawców, aby tych, którzy nie spełniają wymaganych minimów, nie dopuszczać w ogóle do gry. Żądajmy takich norm i certyfikatów, jakie uznajemy za potrzebne. Kontrolujmy i opisujmy, jakie dane i w jakim celu przekazujemy, sprawdzajmy, gdzie są one umieszczane. Do tych wymagań dostawcy muszą się dostosować, podobnie jak muszą pogodzić się z prawem do audytu czy wykazem podwykonawców – tak zostało to opisane w rozporządzeniu i nie bardzo jest tutaj z czym dyskutować.

PS. A co z notyfikacją w 24 godziny?

Jednym z częściej kwestionowanych zapisów (przez obie strony) jest kontraktowe zobowiązanie dostawcy-procesora do powiadomienia administratora o incydencie. Dostawcy z reguły wpisują w tym miejscu 72 godziny lub „bezzwłocznie”. Duża część zamawiających – 24 godziny (ale bywa i 12). Taki klincz nie ma oczywiście sensu.

Zacznijmy od przepisów (nie lubię ich cytować, ale akurat w tym przypadku wiele wyjaśniają). Art. 33 ust.1 rozporządzenia o obowiązkach administratora: „W przypadku naruszenia ochrony danych osobowych administrator bez zbędnej zwłoki – w miarę możliwości, nie później niż w terminie 72 godzin po stwierdzeniu naruszenia – zgłasza je organowi nadzorczemu właściwemu zgodnie z art. 55, chyba że jest mało prawdopodobne, by naruszenie to skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych. Do zgłoszenia przekazanego organowi nadzorczemu po upływie 72 godzin dołącza się wyjaśnienie przyczyn opóźnienia”.

I o procesorze: „2. Podmiot przetwarzający po stwierdzeniu naruszenia ochrony danych osobowych bez zbędnej zwłoki zgłasza je administratorowi”.

Dodatkowo Grupa 29 w swojej opinii zamieszcza takie zdanie: „The controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as »aware« once the processor has informed it of the breach”.

Kwestia wydaje się jasna: administrator ma 72 godziny od momentu, gdy dowie się o incydencie, w tym na skutek zgłoszenia go przez procesora. Czas nie liczy się więc od samego „wydarzenia”, ale od chwili uzyskania wiedzy o nim. Nie ma więc sensu wpisywanie krótszych terminów do umów powierzenia. Racja? Nie do końca…

Istnieją co najmniej dwa przypadki, kiedy obowiązek wcześniejszej notyfikacji ma uzasadnienie. Pierwszy to biznesowe oczekiwanie klienta, który zawiera umowę z superprofesjonalnym dostawcą usług, np. chmurowych, posiadającym całą infrastrukturę bezpieczeństwa, SOK, monitorowanie online itp., itd. Od takiego dostawcy można oczekiwać najwyższej staranności i powiadomienia w czasie znacznie krótszym niż 72 godziny.

Drugi przypadek jest zdecydowanie bardziej prawniczy i ma potencjalnie większe znaczenie dla administratora. Nigdzie nie jest powiedziane, że informacja o incydencie musi pochodzić od procesora – bardzo często zdarza się, że administrator o wycieku danych dowiaduje się niezależnie, np. z darknetu (lub, co gorsza, ze swojego profilu facebookowego). Wtedy 72 godziny zaczynają płynąć od tego momentu. Jeżeli administrator ma podejrzenia, że incydent jest po stronie procesora, wpisane w DPA „bezzwłocznie” lub 72 godziny będą wysoce niewystarczające. W takim przypadku, przy „aktywnym” zapytaniu administratora, termin na wyjaśnienia powinien być krótszy.

Trzeba wypracować procedury wyboru i oceny dostawców, aby tych, którzy nie spełniają wymaganych minimów, nie dopuszczać do gry. Żądajmy norm i certyfikatów, jakie uznajemy za potrzebne. Kontrolujmy i opisujmy, jakie dane i w jakim celu przekazujemy, sprawdzajmy, gdzie są one umieszczane. Do tych wymagań dostawcy muszą się dostosować.

Co to oznacza w praktyce? Podobnie jak w całym RODO, także i tutaj liczy się przede wszystkim polityka zamawiającego (administratora). W zależności od rodzaju danych, ryzyka i samego dostawcy zamawiający może wprowadzić obowiązek wcześniejszej notyfikacji i pozostaje to jego prawem, tak jak każde inne wymaganie. Ryzykuje jedynie, że istotna część dostawców go nie spełni.

Jeżeli zamawiający nie chce nic zmieniać, umowa gwarantująca mu powiadomienie bezzwłoczne lub w 72 godziny jest poprawna z prawnego punktu widzenia. Jedyne, co bym doradzał, to wprowadzenie krótszego terminu w przypadku, gdy administrator z własnej inicjatywy wystąpi z pytaniem dotyczącym incydentu.

I ostatnia uwaga, na podstawie kilku incydentów, które mamy za sobą: praktyka najlepiej weryfikuje dostawców. Część tych, których mam tu na myśli, nawet się nie zorientowała, że doszło do wycieku. Jakiekolwiek informacje – na nasze zapytanie – otrzymaliśmy dopiero po kilku dobach. W takiej sytuacji ani prawo, ani umowa niewiele pomogą – trzeba raczej zastanowić się nad zmianą dostawcy.

Autor jest wspólnikiem kancelarii prawnej Maruta Wachta.