Kiedy firma musi zawrzeć umowę powierzenia?

Obowiązek powstaje, gdy jeden podmiot przetwarza dane osobowe na rzecz drugiego i nie realizuje przy tym własnego, niezależnego celu. Typowymi przykładami mogą być:

Nie każdy dostawca w tych kategoriach automatycznie będzie procesorem. O kwalifikacji decyduje konkretny model. Jeżeli kontrahent wykorzystuje dane również do własnej analityki, profilowania, rozwoju niezależnej usługi albo własnego marketingu, trzeba osobno ocenić te operacje. W ramach jednej relacji podmiot może być procesorem dla części czynności i odrębnym administratorem dla innych.

Umowa powierzenia może stanowić załącznik do umowy głównej albo jej wyodrębnioną część. RODO wymaga formy pisemnej, w tym elektronicznej. DPA powinna być spójna z opisem usługi, SLA, zasadami bezpieczeństwa i odpowiedzialności. W przeciwnym razie dokumenty mogą przewidywać różne terminy zgłoszenia incydentu albo sprzeczne reguły korzystania z podwykonawców.

  • dostawca hostingu utrzymujący bazę klientów;
  • biuro rachunkowe przetwarzające dane pracowników zgodnie z zakresem zlecenia;
  • dostawca systemu CRM lub helpdesku, który przechowuje dane użytkowników klienta;
  • zewnętrzna firma prowadząca wysyłkę newslettera z bazy administratora;
  • serwis IT uzyskujący dostęp do danych podczas utrzymania systemu.

Jak odróżnić procesora od odrębnego administratora?

Administrator ustala cele i sposoby przetwarzania danych. Procesor działa w jego imieniu i na podstawie udokumentowanych instrukcji. Współadministratorzy wspólnie ustalają cele i sposoby przetwarzania.

Najpierw warto odpowiedzieć na pytania praktyczne:

Procesor może samodzielnie dobierać część rozwiązań technicznych lub organizacyjnych, nie tracąc tego statusu. Jeżeli jednak zaczyna określać własny cel przetwarzania, w tym zakresie może zostać uznany za administratora. Zgodnie z art. 28 ust. 10 RODO procesor, który z naruszeniem rozporządzenia sam określa cele i sposoby przetwarzania, jest traktowany jako administrator w odniesieniu do tego przetwarzania.

Przy usługach chmurowych i SaaS analiza ról powinna poprzedzać negocjowanie wzoru dostawcy. Więcej elementów umowy głównej opisuje artykuł Umowa SaaS z klientem biznesowym — co uregulować przed rozpoczęciem sprzedaży?.

  • kto decyduje, dlaczego dane są wykorzystywane;
  • kto określa kategorie osób i zakres danych;
  • czy dostawca może użyć danych do własnych celów;
  • kto decyduje o czasie przechowywania;
  • czy dostawca może łączyć dane z informacjami z innych klientów;
  • kto odpowiada na żądania osób, których dane dotyczą.

Co obowiązkowo powinna zawierać DPA?

Umowa albo inny instrument prawny musi określać co najmniej:

Powinna również zobowiązywać procesora między innymi do:

Samo powtórzenie tej listy nie rozwiązuje problemów wykonawczych. Umowa powinna wskazywać osoby kontaktowe, sposób przekazywania instrukcji, format informacji o incydencie, czas reakcji oraz procedurę eksportu i usunięcia danych. Jeżeli przetwarzanie jest złożone, opis operacji i zabezpieczeń warto umieścić w aktualizowanych załącznikach.

  • przedmiot i czas trwania przetwarzania;
  • charakter i cel przetwarzania;
  • rodzaj danych osobowych i kategorie osób;
  • obowiązki i prawa administratora.
  • działania wyłącznie na udokumentowane polecenie administratora, także w zakresie transferów danych, chyba że przetwarzanie nakazuje prawo;
  • zapewnienia poufności osobom upoważnionym do przetwarzania;
  • wdrożenia środków wymaganych przez art. 32 RODO;
  • przestrzegania zasad angażowania podprocesorów;
  • wspierania administratora przy realizacji praw osób;
  • pomocy przy obowiązkach dotyczących bezpieczeństwa, naruszeń, oceny skutków i konsultacji z organem;
  • usunięcia albo zwrotu danych po zakończeniu usług, według decyzji administratora, chyba że prawo wymaga dalszego przechowywania;
  • udostępniania informacji potrzebnych do wykazania zgodności oraz umożliwienia audytów i inspekcji;
  • sygnalizowania, że instrukcja administratora w ocenie procesora narusza RODO lub inne przepisy o ochronie danych.

Jak zweryfikować dostawcę, zamiast polegać na jego oświadczeniu?

Administrator może korzystać wyłącznie z procesorów zapewniających wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych. Nie jest to jednorazowa formalność przy podpisaniu umowy. Zakres weryfikacji powinien odpowiadać ryzyku, rodzajowi danych, skali usługi i zależności biznesowej.

W praktyce można sprawdzić między innymi:

  • opis architektury i lokalizacje przetwarzania;
  • zasady kontroli dostępu, uwierzytelniania, szyfrowania i tworzenia kopii;
  • procedurę zarządzania podatnościami i incydentami;
  • wyniki niezależnych audytów albo certyfikaty — z oceną ich rzeczywistego zakresu;
  • historię istotnych naruszeń i sposób wdrożenia działań naprawczych;
  • ciągłość działania i możliwość odzyskania danych;
  • listę podprocesorów i podział odpowiedzialności;
  • proces usunięcia lub zwrotu danych po rozwiązaniu umowy.
PRAKTYKA

Jak ten problem wygląda w praktyce

Przykład

Hipotetyczny przykład: dostawca CRM z nieprzejrzystym łańcuchem podprocesorów

Spółka wdraża chmurowy CRM zawierający dane kontaktowe klientów, historię sprzedaży i korespondencję. Podpisuje jednostronicowy załącznik, w którym dostawca deklaruje „zgodność z RODO” i otrzymuje ogólną zgodę na wszystkich obecnych i przyszłych podwykonawców. Dokument nie wskazuje lokalizacji danych, terminu zgłoszenia incydentu ani sposobu eksportu po zakończeniu usługi. Po kilku miesiącach dochodzi do nieuprawnionego dostępu u podprocesora świadczącego wsparcie z państwa trzeciego. Dostawca informuje klienta po pięciu dniach, ponieważ jego wewnętrzna procedura nie przewiduje wcześniejszego powiadomienia. Klient nie ma pełnej listy objętych osób ani informacji potrzebnych do oceny ryzyka. Prawidłowy proces powinien rozpocząć się od mapy ról i operacji. DPA powinna wskazywać zakres danych, instrukcje, środki bezpieczeństwa, podprocesorów i lokalizacje, procedurę zmian oraz szybkie zgłoszenie incydentu. Osobno należałoby ocenić mechanizm transferowy i możliwość sprzeciwu wobec nowego podprocesora. Umowa główna powinna zapewniać eksport danych i współpracę przy migracji.

Jak uregulować podprocesorów i transfery poza EOG?

Procesor nie może zaangażować dalszego podmiotu przetwarzającego bez uprzedniego szczegółowego albo ogólnego pisemnego upoważnienia administratora. Przy upoważnieniu ogólnym powinien informować o planowanych zmianach, tak aby administrator miał możliwość wniesienia sprzeciwu.

DPA powinna określać:

Sama zgoda na podprocesora nie rozwiązuje kwestii transferu danych do państwa trzeciego. Jeżeli w łańcuchu występuje przekazanie lub dostęp spoza EOG, trzeba osobno ustalić podstawę z rozdziału V RODO, zakres transferu i wymagane zabezpieczenia. Dotyczy to również sytuacji, w której podstawowa infrastruktura znajduje się w EOG, ale wsparcie techniczne może uzyskać dostęp z innego państwa.

  • aktualną listę albo dostępny rejestr podprocesorów;
  • zakres wykonywanych przez nich operacji;
  • państwa, w których następuje przetwarzanie;
  • sposób i termin powiadamiania o zmianach;
  • realny tryb zgłoszenia sprzeciwu oraz skutki braku porozumienia;
  • obowiązek nałożenia na podprocesora zasadniczo tych samych obowiązków ochrony danych;
  • odpowiedzialność głównego procesora za wykonanie obowiązków przez podprocesora.

Jak DPA powinna regulować incydenty, audyty i zakończenie usługi?

Procesor ma zgłosić administratorowi naruszenie ochrony danych bez zbędnej zwłoki po jego stwierdzeniu. Administrator może mieć jedynie 72 godziny na zgłoszenie naruszenia organowi nadzorczemu, dlatego ogólne powtórzenie ustawowego zwrotu może być niewystarczające operacyjnie.

Umowa powinna określać minimalny zakres pierwszego zgłoszenia, kanał alarmowy, dostępność zespołu, zasady aktualizacji informacji i zabezpieczenia dowodów. Wymagany termin warto dopasować do usługi i ryzyka. Procesor nie powinien odkładać pierwszej informacji do czasu zakończenia pełnego dochodzenia.

Prawo do audytu powinno pozwalać administratorowi uzyskać informacje wystarczające do wykazania zgodności. Jednocześnie w usługach wieloklienckich rozsądne jest uporządkowanie kolejności środków: dokumentacja i raporty niezależne, spotkanie z zespołem bezpieczeństwa, a w uzasadnionych przypadkach audyt zdalny lub na miejscu. Ograniczenia audytowe nie mogą pozbawiać administratora realnej możliwości kontroli.

Plan wyjścia powinien natomiast rozstrzygać:

  • w jakim formacie i terminie dane zostaną zwrócone;
  • kto odpowiada za migrację;
  • kiedy zostaną usunięte kopie robocze i zapasowe;
  • jak procesor potwierdzi usunięcie;
  • jakie dane musi zachować na podstawie prawa i jak zostaną odseparowane;
  • czy administrator ma dostęp do danych w okresie wypowiedzenia i po awarii usługi.
PODSTAWY PRAWNE

Podstawy prawne

  • Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), w szczególności art. 4 pkt 7 i 8, art. 26, art. 28, art. 29, art. 32, art. 33 oraz art. 44–49.
  • 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.
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

DPA jest elementem zarządzania realnym procesem, a nie formalnym załącznikiem do każdej umowy z dostawcą. Największe ryzyko powstaje zwykle wcześniej: przy błędnym ustaleniu ról, braku weryfikacji zabezpieczeń albo nieprzejrzystym łańcuchu podprocesorów. Dokument powinien łączyć wymagania art. 28 RODO z procedurami, które da się wykonać podczas incydentu, audytu i zakończenia usługi.