Jakie są najczęstsze błędy i pułapki podczas przeprowadzania ćwiczeń tabletop i jak ich uniknąć?

Przez dziewiętnaście poprzednich artykułów szczegółowo omówiliśmy strategiczną wartość, metodykę oraz różnorodne scenariusze ćwiczeń tabletop. Zbudowaliśmy obraz potężnego narzędzia do weryfikacji planów BCP, testowania zgodności z NIS2 i RODO, a nawet przygotowania na ataki z użyciem AI. Wydawać by się mogło, że jest to proces prosty: zebrać ludzi, przedstawić problem i rozpocząć dyskusję.

Niestety, rzeczywistość jest bardziej skomplikowana. Różnica między ćwiczeniem, które realnie buduje odporność, a sesją, która jest jedynie „teatrem bezpieczeństwa”, leży w niuansach wykonania. Niezwykle łatwo jest przeprowadzić złe ćwiczenie tabletop – takie, które marnotrawi bezcenny czas całej kadry zarządzającej (persony CISO, CIO, CEO) i, co gorsza, pozostawia zespół z fałszywym poczuciem bezpieczeństwa. Identyfikacja tych pułapek jest pierwszym krokiem do ich uniknięcia. Jako partner, którego działanie opiera się na wartościach doskonałości operacyjnej i profesjonalizmu, nFlo postrzega swoje zadanie nie tylko w przeprowadzeniu sesji, ale w zagwarantowaniu jej realnej wartości diagnostycznej. W tym artykule podsumowujemy 10 najczęstszych błędów, które niweczą cały wysiłek, i pokazujemy, jak profesjonalne podejście je eliminuje.

Dlaczego traktowanie tabletopu jak egzaminu, a nie ćwiczenia, niszczy całą wartość sesji?

Jest to najbardziej fundamentalny błąd psychologiczny, który niszczy całą wartość diagnostyczną ćwiczenia. Dochodzi do niego, gdy w sali konferencyjnej panuje atmosfera osądu i szukania winnych, a nie wspólnego poszukiwania luk.

Sesja tabletop musi być wyraźnie i wielokrotnie komunikowana przez facylitatora jako ćwiczenie typu „no-fault” (bez obwiniania) oraz „non-threatening” (bez zagrożenia). Cel jest jeden: znaleźć błędy w planie, a nie w ludziach. W momencie, gdy uczestnicy – zwłaszcza kadra kierownicza (CISO, CTO) – czują, że są „oceniani” lub „egzaminowani”, natychmiast przechodzą do defensywy. Przestają otwarcie przyznawać się do problemów. Zamiast szczerego „Właściwie to nie wiemy, kto ma autorytet, by podjąć tę decyzję”, usłyszymy wymijającą, korporacyjną odpowiedź, która ma na celu „zaliczenie” pytania. W tej sekundzie cały cel ćwiczenia – odkrywanie ukrytych luk – zostaje zaprzepaszczony.

Rozwiązaniem jest świadome budowanie „bezpiecznej przestrzeni” (safe space) przez facylitatora. Musi on aktywnie nagradzać szczerość. Gdy zespół identyfikuje krytyczną lukę (np. „Okazuje się, że nasz plan BCP opiera się na nieistniejącym już oprogramowaniu!”), facylitator nie powinien reagować krytyką, lecz entuzjazmem: „Fantastycznie! To jest kluczowe odkrycie i dokładnie dlatego tu jesteśmy. Zanotujmy to jako priorytet w raporcie AAR.” Taka postawa wzmacnia kulturę transparentności.

W jaki sposób zbyt ogólny lub nierealistyczny scenariusz prowadzi do straty czasu?

Scenariusz jest sercem ćwiczenia. Jeśli jest słaby, cała sesja będzie bezwartościowa. Błąd ten ma dwie skrajności. Pierwsza to scenariusz zbyt ogólny („Zostaliśmy zhakowani. Co robimy?”). Taki opis nie dostarcza uczestnikom żadnego konkretnego punktu zaczepienia, uniemożliwiając zastosowanie realnych procedur. Dyskusja natychmiast staje się teoretyczna i jałowa.

Druga skrajność to scenariusz absurdalny lub całkowicie niedopasowany do profilu firmy („W nasze centrum danych uderzył meteoryt”). Uczestnicy natychmiast tracą zaangażowanie, kwitując scenariusz stwierdzeniem „To nam się nigdy nie zdarzy”. Testowanie firmy e-commerce scenariuszem ataku na systemy OT/ICS mija się z celem, podobnie jak testowanie zakładu produkcyjnego scenariuszem ataku na aplikację mobilną dla klientów detalicznych. Rozwiązaniem jest „hiper-customizacja”, o której pisaliśmy w kontekście AI (Art. 19) oraz CISA (Art. 10). Scenariusz musi być „realistyczny” i „dostosowany” (tailored). Musi bazować na faktycznym profilu ryzyka organizacji (Art. 5), jej stosie technologicznym i branży. Problem przedstawiony przez facylitatora musi być na tyle wiarygodny, by zarząd (persony CEO, CIO) poczuł, że „to naprawdę może się nam przydarzyć jutro”.

Dlaczego brak odpowiednich uczestników (np. działu prawnego czy HR) mija się z celem?

To bardzo częsta i kosztowna pomyłka. Organizator (najczęściej dział IT lub bezpieczeństwa) zaprasza na ćwiczenie wyłącznie innych pracowników technicznych. W rezultacie przeprowadzają oni „security tabletop” (o czym pisaliśmy w Art. 16), błędnie wierząc, że przetestowali gotowość całej organizacji.

Konsekwencje są łatwe do przewidzenia. Ćwiczenie dociera do krytycznego punktu decyzyjnego – np. „Atakujący żądają okupu i grożą publikacją danych RODO” – i dyskusja staje w miejscu. W sali nie ma nikogo, kto byłby uprawniony do podjęcia decyzji o płatności (Zarząd/CFO), ocenił ryzyko prawne (Dział Prawny/IOD) czy zarządził komunikacją (PR/HR). Zespół IT może jedynie zgadywać, co „tamci” by zrobili. Tabletop z definicji testuje współpracę międzyfunkcyjną. To jest jego największa wartość. Przeprowadzenie scenariusza naruszenia danych (Art. 12) bez IOD i prawników, lub scenariusza zagrożenia wewnętrznego (Art. 14) bez działu HR, jest kompletną porażką i stratą czasu. Cała sztuka polega na zebraniu tych wszystkich, na co dzień odizolowanych „silosów” przy jednym stole.

Jak niewłaściwa wielkość grupy wpływa na dynamikę dyskusji?

Logistyka ma znaczenie. Błąd dotyczący wielkości grupy również ma dwie skrajności. Pierwsza to grupa zbyt mała – np. zaproszono tylko CISO i szefa IT. Brakuje wtedy kluczowych funkcji (Legal, HR, Operacje), aby przetestować realne procesy decyzyjne, co sprowadza się do błędu nr 3.

Znacznie częstsza jest jednak grupa zbyt duża. Organizator, chcąc „poinformować wszystkich”, zaprasza na 3-godzinne spotkanie 30, 40, a nawet 50 osób. Efekt jest natychmiastowy i katastrofalny: interaktywne ćwiczenie (exercise) zamienia się w pasywną prezentację (presentation). W grupie powyżej 15-20 osób efektywna, dynamiczna dyskusja jest niemożliwa. Większość uczestników automatycznie przechodzi w tryb „obserwatora”. Zamiast angażować się w rozwiązywanie problemu, siedzą cicho, sprawdzając e-maile na laptopach. Rozwiązaniem jest restrykcyjne trzymanie się grupy 8-15 kluczowych decyzyjnych uczestników. Lepiej przeprowadzić wartościową sesję dla 12 zaangażowanych menedżerów niż prezentację dla 40 znudzonych pracowników.

W jaki sposób dominacja dyskusji przez jedną osobę (np. CISO) zaburza przebieg ćwiczenia?

Jest to pułapka, która często zdarza się w grupach o silnej hierarchii lub z jedną, dominującą osobowością. Najczęściej jest to osoba najbardziej kompetentna technicznie (np. CISO lub CTO, nasze persony Anna/Tomasz), która mimowolnie odpowiada na każde pytanie facylitatora, szczegółowo wyjaśniając, jak zadziałałyby jej systemy i co zrobiłby jej zespół.

Taka dominacja natychmiast „zabija” dyskusję i niweczy cel ćwiczenia. Ucisza pozostałych uczestników. Przedstawiciel działu prawnego czy HR, czując się mniej kompetentny w technicznej dyskusji, milknie. W rezultacie ćwiczenie nie testuje współpracy, a jedynie weryfikuje (lub utwierdza) to, co CISO sądzi, że powinno się wydarzyć. To jest jedno z kluczowych zadań dla silnego facylitatora (Art. 8). Dobry, zwłaszcza zewnętrzny i neutralny, facylitator potrafi zarządzić taką dynamiką. Użyje swojej asertywności, aby grzecznie przerwać dominującej osobie („Dziękuję, Tomaszu, to kluczowe spojrzenie techniczne. A teraz musimy usłyszeć, co Dział Prawny sądzi o ryzyku reputacyjnym tej decyzji?”). Aktywne wywoływanie „cichych” uczestników jest niezbędne.

Jakie ryzyko niesie słaby lub stronniczy facylitator?

Jak wielokrotnie podkreślaliśmy, facylitator jest najważniejszą osobą na sali, od której zależy 90% sukcesu. Słaby facylitator to osoba, która po prostu czyta pytania ze slajdów, nie zarządza czasem, nie kontroluje dyskusji i pozwala zespołowi „płynąć” w nieproduktywnych kierunkach (np. Błąd 7).

Jednak jeszcze gorszy jest facylitator stronniczy. Dzieje się tak niemal zawsze, gdy ćwiczenie próbuje prowadzić osoba, która jest jednocześnie za nie odpowiedzialna, np. CISO prowadzący tabletop dla własnego zespołu. Taka osoba ma naturalny konflikt interesów. Nawet podświadomie będzie tak sterować dyskusją i dobierać scenariusze, aby unikać znanych słabości swojego działu, a podkreślać jego mocne strony. W rezultacie ćwiczenie diagnostyczne zamienia się w wewnętrzną prezentację marketingową działu IT. Dlatego neutralność jest kluczowa. Zewnętrzny facylitator (np. konsultant nFlo) nie ma tego bagażu. Jego jedynym celem jest obiektywne znalezienie luk, aby pomóc klientowi. Może zadawać „głupie” lub „niewygodne” pytania, których pracownik wewnętrzny bałby się zadać, a które często obnażają najgłębsze problemy.

Dlaczego skupienie się na technologii przy ignorowaniu procesów i ludzi to pułapka?

To klasyczna „techniczna królicza nora”, w którą najczęściej wpadają zespoły IT. Facylitator przedstawia problem (np. „Wykryto ransomware”), a dyskusja natychmiast schodzi na poziom techniczny: „Na którym porcie to weszło? Jaką sygnaturę ma ten malware? Czy nasz EDR to widzi? Jak skonfigurowane są reguły firewalla między VLAN-ami?”. Zespół IT zaczyna 30-minutową debatę nad konfiguracją przełącznika.

W tym czasie cel ćwiczenia umiera. Tabletop nie jest sesją przeglądu konfiguracji (od tego są audyty techniczne). Jest to test ludzi i procesów, wspieranych przez technologię. Głębokie nurkowanie w technologię marnuje bezcenny czas i – co gorsza – całkowicie wyklucza z dyskusji wszystkich nietechnicznych uczestników (Zarząd, Legal, HR, PR), którzy po 5 minutach takiej debaty są już całkowicie wyłączeni i znudzeni. Dobry facylitator musi być strażnikiem „dużego obrazka”. Musi brutalnie, choć grzecznie, przerywać takie dygresje: „Panowie, konfigurację firewalla zostawmy jako punkt do analizy po sesji. Wracając do scenariusza: minęło 30 minut, atak się rozprzestrzenia. Kto podejmuje decyzję o odcięciu fabryki od sieci? Kto komunikuje tę decyzję Prezesowi?”.

Czym grozi strach przed „porażką” w bezpiecznym środowisku ćwiczenia?

Ten błąd jest ściśle powiązany z pierwszym (traktowaniem sesji jak egzaminu). W wielu kulturach organizacyjnych „porażka” jest piętnowana. Zespoły przychodzą więc na tabletop z nastawieniem, że muszą wygrać – czyli gładko przejść przez scenariusz, udowadniając, że wszystkie plany działają perfekcyjnie. Aktywnie ukrywają problemy i nie przyznają się do luk, aby „dobrze wypaść”.

To jest prawdziwa i katastrofalna porażka ćwiczenia. Sesja, która kończy się wnioskiem „Wszystko poszło świetnie, nie mamy żadnych problemów, nasze plany są doskonałe”, jest kompletną stratą czasu. Oznacza to, że nikt nie był szczery, a organizacja właśnie wydała pieniądze na stworzenie śmiertelnie niebezpiecznego, fałszywego poczucia bezpieczeństwa. Sukcesem w tabletopie jest porażka. Celem jest znalezienie luk w bezpiecznym środowisku, aby nie znaleźć ich podczas prawdziwego kryzysu. Dobry facylitator musi to jasno ustawić na początku: „Naszym celem dzisiaj jest znalezienie 3-5 krytycznych błędów w naszych procedurach. Im więcej ich znajdziemy, tym większy sukces odniesiemy.”

Jak brak realistycznych „niespodzianek” (np. kluczowa osoba na urlopie) spłyca test?

Scenariusz, który zakłada idealne warunki („happy path”), nie testuje odporności (resilience). W takim scenariuszu wszyscy kluczowi pracownicy są dostępni, systemy backupowe działają idealnie, a dostawcy odbierają telefony po pierwszym sygnale.

Prawdziwe kryzysy nigdy tak nie wyglądają – zdarzają się o 3 nad ranem w święto, gdy kluczowy administrator jest na urlopie. Jeśli scenariusz jest zbyt prosty, zespół szybko znajduje rozwiązanie: „Nie ma problemu, mamy backupy. Ania (CISO) to ogarnie.” Ćwiczenie się kończy, a fakt, że Ania jest pojedynczym punktem awarii (Single Point of Failure) i nikt poza nią nie ma dostępu do konsoli backupu, nigdy nie zostaje odkryty. Rolą facylitatora (Art. 8) jest testowanie odporności planu poprzez wprowadzanie realistycznych komplikacji, czyli „wstrzyknięć” (injects). Gdy zespół polega na Ani, facylitator musi wprowadzić „niespodziankę”: „Świetny plan. Niestety, Ania jest właśnie na 10-godzinnym locie bez dostępu do internetu. Kto jest jej formalnym, przeszkolonym zastępcą i gdzie znajduje się dokumentacja procedury?”. Taki „inject” natychmiast weryfikuje realną odporność planu, a nie jego teoretyczne założenia.

Dlaczego brak raportu AAR i działań następczych to największy błąd ze wszystkich?

To jest, bez dwóch zdań, najczęstszy i najbardziej destrukcyjny błąd, jaki można popełnić. Organizacja inwestuje czas i pieniądze w przygotowanie, zbiera całą kadrę zarządzającą na 3 godziny, przeprowadza fantastyczną, burzliwą dyskusję i identyfikuje dziesiątki krytycznych luk. Po czym sesja się kończy, facylitator mówi „dziękuję”, a uczestnicy wracają do swoich codziennych obowiązków.

Konsekwencja? Nic się nie zmienia. Nie powstaje żaden formalny Raport po Ćwiczeniu (AAR). Nie zostaje stworzona żadna „Lista Działań” (Action List), o której pisaliśmy w Art. 9. Nikt nie jest formalnie odpowiedzialny za naprawę zidentyfikowanych luk. Nie ma żadnych terminów. Cała wiedza i bezcenne wnioski z sesji „wyparowują” w ciągu 48 godzin. Należy to powiedzieć jasno: ćwiczenie tabletop bez formalnego, śledzonego planu działań naprawczych (AAR) jest całkowitą stratą czasu i zasobów. Ćwiczenie jest tylko procesem zbierania danych. Prawdziwym produktem jest raport AAR. To ten dokument przekształca dyskusję w mierzalną poprawę bezpieczeństwa i stanowi dowód należytej staranności dla audytorów (Art. 17).

10 grzechów głównych ćwiczeń tabletop: Fiszka podsumowująca

Brak raportu AAR: Największy błąd – brak formalnego planu działań naprawczych po zakończeniu sesji.

Traktowanie sesji jak egzaminu: Zamiast bezpiecznego ćwiczenia (zasada „no-fault”).

Nierealistyczny scenariusz: Zbyt ogólny, absurdalny lub niedopasowany do profilu firmy.

Zły skład (brak Legal/HR): Testowanie tylko zespołu IT i ignorowanie kluczowych decydentów.

Zła wielkość grupy: Zbyt duża grupa zamienia interaktywne ćwiczenie w pasywną prezentację.

Dominacja jednej osoby: Pozwolenie, by CISO/CTO odpowiadał na wszystkie pytania.

Słaby/stronniczy facylitator: Prowadzący, który jest sędzią we własnej sprawie lub nie panuje nad sesją.

Zejście w „techniczną norę”: Skupienie na konfiguracji sprzętu zamiast na procesach i decyzjach.

Strach przed „porażką”: Dążenie do „zaliczenia” ćwiczenia zamiast do szczerego odkrywania luk.

Brak „niespodzianek”: Testowanie planu w idealnych warunkach, bez testowania jego odporności (np. kluczowa osoba na urlopie).