Dlaczego wyznaczenie dyrektora IT nie zwalnia zarządu z odpowiedzialności 

W Twojej organizacji temat UKSC może w pierwszej kolejności trafić do dyrektora IT albo osoby odpowiedzialnej za bezpieczeństwo. Taki ruch może być potrzebny operacyjnie, ale nie odpowiada konstrukcji ustawy. Artykuł 8c stanowi, że kierownik podmiotu kluczowego lub ważnego ponosi odpowiedzialność za wykonywanie wskazanych obowiązków z zakresu cyberbezpieczeństwa. Jeżeli kierownikiem jest organ wieloosobowy i nie wskazano osoby odpowiedzialnej, odpowiedzialność ponoszą wszyscy członkowie tego organu. Ustawa dodaje, że odpowiedzialność pozostaje także wtedy, gdy część albo całość obowiązków powierzono innej osobie za jej zgodą. 

Oznacza to, że zarząd powinien stworzyć model nadzoru, a nie tylko wyznaczyć wykonawcę. Ekspert może przygotować analizę ryzyka, polityki i plan reagowania. Dostawca zewnętrzny może monitorować systemy. Pełnomocnik może koordynować projekt. Kierownik nadal musi podejmować decyzje, zapewnić środki, przydzielić zadania i sprawdzać ich wykonanie. Dobrze zaprojektowany model pozwala mu wykonywać tę rolę na podstawie czytelnych raportów, zamiast oczekiwać od niego znajomości konfiguracji technicznej. 

Kto jest kierownikiem podmiotu   

Ustawa posługuje się definicją odsyłającą do kierownika jednostki w rozumieniu przepisów o rachunkowości oraz uwzględniającą szczególne formy organizacyjne. W spółce kapitałowej będzie to co do zasady organ zarządzający. W jednostkach publicznych i innych organizacjach ustalenie wymaga odniesienia do właściwej konstrukcji prawnej. Nie należy automatycznie przypisywać tej roli szefowi IT, administratorowi systemu ani inspektorowi ochrony danych. Są to funkcje merytoryczne, lecz nie muszą być „kierownikiem podmiotu” w rozumieniu UKSC. 

Pierwszym zadaniem prawnym jest więc wskazanie, kto formalnie pełni tę funkcję, czy organ jest jednoosobowy czy wieloosobowy oraz czy wyznaczono osobę odpowiedzialną w ramach organu. Uchwała lub regulamin może uporządkować odpowiedzialność wewnętrzną, jednak nie powinien tworzyć fikcji, że temat całkowicie przestaje dotyczyć pozostałych członków zarządu. W szczególności każdy członek powinien rozumieć status organizacji, podstawowe ryzyka, stan wdrożenia oraz znaczenie decyzji budżetowych. 

Pięć obowiązków kierownika zapisanych wprost 

Artykuł 8d tworzy praktyczną listę zadań. Kierownik podejmuje decyzje dotyczące przygotowania, wdrażania, stosowania, przeglądu i nadzoru systemu zarządzania bezpieczeństwem informacji. Planuje adekwatne środki finansowe. Przydziela zadania i nadzoruje ich wykonanie. Zapewnia świadomość personelu oraz znajomość wewnętrznych regulacji. Zapewnia zgodność działania podmiotu z prawem i regulacjami wewnętrznymi. Każdy z tych obowiązków powinien mieć odzwierciedlenie w dokumentach i praktyce zarządczej. 

Nie chodzi o produkowanie uchwał bez treści. Decyzja dotycząca SZBI powinna opierać się na zakresie usług i systemów, wynikach oceny ryzyka oraz planie działań. Budżet powinien wynikać z konkretnych potrzeb, takich jak monitoring, kopie zapasowe, zarządzanie tożsamością, testy, szkolenia czy bezpieczeństwo dostawców. Przydział zadań wymaga nazwanych właścicieli i zastępstw. Nadzór potrzebuje mierników. Świadomość personelu wymaga działań dopasowanych do ról. Zgodność oznacza regularne sprawdzenie czy praktyka odpowiada przyjętym procedurom. 

Decyzje o SZBI, które powinny trafić na poziom zarządu  

System zarządzania bezpieczeństwem informacji nie sprowadza się do jednego dokumentu. To sposób identyfikowania ryzyka, wyboru środków, reagowania na incydenty, oceny skuteczności i ciągłego doskonalenia. Kierownik powinien zatwierdzić zakres SZBI, kryteria akceptacji ryzyka, role i odpowiedzialności, najważniejsze polityki, plan wdrożenia oraz sposób raportowania. Powinien również otrzymywać informacje o ryzykach przekraczających przyjętą tolerancję i decydować o ich ograniczeniu, unikaniu, przeniesieniu albo świadomej akceptacji. 

Zarząd nie musi zatwierdzać każdej instrukcji technicznej. Powinien natomiast rozstrzygać kwestie, które wpływają na ryzyko biznesowe lub wymagają istotnych nakładów. Przykładem jest brak zapasowego centrum przetwarzania, zależność od jednego dostawcy, niedostateczny czas odtworzenia krytycznej usługi albo konieczność modernizacji systemu, którego producent nie wspiera. Raport techniczny powinien zostać przetłumaczony na wpływ na usługę, klientów, finanse i obowiązki prawne. 

Budżet adekwatny, czyli jaki 

Ustawa nie podaje procentu przychodów, który trzeba przeznaczyć na cyberbezpieczeństwo. Wymaga planowania środków adekwatnych do obowiązków i ryzyka. Budżet powinien więc wynikać z udokumentowanej oceny, a nie z porównania z przypadkową firmą. Organizacja o rozproszonej infrastrukturze, wysokiej zależności od systemów i niskiej tolerancji na przestój będzie potrzebować innego poziomu zabezpieczeń niż podmiot o prostszym modelu. Znaczenie mają także skutki społeczne i gospodarcze zakłócenia usługi. 

W planie finansowym warto oddzielić koszty jednorazowe od stałych. Jednorazowe mogą obejmować analizę luk, uporządkowanie aktywów, wdrożenie narzędzi, testy planów i zmianę umów. Stałe obejmują monitoring, obsługę podatności, szkolenia, utrzymanie kopii, audyty dostawców, ćwiczenia i raportowanie. Zarząd powinien widzieć zależności: obniżenie budżetu na określone działanie zwiększa nazwane ryzyko albo wydłuża termin wdrożenia. Taka informacja umożliwia rzeczywistą decyzję.

Przydział zadań i model trzech linii 

W praktyce sprawdza się rozdzielenie odpowiedzialności wykonawczej, nadzorczej i niezależnej oceny. Pierwsza linia to właściciele usług, systemów i procesów, którzy zarządzają ryzykiem na co dzień. Druga linia, na przykład funkcja bezpieczeństwa, compliance lub ryzyka, ustanawia metodykę, monitoruje i wspiera. Trzecia linia, jeśli istnieje, niezależnie ocenia skuteczność. Model nie musi być rozbudowany. W mniejszej organizacji jedna osoba może pełnić kilka ról, pod warunkiem świadomego zarządzania konfliktami i zapewnienia kontroli. 

Macierz odpowiedzialności powinna obejmować co najmniej kwalifikację i Wykaz KSC, ocenę ryzyka, aktywa, dostępy, podatności, ciągłość działania, dostawców, incydenty, zgłoszenia, szkolenia, kontakt z CSIRT i organami, dokumentację oraz audyt. Dla każdej dziedziny trzeba wskazać osobę odpowiedzialną, wykonawców, konsultowanych i informowanych. Sama nazwa działu nie wystarcza. Należy określić również zastępstwo oraz ścieżkę eskalacji, zwłaszcza dla zdarzeń poza godzinami pracy. 

Raportowanie do zarządu bez zbędnych szczegółów technicznych  

Raport dla kierownika powinien odpowiadać na pytania zarządcze: jakie usługi są zagrożone, które ryzyka przekraczają tolerancję, jakie działania są opóźnione, czy organizacja jest gotowa wykryć i zgłosić incydent, czy kluczowi dostawcy spełniają wymagania oraz jakie decyzje są potrzebne. Lista tysięcy alertów albo podatności bez kontekstu nie pozwala wykonywać nadzoru. Mierniki muszą być powiązane z procesem i trendem. 

Przykładowe mierniki to odsetek krytycznych aktywów objętych monitoringiem, czas usuwania podatności krytycznych, pokrycie uwierzytelnianiem wieloskładnikowym, skuteczność odtworzeń z kopii, liczba przetestowanych planów, odsetek ocenionych dostawców, czas od wykrycia do eskalacji incydentu oraz realizacja szkoleń. Obok liczb powinien znaleźć się komentarz o wpływie na usługę. Zarząd powinien otrzymywać raport regularnie, a nie dopiero po incydencie.

Coroczne szkolenie kierownika 

Artykuł 8e wymaga, aby kierownik podmiotu oraz osoba, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa, raz w roku kalendarzowym odbyli szkolenie. Udział ma być udokumentowany. Program powinien obejmować wykonywanie obowiązków wskazanych w ustawie, a więc nie może ograniczać się do ogólnego kursu o phishingu. Powinien wyjaśniać model odpowiedzialności, zarządzanie ryzykiem, obowiązki incydentowe, nadzór, dokumentację, audyty i sankcje. 

Dobre szkolenie zarządu wykorzystuje scenariusze decyzyjne. Co zrobić, gdy ransomware zatrzymuje usługę? Kto ocenia, czy incydent jest poważny? Jak działa eskalacja w pierwszych godzinach? Kiedy informowani są klienci, CSIRT, organ i inne zainteresowane strony? Jak zarząd podejmuje decyzję o wyłączeniu systemu? Takie ćwiczenie łączy prawo z praktyką i ujawnia braki w procedurze. Protokół, lista obecności i materiały pozwalają wykazać wykonanie obowiązku.

Delegowanie i outsourcing bez utraty kontroli 

Ustawa wprost zamyka prostą drogę do uwolnienia się od odpowiedzialności przez delegowanie. Nie oznacza to, że outsourcing jest niepożądany. Dostawca może zapewnić kompetencje i całodobową obsługę, których organizacja nie zbuduje samodzielnie. Trzeba jednak określić wymagania, uprawnienia, sposób raportowania, dostęp do informacji, czasy reakcji, współpracę przy incydencie, zasady podwykonawstwa, ciągłość oraz możliwość kontroli. Umowa powinna odpowiadać rzeczywistemu modelowi operacyjnemu. 

Kierownik musi otrzymywać wiarygodny obraz wykonania usługi. Raport „wszystko działa” nie jest nadzorem. Potrzebne są mierniki, wyniki testów, informacje o incydentach i podatnościach, status działań naprawczych oraz ryzyka wynikające z łańcucha dostaw. Organizacja powinna zachować zdolność podejmowania decyzji nawet wtedy, gdy znacząca część funkcji bezpieczeństwa została powierzona na zewnątrz. Powinna też mieć plan zmiany dostawcy albo działania w razie jego niedostępności. 

Odpowiedzialność i sankcje 

Nowelizacja przewiduje kary dla podmiotów oraz możliwość nałożenia kary na kierownika za niewykonanie określonych obowiązków, jeżeli przemawia za tym czas, zakres lub charakter naruszenia. Wobec kierownika kara może co do zasady sięgać 300 procent otrzymywanego wynagrodzenia obliczanego według zasad ekwiwalentu urlopowego. Dla kierowników podmiotów publicznych ustawa przewiduje odrębny limit, z wyjątkiem sytuacji wskazanej w przepisie. Kary na podstawie nowych regulacji mogą być po raz pierwszy nakładane po upływie dwóch lat od wejścia ustawy w życie. 

Sankcje nie powinny być jedynym powodem wdrożenia. Znacznie poważniejsze mogą być przerwa w świadczeniu usługi, szkoda po stronie klientów, koszty odtworzenia, odpowiedzialność kontraktowa i utrata zaufania. Kierownik powinien zatem zadbać o poprawną kwalifikację, formalne decyzje dotyczące SZBI, budżet powiązany z ryzykiem, wyznaczenie osób odpowiedzialnych, regularne raporty, ćwiczenia i dokumentowanie działań. 

Minimalny kalendarz nadzorczy 

Co najmniej raz w roku zarząd powinien przeprowadzić formalny przegląd SZBI, odbyć wymagane szkolenie i zatwierdzić plan na kolejny okres. Częściej, na przykład kwartalnie, powinien otrzymywać raport o ryzyku, incydentach, podatnościach, dostawcach, ciągłości i postępie wdrożenia. Po poważnym incydencie, dużej zmianie systemowej, przejęciu albo uruchomieniu nowej usługi potrzebny jest przegląd nadzwyczajny. Terminy te należy wpisać do kalendarza organu, a nie pozostawić wyłącznie w narzędziu zespołu IT. 

Każde posiedzenie powinno kończyć się konkretnym rezultatem: przyjęciem ryzyka, zatwierdzeniem finansowania, poleceniem działania albo odnotowaniem braku decyzji wraz z przyczyną. Protokół nie musi ujawniać wrażliwych szczegółów architektury, ale powinien pokazywać, że kierownik rozumiał problem i świadomie nim zarządził. Szczegółowe materiały techniczne mogą stanowić załączniki o ograniczonym dostępie. 

Jak zarząd powinien rozmawiać o cyberbezpieczeństwie 

Rozmowa z zarządem powinna dotyczyć usług i skutków ich zakłócenia, a nie szczegółów konfiguracji systemów. Zarząd musi wiedzieć, jak długo Twoja organizacja może działać po awarii, którzy dostawcy są niezbędni i jakie decyzje wymagają finansowania. Tak przedstawione informacje pozwalają ocenić ryzyko i wyznaczyć priorytety. 

Jak dokumentować decyzje zarządu 

Protokoły i raporty powinny wskazywać, jakie ryzyko przedstawiono zarządowi, jakie rozwiązanie wybrano, kto odpowiada za jego wykonanie i w jakim terminie ma zakończyć pracę. Jeżeli decyzję odłożono, należy zapisać przyczynę i termin ponownego rozpatrzenia. Taka dokumentacja pokazuje rzeczywisty nadzór, a nie tylko formalne zatwierdzenie dokumentów.

Rola prawnika we wsparciu zarządu 

Prawnik powinien wyjaśnić zarządowi zakres ustawowej odpowiedzialności, zadbać o prawidłowy podział zadań i sprawdzić, czy decyzje znajdują odzwierciedlenie w regulacjach wewnętrznych oraz umowach z dostawcami. Informacje o podatnościach, monitoringu i odtworzeniu systemów muszą jednak pochodzić od osób, które odpowiadają za te obszary na co dzień. 

Rola audytu wewnętrznego 

Audyt wewnętrzny może sprawdzić, czy zarząd otrzymuje pełne informacje, czy przydzielone zadania są wykonywane i czy organizacja potrafi przedstawić dowody działania przyjętych procedur. Nie przejmuje odpowiedzialności za wdrożenie. Daje zarządowi niezależną ocenę tego, czy przyjęty model nadzoru działa w praktyce. 

Zmiany wymagające decyzji zarządu 

Nowa usługa, przejęcie, migracja do chmury, zmiana ważnego dostawcy lub wejście na nowy rynek mogą zmienić status prawny i poziom ryzyka. W Twojej organizacji takie zdarzenia powinny uruchamiać dodatkowy przegląd UKSC oraz decyzję, czy trzeba zmienić zakres SZBI, budżet, podział zadań albo dane w Wykazie KSC. 

Komunikacja z klientami i partnerami 

Klienci i partnerzy mogą pytać o status organizacji, sposób zarządzania bezpieczeństwem i gotowość do obsługi incydentów. Odpowiedzi powinny być wcześniej uzgodnione i zgodne z rzeczywistym stanem wdrożenia. Nie należy składać zapewnień o całkowitym bezpieczeństwie. Wiarygodniejsze są konkretne informacje o nadzorze, testach i działaniach naprawczych.

Wniosek 

UKSC nakłada na zarząd konkretne obowiązki dotyczące cyberbezpieczeństwa. Kierownik nie zastępuje specjalistów, lecz nadaje kierunek, zapewnia zasoby, rozdziela odpowiedzialność i sprawdza wykonanie. Delegowanie jest narzędziem organizacji pracy, nie mechanizmem wyłączenia odpowiedzialności. Im wcześniej zarząd ustali rytm decyzji i raportowania, tym mniej prawdopodobne jest, że projekt utknie pomiędzy prawem, IT, operacjami i finansami. 

Najbardziej dojrzałe podejście nie polega na przedstawianiu zarządowi wyłącznie listy kar. Polega na pokazaniu zależności między bezpieczeństwem a ciągłością konkretnej usługi. Wtedy obowiązki ustawowe stają się częścią zwykłego zarządzania ryzykiem przedsiębiorstwa, a nie jednorazową akcją dokumentacyjną.