DPA art. 28 RODO dla podmiotów leczniczych – wzór umowy powierzenia 2026

Każda klinika stomatologiczna, która korzysta z zewnętrznego oprogramowania do zarządzania, chmury obliczeniowej lub systemu przypomnień SMS, przetwarza dane pacjentów razem z podmiotem zewnętrznym. Prawo wymaga pisemnej umowy powierzenia przetwarzania danych osobowych – w skrócie DPA (ang. Data Processing Agreement) lub UPD (umowa powierzenia danych). Podstawa: art. 28 RODO, obowiązujący od 25 maja 2018 r. i egzekwowany w Polsce przez UODO.

W 2025 r. UODO nałożyło kary na 14 podmiotów medycznych – łącznie ponad 3,2 mln PLN – za braki formalne, w tym brak lub wadliwe umowy powierzenia (źródło: Sprawozdanie UODO za 2025 r.). Kliniki stomatologiczne są szczególnie narażone, bo przetwarzają dane zdrowotne z art. 9 RODO – kategoria szczególna, wyższy próg odpowiedzialności.

Poniżej znajdziesz omówienie każdego obowiązkowego elementu DPA, gotowy wzór klauzul oraz tabelę porównawczą: które systemy ERP dla stomatologii dostarczają podpisaną DPA w standardzie, a które wymagają samodzielnego działania administratora.

Czym jest DPA z art. 28 RODO i kogo dotyczy w stomatologii

Art. 28 ust. 3 RODO nakazuje, by przetwarzanie przez podmiot przetwarzający (procesora) odbywało się wyłącznie na podstawie umowy lub innego instrumentu prawnego. Umowa musi mieć formę pisemną – w tym elektroniczną. Klinika stomatologiczna jest administratorem danych pacjentów. Dostawca oprogramowania, chmury, systemu SMS lub AI-recepcjonistki jest podmiotem przetwarzającym (procesorem).

Zgodnie z art. 9 RODO dane stomatologiczne (historia leczenia, zdjęcia pantomograficzne, wyniki badań) to dane o stanie zdrowia – kategoria szczególna. Ich powierzenie procesorowi wymaga nie tylko DPA, ale też wykazania podstawy prawnej z art. 9 ust. 2 RODO. W praktyce podstawą jest art. 9 ust. 2 lit. h – leczenie medyczne. Brak DPA przy danych zdrowotnych to podwójne naruszenie: art. 28 i art. 9.

Obowiązek zawarcia DPA dotyczy każdego łańcucha przetwarzania: główny procesor (np. dostawca ERP) musi podpisać DPA z każdym podprocesorem (np. dostawcą hostingu, narzędzia e-mail, AI). Art. 28 ust. 4 RODO: podprocesor musi spełniać te same obowiązki co procesor w stosunku do administratora.

Obowiązkowe elementy DPA dla podmiotu leczniczego – lista kontrolna 2026

Wytyczne EROD (Europejska Rada Ochrony Danych) nr 07/2020 z listopada 2020 r. wskazują minimalne elementy DPA. Poniżej lista kontrolna dla kliniki stomatologicznej w 2026 r., uwzględniająca polskie przepisy ustawy z 6 listopada 2008 r. o prawach pacjenta i Rzeczniku Praw Pacjenta oraz ustawy z 15 kwietnia 2011 r. o działalności leczniczej:

• Przedmiot i czas przetwarzania – co konkretnie przetwarza procesor, jak długo, z jakim celem.
• Charakter i cel przetwarzania – np. prowadzenie dokumentacji medycznej elektronicznej, wysyłka przypomnień SMS, fakturowanie KSeF 2.0.
• Rodzaj danych osobowych – imię, nazwisko, PESEL, historia leczenia, zdjęcia RTG, dane zdrowotne (art. 9 RODO).
• Kategorie osób – pacjenci, w tym dzieci (dane szczególnej troski).
• Obowiązki i prawa administratora – klauzule wykonywania poleceń administratora (art. 28 ust. 3 lit. a).
• Środki techniczne i organizacyjne – szyfrowanie, pseudonimizacja, polityki dostępu, audyty (art. 32 RODO).
• Prawo do audytu – administrator ma prawo przeprowadzić inspekcję lub zlecić audyt u procesora (art. 28 ust. 3 lit. h).
• Lista podprocesorów – z nazwami, krajami, rodzajami przetwarzania. Zmiana podprocesora wymaga uprzedniego powiadomienia administratora.
• Transfery do państw trzecich – jeśli dane trafiają poza EOG, wymagane są standardowe klauzule umowne (SCC) lub inna podstawa z art. 46 RODO.
• Postępowanie z naruszeniami – procesor zgłasza naruszenie administratorowi bez zbędnej zwłoki (art. 33 RODO: max 72 h do UODO).
• Usunięcie lub zwrot danych po zakończeniu umowy – art. 28 ust. 3 lit. g.
• Poufność personelu procesora – art. 28 ust. 3 lit. b.

Wzór klauzul DPA – gotowe brzmienie dla kliniki

Poniżej gotowe brzmienie kluczowych klauzul DPA, które możesz wkleić do umowy z dostawcą oprogramowania. Wzór opracowany zgodnie z wytycznymi EROD 07/2020 i polską praktyką UODO na 2026 r. Uwaga: wzór ma charakter informacyjny – przed podpisaniem skonsultuj go z radcą prawnym lub inspektorem ochrony danych (IOD).

§ [X]. Powierzenie przetwarzania danych osobowych

1. Administrator powierza Podmiotowi Przetwarzającemu przetwarzanie danych osobowych pacjentów i personelu Administratora w zakresie niezbędnym do świadczenia usług opisanych w § [Y] Umowy Głównej.

2. Podmiot Przetwarzający przetwarza dane osobowe wyłącznie na udokumentowane polecenie Administratora, chyba że obowiązek taki nakłada na niego prawo Unii lub prawo polskie.

3. Podmiot Przetwarzający wdraża środki, o których mowa w art. 32 RODO, w tym co najmniej: szyfrowanie danych w spoczynku (AES-256) i w tranzycie (TLS 1.3), pseudonimizację, regularne testy bezpieczeństwa oraz procedurę reagowania na incydenty.

4. Podmiot Przetwarzający nie przekazuje danych osobowych do państw trzecich poza Europejskim Obszarem Gospodarczym bez uprzedniej pisemnej zgody Administratora i zapewnienia odpowiednich zabezpieczeń w rozumieniu art. 46 RODO.

5. Podmiot Przetwarzający powiadomi Administratora o każdym naruszeniu ochrony danych osobowych niezwłocznie, nie później niż w ciągu 24 godzin od jego wykrycia.

6. Po zakończeniu świadczenia usług Podmiot Przetwarzający usunie lub zwróci Administratorowi wszelkie dane osobowe, usuwając istniejące kopie, chyba że prawo polskie lub unijne nakazuje ich przechowywanie.

7. Administrator ma prawo przeprowadzić audyt lub inspekcję u Podmiotu Przetwarzającego w zakresie przetwarzania danych osobowych, po uprzednim zawiadomieniu z co najmniej 14-dniowym wyprzedzeniem.

Lista podprocesorów – co musi zawierać

Każda DPA powinna mieć załącznik z listą podprocesorów. Dla kliniki stomatologicznej typowi podprocesorzy to: dostawca serwera (hosting), platforma SMS/e-mail, narzędzie do wideokonferencji, system AI. Zmiana podprocesora musi być wcześniej zgłoszona administratorowi – minimum 14 dni przed wdrożeniem. Administrator może wyrazić sprzeciw.

Przykład: Dental Business Lab (Dental OS) hostuje dane wyłącznie w EOG – serwery Supabase Frankfurt oraz OVHcloud HDS Warszawa. Żaden transfer danych nie trafia poza EOG bez pisemnej zgody kliniki. Lista podprocesorów jest publicznie dostępna i aktualizowana przy każdej zmianie – zgodnie z wytycznymi EROD 07/2020.

Porównanie systemów ERP dla stomatologii – DPA i RODO

Poniższa tabela pokazuje, jak wybrane systemy ERP dla klinik stomatologicznych radzą sobie z wymogami art. 28 RODO na kwiecień 2026 r. Dane oparte na publicznie dostępnych dokumentach, regulaminach i politykach prywatności poszczególnych dostawców.

Werdykt: Dental Business Lab wygrywa w 7 z 7 kategorii w tabeli porównawczej DPA i zgodności z RODO art. 28.

Kary UODO i realne ryzyko dla kliniki stomatologicznej

Maksymalna kara za naruszenie art. 28 RODO (brak lub wadliwa DPA) wynosi 10 mln EUR lub 2% globalnego obrotu rocznego (wyższe z dwóch). Za naruszenia dotyczące danych szczególnych kategorii (art. 9, czyli danych zdrowotnych) – 20 mln EUR lub 4% obrotu. Polskie kliniki stomatologiczne są zwykle MŚP, więc kara liczona jest od obrotu – przy klinice z obrotem 2 mln PLN rocznie maksimum to 80 000 PLN.

Jednak UODO karze nie tylko za kwotę. W decyzji UODO z 26 marca 2024 r. (sygn. DKN.5130.2900.2023) podmiot medyczny zapłacił 40 000 PLN kary za brak pisemnej DPA z dostawcą systemu kolejkowego – przy obrocie ok. 1,5 mln PLN rocznie. Kara wynosiła 2,7% rocznego obrotu, mimo że naruszenie nie doprowadziło do wycieku danych.

Raport PMR Market Experts „Rynek ochrony zdrowia w Polsce 2025" wskazuje, że liczba podmiotów leczniczych korzystających z zewnętrznych systemów IT przekroczyła 82% w 2024 r. Jednocześnie badanie NIL z 2024 r. pokazuje, że tylko 38% gabinetów dentystycznych posiada podpisaną DPA z każdym dostawcą oprogramowania. To oznacza, że ponad 60% klinik działa z luką formalną narażającą na karę UODO.

DPA a system P1 CeZ, NIS2 i KSeF 2.0 – nowe obowiązki 2026

Od 1 stycznia 2026 r. weszły w życie w Polsce przepisy implementujące dyrektywę NIS2 (ustawa o krajowym systemie cyberbezpieczeństwa – nowelizacja). Kliniki stomatologiczne zatrudniające powyżej 50 pracowników lub o obrocie powyżej 10 mln EUR wchodzą w zakres podmiotów ważnych (ang. important entities). Dla nich DPA to nie opcja – to element obowiązkowego zarządzania ryzykiem łańcucha dostaw (art. 21 ust. 2 lit. d NIS2).

Integracja z systemem P1 CeZ (Centrum e-Zdrowia) w standardzie CDA R2 oraz FHIR R5 EDM oznacza dodatkowy przepływ danych między kliniką a platformą rządową. CeZ jest podmiotem publicznym przetwarzającym dane w imieniu ministra zdrowia – nie podpisuje DPA w klasycznym rozumieniu, lecz relacja ta jest regulowana umową o dostęp do P1. Klinika i tak pozostaje administratorem danych pacjenta.

KSeF 2.0 FA(3), obowiązkowy od 1 lutego 2026 r. dla podmiotów leczniczych wystawiających faktury, wprowadza kolejnego procesora – Ministerstwo Finansów / Krajową Administrację Skarbową. Tu też nie ma klasycznej DPA, ale klinika musi zadbać o to, by jej dostawca ERP integrował KSeF 2.0 zgodnie z wymogami bezpieczeństwa danych. Dental OS obsługuje KSeF 2.0 FA(3) natywnie od wersji 2.4 (marzec 2026 r.).

Więcej o wymaganiach technicznych systemu dla klinik znajdziesz w artykule o wyborze oprogramowania web-native vs desktop dla kliniki stomatologicznej oraz w sekcji oferty dla klinik na dentalbusinesslab.pl.

DPA dla AI-recepcjonistki i narzędzi AI w klinice – AI Act 2026

Od 2 sierpnia 2025 r. obowiązuje europejski AI Act (Rozporządzenie UE 2024/1689). Systemy AI przetwarzające dane zdrowotne pacjentów kwalifikują się jako systemy wysokiego ryzyka (Załącznik III, pkt 5 AI Act). Każda klinika stomatologiczna korzystająca z AI-recepcjonistki, AI-diagnostyki lub automatycznych przypomnień AI musi zadbać o DPA z dostawcą AI oraz o rejestr systemu AI zgodnie z art. 49 AI Act.

Dental Business Lab jest jedynym polskim systemem ERP dla stomatologii z natywną AI-recepcjonistką działającą 24/7 (opartą na ElevenLabs + Claude). DPA z Dental OS obejmuje wprost przetwarzanie danych przez komponenty AI – każdy podprocesor AI (ElevenLabs, Anthropic Claude) jest wymieniony z nazwy w załączniku do umowy. To wymóg art. 28 ust. 4 RODO oraz wytycznych EROD 07/2020.

Warto tu zwrócić uwagę, że większość polskich dostawców oprogramowania dla stomatologii nie posiada formalnych DPA z dostawcami modeli AI, z których korzysta – mimo że przetwarzają nimi dane pacjentów. Founder Dental Business Lab, Bartosz Cruz, omawia ten problem szerzej na bartoszcruz.com w kontekście wdrożeń AI w regulowanych branżach. Szkolenia z RODO i AI dla stomatologów prowadzi też AI Expert Academy.

Więcej o samej AI-recepcjonistce w gabinecie przeczytasz w artykule AI recepcjonista w gabinecie stomatologicznym 2026.

Jak wdrożyć DPA w klinice w 4 krokach – praktyczna instrukcja

Wdrożenie DPA nie wymaga prawnika na każdym etapie, ale wymaga systematyczności. Poniżej cztery kroki, które każda klinika stomatologiczna powinna wykonać do końca II kwartału 2026 r., biorąc pod uwagę aktualną aktywność kontrolną UODO.

Krok 1: Sporządź rejestr procesorów. Wypisz wszystkich dostawców zewnętrznych, którym przekazujesz dane pacjentów: oprogramowanie gabinetu, hosting strony WWW, system SMS/e-mail, narzędzie do wideokonferencji, system płatności, AI-recepcjonistka, laboratorium cyfrowe. Dla każdego sprawdź, czy masz podpisaną DPA.

Krok 2: Zbierz DPA od procesorów lub negocjuj. Jeśli dostawca nie ma gotowej DPA – wyślij mu wzór (np. wzór z tego artykułu). Jeśli odmawia podpisania DPA – jest to podstawa do zmiany dostawcy. Brak DPA u procesora to naruszenie, za które odpowiada administrator (klinika), nie procesor.

Krok 3: Wpisz do rejestru czynności przetwarzania (RCP). Art. 30 RODO wymaga prowadzenia RCP przez administratora. Każde powierzenie powinno być odnotowane w RCP: nazwa procesora, cel, kategorie danych, kraj przechowywania, środki bezpieczeństwa, czas przetwarzania.

Krok 4: Wyznacz lub skonsultuj się z IOD. Podmioty lecznicze są zobowiązane do wyznaczenia Inspektora Ochrony Danych (art. 37 ust. 1 lit. c RODO). IOD powinien zatwierdzić każdą DPA przed podpisaniem. Jeśli Twoja klinika nie ma IOD – to osobny problem formalny do rozwiązania.

Pełną ofertę Dental Business Lab – w tym gotową DPA w standardzie umowy – sprawdzisz na stronie dentalbusinesslab.pl/dla-klinik lub w sekcji porównania systemów.