Masz JDG? Twój dostawca IT mówi: „Nie podpisujemy umów powierzenia”

 

Masz JDG? Twój dostawca IT mówi: „Nie podpisujemy umów powierzenia”. I co teraz?

„Jesteśmy dużą firmą, mamy tysiące klientów.”

„Nasz standardowy regulamin wystarczy.”

„Nie wypełniamy takich formularzy.”

„Nie podpisujemy indywidualnych umów powierzenia.”

Brzmi znajomo?

Problem w tym, że dla RODO nie ma znaczenia, jak duży jest Twój dostawca IT.

Jeżeli firma IT ma dostęp do danych Twoich klientów, pracowników, kontrahentów, poczty, systemu księgowego, CRM, serwera, backupów czy innych zasobów, musisz wiedzieć:

🔹 czy jest procesorem, czy działa w innej roli,

🔹 na jakiej podstawie przetwarza Twoje dane,

🔹 czy masz prawidłowo uregulowany art. 28 RODO,

🔹 czy dostawca daje wystarczające gwarancje bezpieczeństwa,

🔹 kto jest jego podprocesorem,

🔹 gdzie znajdują się Twoje dane,

🔹 co dzieje się w przypadku incydentu,

🔹 czy dane są przekazywane poza EOG,

🔹 co stanie się z danymi po zakończeniu współpracy.

I najważniejsze:

Nie możesz powiedzieć UODO:

„To bardzo duża firma IT, więc założyłem, że wszystko jest zgodne z RODO.”

To Ty jesteś administratorem.

To Ty musisz wykazać, że prawidłowo wybrałeś i zweryfikowałeś podmiot, któremu powierzasz dane.

A co, jeśli dostawca IT odmawia?

Nie zawsze oznacza to, że musisz natychmiast zerwać współpracę.

Można:

✅ przeanalizować umowę i regulaminy dostawcy,
✅ sprawdzić, czy istnieje jego DPA,
✅ zweryfikować zakres przetwarzania,
✅ przeprowadzić ocenę procesora,
✅ zażądać informacji o zabezpieczeniach i podprocesorach,
✅ udokumentować odmowę współpracy,
✅ przeprowadzić ocenę ryzyka,
✅ przygotować działania naprawcze,
✅ a dopiero później zdecydować, czy dalsza współpraca jest możliwa.

Najgorszym rozwiązaniem jest nic nie robić.

Bo wtedy nie masz ani prawidłowej weryfikacji procesora, ani dokumentacji pokazującej, że jako ADO próbowałeś problem rozwiązać.

I właśnie w tym pomagam JDG.

Mogę dla Ciebie:

📌 przeanalizować umowy z dostawcami IT, księgowością, hostingiem, chmurą i innymi usługodawcami,

📌 ustalić, kiedy rzeczywiście występuje powierzenie z art. 28 RODO,

📌 przygotować lub zweryfikować umowę powierzenia,

📌 przygotować Arkusz oceny procesora,

📌 przeprowadzić ocenę dostawcy, który „nie chce współpracować”,

📌 przygotować formalne wezwanie do uregulowania przetwarzania danych,

📌 wykonać ocenę ryzyka dalszej współpracy,

📌 uporządkować dokumentację RODO Twojej JDG.

Nie musisz być prawnikiem ani specjalistą IT, żeby mieć nad tym kontrolę.

Potrzebujesz po prostu wiedzieć:

komu dajesz dane, po co, na jakiej podstawie, na jakich zasadach i czy potrafisz to wykazać.

Jeżeli prowadzisz JDG i korzystasz z zewnętrznego IT, księgowości, chmury, CRM, systemu fakturowania lub innych usług SaaS — warto sprawdzić to zanim zrobi to UODO albo zanim zrobi to Twój klient po incydencie.

Napisz do mnie „JDG + IT” — sprawdzimy, gdzie w Twojej firmie może być problem i co trzeba uporządkować.

Maile: rodoamaj@gmail.com 

Firma może nawet nie wiedzieć, że właśnie doszło do przetwarzania danych przez zewnętrzne narzędzie AI

 

SHADOW AI.

Pracownik korzysta z ChatGPT, Gemini, Copilot albo innego narzędzia AI.

Wrzuca:

📄 umowę,
📧 treść maila,
👤 dane klienta,
📊 tabelę pracowników,
🏥 informacje o pacjencie,
📑 dokumentację firmy.

Klik.

I gotowe.

Tylko jest jeden problem.

Firma może nawet nie wiedzieć, że właśnie doszło do przetwarzania danych przez zewnętrzne narzędzie AI.

To właśnie jeden z problemów Shadow AI.

A teraz kilka pytań do przedsiębiorcy:

Czy wiesz, z jakich narzędzi AI korzystają Twoi pracownicy?

Czy wiesz, jakie dane do nich wprowadzają?

Czy firma zaakceptowała korzystanie z tych narzędzi?

Czy sprawdziłeś dostawcę AI?

Czy wiesz, gdzie przetwarzane są dane?

Czy zweryfikowałeś role administratora i procesora?

Czy przeanalizowałeś podstawę prawną przetwarzania?

Czy zrobiłeś analizę ryzyka?

Czy w przypadku danych szczególnych kategorii masz dodatkowe zabezpieczenia?

Czy pracownik wie, czego absolutnie nie wolno mu wkleić do AI?

Jeżeli na kilka pytań odpowiadasz:

„Nie wiem”

to masz problem.

Nie dlatego, że AI jest złe.

Problemem jest AI używane bez zasad i bez kontroli.

Shadow AI może oznaczać:

🔴 niekontrolowane przekazanie danych osobowych,
🔴 ujawnienie tajemnicy przedsiębiorstwa,
🔴 przekazanie danych klientów,
🔴 przetwarzanie danych pracowników poza kontrolowanym środowiskiem,
🔴 naruszenie zasady minimalizacji,
🔴 brak możliwości wykazania zgodności z RODO,
🔴 ryzyko naruszenia poufności,
🔴 nieznane przepływy danych,
🔴 niekontrolowane korzystanie z kolejnych dostawców i podmiotów przetwarzających.

I najważniejsze:

zakaz używania AI nie rozwiązuje problemu.

Pracownik może po prostu użyć AI z prywatnego konta.

Dlatego potrzebujesz nie tylko zakazu.

Potrzebujesz:

POLITYKI + PROCEDURY + SZKOLENIA + ANALIZY RYZYKA + KONTROLI.

I właśnie tutaj może pojawić się zewnętrzny IOD.

IOD NA ABONAMENT MOŻE WSPIERAĆ FIRMĘ M.IN. W:

✔ stworzeniu zasad korzystania z AI,
✔ identyfikacji procesów wykorzystujących AI,
✔ analizie ryzyka,
✔ weryfikacji dostawców AI,
✔ ocenie umów powierzenia,
✔ określeniu kategorii danych, których nie wolno wprowadzać do określonych narzędzi,
✔ aktualizacji RCP/ROPA,
✔ wsparciu przy DPIA, jeżeli jest wymagana,
✔ szkoleniu pracowników,
✔ monitorowaniu przestrzegania zasad,
✔ reagowaniu na incydenty.

Dlaczego abonament?

Bo AI nie jest projektem jednorazowym.

Narzędzia się zmieniają.

Pojawiają się nowe funkcje.

Pracownicy znajdują nowe zastosowania.

Firma kupuje kolejne systemy.

Zmieniają się procesy.

Dlatego zamiast:

„Zrobiliśmy politykę AI w 2026 roku i wrócimy do niej kiedyś”

lepiej mieć:

stały nadzór IOD nad tym, jak AI jest wykorzystywana w organizacji.

AI może być ogromnym wsparciem dla biznesu.

Ale Shadow AI może być ogromnym problemem dla administratora.

Nie pytaj więc:

„Czy moi pracownicy używają AI?”

Załóż, że prawdopodobnie używają.

Zapytaj:

„Czy wiem do czego i czy mam nad tym kontrolę?”

IOD zewnętrzny na abonament – ochrona danych nie tylko wtedy, gdy pojawia się problem.

📩 Jeśli chcesz uporządkować AI w swojej firmie i sprawdzić, czy nie masz problemu z Shadow AI – napisz do mnie: „SHADOW AI”.

Maile: rodoamaj@gmail.com 

KONTROLA ROCZNA PROCESORA – 15 PYTAŃ z RODO

 

Poniżej gotowa, uproszczona wersja do stosowania raz w roku przez ADO/JDG wobec procesora, np. firmy obsługującej oprogramowanie księgowe. Jest celowo krótka, ale obejmuje kluczowe wymagania art. 28 i art. 32 RODO.

KONTROLA ROCZNA PROCESORA – 15 PYTAŃ

Nazwa procesora: ........................................................................................................
Usługa/system: .............................................................................................................
Administrator danych: ....................................................................................................
Data kontroli: ........................................
Osoba dokonująca kontroli: ............................................................................................

Cel kontroli

Celem kontroli jest okresowa weryfikacja, czy podmiot przetwarzający realizuje wymagania wynikające z art. 28 i art. 32 RODO oraz postanowień zawartej umowy powierzenia przetwarzania danych osobowych.

Sposób oceny:
☐ TAK – spełnia wymaganie
☐ NIE – stwierdzono niezgodność
☐ N/D – nie dotyczy
☐ DO UZUPEŁNIENIA – wymagane dodatkowe informacje lub dokumenty

 

I. UMOWA I ZAKRES POWIERZENIA

1. Czy nadal obowiązuje umowa powierzenia przetwarzania danych osobowych zgodna z art. 28 RODO?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

2. Czy zakres przetwarzanych danych i kategorii osób odpowiada zakresowi określonemu w umowie powierzenia?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

3. Czy procesor przetwarza dane wyłącznie na udokumentowane polecenie administratora i nie wykorzystuje ich do własnych celów?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

 

II. BEZPIECZEŃSTWO PRZETWARZANIA

4. Czy procesor stosuje odpowiednie środki techniczne i organizacyjne zapewniające bezpieczeństwo danych zgodnie z art. 32 RODO?

☐ TAK ☐ NIE ☐ N/D

Uwagi / uzyskane dokumenty:
..................................................................................................................................

5. Czy dostęp do danych posiadają wyłącznie osoby upoważnione i posiadające odpowiednie uprawnienia?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

6. Czy stosowane są odpowiednie mechanizmy uwierzytelniania i kontroli dostępu, w tym – jeżeli jest to adekwatne – uwierzytelnianie wieloskładnikowe?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

7. Czy wykonywane są kopie zapasowe danych oraz czy procesor posiada procedurę odtworzenia danych w przypadku awarii?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

8. Czy w okresie ostatnich 12 miesięcy wystąpiły incydenty lub naruszenia ochrony danych związane z powierzonymi danymi?

☐ NIE
☐ TAK – zostały zgłoszone administratorowi
☐ TAK – nie zostały zgłoszone administratorowi

Jeżeli TAK – opis i sposób obsługi:
..................................................................................................................................

 

III. PODMIOTY PODPRZETWARZAJĄCE I LOKALIZACJA DANYCH

9. Czy procesor korzysta z podmiotów podprzetwarzających i czy administrator posiada aktualną listę tych podmiotów?

☐ NIE
☐ TAK – lista aktualna
☐ TAK – lista wymaga aktualizacji

Uwagi:
..................................................................................................................................

10. Czy w ostatnim roku nastąpiła zmiana podmiotów podprzetwarzających, dostawcy hostingu, lokalizacji danych lub zasad przekazywania danych poza EOG?

☐ NIE
☐ TAK – zmiana została zgłoszona/zaakceptowana
☐ TAK – wymaga dodatkowej weryfikacji

Uwagi:
..................................................................................................................................

 

IV. REALIZACJA OBOWIĄZKÓW PROCESORA

11. Czy procesor posiada procedurę reagowania na incydenty i zapewnia administratorowi niezwłoczne informacje potrzebne do oceny naruszenia z art. 33 i 34 RODO?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

12. Czy procesor zapewnia administratorowi pomoc w realizacji praw osób, których dane dotyczą, w szczególności w zakresie dostępu, sprostowania, usunięcia, ograniczenia przetwarzania i przenoszenia danych?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

13. Czy procesor po zakończeniu świadczenia usługi zapewni zwrot lub usunięcie danych zgodnie z decyzją administratora i art. 28 ust. 3 lit. g RODO?

☐ TAK ☐ NIE ☐ N/D

Uwagi:
..................................................................................................................................

14. Czy procesor umożliwia administratorowi przeprowadzenie kontroli, audytu lub uzyskanie informacji niezbędnych do wykazania spełnienia obowiązków wynikających z art. 28 RODO?

☐ TAK ☐ NIE ☐ N/D

Uwagi / uzyskane dokumenty:
..................................................................................................................................

15. Czy w ocenie administratora procesor nadal daje wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych zapewniających bezpieczeństwo przetwarzania?

☐ TAK – brak działań
☐ TAK – wymagane działania doskonalące
☐ NIE – wymagane działania korygujące
☐ WYMAGA POGŁĘBIONEJ KONTROLI

Uzasadnienie:
..................................................................................................................................

 

PODSUMOWANIE KONTROLI

Wynik kontroli

☐ A – zgodność potwierdzona – brak niezgodności wymagających działań.

☐ B – zgodność z zaleceniami – stwierdzono uchybienia o niskim ryzyku, niewymagające wstrzymania przetwarzania.

☐ C – niezgodność wymagająca działań korygujących – procesor powinien przedstawić plan i termin usunięcia niezgodności.

☐ D – kontrola pogłębiona – stwierdzono okoliczności wymagające dodatkowej analizy, w szczególności incydent, zmianę podprocesora, zmianę lokalizacji danych, istotną zmianę systemu lub poważne uchybienia bezpieczeństwa.

Stwierdzone niezgodności / zalecenia

Dokumenty / dowody uzyskane podczas kontroli

☐ aktualna umowa powierzenia
☐ lista podprocesorów
☐ informacja o lokalizacji danych
☐ informacja o środkach bezpieczeństwa
☐ potwierdzenie procedury obsługi incydentów
☐ potwierdzenie wykonywania kopii zapasowych
☐ inne: ....................................................................................

Decyzja administratora

☐ pozostawić procesora bez dodatkowych działań
☐ zobowiązać procesora do działań korygujących
☐ przeprowadzić kontrolę uzupełniającą
☐ przeprowadzić pogłębioną kontrolę procesora
☐ dokonać ponownej oceny zasadności korzystania z procesora

Data następnej kontroli: ............................................................

Kontrola wcześniejsza zostanie przeprowadzona w przypadku:

• naruszenia ochrony danych,
• istotnej zmiany zakresu przetwarzania,
• zmiany podprocesora lub lokalizacji danych,
• istotnej zmiany systemu lub infrastruktury,
• stwierdzenia poważnej niezgodności,
• innych okoliczności mogących wpływać na bezpieczeństwo przetwarzania.

Osoba dokonująca kontroli:
............................................................

Administrator / ADO:
............................................................

Ta wersja nadaje się jako coroczny dowód realizacji obowiązku monitorowania procesora przez administratora. Przy procesorze wysokiego ryzyka warto potraktować te 15 pytań jako kontrolę podstawową, a w przypadku odpowiedzi „NIE” lub „DO UZUPEŁNIENIA” przejść do pełnego audytu procesora.

FIRMA IT, KTÓRA OBSŁUGUJE DANE KLIENTÓW, POWINNA MIEĆ WŁASNY SYSTEM ZGODNOŚCI Z RODO

 

MASZ 50 KLIENTÓW?

To może oznaczać, że masz również:

50 potencjalnych problemów z RODO.

Brzmi ostro?

Bo takie właśnie jest RODO w outsourcingu IT.

Każdy klient to potencjalnie:

🔴 inny zakres danych,
🔴 inne systemy,
🔴 inni użytkownicy,
🔴 inne lokalizacje danych,
🔴 inni podprocesorzy,
🔴 inne wymagania bezpieczeństwa,
🔴 inna umowa powierzenia,
🔴 inne ryzyka.

A teraz wyobraź sobie, że przy 50 klientach każdą umowę sprawdzasz ręcznie.

Albo jeszcze gorzej:

każdy klient przysyła Ci swój wzór umowy powierzenia, a Ty po prostu go podpisujesz.

To nie jest system.

To jest zarządzanie ryzykiem na pamięć.

FIRMA IT POWINNA MIEĆ SWÓJ STANDARD.

Czyli:

1️⃣ WŁASNY WZÓR UMOWY POWIERZENIA

Dostosowany do rzeczywistych usług:

☁️ chmura
🖥️ serwery
💾 backup
📧 poczta
🔧 administracja systemami
🏥 EDM
🛒 e-commerce
🧑‍💻 helpdesk
🔐 cyberbezpieczeństwo

2️⃣ ARKUSZ WERYFIKACJI UMOWY

Przed podpisaniem sprawdzasz:

✔ przedmiot i czas przetwarzania,
✔ zakres danych,
✔ kategorie osób,
✔ cele przetwarzania,
✔ podprocesorów,
✔ transfery danych,
✔ obowiązki procesora,
✔ bezpieczeństwo,
✔ naruszenia,
✔ audyty,
✔ zakończenie współpracy.

3️⃣ ARKUSZ ZGODNOŚCI USŁUGI Z UMOWĄ

Bo najważniejsze pytanie brzmi:

CZY TO, CO ROBISZ TECHNICZNIE, ZGADZA SIĘ Z TYM, CO PODPISAŁEŚ?

Umowa mówi:

„brak dalszych podmiotów przetwarzających”.

A Ty korzystasz z AWS, Microsoft, Google, zewnętrznego backupu i firmy serwisowej?

Problem.

Umowa mówi:

„dane przechowywane na terenie EOG”.

A część infrastruktury znajduje się poza EOG?

Problem.

Umowa mówi:

„dostęp wyłącznie dla upoważnionego personelu”.

A administratorzy zewnętrznej firmy mają dostęp do systemu?

Problem.

I właśnie dlatego potrzebujesz SYSTEMU.

Nie kolejnego PDF-a.

Nie kolejnej umowy skopiowanej z Internetu.

SYSTEMU OBSŁUGI RODO DLA PROCESORA IT.

Dzięki niemu przy 5 klientach, 50 klientach czy 200 klientach nie zaczynasz za każdym razem od zera.

Masz:

📋 standardową umowę,
📋 checklistę weryfikacyjną,
📋 arkusz kontroli procesora,
📋 rejestr podprocesorów,
📋 procedurę obsługi naruszeń,
📋 procedurę realizacji żądań administratora,
📋 wymagania bezpieczeństwa,
📋 dokumentowanie kontroli.

CO TO DAJE?

Mniej chaosu.

Szybsze podpisywanie umów.

Mniej błędów.

Lepszą obsługę klientów.

Większą przewidywalność.

I przede wszystkim:

możliwość wykazania, że Twoja firma IT rzeczywiście zarządza ochroną danych, a nie tylko podpisuje dokumenty RODO.

Bo kiedy wydarzy się incydent, klient nie będzie pytał:

„Czy macie jakąś umowę powierzenia?”

Zapyta:

„Proszę pokazać, jak zapewniacie bezpieczeństwo danych moich klientów.”

I wtedy dobrze mieć coś więcej niż plik:

„Umowa_powierzenia_final_final2.docx”.

FIRMO IT – ZBUDUJ SWÓJ SYSTEM RODO, ZANIM ZBUDUJE GO ZA CIEBIE INCYDENT.

Przygotowuję dla firm IT pakiet dokumentacji RODO dla procesora, obejmujący m.in.:

🔹 wzór umowy powierzenia,
🔹 arkusz badania umowy,
🔹 arkusz zgodności usług z umową,
🔹 kontrolę podprocesorów,
🔹 wymagania wobec dostawców,
🔹 procedurę obsługi naruszeń,
🔹 dokumentowanie kontroli i nadzoru.

Chcesz sprawdzić, jak taki system można zbudować w Twojej firmie?

📩 Napisz: „IT + RODO”.

Maile: rodoamaj@gmail.com 

AUDYT PROCESORA IT DLA PRAKTYKI LEKARSKIEJ

 

LEKARZU, TWÓJ PROCESOR MOŻE WŁAŚNIE ZGOTOWAĆ CI POZEW.

Nieświadomie.

Bo wystarczy, że jego system zostanie zaatakowany, dane pacjentów wyciekną, a potem okaże się, że:

❌ nie sprawdzałeś zabezpieczeń procesora,
❌ nie kontrolowałeś jego podwykonawców,
❌ nie wiedziałeś, gdzie faktycznie są dane,
❌ nie wiedziałeś, kto ma dostęp administracyjny,
❌ nie miałeś aktualnej analizy ryzyka,
❌ nie miałeś procedury reagowania na incydent.

I wtedy możesz usłyszeć:

„Ale przecież to firma IT odpowiadała za system.”

Tylko że pacjent może zapytać:

„A kto był administratorem moich danych?”

I tutaj kończy się wygodne myślenie, że:

„Mam podpisaną umowę z informatykiem, więc RODO mam załatwione.”

Nie.

Umowa powierzenia z art. 28 RODO nie zastępuje nadzoru nad procesorem.

A dokument podpisany trzy lata temu nie zabezpieczy Cię przed problemem, który wydarzy się jutro.

CO ZROBIŁBYM NA TWOIM MIEJSCU?

Sprawdziłbym procesora zanim zrobi to UODO albo pacjent.

Nie interesuje mnie wyłącznie to, co firma IT napisała w ofercie.

Sprawdziłbym m.in.:

🔎 gdzie znajdują się dane pacjentów,
🔎 kto ma do nich dostęp,
🔎 kto jest podprocesorem,
🔎 czy dane opuszczają EOG,
🔎 jak wykonywane są backupy,
🔎 czy backup można rzeczywiście odtworzyć,
🔎 czy stosowane jest MFA,
🔎 jak zarządzane są konta administratorów,
🔎 jak rejestrowany jest dostęp do danych,
🔎 jak szybko procesor informuje o incydencie,
🔎 czy procesor testuje swoje zabezpieczenia,
🔎 co dzieje się z danymi po zakończeniu współpracy.

I przede wszystkim:

czy lekarz może udowodnić, że jako administrator właściwie zweryfikował i nadzorował procesora.

BO DZISIAJ NIE WYSTARCZY POWIEDZIEĆ:

„Mam firmę IT.”

Trzeba wiedzieć:

CO TA FIRMA ROBI Z DANYMI TWOICH PACJENTÓW.

I trzeba umieć to wykazać.

Dlatego uruchamiam usługę:

🔴 AUDYT PROCESORA IT DLA PRAKTYKI LEKARSKIEJ

Sprawdzam nie tylko samą umowę powierzenia.

Sprawdzam relację lekarz → procesor → podprocesorzy → systemy → dane pacjentów → zabezpieczenia → reakcja na incydent.

Po audycie otrzymujesz:

✔ wykaz stwierdzonych niezgodności,
✔ ocenę ryzyka,
✔ wskazanie brakujących zabezpieczeń,
✔ listę pytań i wymagań do procesora,
✔ rekomendacje zmian w umowie i organizacji współpracy,
✔ wskazanie działań priorytetowych,
✔ materiał pozwalający wykazać, że administrator nie pozostawił bezpieczeństwa danych wyłącznie w rękach dostawcy IT.

Nie czekaj na wyciek, żeby sprawdzić, czy Twój procesor rzeczywiście chroni dane pacjentów.

Bo po wycieku pytanie:

„Czy można było zrobić coś wcześniej?”

może być znacznie droższe niż audyt wykonany dzisiaj.

📩 Jeżeli prowadzisz prywatną praktykę lekarską i korzystasz z zewnętrznego IT/EDM/chmury – napisz do mnie „PROCESOR”.

Sprawdzimy, gdzie naprawdę znajduje się Twoje ryzyko.

Maile: rodoamaj@gmail.com 

Można spodziewać się zwiększonego zainteresowania dochodzeniem roszczeń po naruszeniach danych

 

LEKARZU – PO WYCIEKU DANYCH PROBLEM MOŻE DOPIERO SIĘ ZACZĄĆ.

Ujawnione informacje o bardzo wysokich zarobkach lekarzy.

Do tego kolejne incydenty związane z wyciekami danych z systemów informatycznych obsługujących placówki i prywatne praktyki lekarskie.

I pojawia się pytanie:

Czy możemy spodziewać się większej liczby pozwów pacjentów przeciwko lekarzom?

Nie twierdzę, że fala pozwów na pewno nastąpi.

Ale jeden element jest bardzo istotny.

RODO daje osobie, której dane dotyczą, możliwość dochodzenia odszkodowania przed sądem cywilnym.

UODO wprost wskazuje, że niezależnie od postępowania przed Prezesem UODO osoba, której dane dotyczą, może pozwać administratora lub podmiot przetwarzający i dochodzić odszkodowania za szkodę majątkową lub niemajątkową.

A w przypadku prywatnej praktyki lekarskiej lekarz bardzo często jest administratorem danych swoich pacjentów.

I wtedy argument:

„To mojemu informatykowi wyciekły dane”

może być zdecydowanie niewystarczający.

Co powinien zrobić lekarz?

1. Sprawdzić umowę z dostawcą IT

Czy rzeczywiście mamy prawidłową umowę powierzenia z art. 28 RODO?

Czy określono zakres przetwarzania?

Czy procesor może korzystać z dalszych podmiotów?

Czy lekarz ma prawo do kontroli?

2. Zweryfikować, jakie dane faktycznie znajdują się u procesora

Nie tylko:

„mam system EDM”.

Trzeba wiedzieć:

• jakie dane pacjentów są przechowywane,

• gdzie są przechowywane,

• kto ma do nich dostęp,

• jakie kopie zapasowe są tworzone,

• gdzie się znajdują,

• jak długo są przechowywane,

• czy dane trafiają poza EOG.

3. Przeprowadzić realną analizę ryzyka

Nie dokument „na półkę”.

Analizę obejmującą m.in.:

🔹 ransomware,
🔹 kradzież danych,
🔹 nieuprawniony dostęp,
🔹 błędy personelu,
🔹 błędną konfigurację systemu,
🔹 utratę urządzeń,
🔹 atak na dostawcę IT,
🔹 kopie zapasowe,
🔹 dostęp administratorów systemu.

4. Sprawdzić art. 32 RODO

Czy zastosowane środki techniczne i organizacyjne są rzeczywiście adekwatne do ryzyka?

UODO przy ocenie naruszeń bierze pod uwagę m.in. charakter i skalę naruszenia, liczbę osób, skutki, wcześniejsze naruszenia oraz zastosowane środki techniczne i organizacyjne.

5. Przygotować procedurę reagowania na wyciek

Lekarz powinien wiedzieć:

kto → kiedy → co zgłasza → komu → jak analizujemy ryzyko → kiedy zgłaszamy do UODO → kiedy zawiadamiamy pacjentów.

Po incydencie u MyDr UODO przypomniał administratorom, że sam fakt, iż naruszenie nastąpiło u procesora, nie zwalnia administratora z realizacji obowiązków wynikających z art. 33 i 34 RODO.

6. Zacząć kontrolować procesora

Nie wystarczy podpisać umowy powierzenia i zapomnieć o niej na 5 lat.

Administrator powinien być w stanie wykazać, że zweryfikował procesora i jego środki bezpieczeństwa.

I jeszcze jedna rzecz.

Dzisiaj wielu lekarzy patrzy na RODO przede wszystkim przez pryzmat kontroli UODO.

To może być za mało.

Bo potencjalnym problemem nie musi być tylko:

„czy UODO nałoży karę?”

Może pojawić się również pytanie:

„czy pacjent będzie dochodził swoich roszczeń?”

Dlatego lekarz prowadzący prywatną praktykę powinien traktować bezpieczeństwo danych pacjentów nie jako formalność, ale jako element zarządzania ryzykiem swojej działalności.

RODO zaczyna się od dokumentacji.
Ale kończy się na odpowiedzialności.

Dzisiaj UODO pokazuje, dlaczego miałem rację

 

W maju 2023 mnie za to atakowano.
Dzisiaj UODO pokazuje, dlaczego miałem rację.

Napisałem wtedy wprost:

maile starsze niż 90 dni powinny być usuwane, jeżeli nie ma podstawy i potrzeby ich dalszego przechowywania.

I zaczęła się dyskusja.

Byli IOD, którzy mnie za to krytykowali.
Byli tacy, którzy twierdzili, że „RODO nie nakazuje usuwać maili po 90 dniach”.

Oczywiście, że nie nakazuje magicznego terminu 90 dni.

Tylko że nigdy nie chodziło mi o magiczne 90 dni.

Chodziło o coś znacznie ważniejszego:

ANALIZĘ RYZYKA.

Jeżeli administrator przechowuje ogromne ilości korespondencji przez lata, musi umieć odpowiedzieć:

➡️ Po co ją nadal przechowujemy?
➡️ Czy jest to rzeczywiście niezbędne?
➡️ Jakie ryzyko wiąże się z jej przechowywaniem?
➡️ Jak długo powinniśmy ją przechowywać?
➡️ Jak ograniczamy dostęp?
➡️ Co robimy ze starymi danymi?

I właśnie tutaj najnowsza decyzja UODO dotycząca bezpieczeństwa poczty elektronicznej jest bardzo wymowna.

UODO nie zaakceptował podejścia „jakoś to będzie”.

Brak właściwej analizy ryzyka i odpowiednich środków bezpieczeństwa może skończyć się realną karą finansową.

Dlatego powtórzę coś, co pisałem już w 2023 roku:

RODO nie zaczyna się od procedury.
RODO zaczyna się od prawidłowo wykonanej analizy ryzyka.

To ona powinna być fundamentem decyzji dotyczących retencji, dostępu, zabezpieczeń i usuwania danych.

A jeżeli IOD rekomenduje określony okres przechowywania danych, powinien móc powiedzieć:

„Mam na to podstawę. Wynika to z analizy ryzyka, zasad RODO i specyfiki procesu”.

Nie z widzimisię.
Nie z intuicji.
Nie dlatego, że „wszyscy tak robią”.

Z analizy ryzyka.

I czasami warto bronić takiego stanowiska, nawet jeśli w danym momencie inni IOD je kwestionują.

Bo RODO to nie konkurs popularności.

To zarządzanie ryzykiem.