01

Kiedy kontrahent jest podmiotem przetwarzającym?

Procesor przetwarza dane osobowe w imieniu administratora. Administrator określa cele i zasadnicze sposoby przetwarzania, natomiast procesor wykonuje usługę obejmującą operacje na danych na jego rzecz. Typowymi przykładami mogą być hosting bazy klientów, utrzymanie systemu HR, obsługa wysyłki newslettera, zewnętrzna archiwizacja albo przetwarzanie listy płac.

Nie każdy usługodawca mający kontakt z danymi jest procesorem. Dostęp przypadkowy lub czysto incydentalny może wymagać zabezpieczeń poufności, ale nie zawsze umowy powierzenia. Z drugiej strony kontrahent, który sam decyduje, po co wykorzystuje dane i określa istotne elementy procesu, może być administratorem niezależnie od tego, że strony nazwały go procesorem.

Przykładowo zewnętrzny inspektor ochrony danych nie staje się automatycznie procesorem tylko dlatego, że w ramach doradztwa zapoznaje się z dokumentacją. UODO wskazuje, że wykonywanie zadań IOD przez osobę zewnętrzną powinno opierać się na umowie o świadczenie usług, a nie co do zasady na umowie powierzenia dotyczącej samej funkcji IOD.

02

Procesor, odrębny administrator czy współadministrator?

Jeżeli strony niezależnie ustalają własne cele przetwarzania, każda może być odrębnym administratorem. Taka sytuacja występuje często, gdy usługodawca ma własny obowiązek prawny albo zawodowy dotyczący danych i nie wykonuje wyłącznie instrukcji klienta.

Współadministratorzy wspólnie określają cele i sposoby przetwarzania. Wtedy potrzebne jest uzgodnienie z art. 26 RODO, które w przejrzysty sposób określa zakres odpowiedzialności, w szczególności za realizację praw osób i obowiązek informacyjny. Zawarcie DPA w relacji, która w rzeczywistości jest współadministrowaniem, może ukryć problem zamiast go rozwiązać.

Relacja może być mieszana. Dostawca SaaS może przetwarzać dane użytkowników klienta jako procesor, a jednocześnie działać jako odrębny administrator w odniesieniu do danych kontaktowych osób reprezentujących klienta, rozliczeń lub obowiązków bezpieczeństwa wynikających z prawa. Umowa powinna te role rozdzielić.

03

Co obowiązkowo musi zawierać umowa z art. 28 RODO?

Umowa lub inny instrument prawny powinny wiązać procesora z administratorem i mieć formę pisemną, w tym elektroniczną. Dokument musi określać przedmiot i czas trwania przetwarzania, jego charakter i cel, rodzaj danych osobowych, kategorie osób oraz obowiązki i prawa administratora.

Procesor powinien przetwarzać dane wyłącznie na udokumentowane polecenie administratora, chyba że obowiązek wynika z prawa. Musi zapewnić poufność osób upoważnionych, wdrożyć środki z art. 32 RODO, przestrzegać reguł angażowania podprocesorów oraz wspierać administratora przy realizacji praw osób, ocenie bezpieczeństwa, naruszeniach i — gdy dotyczy — ocenie skutków dla ochrony danych.

Po zakończeniu usługi procesor powinien, według wyboru administratora, usunąć albo zwrócić dane i usunąć istniejące kopie, chyba że prawo nakazuje ich dalsze przechowywanie. Musi również udostępniać informacje potrzebne do wykazania zgodności i umożliwiać audyty, w tym inspekcje, na zasadach możliwych do wykonania w praktyce.

04

Jak uregulować podprocesorów?

Procesor nie może zaangażować kolejnego procesora bez uprzedniej szczegółowej albo ogólnej pisemnej zgody administratora. Przy zgodzie ogólnej powinien informować o zamierzonych zmianach, tak aby administrator mógł wyrazić sprzeciw.

Umowa powinna wskazywać procedurę aktualizacji listy podprocesorów, termin zawiadomienia, zakres informacji o nowym podmiocie oraz konsekwencje uzasadnionego sprzeciwu. Sama publikacja nowej listy na stronie dostawcy bez skutecznego poinformowania klienta może nie zapewniać realnej możliwości reakcji.

Na podprocesora trzeba nałożyć zasadniczo te same obowiązki ochrony danych, które wiążą procesora wobec administratora. Procesor pozostaje odpowiedzialny wobec administratora za wykonanie obowiązków przez podprocesora. W łańcuchu chmurowym warto ustalić nie tylko nazwy dostawców, ale również zakres usługi, lokalizacje przetwarzania i podstawę ewentualnego transferu poza EOG.

05

Jak zweryfikować procesora przed podpisaniem umowy?

Administrator może korzystać wyłącznie z procesorów zapewniających wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych. Ocena powinna odpowiadać ryzyku i charakterowi usługi. Dla prostego narzędzia do zapisów na wydarzenie może być lżejsza niż dla dostawcy obsługującego dane medyczne albo pełną bazę pracowników.

Weryfikacja może obejmować opis architektury, zarządzanie dostępem, szyfrowanie, kopie zapasowe, testy bezpieczeństwa, procedurę reagowania na incydenty, certyfikaty, wyniki audytów, retencję, lokalizacje danych i historię istotnych naruszeń. Certyfikat jest dowodem pomocniczym, a nie automatycznym zwolnieniem administratora z oceny.

W decyzji dotyczącej McDonald’s Polska Prezes UODO podkreślił, że wieloletnia współpraca i referencje nie wystarczały do oceny gwarancji procesora. Praktyczny wniosek jest szerszy: wybór dostawcy powinien pozostawić ślad pokazujący, jakie informacje sprawdzono, jakie ryzyka przyjęto i jakie zabezpieczenia uzgodniono.

06

Jak ułożyć procedurę naruszeń i współpracy z administratorem?

Procesor ma zawiadomić administratora o naruszeniu ochrony danych bez zbędnej zwłoki po jego stwierdzeniu. RODO nie wyznacza procesorowi osobnego terminu 72 godzin. Ten termin dotyczy zgłoszenia przez administratora do organu nadzorczego, dlatego kontraktowy termin procesora powinien zostawiać administratorowi realny czas na ocenę i decyzję.

DPA powinna określać kanał alarmowy, minimalny zakres pierwszej informacji, obowiązek przekazywania kolejnych ustaleń, zabezpieczenie dowodów, współpracę przy analizie ryzyka i komunikacji oraz zasady pokrywania uzasadnionych kosztów. Sztywny obowiązek dostarczenia pełnego raportu w kilka godzin może być nierealny; lepszy jest model wczesnego zawiadomienia i informacji uzupełnianych etapami.

Plan pierwszych działań administratora opisuje artykuł Naruszenie ochrony danych osobowych — co firma powinna zrobić w pierwszych 72 godzinach?.

07

Czy standardowy wzór DPA wystarczy?

Wzór jest punktem wyjścia, nie dowodem zgodności. Załącznik opisujący przetwarzanie powinien odpowiadać rzeczywistej usłudze. Ogólne sformułowanie „wszelkie dane niezbędne do realizacji umowy” utrudnia ocenę zakresu, ryzyka, retencji i zabezpieczeń.

Umowa powierzenia powinna być też spójna z kontraktem głównym. W relacji technologicznej warto równolegle sprawdzić kwestie opisane w artykule Umowa SaaS z klientem biznesowym — co uregulować przed rozpoczęciem sprzedaży?. Szersza kontrola procesorów, rejestrów i rzeczywistych przepływów danych może być częścią audytu RODO w małej i średniej firmie.

Komisja Europejska przyjęła standardowe klauzule umowne między administratorami i procesorami w decyzji 2021/915. Ich użycie może spełnić wymagania art. 28 ust. 3 i 4 RODO. Nie należy ich mylić ze standardowymi klauzulami z decyzji 2021/914 dotyczącymi transferów do państw trzecich. Jeżeli dane trafiają poza EOG, trzeba oddzielnie ustalić mechanizm transferu i — gdy wymagane — ocenić jego skuteczność.

PRAKTYKA

Jak ten problem wygląda w praktyce

Przykład

Przykład praktyczny — sytuacja hipotetyczna

Polska spółka wdraża platformę HR do obsługi rekrutacji i dokumentacji pracowniczej. Dostawca przesyła jednostronicową DPA, w której zapisano jedynie, że „przetwarza dane zgodnie z RODO”. Lista podprocesorów jest dostępna pod zmiennym adresem internetowym, a dostawca może ją aktualizować bez zawiadomienia. Umowa nie określa czasu zgłoszenia incydentu ani sposobu usuwania kopii zapasowych po zakończeniu usługi. Po kilku miesiącach dostawca dodaje usługę analityczną z USA i wykorzystuje część danych do rozwijania własnego modułu porównawczego. Dochodzi do nieuprawnionego dostępu, ale klient otrzymuje informację po czterech dniach. Spółka nie jest w stanie szybko ustalić kategorii danych, liczby osób ani lokalizacji kopii. Ryzyko powstało nie tylko przez brak rozbudowanych klauzul, lecz przede wszystkim przez niewłaściwe określenie ról i brak procesu kontroli dostawcy. Prawidłowa umowa powinna rozdzielić przetwarzanie na polecenie klienta od ewentualnych własnych celów dostawcy, zawierać opis danych i operacji, listę zatwierdzonych podprocesorów, procedurę zmian, wymagania bezpieczeństwa, szybkie zawiadomienie o incydencie oraz zasady zwrotu i usunięcia danych wraz z kopiami. Przed podpisaniem spółka powinna udokumentować ocenę gwarancji dostawcy i mechanizmu transferu.

Checklista robocza

Kwestie do ustalenia lub sprawdzenia przed działaniem

  • Kto faktycznie ustala cele i istotne sposoby przetwarzania w każdym procesie?
  • Jakie operacje na danych są konieczne do wykonania usługi i które stanowią własne cele dostawcy?
  • Jakie kategorie osób i danych, w tym dane szczególnych kategorii, obejmuje usługa?
  • Jak zweryfikowano gwarancje bezpieczeństwa i zgodności procesora?
  • Którzy podprocesorzy są zatwierdzeni i jak administrator dowie się o zmianie?
  • Gdzie dane są przechowywane i czy występują transfery poza EOG?
  • Jak szybko procesor ma zgłosić incydent i jakie informacje przekaże w pierwszej wiadomości?
  • Jak zostaną zwrócone lub usunięte dane, logi i kopie zapasowe po zakończeniu współpracy?

Najważniejsze zagadnienia w skrócie

ZagadnienieKluczowa informacja
ProcesorPrzetwarza dane w imieniu administratora i zasadniczo według jego udokumentowanych poleceń.
Odrębny administratorSam określa cele i istotne sposoby własnego przetwarzania; DPA nie zastępuje właściwej podstawy i obowiązków administratora.
WspóładministratorWspólnie z innym podmiotem ustala cele i sposoby; potrzebne jest uzgodnienie z art. 26 RODO.
PodprocesorWymaga szczegółowej lub ogólnej pisemnej zgody oraz nałożenia odpowiednich obowiązków ochrony danych.
IncydentProcesor informuje bez zbędnej zwłoki; kontrakt powinien pozwalać administratorowi zmieścić się w swoim terminie 72 godzin, gdy zgłoszenie jest wymagane.
Transfer poza EOGDPA z art. 28 nie jest sama w sobie mechanizmem legalizującym transfer do państwa trzeciego.
Koniec usługiAdministrator wybiera co do zasady zwrot albo usunięcie danych; wyjątek wymaga podstawy prawnej dalszego przechowywania.
PODSTAWY PRAWNE

Podstawy prawne

  • Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z 27 kwietnia 2016 r. (RODO), w szczególności art. 4 pkt 7 i 8, art. 26, art. 28, art. 29, art. 32–36, art. 44–49, art. 82 i art. 83.
  • Decyzja wykonawcza Komisji (UE) 2021/915 z 4 czerwca 2021 r. w sprawie standardowych klauzul umownych między administratorami a podmiotami przetwarzającymi na podstawie art. 28 ust. 7 RODO oraz art. 29 ust. 7 rozporządzenia (UE) 2018/1725.
Rozwiń tematE-commerce i technologie RODO i compliance

Materiał ma charakter ogólny i nie stanowi porady prawnej w konkretnej sprawie. Właściwe rozwiązanie zależy od stanu faktycznego, dokumentów i celu biznesowego.

Podsumowanie

Dobra DPA zaczyna się od właściwego określenia ról, a nie od wyboru wzoru. Powinna opisywać rzeczywistą usługę, dawać administratorowi kontrolę nad podprocesorami i zmianami oraz zapewniać wykonalną współpracę przy bezpieczeństwie, prawach osób i zakończeniu usługi. Mogę ustalić role stron, przygotować lub zweryfikować umowę powierzenia, przeprowadzić ocenę dostawcy i uporządkować proces zarządzania procesorami w firmie.