Smok prawdziwie nieprzyjemny, czyli przetwarzanie danych a projekt IT

Kontynuacja jednego postu

RODO zaskoczyło mnie pod wieloma względami – od nieprzygotowania legislacyjnego, przez fatalny mechanizm implementacji, po skutki biznesowe. Te ostatnie są zresztą znacznie poważniejsze, niż przypuszczałem (i nie mam tu na myśli samych wdrożeń, ale wpływ na codzienny biznes).

Mimo mojej aktywności związanej z RODO jestem jednak przede wszystkim prawnikiem transakcyjnym; oczywiście muszę uwzględniać regulacje, ale dobrem nadrzędnym pozostaje dla mnie zamknięcie umowy. Kiedy trafiam na nieakceptowalne ryzyko czy wręcz zakaz – odpuszczam, kiedy trafiam na przeszkody do przeskoczenia (patrz: KNF a chmura…) – staram się spełnić wymagania i regulatora, i klienta.

Teraz do procesu negocjowania doszedł kolejny element układanki. Ledwo RODO zaczęło obowiązywać, a już wróciły do mnie trzy umowy serwisowe, wstrzymane wskutek nieuzgodnienia umowy o przetwarzanie danych osobowych (DPA), oraz dwa wypowiedzenia. Wszystko wskazuje na to, ze takie sytuacje będą się powtarzać.

Nikt nie wie, jak znaleźć równowagę między ryzykiem regulacyjnym a standardem umów, więc będziemy metodą prób (i błędów) ten standard wypracowywać. Z tego powodu zauważalna część umów IT może być procedowana zdecydowanie dłużej, a w niektórych przypadkach nigdy nie zostanie uzgodniona. Napisałem o tym krótki post, który w tydzień miał chyba ponad 20k odtworzeń – jak na mnie i jak na post merytoryczny, dużo. Z tego powodu trochę więcej rozważań jak zderzyć przetwarzanie danych z codziennością projektów IT. Zanim wstrzymamy zawieranie umów, powołując się na RODO, warto rozważyć kilka poniższych kwestii.

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

W przypadku większości umów, o których piszę – serwisu, atik, outsourcingu czy chmury – istotą usługi nie są operacje na danych, ale dane są przekazywane. Tym niemniej w części przypadków dane osobowe nie znajdą się w posiadaniu dostawcy (np. niektóre umowy serwisowe, skupione na dostarczaniu patchy i nowych wersji). I w teorii i w praktyce nie potrzebujemy żadnych umów.

Rynek jednak zachowuje się po swojemu i jest widoczna tendencja, by umowę DPA zawierać z automatu, na wszelki wypadek. Co ciekawe, często to dostawcy narzucają takie podejście – ktoś musiał ich dobrze wystraszyć. Wydaje się to działaniem trochę na wyrost.

Bardziej problematyczny jest przypadek, w którym dostawca dysponuje dostępem do danych, choć nie jest to przedmiotem jego umowy, a możliwość ta wynika tylko z okoliczności faktycznych (np. kolokacja serwera rozumiana wyłącznie jako najem i obsługa serwerowni, bez ingerencji w oprogramowanie). Teoretycznie więc dostawca może te dane wynieść na dysku albo może je zniszczyć – 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 potencjalna możliwość. Osobiście broniłbym jednak stanowiska mówiącego, że jeżeli dostęp do danych nie wynika z umowy i nie jest – nawet incydentalnie – częścią usługi, przetwarzanie danych nie zachodzi.

Kwestia numer dwa

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

Niestety – raczej tak. Biorąc pod uwagę definicję przetwarzania w rozporządzeniu, podany katalog, zachowawcze podejście do tematu regulatorów czy rodzącej się doktryny, nieustabilizowaną praktykę, powinniśmy założyć, że de facto każda operacja na danych będzie przetwarzaniem. Tak, będą wyjątki, ale traktujmy je jak wyjątki.

Na rynku (np. niektórych dostawców data center) pojawia się teza, że sama administracja warstwą sprzętową i systemową (middleware), backup-em bez podglądu danych itp. nie jest przetwarzaniem – niestety (albo stety), czynności te mieszczą się w definicji z Rozporządzenia. Od razu zaznaczam, że nie rozstrzygam tego problemu z punktu widzenia teorii – tu można by sporo podyskutować, np. o koncepcji data beyond use, której jestem dużym zwolennikiem. Niemniej ani, maj ani czerwiec, ani reszta 2018 roku nie są raczej najlepszym czasem na teorię.

Kwestia trzecia, chyba najważniejsza

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

Nie samym powierzeniem RODO stoi; niby oczywista sprawa, ale trochę znika w szale i szumie. Np. pracodawca nie powierza danych własnym pracownikom, ale umożliwia im do nich dostęp, do czego wystarczy upoważnienie – DPA nie jest potrzebne. Oczywiście, jak to z RODO, nie ma pewności, gdzie przebiega granica między udostępnieniem a powierzeniem.

To może być najbardziej praktyczny test na weryfikację konieczności zawarcia umowy DPA, opiszę więc kilka modeli:

Model pierwszy – 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. Administrator nie przekazuje danych na zewnątrz. W mojej ocenie – wystarczy upoważnienie, nie ma potrzeby zawierania DPA. Znacznie trudniej jak dostawca wchodzi np. z własnym sprzętem i nie jest monitorowany – tu raczej DPA.

Model drugi – 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. W mojej ocenie dochodzi tu do powierzenia, potrzebne będzie więc zawarcie DPA.

Model trzeci (trudny, pośredni) – częściowa (choć mocna) kontrola. Przypadek zdalnego serwisu za pomocą VPN – dostawca loguje się w systemie administratora, adminsitrator to nadzoruje, nagrywa sesję etc, ale nadal technicznie dane są powielane poza przedsiębiorstwem i np. dostawca może je nagrywać poza wiedzą adminsitratora. Bardzo bym chciał bronic tezy, że przy tak daleko posuniętej kontroli i zobowiązaniach kontraktowych mamy do czynienia z upoważnieniem, a nie powierzeniem, ale 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 IODO zażądałoby mimo wszystko DPA.

Kilka przykładów, które znam z własnego doświadczenia:

  • serwis atik, w którym może się zdarzyć, że dane zostaną pobrane na zewnątrz przy weryfikacji zgłoszenia błędów – DPA,
  • chmura – praktycznie zawsze DPA, choć bywają chmury (a zwłaszcza aplikacje), gdzie po prostu danych osobowych nie ma (np. modele matematyczne),
  • serwis on site komputerów – upoważnienie, (iv) audyt licencyjny – często okazuje się, że np. audytor bierze logi do siebie, a w nich znajdują się dane – 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 – nie zachodzi przetwarzanie, nie ma więc potrzeby zawierania DPA.

Podsumowując

Decyduje kontrola administratora – z ostrożności na dziś przyjąłbym że pełna.

Rynek

Rynek zaakceptował umowy DPA jako zjawisko. Dostawcy mają swoje wzorce – część z tych wzorców nie spełnia wymagań RODO, nic więc dziwnego, że działy prawne czy compliance mówią „nie”. Zamawiający mają swoje – niektóre zupełnie szalone. Dlatego część dostawców, z przyczyn biznesowych, także mówi „nie” („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 ilość takich projektów jest niewiarygodna (większość z naszych klientów dostała po kilkaset różnych wzorców, mój rekord to wysłane kilkadziesiąt tysięcy egzemplarzy umowy). Uzgodnienie odstępstwa od standardu z centralą zagraniczną również jest 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 umowa DPA, czy może wystarczy upoważnienie. Mam nadzieję, że z czasem rynek 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 itd., zajmie trochę czasu. Podobnie jak z licencjami czy wdrożeniami – mamy 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. DPA tego nie ma, a strach jest większy, bo 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 będzie 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, kontrolujmy, 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 jest to opisane w rozporządzeniu i nie bardzo mają z czym tutaj dyskutować.

Tyle w zakresie weekendowych obserwacji. Osobno napiszę o wymaganiu „notyfikacji administratora w 24h od incydentu” przez procesora co jest jedną z najczęściej dyskutowanych klauzul (a kluczowi dostawcy tego nie mają, jak mają to 72h). Ciekawy case, gdyż jest nieprawdziwy z jednej strony, a bardzo prawdziwy z drugiej, ale nie z tej, o której zazwyczaj się myśli …

I mam szczerą nadzieję więcej pisać o licencjach, audytach i chmurach … To mnie naprawdę ciekawi 🙂


Zobacz inne artykuły Marcina Maruty