DPA (umowa powierzenia przetwarzania danych): 7 elementów, których nie wolno pominąć

DPA (Data Processing Agreement, umowa powierzenia przetwarzania danych) to obowiązkowy dokument, gdy Twoja firma przekazuje dane osobowe innemu podmiotowi. Brakuje go w większości polskich startupów, agencji i software house'ów, które dopiero przy pierwszej kontroli UODO odkrywają, że przetwarzają dane klientów lub pracowników bez podstawy prawnej. Brak DPA = naruszenie art. 28 RODO = kara do 10 mln EUR lub 2% globalnego obrotu. Poniżej znajdziesz 7 elementów, które każdy DPA musi zawierać, plus 5 najczęstszych błędów, które kosztują kary nawet przy poprawnie zawartej umowie.

DPA w 30 sekund

DPA to skrót od Data Processing Agreement - po polsku ,,umowa powierzenia przetwarzania danych osobowych’’.
Obowiązkowa zawsze, gdy firma przekazuje dane osobowe podmiotowi zewnętrznemu (SaaS, hosting, agencja, księgowy, freelancer).
Podstawa prawna: art. 28 RODO.
Kara za brak: do 10 mln EUR lub 2% globalnego rocznego obrotu.
Forma: elektroniczna jest w pełni legalna (regulamin, checkbox ,,akceptuję").
7 elementów obowiązkowych: przedmiot i czas, charakter i cel, rodzaj danych, kategorie osób, obowiązki stron, warunki podpowierzenia, środki bezpieczeństwa.
Dwie role: administrator (decyduje o celu) i procesor (przetwarza w jego imieniu).

Artykuł opracowany przez Łukasza Gębczyka – prawnika Lexable, który na co dzień buduje dokumentację prawną dla SaaS’ów, marketplace’ów i startupów technologicznych.

Czym jest DPA i kogo dotyczy w 2026 roku?

DPA (Data Processing Agreement, po polsku: umowa powierzenia przetwarzania danych osobowych) to umowa zawierana między administratorem danych a podmiotem przetwarzającym (procesorem), który przetwarza dane w imieniu administratora. Reguluje ją art. 28 rozporządzenia RODO (UE 2016/679).

W praktyce: jeśli Twoja firma korzysta z jakiejkolwiek zewnętrznej usługi mającej dostęp do danych osobowych Twoich klientów, pracowników czy użytkowników - musisz mieć DPA z tym dostawcą.

Kogo dotyczy DPA w sektorze technologicznym

Każda firma SaaS udostępniająca usługę klientom B2B - jest procesorem dla swoich klientów i potrzebuje DPA z każdym z nich,
Software house budujący rozwiązanie z dostępem do danych klienta końcowego - procesor klienta,
Agencja marketingowa prowadząca kampanie e-mail lub remarketing dla klienta - procesor,
Każda firma używająca chmury (AWS, Azure, GCP, Vercel, Cloudflare) - administrator względem dostawcy chmury, który jest procesorem,
Każda firma używająca narzędzi SaaS (HubSpot, Mailchimp, Stripe, Slack, Zoom, Notion) - administrator względem każdego dostawcy,
Każda firma korzystająca z księgowości zewnętrznej lub HR-tech - administrator względem biura,
E-commerce z fulfillmentem zewnętrznym - administrator względem operatora magazynu.

W typowej polskiej firmie technologicznej liczba potrzebnych DPA waha się od kilkunastu do kilkudziesięciu. Większość founderów ma od zera do pięciu.

Dlaczego founderzy nie wiedzą o DPA

Trzy najczęstsze nieporozumienia:

,,Mam politykę prywatności, więc jestem RODO compliant’’ - polityka prywatności to obowiązek wobec osób, których dane dotyczą. DPA to obowiązek wobec partnerów biznesowych. To dwa różne dokumenty.
,,Korzystam z dużej firmy, więc oni o to dbają’’ - duże firmy mają DPA gotowe, ale musisz je aktywnie zaakceptować. AWS, Google, Microsoft, OpenAI - wszyscy publikują DPA na stronach lub w regulaminach. Nieakceptacja = brak DPA.
,,To dotyczy tylko dużych firm’’ - art. 28 RODO nie zna wyjątków dla startupów. Kara dotyczy tych samych progów.

Kara za brak DPA w 2026 roku

Brak DPA to naruszenie art. 28 RODO. Kary określa art. 83 RODO: do 10 mln EUR lub 2% całkowitego rocznego światowego obrotu (w zależności od tego, która kwota jest wyższa).

W Polsce UODO regularnie nakłada kary za naruszenia art. 28 - od kilkudziesięciu do kilkuset tysięcy złotych. Kara dotyczy nawet sytuacji, gdy dane były przetwarzane bezpiecznie, ale brakowało formalnej umowy.

UODO sprawdza DPA standardowo podczas każdej kontroli. To pierwsza rzecz, o którą pyta inspektor.

7 elementów DPA, których nie wolno pominąć

Art. 28 ust. 3 RODO określa minimalną treść umowy powierzenia. Pominięcie któregokolwiek z elementów oznacza wadliwość dokumentu i ryzyko sankcji - nawet jeśli formalnie umowa istnieje.

Element 1: Przedmiot i czas trwania przetwarzania

Co konkretnie procesor robi z danymi i jak długo. Nie wystarczy ,,w związku z umową główną’’. Trzeba precyzyjnie:

jakie operacje na danych są wykonywane (przechowywanie, analizowanie, hostowanie, wysyłanie maili, generowanie raportów),
przez jaki okres (konkretna data, określony czas, do zakończenia umowy głównej + okres retencji),
w jakim systemie/infrastrukturze.

Element 2: Charakter i cel przetwarzania

W jakim celu procesor przetwarza dane i w jaki sposób. ,,Cel’’ musi być biznesowy i konkretny - ,,świadczenie usług hostingowych’’, ,,obsługa kampanii mailingowej’’, ,,rozliczenia kadrowo-płacowe’’. Nie wystarczy samo ,,wykonanie umowy’’.

Element 3: Rodzaj danych osobowych

Konkretny zakres przetwarzanych danych. Trzeba wyszczególnić:

dane zwykłe (imię, nazwisko, adres e-mail, telefon, IP, identyfikator urządzenia) i ich konkretne kategorie,
dane szczególnych kategorii (zdrowie, biometria, pochodzenie rasowe lub etniczne, poglądy polityczne) - jeśli występują, wymagana dodatkowa ochrona,
dane karne (wyroki, postępowania) - osobno regulowane.

Element 4: Kategorie osób, których dane dotyczą

Czyje dane są przetwarzane. Standardowe kategorie:

pracownicy administratora,
klienci administratora (osoby fizyczne),
użytkownicy końcowi aplikacji administratora,
kontrahenci, freelancerzy, podwykonawcy,
kandydaci do pracy,
osoby zapisane na newsletter.

Im precyzyjniej, tym lepiej. UODO podczas kontroli sprawdza zgodność tych kategorii z faktycznym przetwarzaniem.

Element 5: Obowiązki i prawa administratora

Co Ty (jako administrator) możesz i musisz robić. Standardowy zakres:

prawo do kontroli i audytu - możliwość weryfikacji procesora, w tym audytów na miejscu (możesz zlecić zewnętrznemu audytorowi),
prawo wydawania udokumentowanych poleceń - procesor wykonuje tylko to, co Ty mu nakażesz,
obowiązek przekazywania instrukcji w formie pisemnej lub elektronicznej.

Element 6: Obowiązki podmiotu przetwarzającego (procesora)

Tu jest najwięcej szczegółów. Procesor musi:

przetwarzać dane wyłącznie na udokumentowane polecenie administratora,
zapewnić, że osoby upoważnione do przetwarzania podpisały zobowiązanie do poufności,
wdrożyć odpowiednie środki techniczne i organizacyjne,
prowadzić rejestr czynności przetwarzania (jeśli zatrudnia powyżej 250 osób lub przetwarza dane wrażliwe),
pomagać administratorowi w realizacji praw osób fizycznych (dostęp, sprostowanie, usunięcie, przenoszenie),
pomagać w ocenie skutków dla ochrony danych (DPIA), jeśli wymagana,
zgłaszać naruszenia ochrony danych bez zbędnej zwłoki,
po zakończeniu umowy zwrócić lub usunąć dane,
udostępniać administratorowi wszelkie informacje niezbędne do wykazania zgodności,
umożliwiać audyty i kontrole.

Element 7: Warunki korzystania z podprocesorów

Procesor często korzysta z usług kolejnego podmiotu (np. hosting używa AWS, biuro księgowe używa zewnętrznego archiwum). To wymaga uregulowania.

Dwa modele zgody na podpowierzenie:

zgoda szczegółowa - administrator akceptuje każdego konkretnego podprocesora osobno,
zgoda ogólna - administrator akceptuje listę podprocesorów z prawem sprzeciwu wobec zmian.

W obu przypadkach DPA musi określać:

listę aktualnych podprocesorów (zazwyczaj jako załącznik),
procedurę informowania o zmianach (rekomendowane min. 14-30 dni przed zmianą),
prawo administratora do sprzeciwu,
zasadę: procesor odpowiada za podprocesora jak za własne działania.

Poza listą z art. 28 ust. 3 RODO, każdy nowoczesny DPA powinien zawierać też:

konkretne środki bezpieczeństwa (art. 32 RODO) - szyfrowanie, pseudonimizacja, MFA, kontrola dostępu, kopie zapasowe, testowanie bezpieczeństwa,
procedurę obsługi naruszeń - termin powiadomienia (max 24h), kanał, zakres informacji,
transfer danych poza EOG - jeśli ma miejsce, podstawa prawna (Standardowe Klauzule Umowne SCC, decyzja adekwatności Komisji),
procedura zwrotu/usunięcia danych po zakończeniu umowy.

5 najczęstszych błędów w DPA, które kosztują kary

Duży odsetek polskich firm ma DPA z podstawowymi błędami. UODO wykrywa je rutynowo podczas kontroli.

Błąd 1: Brak konkretnego celu i charakteru przetwarzania

Najczęstszy. Umowy zawierają sformułowanie ,,w związku z umową główną’’ zamiast konkretnego celu biznesowego. To nie spełnia wymogów RODO.

Błąd 2: Automatyczna zgoda na podprocesorów bez kontroli

Zapis ,,procesor może korzystać z usług podwykonawców’’ bez listy i procedury = brak realnej kontroli administratora. W razie incydentu ryzyko po stronie administratora.

Błąd 3: Brak klauzuli o czasie trwania przetwarzania

Wiele DPA pomija ten element całkowicie. To jawne naruszenie art. 28 ust. 3 RODO.

Błąd 4: Ogólnikowe zapisy o zabezpieczeniach

,,Procesor zapewnia odpowiednie środki bezpieczeństwa’’ to za mało. Art. 32 RODO wymaga konkretów.

Błąd 5: Brak procedury obsługi naruszeń

Procesor ma obowiązek zgłosić naruszenie ,,bez zbędnej zwłoki’’, ale to wyrażenie elastyczne. Administrator ma 72 godziny na zgłoszenie do UODO - jeśli procesor poinformuje na 71. godzinie, jest za późno.

DPA dla SaaS i software house: 5 sytuacji, w których jesteś jednocześnie administratorem i procesorem

Klasyczna pułapka founderska. Działasz w obu rolach jednocześnie i każda rola wymaga innych dokumentów.

Sytuacja 1: SaaS B2B z danymi użytkowników końcowych klientów

Wobec swojego klienta (firmy, która kupiła Twoją aplikację) - jesteś procesorem. Klient = administrator. Ty potrzebujesz DPA, w której jesteś procesorem.
Wobec swoich pracowników - jesteś administratorem.
Wobec dostawców chmury (AWS, Vercel) - jesteś administratorem (albo procesorem dalszego rzędu, w zależności od konstrukcji). Potrzebujesz DPA z dostawcą.

Sytuacja 2: Software house budujący aplikację dla klienta

Podczas developmentu - jeśli masz dostęp do danych testowych lub produkcyjnych klienta, jesteś procesorem.
Po wdrożeniu, jeśli świadczysz support - nadal procesor.
Wobec swoich freelancerów mających dostęp do projektu - oni są podprocesorami, potrzebują DPA z Tobą i Twoja zgoda od klienta na podpowierzenie.

Sytuacja 3: Agencja marketingowa

Wobec klienta dla którego prowadzisz kampanie - jesteś procesorem (pracujesz na jego bazie kontaktów).
Wobec dostawców narzędzi (Mailchimp, HubSpot, Meta Ads) - jesteś administratorem (albo dalszym procesorem klienta, w zależności od ustaleń).

Sytuacja 4: Marketplace lub platforma z trzema stronami

Wobec sprzedawców i kupujących - jesteś administratorem (samodzielnie określasz cele platformy).
Niektóre dane, które przetwarzasz tylko technicznie dla sprzedawców (np. fulfillment) - możesz być procesorem wobec sprzedawców.

Sytuacja 5: Fintech lub HR-tech z integracjami

Wobec użytkownika końcowego - administrator.
Wobec banków/HRIS-ów, z którymi się integrujesz - rola zależy od umowy (najczęściej każdy administrator we własnym celu, czyli udostępnienie danych zamiast powierzenia).

Wniosek dla foundera: zrób mapę przepływu danych w swojej firmie. Każda strzałka między systemami/podmiotami to potencjalne miejsce, w którym potrzebujesz DPA lub upoważnienia.

Forma DPA: czy musi być papierowa?

Nie. Forma elektroniczna jest w pełni legalna. RODO nie wymaga formy pisemnej z podpisem własnoręcznym dla DPA. Akceptowalne formy:

klasyczna umowa pisemna podpisana przez obie strony,
podpis elektroniczny (kwalifikowany lub zaufany),
wymiana e-maili z jasną akceptacją warunków,
akceptacja regulaminu SaaS, w którym DPA jest częścią lub załącznikiem,
klikrap ,,akceptuję DPA’’ podczas rejestracji w usłudze - tak działa większość globalnych SaaS-ów.

Co się dzieje z danymi po zakończeniu umowy?

Po zakończeniu współpracy procesor ma jedno z dwóch zadań do wykonania:

Zwrot danych - przekazanie administratorowi wszystkich danych w eksportowalnym formacie wraz z kopiami,
Usunięcie danych - trwałe zniszczenie danych i wszystkich kopii (włącznie z backupami).

Wybór należy do administratora i powinien być wskazany w DPA. Standardowy termin: 30 dni od zakończenia umowy.

Procesor musi dostarczyć potwierdzenie wykonania (protokół zniszczenia/zwrotu). Bez tego dokumentu administrator nie ma dowodu wypełnienia obowiązku wobec UODO.

DPA a transfer danych poza EOG

Jeśli procesor (lub jego podprocesor) jest poza Europejskim Obszarem Gospodarczym, sama umowa powierzenia nie wystarcza. Wymagane są dodatkowe mechanizmy z rozdziału V RODO:

Decyzja adekwatności Komisji Europejskiej (np. UK, Szwajcaria, Japonia, Korea Południowa, Data Privacy Framework dla certyfikowanych firm),
Standardowe Klauzule Umowne (SCC),
Wiążące reguły korporacyjne (BCR) - dla grup kapitałowych,
Zatwierdzony kodeks postępowania lub mechanizm certyfikacji.

W praktyce dla typowej polskiej firmy używającej AWS US, Google US, OpenAI - SCC są standardem. Sprawdź, czy DPA Twojego dostawcy zawiera SCC jako załącznik - większość dużych SaaS-ów to ma, ale trzeba aktywnie zaakceptować.

FAQ: DPA i umowa powierzenia 2026

Czy DPA musi być po polsku?

Nie ma takiego wymogu. DPA może być w dowolnym języku, jeśli obie strony go rozumieją. W praktyce w Polsce dominuje angielski (zwłaszcza z dostawcami zagranicznymi) lub polski (z polskimi partnerami).

Jakie są konsekwencje braku DPA?

Brak DPA to naruszenie art. 28 RODO. Kara do 10 mln EUR lub 2% globalnego rocznego obrotu. UODO w Polsce nakłada kary od kilkudziesięciu do kilkuset tysięcy złotych. Kara grozi nawet, gdy dane były przetwarzane bezpiecznie - liczy się sam brak formalnej podstawy.

Czy DPA z OpenAI, Anthropic lub Google jest wymagana?

Tak, jeśli używasz ich API w sposób, który przekazuje dane osobowe. Wszyscy ci dostawcy publikują DPA na stronach internetowych.

Co zrobić, gdy procesor naruszy ochronę danych?

Procesor musi niezwłocznie poinformować administratora o naruszeniu. Administrator ma 72 godziny na zgłoszenie do UODO (jeśli naruszenie niesie ryzyko dla osób fizycznych). Kluczowa jest szybka komunikacja, dokumentowanie przebiegu zdarzenia i współpraca w minimalizowaniu skutków. Praktycznie: każde DPA powinno mieć w klauzuli incident response konkretny czas powiadomienia (max 24h) i kanał komunikacji.

Czy DPA z biurem księgowym jest wymagana?

Tak. Biuro księgowe ma dostęp do danych pracowników (lista płac, ZUS, podatki) - jest klasycznym procesorem. Jedna z najczęstszych dziur w polskich firmach. Sprawdź swoją współpracę z księgowym - jeśli nie ma osobnej umowy lub klauzuli DPA w umowie głównej.

Czy mogę użyć szablonu DPA z internetu?

Możesz, ale ostrożnie. Szablony są punktem wyjścia, nie gotowym dokumentem. Każda firma ma inny model przetwarzania, inne kategorie danych, inną listę podprocesorów, inne ryzyka. Szablon trzeba dostosować. Najczęstszy błąd: pobranie szablonu, podpisanie bez zmian, brak aktualizacji listy podprocesorów. UODO podczas kontroli sprawdza zgodność DPA z faktycznym przetwarzaniem - rozjazd to naruszenie.

W kontekście SaaS i platform technologicznych warto pamiętać, że DPA to tylko jeden z kilku obowiązkowych dokumentów - regulamin, polityka prywatności i klauzule informacyjne to równoległe wymogi. O zgodności regulaminów z aktualnym stanem prawnym pisaliśmy w artykule Klauzule abuzywne 2026: lista 25 najgroźniejszych zapisów po likwidacji rejestru UOKiK. Jeśli korzystasz z AI w swojej aplikacji, zwróć też uwagę na obowiązki wynikające z AI Act od 2 sierpnia 2026 r., które w wielu przypadkach łączą się z reżimem RODO.

Chcesz mieć DPA dopasowane do Twojego SaaS, software house'u lub agencji?

Rozpocznij teraz i wybierz jedną z opcji:

zamów przygotowanie umowy DPA w Lexable,
prześlij obecne DPA do audytu - sprawdzimy zgodność z wymogami i wskażemy luki.

Wolisz mailowo? Napisz: contact@lexable.pl.