DPA Agreement: kiedy firma IT potrzebuje umowy o przetwarzaniu danych osobowych

Firma sprzedaje usługę SaaS klientowi z UE. Klient przesyła do systemu dane pracowników lub klientów, dostawca je przechowuje, tworzy kopie zapasowe i zapewnia dostęp zespołowi wsparcia. Podczas uzgadniania umowy klient prosi o podpisanie Data Processing Agreement, czyli DPA.

Taki dokument często jest postrzegany jako formalny załącznik ze standardowego pakietu GDPR. Jednak DPA określa prawny model pracy z danymi: kto ustala cele przetwarzania, kto wykonuje instrukcje, którzy wykonawcy uzyskują dostęp do informacji oraz jak strony postępują w przypadku naruszenia ochrony danych.

Jeżeli postanowienia umowy są niezgodne z architekturą produktu, DPA nie pomoże przejść audytu klienta. Co więcej, firma może przyjąć zobowiązania, których jej zespół techniczny nie jest w stanie wykonać.

Wyrażenie DPA Agreement często pojawia się w zapytaniach wyszukiwania, chociaż słowo Agreement jest już częścią skrótu DPA. Prawidłowa pełna nazwa dokumentu to Data Processing Agreement, czyli umowa o przetwarzaniu danych osobowych.

Kiedy zawarcie DPA jest obowiązkowe

DPA jest wymagane, jeżeli jedna firma przetwarza dane osobowe w imieniu innej. Zasada ta została określona w art. 28 GDPR i ma zastosowanie do relacji pomiędzy administratorem danych a podmiotem przetwarzającym.

Administrator danych decyduje, w jakim celu wykorzystywane są dane osobowe oraz jakie podstawowe zasady przetwarzania będą obowiązywać. Podmiot przetwarzający wykonuje operacje w jego imieniu i postępuje zgodnie z udokumentowanymi instrukcjami.

Na przykład klient korzysta z CRM do pracy z własną bazą klientów. Określa zakres danych, cele ich wykorzystywania oraz okresy przechowywania. Dostawca CRM zapewnia środowisko techniczne, przechowuje informacje i wspiera działanie systemu. W ramach tej operacji klient jest administratorem danych, a dostawca CRM występuje jako podmiot przetwarzający.

Firma IT zazwyczaj potrzebuje DPA w następujących przypadkach:

• usługa SaaS przechowuje lub analizuje dane przesłane przez klienta
• deweloper uzyskuje dostęp do produkcyjnej bazy danych, logów lub kopii zapasowych klienta
• zespół wsparcia ma dostęp do zgłoszeń użytkowników i danych ich kont
• dostawca usług chmurowych przechowuje bazy danych lub pliki
• usługa mailingowa przetwarza adresy e-mail i historię komunikacji
• system monitorowania otrzymuje adresy IP, identyfikatory urządzeń i dzienniki zdarzeń

Do zastosowania art. 28 nie jest wymagane, aby wykonawca regularnie przeglądał dane. Dostęp może być wykorzystywany wyłącznie podczas wsparcia technicznego lub badania incydentu. Jeżeli taki dostęp należy do funkcji wykonawcy i dotyczy danych osobowych, relację stron należy sprawdzić pod kątem zgodności z modelem administrator danych–podmiot przetwarzający.

DPA można zawrzeć jako odrębną umowę lub jako załącznik do MSA, SaaS Agreement albo umowy o świadczenie usług deweloperskich. Nazwa i miejsce dokumentu nie mają decydującego znaczenia. Warunki muszą być wiążące dla stron i zgodne z art. 28 GDPR.

Kiedy DPA nie jest odpowiednim rozwiązaniem

Samo otrzymywanie danych osobowych nie powoduje, że firma staje się podmiotem przetwarzającym. Rola zależy od tego, kto podejmuje decyzje dotyczące celów i istotnych sposobów wykorzystywania informacji.

Bank, instytucja płatnicza lub profesjonalny doradca mogą przetwarzać otrzymane informacje w celu wykonywania własnych obowiązków. W tym zakresie działają jako samodzielni administratorzy danych, dlatego umowa na podstawie art. 28 nie jest odpowiednia dla takich operacji.

Jeżeli dwie firmy wspólnie określają cele i sposoby przetwarzania, mogą powstać między nimi relacje współadministratorów. Ich obowiązki są rozdzielane zgodnie z art. 26 GDPR.

Jeden dostawca może czasami łączyć kilka ról. Platforma SaaS przetwarza bazę klienta na jego zlecenie, a jednocześnie samodzielnie wykorzystuje część danych technicznych do ochrony usługi, zapobiegania oszustwom lub wykonywania obowiązków prawnych. Każdą operację należy oceniać osobno. Sformułowanie zawarte w umowie nie zmieni faktycznego statusu firmy, jeżeli produkt działa inaczej.

Co powinno znaleźć się w DPA

Art. 28 GDPR określa obowiązkową treść umowy. Krótka klauzula dotycząca poufności lub przestrzegania przepisów nie może jej zastąpić.

W DPA należy określić:

1. przedmiot i czas trwania przetwarzania
2. charakter i cele operacji na danych
3. rodzaje danych osobowych i kategorie osób, których dane dotyczą
4. prawa i obowiązki administratora danych
5. zasady wykonywania udokumentowanych instrukcji
6. wymogi dotyczące poufności i bezpieczeństwa
7. zasady korzystania z podwykonawców przetwarzania
8. zasady usuwania lub zwrotu danych
9. pomoc w zakresie żądań użytkowników, DPIA i incydentów
10. udostępnianie informacji i przeprowadzanie audytów

Opis powinien umożliwiać ustalenie, jakie informacje otrzymuje podmiot przetwarzający i co może z nimi robić. Sformułowania takie jak „wszystkie dane niezbędne do świadczenia usług” wyznaczają zbyt szerokie granice.

W przypadku produktu SaaS można osobno wskazać dane rejestracyjne, dane kontaktowe, treść zgłoszeń, historię działań oraz identyfikatory techniczne. Konkretny wykaz zależy od funkcji produktu i danych, które klient faktycznie przesyła do systemu.

Po zakończeniu świadczenia usług informacje są zwracane administratorowi danych lub usuwane zgodnie z jego wyborem, chyba że prawo wymaga ich dalszego przechowywania. Termin usunięcia należy uzgodnić z polityką tworzenia kopii zapasowych. Zobowiązanie do natychmiastowego usunięcia wszystkich kopii jest często niemożliwe do wykonania, ponieważ dane zapasowe są przechowywane do zakończenia ustalonego cyklu nadpisywania.

Dlaczego sekcję dotyczącą bezpieczeństwa należy uzgodnić z zespołem technicznym

Ogólne zobowiązanie do stosowania odpowiednich środków technicznych i organizacyjnych nie daje klientowi jasnego obrazu sposobu ochrony danych. W DPA lub osobnym załączniku należy opisać zarządzanie dostępem, szyfrowanie, tworzenie kopii zapasowych, rejestrowanie działań oraz procedurę reagowania na incydenty.

Treść tej sekcji zależy od ryzyka związanego z przetwarzaniem. Dostawca platformy medycznej pracuje z bardziej wrażliwymi informacjami niż usługa służąca do wysyłania zaproszeń firmowych. Ten sam szablon środków bezpieczeństwa dla takich produktów będzie albo niewystarczający, albo z góry niemożliwy do wykonania.

Zespół techniczny powinien sprawdzić warunki przed podpisaniem umowy. W dokumencie mogą pojawić się zobowiązania dotyczące całodobowego monitorowania, konkretnych standardów szyfrowania lub terminów przywracania systemów, których produkt jeszcze nie spełnia. Po podpisaniu rozbieżność może zostać wykryta podczas audytu klienta lub w trakcie incydentu.

Prawo administratora danych do audytu również należy opisać z wyprzedzeniem. W umowie można określić termin powiadomienia, zasady poufności, dopuszczalne sposoby przeprowadzania kontroli oraz podział kosztów. Całkowity zakaz audytu jest sprzeczny z art. 28, natomiast nieograniczony dostęp klienta do infrastruktury może stwarzać zagrożenie dla innych klientów.

Jak uregulować korzystanie z podwykonawców przetwarzania

Dostawca SaaS rzadko wykonuje wszystkie operacje samodzielnie. W przetwarzaniu mogą uczestniczyć dostawca hostingu, platforma chmurowa, system mailingowy, usługa monitorowania oraz zewnętrzny zespół wsparcia. Jeżeli taki wykonawca otrzymuje dane osobowe w ramach usług świadczonych na rzecz administratora danych, staje się podwykonawcą przetwarzania.

Do jego zaangażowania wymagane jest uprzednie szczegółowe lub ogólne pisemne upoważnienie administratora danych. W przypadku ogólnego upoważnienia dostawca informuje klienta o dodaniu lub zmianie podwykonawcy przetwarzania i zapewnia mu czas na zgłoszenie sprzeciwu.

W DPA należy określić, gdzie znajduje się aktualna lista podwykonawców przetwarzania, w jaki sposób wysyłane są powiadomienia oraz ile czasu klient ma na odpowiedź. Sam link do strony internetowej nie rozwiązuje problemu, jeżeli dostawca może zmienić wykaz bez powiadomienia.

Podwykonawca przetwarzania przyjmuje porównywalne obowiązki w zakresie ochrony danych. Główny podmiot przetwarzający nadal odpowiada przed administratorem danych za ich wykonanie. Przed podłączeniem nowej usługi należy sprawdzić jej warunki umowne, środki bezpieczeństwa, lokalizację systemów oraz zasady dalszego przekazywania informacji.

Co przewidzieć na wypadek naruszenia ochrony danych

W przypadku naruszenia bezpieczeństwa podmiot przetwarzający informuje administratora danych o incydencie bez zbędnej zwłoki. GDPR nie ustanawia dla podmiotu przetwarzającego uniwersalnego terminu 72 godzin. Termin ten dotyczy zgłoszenia naruszenia organowi nadzorczemu przez administratora danych, jeżeli incydent powoduje odpowiednie ryzyko.

W DPA warto uzgodnić termin pierwszego powiadomienia oraz zakres informacji, które podmiot przetwarzający przekazuje na tym etapie. Administrator danych będzie potrzebował opisu naruszenia, kategorii danych objętych incydentem, przybliżonej liczby osób i rekordów, możliwych konsekwencji oraz zastosowanych środków.

Pełny raport rzadko można przygotować w ciągu pierwszych godzin. Praktyczna procedura powinna przewidywać pierwsze powiadomienie po potwierdzeniu incydentu oraz kolejne aktualizacje w miarę postępu dochodzenia. Osoby kontaktowe, zapasowy kanał komunikacji oraz zasady zabezpieczania dowodów najlepiej określić z wyprzedzeniem.

Czy DPA zastępuje standardowe klauzule umowne SCC

DPA reguluje relację pomiędzy administratorem danych a podmiotem przetwarzającym zgodnie z art. 28 GDPR. Standard Contractual Clauses są stosowane jako jeden z mechanizmów przekazywania danych osobowych poza Europejski Obszar Gospodarczy.

Jeżeli europejski klient przekazuje dane podmiotowi przetwarzającemu w państwie trzecim, samo DPA może nie być wystarczające. Strony powinny sprawdzić, czy istnieje decyzja stwierdzająca odpowiedni stopień ochrony, lub wybrać inny mechanizm zgodnie z rozdziałem V GDPR. Przy stosowaniu SCC ocenia się również przepisy prawa kraju odbiorcy oraz rzeczywiste ryzyko dostępu do informacji.

Moduły 2 i 3 SCC zatwierdzonych przez Komisję Europejską obejmują wymogi art. 28. W odpowiednim modelu mogą jednocześnie uregulować relację z podmiotem przetwarzającym oraz międzynarodowe przekazywanie danych. W tym celu należy prawidłowo wybrać moduł i wypełnić załączniki opisujące przetwarzanie, środki bezpieczeństwa oraz wykaz podwykonawców przetwarzania.

Jakie błędy najczęściej pojawiają się w DPA

Najbardziej widoczny problem pojawia się, gdy umowa nie odpowiada produktowi. W dokumencie wskazano, że wszystkie dane znajdują się w UE, ale kopie zapasowe są przechowywane w innym kraju. Dostawca zobowiązuje się do wcześniejszego uzgadniania każdego podwykonawcy przetwarzania, chociaż zespół techniczny podłącza usługi bez udziału prawnika. Termin usunięcia danych nie uwzględnia kopii zapasowych, a procedura zgłaszania incydentu jest niezgodna z procedurą wewnętrzną.

Błędy pojawiają się również przy określaniu ról. Firma określa siebie jako podmiot przetwarzający w odniesieniu do wszystkich operacji, chociaż wykorzystuje część danych do własnych celów. Możliwa jest również sytuacja odwrotna: dostawca uważa się za samodzielnego administratora danych, mimo że faktycznie wykonuje instrukcje klienta.

DPA bywa również mylone z Privacy Policy i Cookie Policy. Privacy Policy wyjaśnia użytkownikom, w jaki sposób firma przetwarza ich dane. Cookie Policy dotyczy wykorzystywania plików cookie i podobnych technologii. DPA reguluje relacje pomiędzy organizacjami.

Naruszenie obowiązków wynikających z art. 28 może skutkować administracyjną karą pieniężną w wysokości do 10 milionów euro lub do 2 procent całkowitego światowego rocznego obrotu z poprzedniego roku obrotowego, w zależności od tego, która kwota jest wyższa. Strony mogą również spotkać się z roszczeniami o odszkodowanie oraz odpowiedzialnością umowną wobec klienta.

Co sprawdzić przed podpisaniem

Weryfikację DPA należy rozpocząć od schematu przepływu danych. Firma określa, jakie informacje trafiają do produktu, gdzie są przechowywane, kto ma do nich dostęp oraz jakie zewnętrzne usługi uczestniczą w przetwarzaniu.

Przed podpisaniem warto sprawdzić:

• czy role stron odpowiadają rzeczywistemu działaniu produktu
• czy wymieniono wszystkie kategorie danych i osób, których dane dotyczą
• czy środki bezpieczeństwa odpowiadają możliwościom firmy
• czy uwzględniono wsparcie, logi i kopie zapasowe
• czy wskazano pełną listę podwykonawców przetwarzania
• czy uregulowano międzynarodowe przekazywanie danych
• czy uzgodniono terminy powiadamiania o incydentach
• czy możliwe jest spełnienie wymogów dotyczących usuwania danych i audytu

Jeżeli klient proponuje własny szablon, każde zobowiązanie należy omówić z zespołem technicznym. Sam fakt posiadania podpisanego dokumentu nie rekompensuje słabej kontroli dostępu, nieznanego łańcucha podwykonawców przetwarzania ani braku procedury reagowania na naruszenia ochrony danych.