Kupujesz rozwiązanie IT? Sprawdź, czy razem z nim otrzymujesz Analizę Ryzyka i procedury RODO!

 

Dobra oferta IT to nie tylko funkcjonalność, cena i termin wdrożenia. To również bezpieczeństwo danych, ograniczenie ryzyka prawnego i dokumentacja, która pozwala wykazać, że Twoja organizacja świadomie zarządza ochroną danych osobowych.

Wybierając system informatyczny, platformę B2B, sklep internetowy, oprogramowanie do obsługi klientów czy usługę chmurową, warto zadać dostawcy jedno dodatkowe pytanie: czy oferta obejmuje również Analizę Ryzyka oraz procedury związane z RODO?

Jeśli tak, kupujący może zyskać znacznie więcej niż samo narzędzie informatyczne.

1. Kupujesz rozwiązanie, a nie kolejny problem do rozwiązania

Wiele ofert IT koncentruje się na technologii. Dostawca przedstawia funkcjonalności, parametry techniczne, integracje, czas wdrożenia i koszty utrzymania. To ważne, ale nie odpowiada na wszystkie pytania, które powinien zadać sobie przedsiębiorca.

• Jakie dane osobowe będą przetwarzane w systemie?

• Jakie zagrożenia mogą wystąpić podczas korzystania z rozwiązania?

• Kto będzie miał dostęp do danych i na jakich zasadach?

• Jakie zabezpieczenia należy zastosować?

• Co zrobić w przypadku incydentu lub naruszenia ochrony danych?

• Czy konieczne jest zawarcie umowy powierzenia przetwarzania danych osobowych?

Jeżeli dostawca uwzględnia te kwestie już na etapie przygotowania oferty, kupujący otrzymuje rozwiązanie lepiej przygotowane do bezpiecznego wdrożenia.

To różnica między zakupem samej technologii a zakupem technologii wraz z przemyślanym podejściem do bezpieczeństwa i zgodności z RODO.

2. Analiza Ryzyka pozwala podejmować świadome decyzje

Zgodnie z art. 24, 25 i 32 RODO administrator danych powinien wdrażać odpowiednie środki organizacyjne i techniczne, uwzględniając między innymi ryzyko związane z przetwarzaniem danych osobowych.

Analiza Ryzyka nie powinna być dokumentem sporządzonym wyłącznie na potrzeby kontroli. Jej zadaniem jest pomóc organizacji zrozumieć, co może pójść nie tak i jak ograniczyć prawdopodobieństwo wystąpienia problemu oraz jego skutki.

Dobrze przygotowana analiza dotycząca oferowanego rozwiązania IT może wskazywać między innymi:

• zagrożenia związane z nieuprawnionym dostępem do danych;

• ryzyko utraty, uszkodzenia lub ujawnienia informacji;

• konsekwencje błędnej konfiguracji systemu;

• ryzyka wynikające z integracji z innymi systemami;

• wymagania dotyczące kopii zapasowych, logowania zdarzeń i kontroli uprawnień;

• potrzebne zabezpieczenia oraz działania ograniczające ryzyko.

Dla kupującego oznacza to konkretną korzyść: łatwiej ocenić, czy oferowane rozwiązanie odpowiada potrzebom organizacji, jakie dodatkowe zabezpieczenia będą konieczne i jakie koszty mogą pojawić się po wdrożeniu.

Ważne jednak, aby Analiza Ryzyka była dopasowana do konkretnego rozwiązania i sposobu jego wykorzystania. Gotowy dokument powinien być punktem wyjścia do oceny ryzyka u kupującego, a nie automatycznym zastępstwem jego własnej analizy.

3. Procedury RODO ograniczają koszty wdrożenia

Samo rozpoznanie zagrożeń nie wystarczy. Organizacja potrzebuje również zasad postępowania.

Jeżeli oferta IT zawiera przygotowane procedury lub wzory dokumentów, kupujący może szybciej uporządkować kwestie organizacyjne. W zależności od charakteru usługi mogą to być między innymi:

• procedura nadawania i odbierania uprawnień;

• zasady zarządzania incydentami i naruszeniami ochrony danych;

• procedura wykonywania i odtwarzania kopii zapasowych;

• zasady kontroli dostępu do systemu;

• procedura weryfikacji dostawcy i podmiotów przetwarzających;

• wzór umowy powierzenia przetwarzania danych, jeśli jest ona wymagana;

• instrukcje dotyczące bezpiecznego korzystania z rozwiązania.

Takie materiały skracają drogę od zakupu do wdrożenia. Przedsiębiorca nie musi za każdym razem rozpoczynać pracy nad dokumentacją od zera.

Oczywiście dokumenty należy dostosować do rzeczywistych procesów, infrastruktury i podziału odpowiedzialności w organizacji. Sama obecność procedury nie oznacza jeszcze, że jest ona wdrożona i skutecznie stosowana.

4. Niższa cena zakupu nie zawsze oznacza niższy koszt

Porównując oferty IT, łatwo skupić się wyłącznie na cenie licencji, abonamentu lub wdrożenia. Tymczasem pełny koszt rozwiązania może obejmować także przygotowanie dokumentacji, analizę ryzyka, konsultacje prawne i organizacyjne, dodatkowe zabezpieczenia oraz poprawki wynikające z wykrytych niezgodności.

Wyobraźmy sobie dwie oferty.

Oferta A obejmuje wyłącznie system informatyczny. Po zakupie przedsiębiorca sam musi zorganizować analizę ryzyka, opracować procedury i ustalić, jakie wymagania dotyczące ochrony danych powinien spełnić.

Oferta B obejmuje system, wstępną Analizę Ryzyka, rekomendowane zabezpieczenia oraz zestaw procedur i dokumentów do dostosowania.

Nawet jeśli oferta B ma wyższą cenę początkową, może okazać się korzystniejsza po uwzględnieniu całkowitych kosztów wdrożenia i utrzymania. Nie jest to jednak reguła — dokumentacja musi być rzetelna, aktualna i rzeczywiście przydatna.

Dlatego warto porównywać nie tylko ceny, lecz także zakres odpowiedzialności, jakość dokumentacji, wymagane prace po stronie kupującego i koszty utrzymania zgodności.

5. RODO to także kwestia odpowiedzialności za dane klientów

Przedsiębiorca korzystający z systemu IT nie może zakładać, że całą odpowiedzialność za ochronę danych przejmuje dostawca oprogramowania.

Podział ról zależy od rzeczywistego modelu współpracy. Jeżeli przedsiębiorca jest administratorem danych, nadal odpowiada za obowiązki przypisane mu przez RODO, w tym za dobór odpowiednich zabezpieczeń i nadzór nad przetwarzaniem danych.

Z kolei dostawca może pełnić rolę podmiotu przetwarzającego, niezależnego administratora albo występować w innym modelu — zależnie od okoliczności.

Właśnie dlatego dokumentacja towarzysząca ofercie powinna pomagać ustalić:

• kto odpowiada za poszczególne procesy;

• jakie dane i w jakim celu są przetwarzane;

• jakie środki bezpieczeństwa stosuje dostawca;

• jak wygląda obsługa incydentów;

• jakie są zasady współpracy i przekazywania informacji między stronami.

Im wcześniej te kwestie zostaną wyjaśnione, tym mniejsze ryzyko nieporozumień w trakcie współpracy.

6. Dlaczego warto zaangażować zewnętrznego IOD?

Dokumenty przygotowane przez dostawcę IT są cenne, ale nie powinny być jedynym źródłem oceny zgodności rozwiązania z RODO.

Dostawca zna swój produkt. Nie zawsze zna jednak wszystkie procesy kupującego, wewnętrzne zasady dostępu do danych, strukturę organizacyjną, obowiązki wobec klientów czy specyficzne ryzyka wynikające ze sposobu korzystania z systemu.

Dlatego dobrym rozwiązaniem jest zaangażowanie zewnętrznego Inspektora Ochrony Danych (IOD) lub niezależnego eksperta ds. RODO.

Taki specjalista może pomóc kupującemu:

1. Zweryfikować, czy Analiza Ryzyka rzeczywiście obejmuje istotne zagrożenia.

2. Ocenić, czy rekomendowane zabezpieczenia odpowiadają charakterowi przetwarzanych danych.

3. Sprawdzić, czy konieczna jest umowa powierzenia przetwarzania danych.

4. Dostosować procedury do rzeczywistych procesów organizacji.

5. Ustalić, jakie działania należy wykonać przed uruchomieniem systemu.

6. Ocenić potrzebę przeprowadzenia oceny skutków dla ochrony danych (DPIA/OSOD).

7. Pomóc przygotować dokumentację pozwalającą wykazać zgodność z RODO.

Warto pamiętać, że formalne wyznaczenie IOD nie jest obowiązkowe dla każdej firmy. Zależy od spełnienia przesłanek określonych w art. 37 RODO. Nawet jeżeli przedsiębiorca nie ma obowiązku powołania IOD, może skorzystać ze wsparcia zewnętrznego specjalisty.

Najważniejsze jest to, aby osoba oceniająca rozwiązanie patrzyła na nie z perspektywy interesów i obowiązków kupującego, a nie wyłącznie z perspektywy dostawcy.

7. Na co zwrócić uwagę, wybierając ofertę IT wspartą dokumentacją RODO?

Przed podpisaniem umowy warto zapytać dostawcę:

• Czy Analiza Ryzyka dotyczy konkretnego rozwiązania, czy jest jedynie ogólnym wzorem?

• Czy wskazuje konkretne zagrożenia i rekomendowane zabezpieczenia?

• Czy procedury odpowiadają funkcjonalnościom systemu?

• Czy dokumentacja podlega aktualizacji w przypadku istotnych zmian?

• Czy dostawca określa swoją rolę w przetwarzaniu danych?

• Czy materiały można dostosować do procesów kupującego?

• Czy oferta obejmuje wsparcie przy wdrożeniu zaleceń?

Odpowiedzi na te pytania pozwolą odróżnić rzeczywistą wartość dodaną od dokumentacji przygotowanej jedynie po to, aby dobrze wyglądała w ofercie handlowej.

Podsumowanie: bezpieczeństwo warto kupować razem z technologią

Dobrze przygotowana oferta IT powinna uwzględniać nie tylko to, co system potrafi, lecz także to, jak bezpiecznie wykorzystywać go w praktyce.

Analiza Ryzyka, procedury RODO i odpowiednio przygotowana dokumentacja mogą ograniczyć nakład pracy po stronie kupującego, ułatwić wdrożenie oraz pomóc w podejmowaniu świadomych decyzji dotyczących bezpieczeństwa danych.

Nie oznacza to automatycznej gwarancji zgodności z RODO. Ostateczny rezultat zależy również od tego, jak rozwiązanie zostanie skonfigurowane, wdrożone i wykorzystane.

Dlatego warto połączyć trzy elementy: dobrą technologię, rzetelną dokumentację i niezależną ocenę specjalisty ds. ochrony danych.

Zewnętrzny IOD lub ekspert ds. RODO może pomóc sprawdzić, czy rozwiązanie rzeczywiście odpowiada potrzebom organizacji, zanim pojawią się kosztowne poprawki, problemy organizacyjne lub incydenty związane z bezpieczeństwem danych.

Kupując IT, nie pytaj wyłącznie: „Co ten system potrafi?”. Zapytaj również: „Jakie ryzyka ogranicza i jak pomaga mi bezpiecznie przetwarzać dane osobowe?”.

To pytanie może mieć większe znaczenie dla Twojego biznesu, niż początkowo zakładasz.

Potrzebujesz wsparcia przy ocenie oferty IT, przygotowaniu Analizy Ryzyka lub dostosowaniu dokumentacji RODO do wdrażanego rozwiązania? Skonsultuj projekt z zewnętrznym IOD lub ekspertem ds. RODO, zanim podpiszesz umowę i uruchomisz system.

Zespół powołany zarządzeniem Zarządu ma dostęp do danych osobowych.

 

Zespół powołany zarządzeniem Zarządu ma dostęp do danych osobowych. Jakie obowiązki RODO należy mu przydzielić?

Powołanie zespołu zadaniowego zarządzeniem Zarządu jest częstym rozwiązaniem w organizacjach, które chcą przeprowadzić audyt, zoptymalizować zatrudnienie, przeanalizować koszty, uporządkować procesy lub ocenić efektywność pracy poszczególnych komórek organizacyjnych.

Problem pojawia się wtedy, gdy członkowie takiego zespołu otrzymują dostęp do danych osobowych, a w szczególności do informacji o pracownikach, wynagrodzeniach, absencjach, kwalifikacjach zawodowych, wydajności pracy czy sytuacji zdrowotnej.

Zarząd może powołać zespół i określić jego zadania organizacyjne. Nie oznacza to jednak, że samo zarządzenie automatycznie legalizuje dostęp do wszystkich danych osobowych, które mogą okazać się przydatne podczas realizacji projektu.

Jeżeli zespół ma dostęp do danych osobowych, jego zadania, uprawnienia i zasady odpowiedzialności za przetwarzanie danych powinny zostać określone przed rozpoczęciem pracy.

Nie wystarczy zapis: „Zespół realizuje zadania zgodnie z obowiązującymi przepisami prawa”. Potrzebne są konkretne reguły dotyczące dostępu, zakresu danych, poufności, bezpieczeństwa i dokumentowania czynności.

1. Najpierw ustalmy, kto odpowiada za przetwarzanie danych

Podstawowe pytanie brzmi: czy zespół jest odrębnym administratorem danych?

Co do zasady, nie. Jeżeli Zarząd powołuje zespół jako wewnętrzną strukturę organizacyjną przedsiębiorstwa lub innej organizacji, administratorem pozostaje podmiot, który ustala cele i sposoby przetwarzania danych. Zespół działa w jego strukturze organizacyjnej, w granicach powierzonych mu zadań i uprawnień.

Z tego wynikają trzy konsekwencje:

• Zarząd nie może samym zarządzeniem zastąpić podstawy prawnej przetwarzania danych.

• Kierownik zespołu nie uzyskuje automatycznie prawa do wszystkich informacji znajdujących się w organizacji.

• Każdy członek zespołu powinien mieć dostęp tylko do tych danych, które są niezbędne do realizacji powierzonych mu zadań.

W praktyce oznacza to konieczność ustalenia celu przetwarzania, podstawy prawnej, kategorii osób, których dane dotyczą, kategorii danych oraz rzeczywistego zakresu dostępu poszczególnych członków zespołu.

Podstawowe znaczenie mają tutaj art. 5 ust. 1 lit. a–f i ust. 2, art. 6, art. 24, art. 25 oraz art. 32 RODO.

2. Jakie zadania z zakresu RODO należy przydzielić zespołowi?

Jeżeli zespół ma pracować na danych osobowych, zarządzenie powinno zawierać odrębną część regulującą zasady ich przetwarzania. W zależności od charakteru projektu warto przypisać zespołowi następujące obowiązki.

Zadanie 1. Przetwarzanie danych wyłącznie w celu określonym w zarządzeniu

Zespół powinien wykorzystywać dane osobowe wyłącznie w celu realizacji zadania, dla którego został powołany.

Przykładowo, jeżeli zespół ma przeanalizować organizację pracy i zabezpieczenie kadrowe personelu medycznego, nie powinien wykorzystywać pozyskanych danych do prowadzenia niezależnej oceny zachowania konkretnych pracowników, sporządzania nieformalnych rankingów ani podejmowania działań niezwiązanych z powierzonym projektem.

W zarządzeniu warto wskazać, że członkowie zespołu:

• przetwarzają dane wyłącznie w zakresie niezbędnym do realizacji zadania;

• nie wykorzystują danych do celów prywatnych ani innych niezatwierdzonych celów;

• nie podejmują samodzielnie nowych celów przetwarzania;

• nie udostępniają danych osobom spoza uprawnionego kręgu odbiorców.

Podstawa prawna: art. 5 ust. 1 lit. b RODO – ograniczenie celu.

Zadanie 2. Ustalenie minimalnego zakresu danych niezbędnych do analizy

Zespół powinien określić, jakie dane rzeczywiście są potrzebne do realizacji projektu, i ograniczyć ich zakres do niezbędnego minimum.

Jeżeli celem jest ustalenie liczby etatów, obsady dyżurowej lub braków kadrowych, często wystarczą dane zagregowane, zestawienia liczebności albo informacje o strukturze zatrudnienia.

Nie zawsze konieczne będzie udostępnianie imion i nazwisk, numerów PESEL, adresów zamieszkania, informacji o stanie zdrowia czy szczegółowych danych płacowych.

Warto zobowiązać zespół do:

• uzasadniania potrzeby dostępu do danych identyfikujących konkretne osoby;

• korzystania w pierwszej kolejności z zestawień statystycznych lub danych zanonimizowanych;

• ograniczania liczby osób, których dane są analizowane;

• zgłaszania Zarządowi lub osobie odpowiedzialnej za ochronę danych potrzeby rozszerzenia zakresu dostępu.

Podstawa prawna: art. 5 ust. 1 lit. c RODO – minimalizacja danych.

Zadanie 3. Przestrzeganie zasad dostępu do danych

Zarządzenie powinno wskazywać, że dostęp do danych osobowych przysługuje członkom zespołu tylko w zakresie wynikającym z ich zadań i nadanych uprawnień.

W praktyce oznacza to, że samo członkostwo w zespole nie uzasadnia dostępu do całej dokumentacji kadrowej, systemów informatycznych czy akt osobowych.

Warto nałożyć na zespół obowiązek:

• korzystania wyłącznie z przyznanych uprawnień;

• nieprzekazywania kont, haseł ani tokenów dostępowych innym osobom;

• niepozyskiwania danych z systemów, do których członek zespołu nie ma upoważnienia;

• niekopiowania dokumentacji poza zatwierdzone lokalizacje;

• zgłaszania potrzeby nadania, zmiany lub odebrania uprawnień.

Podstawa prawna: art. 29 oraz art. 32 ust. 1 RODO. Art. 29 odnosi się do przetwarzania pod kierownictwem administratora lub podmiotu przetwarzającego.

Zadanie 4. Zachowanie poufności

Każdy członek zespołu powinien być zobowiązany do zachowania w poufności informacji uzyskanych w związku z realizacją zadania.

Dotyczy to zarówno dokumentów papierowych, jak i danych dostępnych w systemach informatycznych, korespondencji, notatek, zestawień, prezentacji oraz ustnych informacji o pracownikach i innych osobach.

Poufność powinna obejmować również okres po zakończeniu prac zespołu, zgodnie z obowiązującymi przepisami i zobowiązaniami danej osoby.

Nie należy jednak zakładać, że sam podpis pod zarządzeniem zawsze wystarczy. Trzeba sprawdzić, czy dana osoba jest już objęta właściwym upoważnieniem i obowiązkiem poufności, a jeśli nie – zapewnić odpowiednie formalne umocowanie.

Podstawa prawna: art. 5 ust. 1 lit. f, art. 29 i art. 32 ust. 4 RODO.

Zadanie 5. Bezpieczne przechowywanie i przekazywanie danych

Zespół powinien pracować na dokumentach i zestawieniach w sposób, który ogranicza ryzyko przypadkowego ujawnienia, utraty lub zniszczenia danych.

W zarządzeniu warto określić, że:

• dokumenty są przechowywane w zatwierdzonych lokalizacjach;

• dane elektroniczne są przekazywane wyłącznie przy użyciu zatwierdzonych kanałów;

• dokumenty papierowe nie są pozostawiane bez nadzoru;

• materiały nie są przesyłane na prywatne skrzynki pocztowe ani kopiowane do prywatnych chmur;

• wydruki i kopie robocze są zabezpieczane oraz usuwane po ustaniu potrzeby ich wykorzystywania, z uwzględnieniem zasad retencji dokumentacji.

Nie należy automatycznie zakazywać każdej kopii czy wydruku. Należy natomiast określić, kiedy są dopuszczalne, kto może je wykonywać i w jaki sposób mają być zabezpieczone.

Podstawa prawna: art. 5 ust. 1 lit. f oraz art. 32 RODO.

Zadanie 6. Zgłaszanie incydentów i podejrzeń naruszenia ochrony danych

Członkowie zespołu powinni mieć obowiązek niezwłocznego zgłaszania podejrzenia naruszenia ochrony danych osobowych osobie lub komórce wskazanej w procedurze obowiązującej u administratora.

Przykładowe zdarzenia to:

• wysłanie zestawienia do niewłaściwego odbiorcy;

• zagubienie dokumentów;

• ujawnienie danych podczas prezentacji;

• uzyskanie dostępu przez osobę nieuprawnioną;

• pozostawienie dokumentacji w miejscu dostępnym dla osób postronnych;

• utrata urządzenia zawierającego dane.

Zespół nie powinien samodzielnie przesądzać, że zdarzenie nie stanowi naruszenia, i rezygnować z jego zgłoszenia. Ocena naruszenia oraz decyzja o ewentualnym zgłoszeniu do Prezesa UODO należą do właściwych osób działających w imieniu administratora, zgodnie z przyjętą procedurą.

Podstawa prawna: art. 33 i 34 RODO.

Zadanie 7. Dokumentowanie operacji i wyników prac

Zespół powinien dokumentować źródła danych, zakres otrzymanych informacji, sposób ich wykorzystania oraz wyniki analiz w zakresie niezbędnym do wykazania prawidłowego przebiegu prac.

Warto przewidzieć:

• ewidencję przekazanych zestawień i dokumentów;

• wskazanie osób uprawnionych do otrzymywania materiałów;

• oznaczenie dokumentów zawierających dane osobowe;

• określenie zasad przygotowywania raportów dla Zarządu;

• weryfikację, czy raport końcowy rzeczywiście wymaga podania danych identyfikujących konkretne osoby.

Raport dotyczący organizacji pracy nie powinien bez uzasadnionej potrzeby zawierać nazwisk, szczegółowych informacji o zdrowiu ani innych danych pozwalających na identyfikację osób.

Podstawa prawna: art. 5 ust. 2 oraz art. 24 RODO.

Zadanie 8. Zakończenie dostępu i uporządkowanie dokumentacji

Po zakończeniu prac albo odwołaniu członka zespołu należy niezwłocznie zweryfikować jego dostęp do danych, systemów i dokumentacji.

Zespół powinien przekazać materiały robocze zgodnie z ustalonymi zasadami oraz usunąć zbędne kopie, o ile ich dalsze przechowywanie nie wynika z obowiązku prawnego lub przyjętych zasad dokumentowania i retencji.

Należy też odebrać lub zmienić uprawnienia informatyczne i rozliczyć dokumenty papierowe.

Podstawa prawna: art. 5 ust. 1 lit. e i f oraz art. 32 RODO.

3. Czy IOD powinien być członkiem zespołu?

To zależy od celu i zakresu prac.

IOD powinien być zaangażowany w konsultacje dotyczące ochrony danych, zwłaszcza gdy zespół ma uzyskać dostęp do danych szczególnie wrażliwych, analizować organizację pracy personelu lub tworzyć nowe rozwiązania związane z przetwarzaniem danych.

Zgodnie z art. 39 ust. 1 lit. a i b RODO IOD informuje o obowiązkach wynikających z przepisów oraz monitoruje ich przestrzeganie. Na podstawie art. 38 ust. 1 administrator zapewnia IOD właściwe i terminowe włączanie we wszystkie sprawy dotyczące ochrony danych osobowych.

Nie oznacza to jednak, że IOD powinien automatycznie zostać członkiem każdego zespołu.

Jeżeli jego zadaniem ma być niezależne monitorowanie zgodności działań zespołu, często korzystniejsze będzie pozostawienie go w roli doradczej i kontrolnej. IOD nie powinien przejmować odpowiedzialności za decyzje biznesowe Zarządu ani za wdrożenie rozwiązań, których zgodność ma następnie niezależnie oceniać.

4. Czy można powołać zespół bez dostępu do danych osobowych?

Tak. W wielu przypadkach to rozwiązanie najbezpieczniejsze i najbardziej efektywne.

Jeżeli celem jest analiza kosztów, efektywności organizacyjnej, obciążenia pracą lub zabezpieczenia kadrowego, należy najpierw sprawdzić, czy zadanie można wykonać na danych zagregowanych lub odpowiednio zanonimizowanych.

Warto przy tym rozróżnić:

• Dane zanonimizowane – nie pozwalają na identyfikację osoby, również przy uwzględnieniu środków, których można racjonalnie użyć.

• Dane pseudonimizowane – pozwalają na identyfikację przy użyciu dodatkowych informacji; nadal są danymi osobowymi.

• Dane zagregowane – przedstawiają zbiorcze wyniki. Mogą nie być danymi osobowymi, jeżeli nie pozwalają na identyfikację konkretnych osób.

Samo usunięcie imienia i nazwiska nie zawsze zapewnia anonimowość. W niewielkiej komórce organizacyjnej połączenie stanowiska, specjalizacji, wymiaru etatu i harmonogramu może pozwolić na rozpoznanie konkretnego pracownika.

Jeżeli zespół nie potrzebuje identyfikacji osób, zarządzenie powinno nakazywać korzystanie w pierwszej kolejności z danych statystycznych i zestawień, a dostęp do danych jednostkowych dopuszczać wyłącznie po uzasadnieniu jego niezbędności.

5. Jakich zadań nie należy automatycznie przydzielać zespołowi?

Zespół zadaniowy nie powinien bez odpowiedniego umocowania i analizy prawnej:

• uzyskiwać nieograniczonego dostępu do akt osobowych;

• podejmować decyzji o celach przetwarzania danych niezależnie od administratora;

• samodzielnie rozszerzać zakresu danych, do których ma dostęp;

• przekazywać danych podmiotom zewnętrznym;

• decydować o zgłoszeniu naruszenia do Prezesa UODO zamiast osób właściwych po stronie administratora;

• przechowywać dokumentacji bez określonego celu i okresu;

• wykorzystywać danych zebranych do jednego celu do innych, niezweryfikowanych celów.

Szczególnej ostrożności wymagają dane dotyczące zdrowia, wynagrodzeń, ocen pracowniczych, absencji oraz inne informacje, które mogą wpływać na sytuację zawodową konkretnej osoby.

6. Co powinno znaleźć się w zarządzeniu Zarządu?

Z punktu widzenia zgodności z RODO rekomenduję, aby zarządzenie zawierało co najmniej:

1. Cel i zakres zadań zespołu.

2. Wskazanie administratora danych.

3. Określenie kategorii danych i osób, których dane mogą być przetwarzane.

4. Zasady ustalania i nadawania uprawnień członkom zespołu.

5. Ograniczenie dostępu do danych niezbędnych do realizacji zadania.

6. Obowiązek zachowania poufności.

7. Zasady przechowywania, przekazywania i zabezpieczania materiałów.

8. Obowiązek zgłaszania incydentów.

9. Zasady dokumentowania i przekazywania wyników prac.

10. Zasady zakończenia dostępu i postępowania z dokumentacją po rozwiązaniu zespołu.

11. Wskazanie roli IOD w konsultowaniu rozwiązań dotyczących ochrony danych.

Warto również określić, kto odpowiada za przygotowanie danych dla zespołu, kto zatwierdza zakres dostępu oraz kto kontroluje wykonanie tych zasad.

Podsumowanie

Powołanie zespołu zarządzeniem Zarządu nie zwalnia administratora z obowiązków wynikających z RODO. Jeżeli członkowie zespołu mają dostęp do danych osobowych, należy określić nie tylko cel ich pracy, ale również granice dostępu, obowiązki poufności, zasady bezpieczeństwa i sposób rozliczenia wykorzystanych informacji.

Najlepszą praktyką jest przyjęcie zasady: najpierw określamy cel, potem minimalny zakres danych, a dopiero na końcu przyznajemy dostęp konkretnym osobom.

Takie podejście ogranicza ryzyko nieuprawnionego ujawnienia informacji, ułatwia wykazanie zgodności z RODO i pozwala Zarządowi realizować zadania organizacyjne bez tworzenia niepotrzebnych zagrożeń dla praw osób, których dane dotyczą.

Lekarz na B2B a IOD

 

Dlaczego lekarz pracujący w szpitalu na kontrakcie B2B powinien korzystać z IOD lub eksperta ds. RODO?

1. Uzasadnienie prawne i organizacyjne

Lekarz wykonujący świadczenia zdrowotne w szpitalu na podstawie kontraktu B2B powinien rozważyć stałą współpracę z inspektorem ochrony danych (IOD) lub ekspertem ds. ochrony danych osobowych. Wynika to przede wszystkim z charakteru przetwarzanych danych, odpowiedzialności lekarza za własne działania oraz konieczności rozdzielenia obowiązków szpitala od obowiązków lekarza jako przedsiębiorcy.

Najważniejsze jest to, że kontrakt B2B nie przenosi automatycznie na szpital całej odpowiedzialności lekarza za przetwarzanie danych osobowych. Jednocześnie nie oznacza, że lekarz zawsze jest odrębnym administratorem danych swoich pacjentów. Status ten należy ustalić na podstawie rzeczywistego podziału decyzji, celów i sposobów przetwarzania danych, a nie wyłącznie na podstawie formy zatrudnienia.

Lekarz może korzystać z systemów informatycznych, infrastruktury i dokumentacji szpitala, ale jednocześnie prowadzić własną działalność gospodarczą, zawierać umowy z innymi podmiotami, korzystać z własnego sprzętu lub świadczyć usługi w kilku placówkach. Każda z tych okoliczności może rodzić odrębne ryzyka związane z ochroną danych.

2. Dlaczego lekarz B2B potrzebuje profesjonalnego wsparcia?

1. Odpowiedzialność za dane pacjentów

Lekarz przetwarza dane dotyczące zdrowia, czyli szczególną kategorię danych osobowych w rozumieniu art. 9 RODO. Nieprawidłowe udostępnienie dokumentacji, utrata danych lub wysłanie ich niewłaściwemu odbiorcy może prowadzić do poważnych konsekwencji prawnych, finansowych i zawodowych.

2. Ustalenie, kto jest administratorem danych

W zależności od organizacji świadczeń administratorem może być szpital, lekarz prowadzący własną praktykę albo więcej niż jeden podmiot w odpowiednim zakresie. Ekspert pomaga ustalić role i obowiązki oraz ocenić, czy potrzebne są dodatkowe uzgodnienia lub umowy.

3. Bezpieczne korzystanie z systemów i sprzętu

Korzystanie z prywatnego telefonu, poczty elektronicznej, chmury, komunikatorów lub nośników danych do celów zawodowych może spowodować nieuprawnione ujawnienie danych. Ekspert określa dopuszczalne zasady korzystania ze sprzętu i pomaga wdrożyć adekwatne zabezpieczenia.

4. Umowy z dostawcami usług

Jeśli lekarz jako przedsiębiorca korzysta z zewnętrznego systemu medycznego, księgowego, hostingu, poczty lub usług IT, trzeba ustalić role stron i wymagane zabezpieczenia. Gdy dostawca przetwarza dane w imieniu lekarza, może być konieczna umowa powierzenia zgodna z art. 28 RODO.

5. Reagowanie na naruszenia ochrony danych

W przypadku wycieku dokumentacji, utraty urządzenia lub nieuprawnionego dostępu trzeba szybko ocenić ryzyko i ustalić obowiązki zgłoszeniowe. Zależnie od roli lekarza oraz okoliczności naruszenia obowiązki mogą spoczywać na szpitalu, lekarzu lub obu podmiotach w ich właściwym zakresie.

6. Dowody zgodności z RODO

W razie kontroli, skargi pacjenta lub sporu lekarz powinien móc wykazać, że przyjął adekwatne środki ochrony danych. W zależności od zakresu jego działalności może to wymagać procedur, analizy ryzyka, ewidencji upoważnień, dokumentowania incydentów oraz weryfikacji dostawców.

3. IOD czy ekspert ds. RODO – kogo powinien wybrać lekarz?

To rozróżnienie ma znaczenie prawne i praktyczne.

Kryterium	IOD	Ekspert ds. RODO
Status	Formalnie wyznaczona funkcja na podstawie art. 37–39 RODO	Doradca lub podmiot świadczący usługi zgodności
Główne zadanie	Informowanie, doradzanie, monitorowanie zgodności i współpraca z organem nadzorczym	Praktyczna pomoc w dokumentacji, analizach, umowach i zabezpieczeniach
Niezależność	Musi być zapewniona zgodnie z art. 38 RODO	Zakres niezależności wynika z umowy i zasad wykonywania usługi
Dokumentacja	Może doradzać i monitorować, ale nie przejmuje odpowiedzialności administratora	Może przygotowywać dokumentację i wspierać wdrożenie rozwiązań
Obowiązek posiadania	Zależy od przesłanek z art. 37 RODO	Nie ma ogólnego obowiązku zatrudniania eksperta
Forma współpracy	Zatrudnienie lub umowa o świadczenie usług; funkcję można powierzyć zewnętrznie	Umowa B2B, abonament lub zlecenie konkretnego zadania

Ważne: lekarz nie ma automatycznego obowiązku wyznaczania własnego IOD tylko dlatego, że pracuje na kontrakcie B2B w szpitalu. Obowiązek trzeba ocenić na podstawie art. 37 RODO, w szczególności tego, czy główna działalność obejmuje przetwarzanie danych o zdrowiu na dużą skalę.
W przypadku indywidualnej praktyki lekarskiej samo przetwarzanie danych pacjentów nie oznacza automatycznie obowiązku wyznaczenia IOD.

Jeżeli lekarz nie ma obowiązku powołania IOD, ale potrzebuje pomocy w realizacji obowiązków RODO, często bardziej adekwatna będzie współpraca z ekspertem ds. RODO, który będzie wspierał go w konkretnych zadaniach.

4. Dlaczego IOD szpitala nie zawsze wystarczy?

IOD szpitala doradza administratorowi danych, którym w typowej sytuacji jest szpital, i monitoruje przestrzeganie przepisów w zakresie jego działalności. Nie oznacza to automatycznie, że zapewnia lekarzowi prowadzącemu działalność B2B pełną obsługę jego własnej działalności gospodarczej.

Przykładowo, lekarz może potrzebować odrębnego wsparcia w zakresie:

• ustalenia, czy w konkretnym procesie działa jako osoba upoważniona przez szpital, odrębny administrator czy podmiot pełniący inną rolę;
• weryfikacji umów zawieranych przez jego praktykę z dostawcami systemów i usług;
• oceny ryzyka korzystania z prywatnych urządzeń, poczty i chmury;
• określenia zasad przechowywania i usuwania dokumentacji;
• przygotowania na wypadek naruszenia ochrony danych;
• oceny, czy dokumentacja i rozwiązania organizacyjne jego własnej praktyki są adekwatne do rzeczywistych procesów.

Nie należy jednak tworzyć dokumentacji ani dublować procedur tylko po to, by formalnie posiadać własny zestaw dokumentów. Zakres wsparcia musi wynikać z faktycznej roli lekarza i rzeczywistych procesów przetwarzania danych.

5. Uzasadnienie biznesowe – dlaczego to się lekarzowi opłaca?

Z punktu widzenia lekarza prowadzącego działalność gospodarczą współpraca z ekspertem ds. RODO może być traktowana jako element zarządzania ryzykiem zawodowym i biznesowym, a nie tylko jako koszt administracyjny.

Potencjalny problem	Wartość wsparcia eksperta
Wyciek danych pacjentów	Pomoc w ocenie naruszenia, dokumentowaniu zdarzenia i ustaleniu obowiązków
Spór ze szpitalem o odpowiedzialność	Analiza podziału ról, umów, uprawnień i obowiązków
Nieprawidłowa umowa z dostawcą IT	Weryfikacja zgodności umowy i zasad przetwarzania danych
Skarga pacjenta lub kontrola UODO	Przygotowanie dokumentacji i wsparcie w odpowiedzi na zarzuty
Zmiana systemu informatycznego lub rozpoczęcie współpracy z nowym podmiotem	Ocena ryzyka przed wdrożeniem
Korzystanie z własnego sprzętu i usług chmurowych	Opracowanie zasad ograniczających ryzyko nieuprawnionego dostępu

Trzeba przy tym pamiętać, że sama umowa z ekspertem ani wyznaczenie IOD nie zwalnia lekarza z odpowiedzialności za jego własne decyzje i działania. Wsparcie specjalisty pomaga jednak właściwie rozpoznać ryzyka, wdrożyć zabezpieczenia i wykazać dochowanie należytej staranności.

6. Uzasadnienie do oferty usług dla lekarzy B2B

Dlaczego lekarz pracujący na kontrakcie B2B powinien mieć własne wsparcie w zakresie RODO?

Kontrakt B2B nie oznacza, że wszystkie obowiązki związane z ochroną danych osobowych przejmuje szpital. Zakres odpowiedzialności lekarza zależy od rzeczywistej roli, jaką pełni w poszczególnych procesach przetwarzania danych.

Lekarz wykonujący działalność gospodarczą funkcjonuje nie tylko jako członek zespołu medycznego, ale również jako przedsiębiorca, który może zawierać własne umowy, korzystać z usług zewnętrznych dostawców i podejmować decyzje dotyczące organizacji swojej praktyki.

Dane pacjentów, w szczególności dane dotyczące zdrowia, wymagają szczególnej ochrony. Błąd w sposobie ich przechowywania, udostępniania lub zabezpieczenia może prowadzić do skarg pacjentów, postępowań przed organem nadzorczym, roszczeń odszkodowawczych i sporów dotyczących odpowiedzialności.

Dlatego warto zapewnić sobie profesjonalne wsparcie IOD lub eksperta ds. RODO, który pomoże ustalić obowiązki lekarza, zweryfikować umowy, ocenić ryzyka, przygotować odpowiednią dokumentację i opracować zasady bezpiecznego korzystania z systemów informatycznych.

Nie chodzi o tworzenie dokumentów dla samej dokumentacji. Chodzi o to, aby lekarz wiedział, za co odpowiada, jakie środki ochrony powinien stosować i jak wykazać, że prawidłowo realizuje obowiązki wynikające z RODO.

RODO w praktyce lekarskiej to nie tylko obowiązek formalny. To również element ochrony zawodowej, bezpieczeństwa pacjentów i stabilności prowadzonej działalności gospodarczej.

Lekarzu – własna praktyka to także własne RODO

 

🩺 LEKARZU – PROWADZISZ WŁASNĄ DZIAŁALNOŚĆ? TWOJE RODO NIE PILNUJE SIĘ SAMO.

Własna praktyka lekarska oznacza nie tylko pacjentów, dokumentację i rozliczenia.

To również odpowiedzialność za dane osobowe i dane dotyczące zdrowia.

I właśnie dlatego warto rozważyć IOD z outsourcingu – nawet wtedy, gdy prowadzisz jednoosobową praktykę.

Dlaczego?

🔴 1. Dane medyczne to dane szczególnej kategorii
Dokumentacja pacjentów, wyniki badań, diagnozy czy informacje o leczeniu wymagają szczególnej ochrony.

🔴 2. Lekarz jest administratorem danych
Korzystanie z programu medycznego, chmury, systemu rejestracji czy usług IT nie oznacza automatycznego przeniesienia odpowiedzialności za RODO na dostawcę.

🔴 3. Jeden błąd może dotyczyć wielu pacjentów
Wyciek z systemu, błędna wiadomość e-mail, niewłaściwie udostępniona dokumentacja czy utrata urządzenia mogą oznaczać naruszenie ochrony danych.

🔴 4. RODO to nie tylko klauzula informacyjna
Potrzebne są m.in. analiza ryzyka, procedury, upoważnienia, umowy powierzenia, zasady retencji, obsługa praw pacjentów i procedura naruszeń.

🔴 5. Technologie zmieniają ryzyko
Elektroniczna dokumentacja, chmura, telemedycyna, AI, systemy rejestracji online, monitoring czy komunikacja z pacjentem tworzą kolejne obszary wymagające kontroli.

🔴 6. IOD daje lekarzowi stałe wsparcie
Nie trzeba za każdym razem szukać prawnika lub firmy „od RODO”, kiedy pojawi się problem.

💡 A co z kosztem?

IOD z outsourcingu nie musi oznaczać dużego stałego wydatku.

Możliwe są dwa modele:

📌 ABONAMENT IOD
Stała miesięczna opłata obejmująca bieżące konsultacje, przegląd dokumentacji, wsparcie przy incydentach, umowach i nowych rozwiązaniach IT.

📌 IOD NA ZLECENIE
Z góry określona, stała stawka za konkretną usługę – np. analizę ryzyka, audyt dokumentacji, analizę umowy z dostawcą systemu, OSOD (DPIA) czy obsługę naruszenia.

To oznacza, że lekarz nie musi tworzyć etatu ani utrzymywać rozbudowanego działu compliance, żeby mieć dostęp do specjalistycznego wsparcia.

Najważniejsze:

IOD nie jest po to, żeby lekarz miał więcej dokumentów.

IOD ma pomóc lekarzowi wiedzieć, jakie dokumenty są rzeczywiście potrzebne, jakie ryzyka występują i co zrobić, kiedy pojawia się problem.

🩺 Prowadzisz praktykę lekarską?

Nie czekaj na incydent, skargę pacjenta albo pytanie UODO.

Outsourcing IOD – abonament lub konkretne zlecenie, ze stałą i przewidywalną stawką.

📩 Napisz, jeśli chcesz sprawdzić, jaki model wsparcia IOD będzie odpowiedni dla Twojej praktyki.

rodoamaj@gmail.com    

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.