Co powinno obejmować szkolenie dla kierowników podmiotów kluczowych i ważnych zgodne z art. 8e KSC?

Dlaczego zakres szkolenia z art. 8e KSC jest krytyczny dla zgodności

Sama nazwa „szkolenie zgodne z art. 8e KSC” ani certyfikat uczestnictwa nie przesądzają o spełnieniu wymagań prawnych. Znaczenie ma przede wszystkim to, czy zakres zajęć odpowiada właściwym przepisom ustawy o krajowym systemie cyberbezpieczeństwa i przygotowuje kierownictwo do wykonywania jego obowiązków. Dlatego ocenę programu należy rozpocząć od ustalenia aktualnego brzmienia regulacji, terminów ich stosowania oraz tego, jakie obowiązki dotyczą danego podmiotu i osób nim kierujących.

Szkolenie dla kierowników podmiotów kluczowych i ważnych ma inny cel niż ogólne szkolenie pracowników z cyberhigieny. Rozpoznawanie phishingu czy bezpieczne korzystanie z poczty są przydatne, ale nie zastępują kompetencji zarządczych. Kierownictwo potrzebuje wiedzy pozwalającej rozumieć ryzyko, oceniać znaczenie proponowanych zabezpieczeń i skutki zakłóceń dla działalności organizacji. Nie chodzi o przygotowanie menedżera do pracy administratora systemów, lecz do świadomego podejmowania decyzji dotyczących cyberbezpieczeństwa.

Program powinien więc łączyć perspektywę prawną, organizacyjną i techniczną. Na poziomie wprowadzającym oznacza to powiązanie zarządzania ryzykiem i bezpieczeństwa systemów z reagowaniem na incydenty, obowiązkami organizacyjnymi, nadzorem oraz odpowiedzialnością kierownictwa. Sam przegląd przepisów nie pokazuje, jak wykorzystać je w zarządzaniu. Z kolei prezentacja zagrożeń technologicznych bez odniesienia do obowiązków decydentów nie daje wystarczającej podstawy do oceny, czy organizacja postępuje właściwie.

Przy zamawianiu szkolenia należy wyraźnie oddzielić zakres wynikający z przepisów od rekomendowanego rozszerzenia programu. Pierwszy wymaga odniesienia do konkretnych obowiązków ustawowych. Drugi powinien uwzględniać sektor, skalę działalności, zależność od usług cyfrowych oraz poziom wiedzy uczestników. Dostosowanie treści do organizacji zwiększa ich użyteczność, ale nie może prowadzić do pominięcia wymaganych zagadnień. Jednocześnie nie należy przedstawiać każdej dobrej praktyki szkoleniowej jako obowiązku prawnego.

Z perspektywy wykazywania zgodności rekomendujemy zachowanie programu z opisem omawianych zagadnień, materiałów oraz potwierdzeń udziału. Taka dokumentacja pomaga ustalić, czego dotyczyło szkolenie i kto je odbył; sam tytuł wydarzenia dostarcza znacznie mniej informacji. Ukończenie szkolenia pozostaje jednak tylko jednym z elementów zgodności — nie zastępuje wdrożenia wymaganych rozwiązań ani rzeczywistego wykonywania obowiązków przez kierownictwo.

Zarządzanie ryzykiem cyberbezpieczeństwa: metody, role i decyzje kierownictwa

Szkolenie dla kierowników podmiotów kluczowych i ważnych powinno przygotowywać do oceny, jak zagrożenia cyberbezpieczeństwa wpływają na realizację zadań organizacji i świadczenie jej usług. Nie chodzi o samodzielne wykonywanie analiz technicznych, lecz o rozumienie ich wyników, weryfikowanie założeń i podejmowanie uzasadnionych decyzji. Rekomendowanym minimum dydaktycznym w tym module jest rozróżnianie podstawowych pojęć, znajomość przebiegu oceny ryzyka oraz rozumienie podziału ról przy wyborze sposobu postępowania z ryzykiem.

Punktem wyjścia jest odróżnienie zagrożenia, podatności i ryzyka. Zagrożeniem może być atak wykorzystujący przejęte dane logowania, a podatnością — niewystarczające zabezpieczenie dostępu. Ryzyko opisuje możliwe konsekwencje takiego scenariusza, z uwzględnieniem prawdopodobieństwa jego wystąpienia. Dla kierownictwa istotne są nie tylko straty finansowe, lecz także zakłócenia usług, skutki dla ich odbiorców, naruszenia poufności informacji oraz konsekwencje prawne. Sama techniczna ocena podatności nie przesądza więc o priorytecie biznesowym.

Uczestnicy powinni poznać podstawową logikę procesu: ustalenie kontekstu i zakresu, identyfikację ryzyk, analizę ich prawdopodobieństwa i skutków oraz porównanie wyników z przyjętymi kryteriami akceptacji. Analiza powinna obejmować kluczowe usługi, wspierające je zasoby i zależności od dostawców. Metoda jakościowa wykorzystuje opisane poziomy, np. niski, średni i wysoki; metoda ilościowa opiera się na oszacowaniach liczbowych, np. częstotliwości zdarzeń i wartości strat. W obu przypadkach znaczenie mają jakość danych, spójność kryteriów i jawne wskazanie niepewności. Kolor w macierzy ryzyka nie zastępuje uzasadnienia oceny.

Jako punkt odniesienia dla metodyki można przedstawić ISO/IEC 27005, dotyczące zarządzania ryzykiem bezpieczeństwa informacji, oraz ogólne wytyczne ISO 31000. Ich omówienie jest rekomendacją programową, a nie wskazaniem, że art. 8e KSC narzuca konkretną normę. Na poziomie menedżerskim ważniejsza od znajomości szczegółów standardu jest umiejętność ustalenia, czy stosowana metoda pozwala porównywać ryzyka i racjonalnie ustalać priorytety.

Podział ról powinien wyraźnie odróżniać wsparcie eksperckie od odpowiedzialności za ryzyko. Specjaliści IT i cyberbezpieczeństwa dostarczają danych oraz proponują zabezpieczenia. Właściciele procesów określają skutki dla działalności. Właściciel ryzyka odpowiada za zarządzanie przypisanym ryzykiem w granicach swoich uprawnień, natomiast kierownictwo rozstrzyga kwestie priorytetów i zasobów zgodnie z przyjętym podziałem kompetencji. Nie należy automatycznie przypisywać wszystkich ryzyk działowi IT.

Szkolenie powinno również wyjaśniać cztery podstawowe sposoby postępowania z ryzykiem: jego ograniczenie, unikanie, dzielenie z inną stroną oraz akceptację. Kluczowe jest pojęcie ryzyka rezydualnego, czyli pozostającego po zastosowaniu zabezpieczeń. Decyzja o jego przyjęciu powinna mieć uzasadnienie, wskazaną osobę uprawnioną do akceptacji oraz warunki ponownej oceny. Ani ubezpieczenie, ani zlecenie usługi dostawcy nie eliminują wszystkich skutków ryzyka, a jego akceptacja nie zastępuje wykonania obowiązków prawnych.

Rekomendowane rozszerzenie obejmuje porównywanie wariantów decyzji: kosztu i czasu wdrożenia zabezpieczeń, oczekiwanej redukcji ryzyka oraz skutków odroczenia działań. Menedżer powinien umieć zapytać nie tylko „ile kosztuje zabezpieczenie?”, lecz przede wszystkim „jakie ryzyko pozostanie i czy organizacja może je zaakceptować?”.

Bezpieczeństwo systemów i ciągłość działania: co menedżer musi rozumieć

Kierownik podmiotu kluczowego lub ważnego nie musi znać konfiguracji zabezpieczeń, powinien jednak rozumieć, jak ich skuteczność wpływa na zdolność organizacji do świadczenia usług. W tej części szkolenia należy połączyć podstawy ochrony systemów z konsekwencjami operacyjnymi: niedostępnością usługi, utratą danych lub wykorzystaniem informacji, których poprawności nie można potwierdzić.

Punktem wyjścia są trzy właściwości bezpieczeństwa informacji: poufność, czyli dostęp wyłącznie dla uprawnionych osób i systemów; integralność, czyli ochrona przed nieuprawnioną zmianą lub zniszczeniem; oraz dostępność, czyli możliwość korzystania z informacji i systemów wtedy, gdy są potrzebne. Menedżer powinien rozumieć, że działająca aplikacja nie oznacza jeszcze bezpiecznej usługi — może przetwarzać zmienione dane albo udostępniać je osobom nieuprawnionym.

Jako podstawowy zakres dydaktyczny rekomendujemy omówienie trzech grup zabezpieczeń, bez wchodzenia w instrukcje ich konfiguracji:

• Ochrona dostępu i danych — nadawanie wyłącznie uprawnień niezbędnych do pracy, uwierzytelnianie wieloskładnikowe (MFA), szczególna ochrona kont administracyjnych oraz szyfrowanie. Uczestnik powinien rozumieć, przed czym chroni każde z tych rozwiązań i dlaczego nie zastępują się wzajemnie.
• Utrzymanie bezpieczeństwa systemów — aktualizacje, usuwanie podatności, bezpieczna konfiguracja oraz segmentacja sieci, która ogranicza możliwość rozprzestrzeniania się zagrożeń. Istotne jest również znaczenie wsparcia producenta dla używanego oprogramowania i urządzeń.
• Odporność i odtwarzanie — kopie zapasowe, rozwiązania zapasowe oraz testy przywracania. Należy wyjaśnić, że redundancja ogranicza skutki awarii, ale nie zastępuje backupu: błędne lub zaszyfrowane dane mogą zostać powielone także w systemie zapasowym.

Ciągłość działania jest pojęciem szerszym niż odtworzenie infrastruktury IT. Plan ciągłości działania (BCP) dotyczy utrzymania najważniejszych procesów, także w trybie zastępczym. Plan odtwarzania po awarii (DRP) koncentruje się na przywróceniu systemów i danych. Podstawą ustalania priorytetów jest analiza wpływu zakłóceń na działalność (BIA), wskazująca skutki przestoju oraz zależności od ludzi, technologii i dostawców.

Na poziomie zarządczym konieczne jest rozróżnienie RTO — docelowego czasu przywrócenia działania — i RPO — dopuszczalnej utraty danych wyrażonej w czasie. Przykładowo RTO wynoszące cztery godziny i RPO wynoszące godzinę oznaczają dwa odrębne cele: przywrócenie działania w ciągu czterech godzin oraz możliwość odtworzenia danych do punktu nie starszego niż godzina przed zakłóceniem. Nie są to gwarancje wynikające z samego posiadania kopii zapasowych.

Rekomendowanym rozszerzeniem jest omówienie zależności usługi od zasilania, łączności, usług chmurowych i systemów zewnętrznych. Udany zapis kopii nie potwierdza jeszcze możliwości wznowienia pracy: potrzebne są testy odtwarzania, uwzględniające kompletność danych i działanie powiązanych systemów. Menedżer powinien umieć odróżnić deklarowany czas przywrócenia usługi od czasu potwierdzonego w takim teście.

4. Reagowanie na incydenty: proces, odpowiedzialności i komunikacja kryzysowa

W części szkolenia poświęconej reagowaniu na incydenty kierownik powinien poznać przede wszystkim zasady podejmowania decyzji przy niepełnej informacji i pod presją czasu. Nie chodzi o samodzielną analizę złośliwego oprogramowania, lecz o rozumienie sytuacji: jakie usługi są zagrożone, jakie skutki może mieć zwłoka i kto jest uprawniony do uruchomienia działań ograniczających szkody. Rekomendowany zakres podstawowy obejmuje przebieg obsługi incydentu, podział ról oraz zasady zgłoszeń i komunikacji.

Punktem wyjścia jest rozróżnienie sygnału ostrzegawczego, incydentu bezpieczeństwa i sytuacji wymagającej uruchomienia zarządzania kryzysowego. Nie każdy alert oznacza potwierdzony incydent, a nie każdy incydent wymaga zaangażowania całego kierownictwa. Szkolenie powinno wyjaśniać kryteria eskalacji, czyli przekazania sprawy na odpowiedni poziom decyzyjny. Znaczenie mają zwłaszcza wpływ na świadczenie usług, zakres dotkniętych systemów i danych, możliwe konsekwencje dla odbiorców oraz tempo rozprzestrzeniania się zagrożenia.

Proces reagowania należy przedstawić jako uporządkowany ciąg działań: wykrycie i wstępna ocena, ograniczenie skutków, usunięcie przyczyny, bezpieczne przywrócenie działania oraz analiza wniosków. Poszczególne działania mogą przebiegać równolegle. Kierownik powinien rozumieć, dlaczego odłączenie systemu może być konieczne mimo kosztów operacyjnych oraz dlaczego przywrócenie usługi nie zawsze oznacza zakończenie incydentu. Ważne jest również zabezpieczanie dowodów i dokumentowanie chronologii działań, ustaleń oraz decyzji.

Podział odpowiedzialności warto omawiać na przykładzie współpracy koordynatora incydentu, zespołu technicznego, właściciela dotkniętej usługi, obsługi prawnej i osób odpowiedzialnych za komunikację. Zespół techniczny ustala fakty i rekomenduje działania, natomiast kierownictwo rozstrzyga kwestie wymagające decyzji biznesowych zgodnie z przyjętymi uprawnieniami. Uczestnik powinien wiedzieć, kto może zatwierdzić ograniczenie dostępności usługi, uruchomić wsparcie zewnętrzne i zaakceptować komunikat. Trzeba także omówić zastępstwa oraz sposób kontaktu poza godzinami pracy.

Odrębnym zagadnieniem są zgłoszenia do właściwych podmiotów i organów. Program powinien wskazywać, kto ocenia obowiązek zgłoszenia, kto je przygotowuje i wysyła oraz od jakiego zdarzenia liczy się właściwy termin. Kryteria, adresatów i terminy należy przedstawić według przepisów obowiązujących dany podmiot. Warto wyraźnie odróżnić zgłoszenie incydentu w reżimie KSC od ewentualnego zgłoszenia naruszenia ochrony danych osobowych na podstawie RODO — jedno nie zastępuje drugiego. Pełna analiza techniczna nie powinna być traktowana jako warunek rozpoczęcia oceny obowiązków zgłoszeniowych.

Komunikacja kryzysowa wymaga uzgodnionego źródła informacji, wskazanych osób zatwierdzających przekaz i kanałów zastępczych na wypadek niedostępności poczty lub komunikatora. Komunikaty dla pracowników, odbiorców usług i partnerów powinny oddzielać potwierdzone fakty od ustaleń w toku, opisywać podejmowane działania oraz wskazywać termin kolejnej aktualizacji. Należy unikać zarówno niepotwierdzonych zapewnień o bezpieczeństwie, jak i ujawniania szczegółów, które mogłyby utrudnić opanowanie incydentu. Kierownik powinien umieć ocenić, czy przekaz jest rzetelny, spójny i użyteczny dla jego odbiorców.

Obowiązki organizacyjne i nadzór: polityki, KPI, przeglądy i raportowanie

Przyjęcie polityki cyberbezpieczeństwa nie jest jeszcze dowodem jej skutecznego stosowania. Szkolenie dla kierowników podmiotów kluczowych i ważnych powinno wyjaśniać, jak powiązać dokumentację z codziennym działaniem organizacji oraz jakich informacji potrzebuje kierownictwo, aby oceniać stan zabezpieczeń. W tym obszarze rekomendujemy omówienie czterech elementów: zasad wewnętrznych, mierników, przeglądów oraz raportowania zarządczego. To praktyczny zakres dydaktyczny — nie zamknięty katalog wymagań wynikających z samego art. 8e KSC.

Polityki i procedury: od zasad do sposobu wykonania. Uczestnicy powinni rozumieć różnicę między polityką, która określa cele i zasady postępowania, a procedurą opisującą realizację konkretnych czynności. Na poziomie wprowadzającym wystarczy pokazać, jak dokumentacja porządkuje m.in. zarządzanie dostępem, zmiany w systemach czy współpracę z dostawcami. Istotne są także zasady nadzoru nad dokumentami: wskazanie osoby odpowiedzialnej za aktualizację, trybu zatwierdzania, wersjonowania oraz udostępniania właściwym pracownikom. Sama obecność dokumentu w repozytorium nie potwierdza, że jego wymagania są znane i stosowane.

KPI: pomiar wykonania i skuteczności. Kluczowe wskaźniki efektywności powinny odpowiadać na konkretne pytania zarządcze, a nie jedynie prezentować liczbę wykonanych zadań. Warto również odróżnić KPI od wskaźników ryzyka, które sygnalizują wzrost ekspozycji na zagrożenia. Przykładowe mierniki przydatne do omówienia podczas szkolenia to:

• Odsetek przeglądów uprawnień zakończonych w terminie — w odniesieniu do wszystkich przeglądów zaplanowanych na dany okres.
• Odsetek działań naprawczych zamkniętych terminowo — z uwzględnieniem wagi ustaleń oraz potwierdzenia skuteczności wdrożonych zmian.
• Odsetek polityk poddanych przeglądowi zgodnie z harmonogramem — uzupełniony informacją o dokumentach wymagających istotnej aktualizacji.

Każdy wskaźnik powinien mieć jednoznaczną definicję, źródło danych, osobę odpowiedzialną za pomiar i próg wymagający reakcji. Szkolenie powinno uwrażliwiać na ograniczenia danych: wysoki wynik dla całej organizacji może ukrywać zaległości w obszarze krytycznym. Dobry wynik KPI nie jest sam w sobie potwierdzeniem zgodności z KSC ani skuteczności wszystkich zabezpieczeń.

Przeglądy: ocena aktualności i adekwatności. Przegląd zarządczy służy ocenie, czy przyjęte rozwiązania nadal odpowiadają potrzebom organizacji. Nie jest tożsamy z audytem, który opiera się na systematycznej ocenie dowodów względem określonych kryteriów. Rekomendujemy omówienie przeglądów planowych oraz uruchamianych po istotnych zmianach organizacyjnych lub technologicznych. Częstotliwość należy dopasować do ryzyka i mających zastosowanie wymagań; nie należy przedstawiać przykładowego harmonogramu jako uniwersalnego terminu ustawowego.

Raportowanie: informacja prowadząca do decyzji. Raport dla kierownictwa powinien przedstawiać najważniejsze odchylenia, trendy, zaległe działania oraz kwestie wymagające rozstrzygnięcia. Dane techniczne należy przełożyć na znaczenie dla działalności podmiotu, wskazując również braki informacji i ograniczenia oceny. Raportowanie wewnętrzne trzeba odróżnić od wymaganych prawem zgłoszeń i przekazywania informacji właściwym organom. Dokumentowanie wyników przeglądów, podjętych decyzji i statusu działań pozwala zachować ciągłość nadzoru oraz wykazać, co rzeczywiście zrobiono — nie tylko co zaplanowano.

6. Odpowiedzialność kierownictwa: czego nie delegować i jak egzekwować

Powierzenie zadań z zakresu cyberbezpieczeństwa nie jest równoznaczne z przeniesieniem odpowiedzialności kierownictwa. To podstawowe rozróżnienie, które powinien wyjaśniać ten moduł szkolenia. Zespół IT, osoba odpowiedzialna za bezpieczeństwo informacji czy zewnętrzny dostawca mogą realizować zadania operacyjne i przygotowywać rekomendacje. Nie zastępują jednak kierownictwa w wykonywaniu obowiązków przypisanych mu przez prawo.

Punktem wyjścia powinno być ustalenie, kto w danej organizacji jest kierownikiem podmiotu w rozumieniu KSC. Nie należy utożsamiać tej funkcji automatycznie z dyrektorem IT ani opierać się wyłącznie na nazwach stanowisk. Program powinien uwzględniać formę prawną organizacji, sposób jej reprezentacji oraz zasady działania organu wieloosobowego. Wewnętrzny podział kompetencji porządkuje pracę, ale sam w sobie nie przesądza o wyłączeniu odpowiedzialności poszczególnych osób.

Rekomendujemy omówienie trzech granic delegowania:

• Wykonanie a decyzja: specjalistom można powierzyć analizę i wdrożenie zabezpieczeń. Decyzje wymagające zatwierdzenia przez kierownictwo powinny pozostać na właściwym szczeblu, zgodnie z przepisami i kompetencjami decyzyjnymi.
• Wsparcie a nadzór: raport eksperta lub zapewnienie dostawcy nie zastępują oceny, czy obowiązki rzeczywiście są wykonywane. Kierownictwo powinno reagować na istotne braki, opóźnienia i sprzeczne informacje.
• Organizacja szkolenia a uczestnictwo: przygotowanie szkolenia można zlecić, lecz obowiązku udziału osoby nim objętej nie realizuje uczestnictwo jej zastępcy lub pracownika działu IT.

Egzekwowanie odpowiedzialności wymaga czegoś więcej niż wydania polecenia. Osoba realizująca zadanie powinna znać oczekiwany rezultat, termin, dostępne zasoby oraz sytuacje wymagające przekazania sprawy do decyzji przełożonego. Kierownictwo powinno wymagać dowodu wykonania i oceny skuteczności, a nie jedynie deklaracji zamknięcia zadania. Jeżeli realizacja jest zagrożona, potrzebna jest decyzja o usunięciu przeszkód, zmianie priorytetów albo innym dopuszczalnym sposobie postępowania.

Istotne decyzje warto dokumentować wraz z ich uzasadnieniem, informacjami dostępnymi w chwili rozstrzygnięcia i wskazaniem dalszych działań. Dotyczy to szczególnie odraczania zabezpieczeń oraz rozstrzygania konfliktów między potrzebami operacyjnymi a bezpieczeństwem. Akceptacja ryzyka nie legalizuje niewykonania obowiązku ustawowego, a sam podpis pod dokumentem nie dowodzi skutecznego nadzoru.

Szkolenie powinno również rozróżniać odpowiedzialność podmiotu od odpowiedzialności osób zarządzających. Omawiając konsekwencje naruszeń, należy wskazywać konkretne przesłanki i podstawy prawne właściwe dla organizacji, zamiast ograniczać przekaz do wysokości kar. Uczestnik powinien rozumieć, za jakie działania i zaniechania może odpowiadać oraz dlaczego outsourcing, podział zadań czy certyfikat ukończenia szkolenia nie stanowią automatycznego zwolnienia z odpowiedzialności.

7. Przykładowy program szkolenia (agenda) i rekomendacje organizacyjne

Program szkolenia dla kierowników podmiotów kluczowych i ważnych powinien prowadzić od zrozumienia obowiązków do przećwiczenia decyzji zarządczych. Nie należy projektować go jako skróconego kursu technicznego. Uczestnik powinien potrafić ocenić informacje otrzymywane od specjalistów, wskazać priorytety i uzasadnić decyzję dotyczącą ryzyka, zasobów lub ciągłości świadczenia usług.

Jako punkt wyjścia rekomendujemy 6 godzin zegarowych zajęć merytorycznych, z dodatkowymi przerwami — w jednym dniu lub w dwóch trzygodzinnych sesjach. Jest to propozycja organizacyjna, a nie wskazanie ustawowego minimum. Przed zatwierdzeniem programu należy zweryfikować aktualne brzmienie art. 8e KSC oraz wymagania mające zastosowanie do konkretnego podmiotu. Sama liczba godzin ani nazwa szkolenia nie przesądzają o realizacji obowiązku.

Przykładowa agenda: 6 godzin pracy z kierownictwem

1. Kontekst regulacyjny i cele szkolenia — 30 minut. Omówienie obowiązków odnoszących się do uczestników oraz powiązanie programu z ich rolami w organizacji. Krótka diagnoza wstępna pozwala ustalić, które zagadnienia wymagają większej uwagi.

2. Zarządzanie ryzykiem cyberbezpieczeństwa — 60 minut. Interpretacja przykładowego rejestru ryzyk, ocena skutków biznesowych i wybór sposobu postępowania z ryzykiem. Rezultatem modułu jest uzasadniona decyzja dotycząca priorytetu działań oraz zasobów potrzebnych do ich realizacji.

3. Bezpieczeństwo systemów i ciągłość działania — 45 minut. Przegląd zależności między usługami, systemami i dostawcami. Uczestnicy ustalają priorytety odtwarzania na podstawie krótkiego scenariusza niedostępności usługi, bez wchodzenia w konfigurację zabezpieczeń.

4. Reagowanie na incydenty — 45 minut. Praca z uproszczonym schematem eskalacji, podziałem ról i obiegiem informacji. Zadaniem kierownictwa jest wskazanie decyzji wymagających jego udziału oraz informacji niezbędnych do ich podjęcia.

5. Obowiązki organizacyjne, nadzór i odpowiedzialność — 45 minut. Ocena przykładowego raportu o stanie cyberbezpieczeństwa. Uczestnicy formułują pytania do osób odpowiedzialnych za realizację zabezpieczeń, identyfikują braki informacyjne i określają sposób kontroli działań naprawczych.

6. Ćwiczenie decyzyjne typu tabletop — 105 minut. Moderowana symulacja incydentu, w której prowadzący stopniowo przekazuje nowe informacje. Uczestnicy podejmują i zapisują decyzje, a następnie omawiają ich konsekwencje. Czas modułu obejmuje wprowadzenie do scenariusza, symulację oraz analizę wniosków.

7. Weryfikacja wiedzy i ustalenie działań po szkoleniu — 30 minut. Krótki test sytuacyjny oraz omówienie odpowiedzi. Na zakończenie uczestnicy wskazują kwestie wymagające sprawdzenia w organizacji, osoby odpowiedzialne i proponowane terminy przeglądu.

Dobór ćwiczeń i wariantu rozszerzonego

Wariant podstawowy powinien obejmować wszystkie wskazane obszary, zamiast szczegółowo rozwijać jeden z nich kosztem pozostałych. Przy złożonej strukturze organizacyjnej, istotnych zależnościach od dostawców lub niewielkim doświadczeniu uczestników rekomendujemy rozszerzenie programu do 8–12 godzin zegarowych. Dodatkowy czas warto przeznaczyć na analizę dokumentów organizacji i kolejne ćwiczenie, a nie na wydłużanie wykładu.

Do symulacji można wybrać jeden z trzech scenariuszy:

• Ransomware i niedostępność kluczowej usługi: ustalenie priorytetów utrzymania działalności, zatwierdzenie działań awaryjnych oraz przygotowanie komunikatu dla interesariuszy.
• Incydent u dostawcy: ocena wpływu na własną organizację, określenie potrzeb informacyjnych i decyzja o uruchomieniu rozwiązania zastępczego.
• Raport ujawniający istotne zaległości w zabezpieczeniach: wybór działań przy ograniczonym budżecie, wskazanie właścicieli zadań i ustalenie sposobu monitorowania postępów.

Ocenie powinien podlegać przede wszystkim proces decyzyjny: rozpoznanie brakujących informacji, właściwa eskalacja, uzasadnienie wyboru i udokumentowanie ustaleń. Nie chodzi o sprawdzanie znajomości technicznych skrótów ani odgadywanie jednej „modelowej” odpowiedzi.

Przygotowanie i dokumentowanie szkolenia

Przed zajęciami warto zebrać informacje o profilu działalności, strukturze kierownictwa, najważniejszych usługach i dojrzałości procesów bezpieczeństwa. Do przygotowania ćwiczeń wystarczą zanonimizowane fragmenty rejestru ryzyk, planu ciągłości działania lub raportu zarządczego. Zakres udostępnianych materiałów, zasady poufności i ewentualnego nagrywania należy uzgodnić z wyprzedzeniem.

Rekomendujemy formę warsztatową na żywo, stacjonarnie lub online, w grupie umożliwiającej każdemu uczestnikowi aktywny udział. Osoby odpowiedzialne za IT, bezpieczeństwo, obsługę prawną i ciągłość działania mogą wspierać ćwiczenia jako eksperci wewnętrzni. Ich obecność nie powinna jednak zastępować zaangażowania szkolonego kierownictwa. Prowadzących należy dobierać pod kątem doświadczenia w zarządzaniu cyberbezpieczeństwem oraz znajomości właściwych regulacji.

Dokumentacja powinna pozwalać odtworzyć rzeczywisty zakres i przebieg szkolenia. Warto zachować datowany program, materiały, potwierdzenia uczestnictwa oraz wyniki weryfikacji wiedzy — z odpowiednią ochroną danych. Certyfikat potwierdzający ukończenie szkolenia nie zastępuje dowodów dotyczących jego treści. Wnioski z ćwiczeń należy przekazać osobom odpowiedzialnym za właściwe procesy i ustalić termin sprawdzenia, czy wymagają zmian w dokumentacji lub praktyce organizacji.

Czy szkolenie z cyberbezpieczeństwa dla zarządu jest obowiązkowe? Art. 8e KSC krok po kroku 03 października 2026

Szkolenie z art. 8e KSC – kto musi je odbyć i jak często? 01 października 2026