Twoja firma podpisała umowę powierzenia danych osobowych z dostawcą usług rok temu. Standardowy szablon, średniej długości, z minimum wymaganym przez RODO. Dziś dowiadujesz się, że dostawca powierzył, bez Twojej zgody, część przetwarzania podwykonawcy spoza Europejskiego Obszaru Gospodarczego. Pierwsze pytanie: czy Twoja klauzula podpowierzenia w ogóle to dopuszcza? Drugie: jaką odpowiedzialność ponosi procesor? Trzecie, zadane najprawdopodbnij przez UODO w trakcie kontroli: jakie środki techniczne i organizacyjne wdrożyłeś, by tego uniknąć? W tym momencie okazuje się, że DPA, które podpisałeś jako formalność, w warunkach naruszenia lub kontroli nie chroni Cię tak, jak zakładałeś.

W tym artykule pokazujemy, które klauzule DPA realnie decydują o odpowiedzialności procesora i administratora. Skupiamy się na obszarach najczęściej zaniedbywanych w typowych umowach: podpowierzeniu, środkach bezpieczeństwa, transferze danych poza UE oraz zakończeniu przetwarzania. Wskazujemy też, które zapisy w DPA są najczęściej kwestionowane przez organy nadzorcze, jakie są obowiązki procesora danych osobowych w RODO oraz jak w DPA klauzule ochrony danych osobowych 2026 różnią się od standardowych szablonów. Tekst pomoże również ocenić, kiedy umowa powierzenia przetwarzania danych osobowych w postaci wzoru dostępnego w internecie wystarczy, a kiedy niezbędne jest indywidualne dostosowanie.

Sprawdź : obsługa incydentów RODO

Dlaczego standardowe DPA przestaje działać przy pierwszym incydencie?

DPA (Data Processing Agreement), czyli umowa powierzenia danych jest wymagana zawsze, gdy administrator danych osobowych zleca przetwarzanie danych osobie trzeciej działającej w jego imieniu. Nie ma znaczenia forma współpracy: czy to dostawca SaaS, agencja marketingowa, biuro rachunkowe czy inny usługodawca. Jeśli przetwarza dane osobowe Twoich klientów, kontrahentów lub ich pracowników, wówczas jest procesorem, a Ty potrzebujesz DPA. Wymaga tego art. 28 RODO.

Standardowa umowa w RODO o powierzeniu przetwarzania, powinna zawierać elementy określone w art. 28 RODO: przedmiot, czas trwania, charakter i cel przetwarzania, rodzaj danych osobowych, kategorie osób, których dane dotyczą, oraz obowiązki i prawa administratora. To minimum jest dobrze znane i typowe, szablony są dostępne w internecie. Zakres przetwarzania danych osobowych przez procesora powinien być doprecyzowany, ogólne stwierdzenie, że powierzamy dane osobowe nie spełnia tego wymogu.

Problem zaczyna się, gdy minimum traktowane jest jako wystarczający standard. Klauzule DPA to nie tylko obowiązkowe elementy z art. 28, ale również sposób ich realizacji, który decyduje o tym, czy w razie incydentu lub naruszenia umowy Twoja firma jest realnie chroniona. Klauzule odpowiedzialności w umowie powierzenia danych, klauzule podpowierzenia, audytu, terminu notyfikacji o naruszeniach, to wszystko obszary, gdzie standardowe szablony często pomijają niuanse decydujące o realnej ochronie. Odpowiedzialność procesora danych w większości typowych umów jest sformułowana w sposób ogólny, który trudno egzekwować w razie sporu.

Za co odpowiada administrator, a za co procesor po naruszeniu danych?

RODO wprowadza dwie role w przetwarzaniu danych osobowych: administratora (art. 4 pkt 7) oraz podmiotu przetwarzającego, czyli procesora (art. 4 pkt 8). Administrator decyduje o celach i sposobach przetwarzania, procesor wykonuje przetwarzanie w imieniu i na rzecz administratora, działa w granicach wydawanych mu poleceń. Z perspektywy każdego DPA to fundamentalne rozróżnienie i źródło częstych nieporozumień kontraktowych.

Najważniejsze różnice w obowiązkach i odpowiedzialności, w perspektywie DPA:

Administrator – wypełnia obowiązki informacyjne wobec podmiotów danych, realizuje ich prawa, zgłasza naruszenia do UODO. Pełna odpowiedzialność administratora danych obejmuje również odpowiedzialność odszkodowawczą RODO wobec osób, których dane dotyczą.
Procesor – obowiązki podmiotu przetwarzającego obejmują wykonywanie przetwarzania wyłącznie zgodnie z udokumentowanymi instrukcjami administratora, niezwłoczne informowanie administratora o naruszeniach (art. 33 ust. 2), wdrożenie środków technicznych i organizacyjnych adekwatnych do ryzyka przetwarzania (art. 32).

Kto ponosi odpowiedzialność za naruszenie danych osobowych? Z punktu widzenia podmiotu danych obie strony, każda za swoje działania (art. 82 ust. 2 RODO). Administrator odpowiada za swoje działania oraz za wybór procesora i nadzór nad nim. Procesor odpowiada wyłącznie wtedy, gdy nie wykonał obowiązków RODO skierowanych konkretnie do podmiotów przetwarzających albo działał wbrew zgodnym z prawem instrukcjom administratora.

W praktyce oznacza to, że odpowiedzialność administratora za naruszenie danych po stronie procesora jest niemal zawsze współistniejąca. Klauzule w DPA decydują o tym, czy administrator może następnie odzyskać część kosztów od procesora w drodze regresu to jest realna funkcja klauzul odpowiedzialności w umowie powierzenia danych.

Podpowierzenie danych – dlaczego większość klauzul nie daje administratorowi kontroli?

Podpowierzenie przetwarzania danych to obszar najczęściej zaniedbywany w typowych DPA, a jednocześnie obszar, w którym najczęściej dochodzi do naruszeń. Procesor angażuje podwykonawców, którzy są dla niego operacyjnie nieodzowni, ale formalnie stają się podprocesorami danych Twojej firmy. Kontrola nad tą siecią wymaga konkretnych klauzul w DPA. Artykuł 28 ust. 2 RODO daje administratorowi prawo wyrażenia zgody na podpowierzenie, ale jego wykonalność zależy od tego, jak zapis jest sformułowany.

Istnieją trzy modele klauzuli podpowierzenia danych osobowych, gdyż zgoda administratora może być wyrażona w różny sposób. Praktyka rynkowa wypracowała kilka rozwiązań:

Zgoda jednostkowa – procesor musi uzyskać pisemną zgodę administratora przed każdym powierzeniem konkretnemu podprocesorowi. Najsilniejsza ochrona, ale operacyjnie uciążliwa dla procesora. Realnie funkcjonuje w sektorach wysokoregulowanych.
Zgoda ogólna z prawem sprzeciwu – procesor może powierzać dane podprocesorom z udostępnionej listy, z obowiązkiem powiadomienia administratora o każdej zmianie listy z [X]-dniowym wyprzedzeniem i prawem administratora do sprzeciwu. To najczęściej akceptowany model w obrocie B2B.
Zgoda blankietowa – administrator zgadza się na powierzenie danych dowolnemu podprocesorowi bez dalszej kontroli. Klauzula szeroko stosowana przez globalnych dostawców SaaS, ale z perspektywy ochrony administratora niewystarczająca.

Niezależnie od wybranego modelu, kluczowe jest zapewnienie, że na podprocesora zostaną nałożone te same obowiązki, które wynikają z DPA między administratorem a procesorem (art. 28 ust. 4 RODO). To wymóg ustawowy, ale w praktyce trudny do weryfikacji, dlatego klauzule audytu w DPA powinny obejmować także prawo audytu łańcucha podprocesorów. Audyt procesora oraz okresowy audyt jego podwykonawców to jeden z najważniejszych mechanizmów nadzoru, jakie pozostają administratorowi po podpisaniu DPA. Klauzule umowne zgodne z RODO powinny precyzyjnie określać zakres tego prawa, w tym możliwość zaangażowania niezależnego audytora.

Sprawdź : Audyt prawny umów IT

Jak wygląda bezpieczna klauzula podpowierzenia w modelu SaaS?

Poniżej miejsce na konkretną propozycję brzmienia klauzuli, którą możesz wykorzystać jako punkt wyjścia w negocjacjach z procesorem:

Sugerowane elementy klauzuli: lista zatwierdzonych podprocesorów jako załącznik, obowiązek powiadomienia administratora o zmianach z [X]-dniowym wyprzedzeniem, prawo administratora do sprzeciwu, obowiązek nałożenia na podprocesora tych samych obowiązków (art. 28 ust. 4 RODO), prawo audytu łańcucha podprocesorów.

Jak opisać środki bezpieczeństwa, żeby DPA przeszło kontrolę UODO?

Art. 32 RODO nakłada na obie strony obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych zapewniających bezpieczeństwo przetwarzania. W DPA ten obowiązek powinien być doprecyzowany, najlepiej przez listę wymaganych środków. Ogólne stwierdzenie: „Procesor wdroży odpowiednie środki bezpieczeństwa” nie jest dobrą prkatyką.

Klauzula środków bezpieczeństwa powinna obejmować:

Konkretne środki techniczne – szyfrowanie danych w spoczynku i w tranzycie, mechanizmy kontroli dostępu, segmentację sieciową, monitoring incydentów, regularne backupy z testowaniem odtwarzania.
Środki organizacyjne – polityki bezpieczeństwa, szkolenia personelu, kontrole dostępu fizycznego, procedury reagowania na incydenty.
Standardy referencyjne – odwołanie do ISO 27001 lub innego standardu branżowego, z obowiązkiem utrzymania certyfikacji w okresie obowiązywania umowy.
Udokumentowanie – obowiązek procesora do udostępnienia administratorowi dokumentacji zastosowanych środków na żądanie.
Aktualizacja – obowiązek dostosowania środków do zmieniającego się stanu wiedzy technicznej i ryzyka.

Z mojej praktyki wynika, że sporządzenie listy konkretnych środków bezpieczeństwa jako załącznika do DPA istotnie ułatwia późniejsze audyty i kontrole. Sama klauzula ogólna z odesłaniem do polityki dostawcy bywa kwestionowana przez organy nadzorcze.

Które zapisy o bezpieczeństwie realnie ograniczają ryzyko administratora?

Poniżej miejsce na konkretną propozycję brzmienia klauzuli zobowiązującej procesora do wdrożenia określonych środków bezpieczeństwa:

Sugerowane elementy klauzuli: odesłanie do załącznika z listą środków technicznych i organizacyjnych, wymóg utrzymania określonych certyfikacji (ISO 27001), obowiązek udokumentowania zastosowanych środków na żądanie administratora, obowiązek aktualizacji środków do zmieniającego się stanu wiedzy technicznej, kara umowna za naruszenie obowiązku.

Czy SCC wystarczą bez osobno negocjowanego DPA?

Standardowe klauzule umowne, czyli SCC zatwierdzone decyzją wykonawczą Komisji 2021/914, są narzędziem głównie do transferu danych osobowych poza Europejski Obszar Gospodarczy. Funkcjonują jednak również jako wzorzec klauzul umownych RODO między administratorem a procesorem.

Czy standardowe klauzule umowne mogą zastąpić indywidualnie negocjowane DPA? W zasadzie tak – zwłaszcza Moduł 2 SCC (administrator do procesora) i Moduł 3 (procesor do podprocesora) zawierają wszystkie elementy wymagane przez art. 28 ust. 3 RODO. W praktyce jednak SCC pełnią dwie różne funkcje, które warto rozróżnić.

Funkcja transferu – SCC jako podstawa transferu danych poza EOG, w sytuacji braku decyzji Komisji o adekwatności. Tu SCC są obligatoryjne.
Funkcja DPA – SCC jako kompletna umowa powierzenia. Dopuszczalne, ale praktyka rynkowa w Polsce idzie w kierunku rozbudowanych DPA z dodatkowymi klauzulami (kary umowne, audyt, podpowierzenie), których SCC nie precyzują.

Z perspektywy ochrony Twojej firmy SCC są dobrym minimum, ale rzadko optymalnym rozwiązaniem. Indywidualnie negocjowane DPA pozwala doprecyzować obszary, w których SCC są ogólne, zwłaszcza limity odpowiedzialności i kar umownych. Problem ten szerzej omawiamy w odrębnym artykule.

Co powinna zawierać klauzula usunięcia lub zwrotu danych po zakończeniu umowy – co dzieje się z danymi po zakończeniu umowy SaaS?

Art. 28 ust. 3 lit. g RODO obliguje procesora do usunięcia lub zwrotu wszystkich danych osobowych po zakończeniu świadczenia usług, zgodnie z wyborem administratora. To jeden z najczęściej zaniedbywanych elementów DPA, gdyż typowy szablon zawiera ogólne klauzule, która w praktyce nie są wystarczające.

Pełna klauzula usunięcia lub zwrotu danych powinna obejmować:

Wybór administratora – pisemne zlecenie zwrotu lub usunięcia danych w określonym terminie po zakończeniu umowy.
Format zwracanych danych – ustrukturyzowany, powszechnie używany format elektroniczny z dokumentacją schematu.
Termin – nie dłuższy niż 30 dni od zakończenia umowy.
Procedura usunięcia – z certyfikatem usunięcia obejmującym także kopie zapasowe.
Wyjątki – obowiązki retencji wynikające z prawa (np. ustawa o rachunkowości) wymagają wyraźnego wskazania.
Konsekwencje naruszenia – procesor, który nie usunął danych w terminie, naraża się na kary umowne i odpowiedzialność odszkodowawczą.

Jak zabezpieczyć usunięcie danych i kopii zapasowych?

Poniżej miejsce na konkretną propozycję brzmienia klauzuli regulującej los danych po zakończeniu świadczenia usług:

Sugerowane elementy klauzuli: pisemne zlecenie administratora wskazujące zwrot lub usunięcie, format zwracanych danych, termin 30 dni, procedura usunięcia z certyfikatem usunięcia obejmującym kopie zapasowe, wyjątki dla obowiązków retencji wynikających z prawa, kara umowna za uchybienie.

Które klauzule DPA najczęściej podważają organy nadzorcze?

Praktyka decyzyjna UODO oraz orzecznictwo TSUE w obszarze RODO dają wgląd w to, które zapisy DPA są najczęściej kwestionowane jako niewystarczające. To wskazówka, których obszarów nie warto pomijać przy negocjacji.

Ogólne klauzule środków bezpieczeństwa – zapisy bez konkretnej listy lub odesłania do standardu rynkowego.
Zgoda blankietowa na podpowierzenie – zapisy dające procesorowi nieograniczone prawo zlecania przetwarzania bez kontroli administratora.
Brak określenia terminu notyfikacji o naruszeniach lub termin nadmiernie długi, powyżej 72 godzin lub brak wskazania terminu notyfikacji.
Brak praw audytu administratora lub ustalenia nieadekwatne do skali przetwarzania.
Klauzule wyłączające odpowiedzialność procesora w sposób rażąco dysproporcjonalny.
Brak określenia kategorii danych i podmiotów danych, zapisy zbyt ogólne uniemożliwiają ocenę zgodności.

Naruszenie ochrony danych osobowych w sytuacji, gdy DPA zawiera takie zapisy, może skutkować karą administracyjną również wobec administratora za nieprawidłowy wybór procesora i nadzór. To dodatkowy argument za audytem prawnym DPA przed jego podpisaniem.

Kiedy procesor odpowiada finansowo za naruszenie danych?

Kary za naruszenie umowy powierzenia RODO funkcjonują w dwóch reżimach równocześnie. Procesor, który naruszy obowiązki z DPA, naraża się na każde z nich osobno.

Sankcje administracyjne – kary nakładane przez UODO (lub inny organ nadzorczy) zgodnie z art. 83 RODO, do 20 mln euro lub 4% rocznego światowego obrotu.
Odpowiedzialność cywilna – wobec administratora na podstawie umowy (kary umowne, odszkodowanie) oraz wobec podmiotów danych na podstawie art. 82 RODO.

Z perspektywy procesora oznacza to, że dobrze skonstruowane DPA jest w jego interesie tak samo, jak w interesie administratora. Precyzyjne klauzule ograniczają ryzyko, niejasne zwiększają tylko nieprzewidywalność.

Kiedy warto negocjować DPA z prawnikiem przed podpisaniem umowy?

Z mojej praktyki wynika, że są cztery momenty, w których zaangażowanie prawnika daje największy zwrot.

Przed podpisaniem DPA – audyt projektu umowy oraz negocjacja klauzul podpowierzenia, audytu, środków bezpieczeństwa i odpowiedzialności. Po podpisaniu możliwości modyfikacji są ograniczone.
Przy aneksowaniu istniejących umów – zwłaszcza po istotnych zmianach po stronie procesora (zmiana właściciela, lokalizacji, zakresu usług).
Przy projektowaniu szablonu DPA dla Twojej firmy – jeden dobrze przemyślany szablon używany w wielu kontraktach skraca późniejsze negocjacje.
Po incydencie lub kontroli UODO (najmniej opłacalny moment) – wsparcie prawne jest możliwe, ale w warunkach presji rzadko prowadzi do istotnej zmiany pozycji.

Jeśli przygotowujesz się do podpisania DPA z nowym dostawcą, aneksujesz obowiązujące umowy lub projektujesz szablon DPA dla Twojej firmy to audyt prawny przed podjęciem decyzji znacząco obniża ryzyko.

Sprawdź : audyt prawny usług chmurowych

Najczęstsze pytania o odpowiedzialność w DPA

Czy standardowe klauzule umowne (SCC) mogą zastąpić indywidualnie negocjowane DPA?

Co do zasady tak, SCC zawierają wszystkie elementy wymagane przez art. 28 RODO. W praktyce jednak SCC są dobrym minimum, ale rzadko optymalnym rozwiązaniem dla ochrony administratora. Indywidualnie negocjowane DPA pozwala doprecyzować obszary, w których SCC są ogólne, zwłaszcza takie jak: limity odpowiedzialności, kary umowne, mechanizmy audytu i klauzule podpowierzenia.

Jaka jest różnica między administratorem danych a procesorem w świetle RODO?

Administrator decyduje o celach i sposobach przetwarzania danych osobowych, ponosi pełną odpowiedzialność odszkodowawczą RODO wobec podmiotów danych i ma obowiązek zgłaszania naruszeń do UODO w 72 godziny. Procesor przetwarza dane wyłącznie zgodnie z udokumentowanymi instrukcjami administratora i odpowiada za wypełnienie obowiązków skierowanych konkretnie do podmiotów przetwarzających. Obie role mogą równocześnie ponosić odpowiedzialność wobec podmiotów danych za swoje działania.

Jakie zapisy w DPA są najczęściej kwestionowane przez organy nadzorcze?

Najczęściej kwestionowane to: ogólne klauzule środków bezpieczeństwa bez konkretnej listy, zgody blankietowe na podpowierzenie, brak określenia terminu notyfikacji o naruszeniach, brak praw audytu administratora oraz klauzule wyłączające odpowiedzialność procesora w sposób dysproporcjonalny.

Dlaczego standardowy wzór DPA rzadko wystarcza przy realnym incydencie?

Klauzule DPA decydują o tym, czy umowa powierzenia danych w razie incydentu realnie chroni administratora, czy pozostaje formalnością. Najczęściej zaniedbywane obszary to podpowierzenie przetwarzania danych, środki techniczne i organizacyjne, klauzule usunięcia danych po zakończeniu umowy oraz mechanizmy audytu. Standardowe szablony i SCC pełnią funkcję minimum, ale rzadko optymalnego maksimum.

Z perspektywy administratora warto inwestować w jakość DPA przed podpisaniem, a nie po incydencie. Audyt projektu umowy, negocjacja kluczowych klauzul i przygotowanie własnego szablonu DPA to działania, które zwracają się zarówno operacyjnie (krótsze późniejsze negocjacje), jak i zmniejszają ryzyko w razie kontroli UODO lub incydentu.

Które klauzule DPA realnie chronią administratora po naruszeniu danych?