Porównanie aplikacji wspierających RODO

rozwiewamy wątpliwości IOD

Tu znajdziesz informacje o kryteriach wyboru programu do RODO.

  • Czy obsługa procesów RODO w chmurze jest lepsza niż w on-premise?

  • Program do RODO w subskrypcji czy w modelu licencyjnym?

  • Aplikacja instalowana na komputerze czy aplikacja webowa?

  • Który rodzaj bazy danych zastosować do wsparcia procesów RODO?

  • Aplikacja autonomiczna (samodzielna) wspierająca procesy wymagane przez Rozporządzenie o Ochronie Danych Osobowych czy moduł RODO wbudowany do innej aplikacji?

Co zmienia RODO w ochronie danych?

RODO zmieniło podejście do ochrony danych. W Ustawie z 29 sierpnia 1997 r. o ochronie danych osobowych była to kategoria zbiorów danych. Natomiast nowa ustawa skupiła się na działaniach opartych o procesy przetwarzania danych osobowych. Co oznacza, że bazuje ona na zespole następujących po sobie czynności dotyczących danych – począwszy od zebrania danych osobowych aż do ich usunięcia. Teoretycznie wydawać się może, że wymagane rejestry zbiorów danych na podstawie UODO mogą być rejestrami czynności przetwarzania danych wg RODO. Niestety, rejestry te nie są tożsame. A dodatkowo nie ma prostego przełożenia z rejestru zbiorów danych na rejestr czynności przetwarzania danych (RCP). Przyczyna jest jedna – powinien on być rozbudowany o wszystkie procesy przetwarzania danych osobowych, które zachodzą u danego administratora danych osobowych. Analiza ryzyka, której dotychczas dokonywano w odniesieniu do zasobów, w RODO dotyczy procesów przetwarzania danych jako całości. Przykładowo są to czynności w rejestrze czynności przetwarzania czy rejestrze kategorii.

Który program do RODO najlepiej wybrać?

Zaczynając przygodę z projektowaniem systemu wspierającego procesy wymagane Rozporządzeniem (RODO) długo analizowaliśmy, w jakim systemie powinna ma być osadzona funkcjonalność RODO. Czy ma to być system wsparcia technicznego (helpdesk/serwisdesk) lub system zarządzania infrastrukturą IT? A może system klasy DLP (Data Loss Prevention) lub też autonomiczna aplikacja? Z otoczenia docierały do nas sygnały, że wbudowanie (lub też zintegrowanie) funkcjonalności wymaganej RODO do istniejącego już systemu jest najlepszym rozwiązaniem. RODO znalazło się w systemach CRM, FK, sprzedaży, aplikacjach helpdesk, systemach zarządzania infrastrukturą IT. Również – nieco ironicznie – w macierzach dyskowych, programach szyfrujących, a nawet szafach do przechowywania dokumentów. Praktyka pokazała, że do dedykowanych zadań (np. prowadzenie rejestrów wymaganych RODO, ewidencji i generacji upoważnień do przetwarzania danych, ewidencji incydentów itp.) sprawdzi się dedykowana aplikacja. A co za tym idzie – aplikacja niezależna od platformy, środowiska, innych aplikacji (a więc innych dostawców). Chodziło o aplikację otwartą, gotową na integrację z innymi systemami (np. CRM, FK, sprzedaż), bądź zbiorami danych (np. rejestr zgód).

Jeden inspektor, wiele podmiotów

Inną kategorią jest praca jednego IOD na rzecz wielu podmiotów. Ostatnie badania rynku (np. gmin, szkół, przedszkoli, mniejszych firm) pokazały, że jeden zewnętrzny IOD obsługuje często wiele podmiotów. W tym wypadku autonomiczna aplikacja z separacją danych, ale jednocześnie możliwością eksportu / importu danych pomiędzy poszczególnymi profilami (komplety danych) wydaje się jedynym, rozsądnym rozwiązaniem.

Wędka RODO?

Podmioty (w większości to producenci oprogramowania i sprzętu IT) reklamujący swoje produkty nie rozróżniają (albo nie chcą) oprogramowania wspierającego procesy wymagane Rozporządzeniem od systemów, w których zaimplementowano odpowiednie funkcjonalności. Oczywiście – funkcjonalności wymagane od tych systemów przez Rozporządzenie.

Poprzez przykładowe procesy – wymagane przez RODO – rozumiemy:

  • prowadzenie bieżących rekrutacji,
  • wykorzystywanie dokumentów aplikacyjnych kandydatów do pracy w przyszłych rekrutacjach,
  • przetwarzanie danych w ramach ZFŚS,
  • korzystanie przez pracowników z dodatkowych benefitów (kart sportowych, ubezpieczenia, opieki medycznej),
  • wykorzystywanie wizerunku pracowników,
  • monitorowanie aktywności pracowników w środowisku IT,
  • czynności związane z realizacją zawartych umów z kontrahentami,
  • obsługę reklamacji itp.

Literatura, wytyczne, interpretacje posługują się powszechnie pojęciem procesów w RODO.

W chmurze (cloud) czy on-premise?

Logika i postęp technologiczny nakazują architekturę chmurową (cloud) – czyli tak naprawdę model aplikacji w formie usługi. Łatwo i szybko taką usługę uruchomić (wystarczy rejestracja konta), co ma wpływ również na korzystną cenę. Dodatkową zaletą jest skalowalność ilościowa (można w krótkim czasie produkt uruchomić w wielu podmiotach).

Dokładna analiza potrzeb potencjalnych Klientów pokazała, że w zakresie funkcjonalności wymaganych przez RODO dane umiejscowione w chmurze nie wchodzą w grę. Wynik naszego badania pokazał, że 98% respondentów chce mieć system zainstalowany na swoich urządzeniach / w swojej infrastrukturze.

Preferencje zakupowe a decyzja o zakupie?

Dane znajdujące się w systemie wspierającym procesy RODO zawierają:

  • dane osobowe pracowników (często z podstawą i okresem zatrudnienia),
  • strukturę organizacyjną,
  • rejestr zbiorów i procesów na tych zbiorach,
  • rejestr zabezpieczeń, integrację z innymi systemami i bazami danych,
  • listę innych podmiotów przetwarzających dane (procesor),
  • rejestr incydentów z pełną historią obsługi,
  • często również analizę ryzyka oraz ocenę skutków przetwarzania.

Wg IOD są to wystarczające powody do przetrzymywania danych w swojej infrastrukturze. Czy to się może zmienić? TAK, z czasem wiele mniejszych podmiotów przeniesie dane z tego typu systemów do chmury. Dlaczego? Z prostej przyczyny – tak będzie wygodniej, taniej, uniwersalniej. Będą to zwłaszcza te podmioty, w których liczba procesów w rejestrach nie jest duża, liczba upoważnionych znikoma, incydenty sporadyczne. A dodatkowo – ryzyko naruszenia danych osobowych niewielkie. Jednak duże podmioty zdecydowanie pozostawią ten obszar w swoich infrastrukturach.

RODOsubskrypcja czy RODOlicencja?

Coraz częściej stosowaną metodą dostarczania (udostępniania) oprogramowania są subskrypcje. W Polsce przyzwyczaili ich do nas producenci programów antywirusowych, oferują je m.in.: Microsoft, Adobe, Autodesk, Corel. Polskie podmioty wciąż preferują licencje, mimo iż przez ostatnie 3 lata obserwujemy zdecydowaną zmianę w tym podejściu. Kluczowa różnica pomiędzy licencją a subskrypcją polega na tym, że w subskrypcji po jej zakończeniu (zazwyczaj po upływie jeszcze dodatkowego okresu, trwającego od 1 do 3 miesięcy od dnia wygaśnięcia) tracimy prawo korzystania z oprogramowania. Dane oczywiście można wyeksportować i przenieść do innego systemu, czy też nawet w skrajnym przypadku do arkusza xls.

Model subskrypcji wydaje się obecnie najbardziej optymalnym rozwiązaniem – zarówno dla Producenta, jak i dla użytkowników końcowych. Z uwagi na implementacje niezbędnych zmian w oprogramowaniu w ciągu najbliższych lat, w tym zmian w podejściu merytorycznym, jak i technologicznym. Jest to model stosunkowo elastyczny i skalowalny. A dodatkowo – gwarantujący użytkownikom bardzo stabilne i sprawdzone wersje oprogramowania. A jednocześnie zapewnia Producentowi środki do jego utrzymania i rozwoju.

Większe podmioty, gdzie liczba administratorów sięga kilkuset mogą wymagać (i obecnie już wymagają) jednak modelu licencyjnego.

Aplikacja tradycyjna czy aplikacja WEB?

O tyle, o ile dla większości Klientów technologia aplikacji nie jest aż tak istotna, to jednak aplikacja webowa jest rozwiązaniem przyszłościowym. Jest to model wysoce elastyczny pod względem skalowalności i użytkowania. Dodatkowo – pracuje na każdym komputerze wyposażonym w przeglądarkę internetową i nie wymaga instalacji żadnych dodatkowych komponentów. A co najważniejsze – zapewnia funkcjonalność typowej aplikacji. W skrajnym przypadku kompletną aplikację webową można zainstalować na jednym przenośnym komputerze. Aplikacje tradycyjne (instalowalne) są bardzo zależne od środowiska, w którym pracują, tj. systemu operacyjnego, bibliotek, programów innych producentów czy aktualizacji. Te wszystkie elementy sprawiają, że liczba błędów zazwyczaj jest większa niż w systemie w technologii webowej. Występują też trudności w jednoczesnej aktualizacji oprogramowania na wielu komputerach odwołujących się do wspólnej bazy danych, które niekoniecznie muszą być w momencie aktualizacji dostępne. W przypadku rozwiązania webowego aktualizacja następuje wyłącznie po stronie serwera webowego i bazy danych. Użytkownicy otrzymują niezwłoczny dostęp z poziomu przeglądarki do nowej wersji.

Wybór bazy danych – komercyjna czy bezpłatna?

Ilość danych w podstawowych rejestrach (czynności przetwarzania, procesora, żądań podmiotów danych, incydentów, upoważnień) duża nie jest (w porównaniu do innych systemów). Teoretycznie bazę danych mógłby stanowić nawet plik xml, txt, xls czy mdb (MS Access). Jednak dodając do tego wymóg dostępności, współdzielenia i bezpieczeństwa, dobrym wyborem wydaje się komercyjny MS SQL Server lub Oracle. Ewentualnie bazy bezpłatne – MS SQL Server w wersji Express Edition, MySQL, PostgreSQL.

Ważnym aspektem jest licencjonowanie bazy danych. W przypadku korzystania z aplikacji przez większą liczbę użytkowników (np. IOD oraz pracownicy przeglądający dostępy / uprawnienia do danych, składający wnioski o dostępy na drodze korzystania z aplikacji) wybór komercyjnego silnika SQL wydaje się stosunkowo drogim rozwiązaniem. Oczywiście, wyjątkiem jest sytuacja, gdy podmiot/firma posiada licencję procesorową (per processor lub per core) bazy danych.