Jak podejście procesowe do rejestru czynności przetwarzania może stać się podstawą skutecznego zarządzania dostępem?

W wielu organizacjach rejestr czynności przetwarzania, upoważnienia do przetwarzania danych osobowych i uprawnienia w systemach informatycznych nadal funkcjonują jako trzy odrębne światy. Jeden prowadzi dział ochrony danych, drugi kadry albo administracja, a trzeci dział IT. Problem polega na tym, że z punktu widzenia bezpieczeństwa informacji i rozliczalności taki podział bardzo często tworzy luki: pracownik ma dostęp do aplikacji, ale nie wiadomo, z jakiej czynności przetwarzania to wynika; albo odwrotnie, posiada formalne upoważnienie, lecz nie przekłada się ono na realnie nadane uprawnienia w systemach.

Tymczasem RODO daje podstawę do zbudowania modelu znacznie bardziej spójnego. Art. 30 RODO nakłada na administratora obowiązek prowadzenia rejestru czynności przetwarzania, a Europejska Rada Ochrony Danych opisuje ten rejestr jako „inwentarz wszystkich operacji przetwarzania”, który ma obejmować: cel przetwarzania, kategorie danych, odbiorców, okres przechowywania i ogólny opis środków bezpieczeństwa. Z kolei z art. 29 oraz art. 32 ust. 4 RODO wynika, że osoba działająca z upoważnienia administratora i mająca dostęp do danych może przetwarzać je wyłącznie na polecenie administratora.

Kluczowe jest to, jak rozumieć samą „czynność przetwarzania”. W oficjalnych wyjaśnieniach Prezesa UODO wskazano, że na potrzeby art. 30 RODO nie trzeba opisywać każdej pojedynczej operacji technicznej. „Czynność przetwarzania” można ujmować zbiorczo jako zespół powiązanych operacji wykonywanych dla określonego celu. UODO podaje wprost przykłady takie jak „rekrutacja pracowników” czy „obsługa umów sprzedaży”, bez potrzeby rozbijania ich na dziesiątki atomowych kroków. To bardzo mocny argument za tym, aby w praktyce utożsamić czynność przetwarzania z procesem realizowanym w organizacji.

W takim ujęciu lista procesów może jednocześnie pełnić funkcję rejestru czynności przetwarzania, ale pod jednym warunkiem: każdy proces musi zawierać komplet informacji wymaganych przez art. 30 RODO. To oznacza, że prawidłowo zdefiniowany proces może być jednocześnie rekordem w RCP, a nie wyłącznie opisem biznesowym.

W praktyce daje to bardzo ważną korzyść: proces przestaje być abstrakcyjnym bytem organizacyjnym, a staje się punktem powiązania między celem przetwarzania, danymi osobowymi, ludźmi i zasobami. Skoro do realizacji procesu potrzebne są określone zasoby, to jednym z naturalnych atrybutów procesu stają się systemy informatyczne, z których korzystają pracownicy biorący udział w jego realizacji. UODO wprost dopuszcza uwzględnianie w rejestrze nazwy systemu lub oprogramowania. Jednocześnie  zgodnie z KSC identyfikując zakres SZBI należy analizować procesy świadczenia usług i wskazywać systemy informacyjne używane w procesach mających wpływ na świadczenie tych usług.

Na tej podstawie można uporządkować także sam mechanizm upoważnień. RODO nie narzuca jednej, sformalizowanej papierowej formy upoważnienia. UODO wyjaśnia jednak, że administrator musi mieć realną kontrolę nad tym, kto, w jakim zakresie oraz na jakich zasadach ma dostęp do danych i jak je przetwarza. Urząd podkreśla też, że wydawanie upoważnień może być jednym z organizacyjnych środków zapewnienia tej kontroli, a na podstawie wydanych upoważnień stosuje się następnie mechanizmy kontroli dostępu w systemach informatycznych. Innymi słowy: upoważnienie nie jest celem samym w sobie, ale punktem wyjścia do prawidłowego nadania uprawnień.

W modelu procesowym zakres upoważnienia pracownika można więc zdefiniować jako listę procesów, w których dana osoba uczestniczy i w ramach których ma prawo przetwarzać dane osobowe. To nie jest literalny zapis z RODO, lecz bardzo logiczny model wynikający z połączenia trzech elementów: po pierwsze, czynność przetwarzania może być ujmowana jako proces; po drugie, proces może być powiązany z konkretnymi systemami; po trzecie, upoważnienie jest podstawą do zastosowania mechanizmów kontroli dostępu. Dzięki temu z jednego źródła można wyprowadzić dla pracownika listę aplikacji, do których potencjalnie może otrzymać dostęp.

Taki model działa również w drugą stronę. Jeżeli składany jest wniosek o dostęp do systemu informatycznego dla pracownika, to uzasadnieniem nie powinno być ogólne stwierdzenie „bo jest zatrudniony w dziale X”, lecz wskazanie procesu, w którym ten pracownik uczestniczy. Wówczas etap akceptacji nie musi polegać wyłącznie na zgodzie przełożonego, ale na weryfikacji dwóch warunków: czy dany system jest rzeczywiście powiązany z tym procesem oraz czy zakres upoważnienia pracownika obejmuje ten proces. Taka logika bardzo dobrze wpisuje się w zasadę ograniczania dostępu do zakresu niezbędnego do wykonywania zadań, co koresponduje zarówno z podejściem UODO do kontroli dostępu, jak i z podejściem ISO do restrykcji dostępu i zasady najmniejszych uprawnień.

Bardzo mocne wsparcie dla takiego podejścia daje KRI, oczywiście w odniesieniu do podmiotów realizujących zadania publiczne. Rozporządzenie w sprawie Krajowych Ram Interoperacyjności w § 19 ust. 1 nakazuje opracować, wdrożyć, monitorować, przeglądać, utrzymywać i doskonalić system zarządzania bezpieczeństwem informacji. Natomiast w § 19 ust. 2 pkt 4 i 5, wymagają, aby osoby zaangażowane w proces przetwarzania informacji posiadały stosowne uprawnienia i uczestniczyły w tym procesie w stopniu adekwatnym do realizowanych zadań, a przy zmianie zadań następowała bezzwłoczna zmiana uprawnień.

Podsumowując: rejestr czynności przetwarzania nie powinien być odrębną „tabelą RODO”, a upoważnienie nie powinno być odrębnym „papierem kadrowym”. Oba te elementy warto osadzić w procesach organizacyjnych. Jeżeli proces jest jednocześnie czynnością przetwarzania, proces jest powiązany z systemami, a upoważnienie pracownika wskazuje procesy, w których uczestniczy, to organizacja zyskuje pełną ścieżkę rozliczalności: od celu przetwarzania, przez człowieka, aż po konkretną aplikację i konkretny dostęp. To właśnie w takim modelu zgodność z RODO zaczyna realnie wspierać bezpieczeństwo informacji, a zarządzanie dostępem przestaje być oderwaną od biznesu czynnością administracyjną.