System Zarządzania Bezpieczeństwem Informacji (SZBI) – czego kierownik powinien wymagać od organizacji?

Kontekst KSC/NIS2 i rola kierownika: co oznacza „minimalne wymagania” wobec SZBI (ISMS)

Kierownik powinien wymagać od organizacji nie tylko dokumentacji bezpieczeństwa, lecz przede wszystkim zdolności do wykazania, że ryzyka związane z bezpieczeństwem informacji są rozpoznawane, a działania ochronne rzeczywiście funkcjonują. System Zarządzania Bezpieczeństwem Informacji (SZBI, ang. ISMS) służy uporządkowaniu tego procesu. Łączy decyzje zarządcze, zasady organizacyjne i zabezpieczenia techniczne w spójny sposób działania. Nie jest pojedynczym narzędziem informatycznym ani projektem, który kończy się po zatwierdzeniu polityki.

KSC, NIS2 i SZBI — różne funkcje, wspólny cel

KSC oznacza krajowy system cyberbezpieczeństwa, którego ramy określa polska ustawa. To w przepisach krajowych należy ustalać obowiązki konkretnego podmiotu, właściwy organ nadzoru oraz terminy realizacji wymagań. NIS2 jest unijną dyrektywą, która wyznacza państwom członkowskim wymagania dotyczące m.in. zarządzania ryzykiem cyberbezpieczeństwa, zgłaszania incydentów i odpowiedzialności organów zarządzających. Ocena obowiązków organizacji wymaga więc sprawdzenia aktualnego brzmienia polskich przepisów wdrażających dyrektywę, w tym regulacji przejściowych, a nie wyłącznie odwołania się do tekstu NIS2.

SZBI jest sposobem organizacji zarządzania bezpieczeństwem, a nie nazwą regulacji. Może obejmować informacje cyfrowe, papierowe i przekazywane ustnie — w zakresie przyjętym przez organizację. Rozpoznawalnym punktem odniesienia dla jego budowy jest norma ISO/IEC 27001. Wdrożenie SZBI według tej normy może wspierać spełnienie obowiązków prawnych, ale sam certyfikat nie stanowi automatycznego potwierdzenia zgodności z KSC lub NIS2. Dyrektywa nie ustanawia też powszechnego obowiązku certyfikacji ISO/IEC 27001.

„Minimum” zależy od organizacji, ale nie jest dowolne

NIS2 przewiduje stosowanie odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Przy ich doborze znaczenie mają m.in. narażenie na ryzyko, wielkość podmiotu oraz prawdopodobieństwo i dotkliwość incydentów, w tym ich skutki społeczne i gospodarcze. Proporcjonalność nie oznacza możliwości pominięcia obowiązkowego wymagania tylko dlatego, że jego realizacja jest kosztowna. Oznacza natomiast, że sposób wdrożenia ochrony powinien odpowiadać rzeczywistym zagrożeniom i znaczeniu świadczonych usług.

Z perspektywy kierownika punktem wyjścia powinno być uzyskanie trzech jednoznacznych odpowiedzi:

• Czy i na jakiej podstawie organizacja podlega regulacjom? Kwalifikacja wymaga uwzględnienia sektora, rodzaju działalności, wielkości podmiotu oraz wyjątków przewidzianych w przepisach. Nie wystarczy ogólne stwierdzenie, że organizacja „jest za mała na NIS2”.
• Jaki zakres obejmuje SZBI? Granice systemu powinny być jasno określone i uzasadnione, bez wyłączania istotnych obszarów wyłącznie dla ułatwienia wdrożenia.
• Na czym opiera się deklaracja spełnienia wymagań? Organizacja powinna umieć przedstawić dowody działania systemu oraz wskazać znane braki, zamiast utożsamiać zgodność z posiadaniem dokumentów.

Kierownik zatwierdza kierunek i sprawuje nadzór

Artykuł 20 NIS2 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa oraz nadzorowały ich wdrażanie. Przewiduje również szkolenia dla członków tych organów. Konkretne zasady odpowiedzialności należy oceniać na gruncie właściwych przepisów krajowych; nie każda osoba zajmująca stanowisko kierownicze jest automatycznie członkiem organu zarządzającego w rozumieniu tych regulacji.

Praktyczna konsekwencja jest zasadnicza: powierzenie zadań specjalistom lub dostawcy zewnętrznemu nie zastępuje nadzoru zarządczego. Kierownik powinien zapewnić warunki do realizacji wymagań, domagać się zrozumiałych informacji o stanie bezpieczeństwa i podejmować decyzje wymagające jego umocowania. Minimalne wymagania wobec SZBI oznaczają zatem nie najkrótszą listę dokumentów, lecz uzasadniony, działający i możliwy do zweryfikowania poziom zarządzania bezpieczeństwem.

Fundamenty SZBI: polityki, role i odpowiedzialności

Kierownik powinien wymagać, aby dla każdej istotnej decyzji dotyczącej bezpieczeństwa informacji było jasne: kto ją podejmuje, kto ją wykonuje i kto sprawdza jej realizację. To podstawowy warunek sprawnego ładu zarządczego w SZBI. Samo powołanie osoby odpowiedzialnej za bezpieczeństwo ani zatwierdzenie zbioru dokumentów nie zapewnia jeszcze takiego porządku. Odpowiedzialności muszą towarzyszyć odpowiednie uprawnienia, zasoby i możliwość eskalowania problemów. Piszemy o tym, bo uczestnicy szkoleń Cognity często sygnalizują, że uporządkowanie ról i odpowiedzialności jest dla nich realnym wyzwaniem w pracy.

Polityki, które wyznaczają zasady działania

Polityka bezpieczeństwa informacji powinna określać kierunek przyjęty przez kierownictwo: cele, podstawowe zasady ochrony informacji oraz zobowiązanie do spełniania mających zastosowanie wymagań. Zakres SZBI należy natomiast jasno zdefiniować — wskazać objęte nim jednostki, procesy i usługi oraz granice odpowiedzialności organizacji. Nie wystarczy ogólna deklaracja, że system obejmuje „bezpieczeństwo IT”, ponieważ informacje są przetwarzane również poza systemami informatycznymi.

Warto rozróżnić funkcje poszczególnych dokumentów. Polityka określa zasady i oczekiwania, standard precyzuje wymagania, a procedura opisuje sposób wykonania zadania. Nie każda organizacja potrzebuje rozbudowanej hierarchii dokumentacji. Potrzebuje jednak spójnych reguł, które pracownicy potrafią odnaleźć i zastosować. Dokument nie powinien nakładać obowiązków na rolę, która faktycznie nie istnieje, ani opisywać działań, na które nie przeznaczono zasobów.

Kierownik powinien oczekiwać, że każdy istotny dokument będzie miał właściciela, określony tryb zatwierdzania, aktualną wersję oraz zasady aktualizacji. Równie ważny jest tryb udzielania odstępstw: kto może je zatwierdzić, na jaki czas i jak dokumentuje się taką decyzję. Dzięki temu wyjątki nie stają się nieformalnym sposobem obchodzenia przyjętych zasad.

Podział ról: kto odpowiada za co

Nazwy stanowisk mogą się różnić zależnie od wielkości i struktury organizacji. Istotne jest rozdzielenie funkcji zarządczych, koordynacyjnych i wykonawczych oraz jednoznaczne przypisanie odpowiedzialności:

• Kierownictwo wyznacza kierunek, zatwierdza kluczowe zasady, zapewnia zasoby i rozstrzyga kwestie przekraczające uprawnienia pozostałych ról. Delegowanie zadań nie oznacza automatycznego przeniesienia odpowiedzialności wynikającej z przepisów.
• CISO lub osoba koordynująca SZBI dba o spójność systemu, wspiera jednostki organizacyjne i przedstawia kierownictwu problemy wymagające decyzji. Nie powinna być domyślnym właścicielem wszystkich ryzyk ani wykonawcą wszystkich zabezpieczeń.
• Właściciel ryzyka odpowiada za zarządzanie przypisanym ryzykiem i ma uprawnienia do podejmowania dotyczących go decyzji w ustalonych granicach. Powinna to być osoba mogąca realnie wpływać na dany obszar działalności.
• Właściciel aktywa odpowiada za określenie wymagań dotyczących powierzonego zasobu, na przykład informacji, aplikacji lub usługi. Nie musi być jego administratorem technicznym.
• Zespoły wykonawcze, w tym IT realizują przypisane zadania i wdrażają wymagania. Sam dostęp administracyjny nie daje im prawa do samodzielnego rozstrzygania wszystkich kwestii biznesowych związanych z bezpieczeństwem.

Mandat i zasady współpracy zamiast odpowiedzialności na papierze

Osoba koordynująca SZBI powinna mieć dostęp do informacji potrzebnych do wykonywania swojej funkcji oraz ustaloną ścieżkę kontaktu z kierownictwem. Spór o priorytety lub finansowanie zabezpieczeń nie może pozostawać nierozstrzygnięty tylko dlatego, że CISO nie zarządza budżetem innej jednostki. Potrzebny jest wskazany poziom decyzyjny i czytelny tryb eskalacji.

W mniejszej organizacji jedna osoba może pełnić kilka funkcji, o ile pozwalają na to mające zastosowanie wymagania. Należy jednak rozpoznać konflikty interesów i ograniczyć sytuacje, w których ta sama osoba wykonuje zadanie oraz samodzielnie ocenia jego poprawność. Praktycznym dowodem uporządkowania SZBI jest zatwierdzony podział odpowiedzialności, spójny z zakresami obowiązków, upoważnieniami i zastępstwami — nie sam schemat organizacyjny.

3. Zarządzanie ryzykiem i zgodnością: metodologia, akceptacja ryzyka, plan postępowania i raportowanie

Kierownik powinien móc ustalić, które ryzyka zagrażają realizacji zadań organizacji, dlaczego uznano je za istotne i kto odpowiada za dalsze działania. Sama macierz ryzyka nie daje takiej wiedzy. Wymaganym rezultatem jest udokumentowana ścieżka od rozpoznanego zagrożenia do decyzji, jej wykonania i oceny ryzyka pozostającego po wdrożeniu zabezpieczeń.

Metodologia: wspólne kryteria zamiast ocen uznaniowych

Organizacja potrzebuje jednej, uzgodnionej metody oceny ryzyka, stosowanej w całym zakresie SZBI. Nie musi ona opierać się na skomplikowanych obliczeniach. Powinna natomiast określać sposób identyfikowania scenariuszy ryzyka, oceniania prawdopodobieństwa i skutków oraz ustalania priorytetów. Skutki należy odnosić do działalności organizacji: utraty dostępności usług, ujawnienia lub naruszenia integralności informacji, strat finansowych, konsekwencji prawnych czy zagrożenia dla ludzi.

Kierownik powinien wymagać zdefiniowanych skal ocen, kryteriów akceptacji i zasad uwzględniania istniejących zabezpieczeń. Bez tego wynik „wysoki” może w różnych jednostkach oznaczać zupełnie inny poziom zagrożenia. Metoda powinna również wskazywać, kiedy ocenę trzeba powtórzyć — zarówno okresowo, jak i po istotnej zmianie, incydencie lub ujawnieniu nowych informacji o zagrożeniach.

Rejestr ryzyk powinien opisywać konkretne scenariusze, a nie same hasła. „Cyberatak” nie wyjaśnia, co może się wydarzyć ani jak wpłynie to na organizację. Użyteczny zapis łączy przyczynę, zdarzenie i następstwo oraz wskazuje właściciela ryzyka, podstawę oceny i przyjętą decyzję.

Ryzyko i zgodność: dwa powiązane, lecz odrębne porządki

Ocena ryzyka pomaga dobrać zabezpieczenia i ustalić kolejność działań. Ocena zgodności odpowiada na inne pytanie: czy organizacja spełnia obowiązujące ją wymagania prawne, regulacyjne i umowne. Niski wynik oceny ryzyka nie jest podstawą do pominięcia jednoznacznego obowiązku.

W kontekście KSC i NIS2 kierownik powinien wymagać ustalenia, które przepisy i obowiązki rzeczywiście dotyczą organizacji, z uwzględnieniem aktualnego stanu prawa krajowego. Potrzebny jest aktualizowany rejestr wymagań, który łączy każdy obowiązek z odpowiedzialną funkcją, dowodem jego spełnienia oraz ewentualną luką i działaniem naprawczym. ISO/IEC 27001 może porządkować zarządzanie bezpieczeństwem, ale certyfikat nie jest automatycznym potwierdzeniem zgodności ze wszystkimi przepisami.

Akceptacja ryzyka: decyzja z uzasadnieniem i granicami

Akceptacja oznacza świadomą zgodę na pozostawienie określonego ryzyka, a nie brak reakcji na problem. Powinna należeć do osoby z odpowiednimi uprawnieniami, zgodnie z ustalonymi progami decyzyjnymi. Ryzyka przekraczające kompetencje właściciela wymagają eskalacji, a nie obniżenia oceny w rejestrze.

W zapisie decyzji należy wskazać poziom akceptowanego ryzyka, uzasadnienie, osobę zatwierdzającą, datę oraz termin lub warunki ponownego rozpatrzenia. Szczególnie ważne jest rozróżnienie ryzyka istniejącego dzisiaj od przewidywanego ryzyka rezydualnego, czyli pozostającego po realizacji planu. Zaplanowane zabezpieczenie nie może być traktowane jak już działające, a akceptacja ryzyka nie zwalnia z obowiązków prawnych.

Plan postępowania: konkretne zobowiązania zamiast deklaracji

Organizacja może ograniczać ryzyko, unikać go przez rezygnację z określonego działania, dzielić je z inną stroną lub je zaakceptować. Ubezpieczenie czy umowa z dostawcą mogą zmienić rozkład części konsekwencji, ale nie oznaczają automatycznego przeniesienia odpowiedzialności prawnej organizacji.

Dla ryzyk wymagających działania plan powinien wskazywać:

• wybrany sposób postępowania i oczekiwany rezultat;
• osobę odpowiedzialną, termin oraz potrzebne zasoby;
• priorytet i zależności wpływające na wykonanie;
• sposób potwierdzenia wdrożenia oraz ponownej oceny ryzyka.

Raportowanie: materiał do decyzji kierownika

Raport zarządczy nie powinien być kopią całego rejestru. Ma pokazywać najistotniejsze ryzyka i ich zmiany, opóźnione działania, luki zgodności oraz akceptacje wymagające odnowienia. Każda sprawa wymagająca rozstrzygnięcia powinna zawierać rekomendację, konsekwencje zwłoki i jasno sformułowaną decyzję do podjęcia. Kierownik powinien również otrzymywać informację, czy wdrożone działania rzeczywiście obniżyły ryzyko — samo zamknięcie zadania nie jest wystarczającym dowodem.

4. Zarządzanie aktywami i informacją: inwentaryzacja, klasyfikacja informacji, kontrola dostępu oraz zarządzanie podatnościami

Kierownik powinien wymagać od organizacji odpowiedzi na cztery pytania: co chronimy, jakiej ochrony to wymaga, kto ma do tego dostęp i gdzie występują znane słabości? Odpowiedzi muszą wynikać z aktualnych rejestrów i stosowanych zabezpieczeń, a nie wyłącznie z deklaracji działu IT. W tym obszarze o skuteczności SZBI decyduje powiązanie informacji z systemami, użytkownikami i procesami, które z niej korzystają.

Inwentaryzacja: nie tylko lista komputerów

Ewidencja aktywów powinna obejmować sprzęt, oprogramowanie, systemy, usługi chmurowe oraz istotne zbiory informacji — również dokumentację papierową. Sama lista urządzeń nie wystarczy, jeśli organizacja nie wie, gdzie przechowuje dane, do czego je wykorzystuje i od jakich usług zależy ich dostępność.

Dla istotnych aktywów należy wskazać co najmniej właściciela, przeznaczenie, lokalizację lub środowisko przetwarzania, znaczenie dla działalności oraz najważniejsze zależności. W przypadku komponentów technicznych potrzebne są także dane pozwalające ocenić ich stan bezpieczeństwa, w tym wersja oprogramowania i status wsparcia producenta.

Wymaganiem kierowniczym powinna być aktualność ewidencji, nie samo jej istnienie. Uruchomienie nowej aplikacji, zakup usługi SaaS czy wycofanie serwera musi skutkować aktualizacją odpowiednich danych. Warto również wymagać porównywania rejestru ze stanem faktycznym, aby wykrywać zasoby uruchomione poza przyjętym procesem. Nie jest konieczne jedno narzędzie do wszystkiego, lecz spójność ewidencji i możliwość ustalenia pełnego zakresu aktywów.

Klasyfikacja informacji: poziom ochrony musi mieć praktyczne znaczenie

Inwentaryzacja odpowiada na pytanie, jakie zasoby organizacja posiada lub wykorzystuje. Klasyfikacja informacji określa natomiast, jak należy się z informacją obchodzić. Powinna uwzględniać skutki jej nieuprawnionego ujawnienia, zmiany, utraty lub niedostępności. Poziom poufności nie zastępuje oceny wymagań dotyczących integralności i dostępności: publiczna informacja może nadal wymagać silnej ochrony przed nieuprawnioną modyfikacją.

Można przyjąć prosty podział, na przykład na informacje publiczne, wewnętrzne i poufne, o ile każdej kategorii towarzyszą jednoznaczne zasady. Pracownik powinien wiedzieć, gdzie wolno przechowywać dany dokument, komu można go przekazać, kiedy wymagane jest szyfrowanie oraz jak bezpiecznie go usunąć. Okresy przechowywania należy ustalać z uwzględnieniem wymogów prawnych, umownych i potrzeb biznesowych, a nie wyłącznie etykiety poufności.

Kierownik powinien oczekiwać dowodów stosowania klasyfikacji, a nie tylko zatwierdzonej tabeli kategorii. Przykładowo: dokument oznaczony jako poufny nie powinien być dostępny przez publiczny link.

Kontrola dostępu: uprawnienia wynikające z rzeczywistych potrzeb

Podstawą jest zasada najmniejszych uprawnień: użytkownik otrzymuje wyłącznie dostęp potrzebny do wykonywania zadań. Trzeba przy tym rozróżniać uwierzytelnianie, czyli potwierdzenie tożsamości, od autoryzacji, czyli określenia dozwolonych działań. Silne hasło lub uwierzytelnianie wieloskładnikowe nie naprawią nadmiernie szerokich uprawnień.

W Cognity omawiamy kontrolę dostępu zarówno od strony technicznej, jak i praktycznej — zgodnie z realiami pracy uczestników. Organizacja powinna zapewnić:

• zatwierdzanie dostępu przed jego nadaniem oraz odbieranie go po ustaniu potrzeby;
• aktualizację uprawnień przy zmianie stanowiska lub zakresu obowiązków, bez automatycznego zachowywania wcześniejszych dostępów;
• okresowe przeglądy uprawnień, szczególnie administracyjnych i dotyczących informacji wrażliwych;
• indywidualne konta użytkowników, oddzielenie pracy administracyjnej od codziennej oraz stosowanie MFA adekwatnie do ryzyka, zwłaszcza dla dostępu zdalnego i uprzywilejowanego;
• objęcie kontrolą również kont technicznych, kluczy API i innych poświadczeń używanych przez aplikacje.

Dowodem działania tych zasad są aktualne uprawnienia i potwierdzenia ich weryfikacji. Samo zgłoszenie odebrania dostępu nie oznacza jeszcze, że został on rzeczywiście zablokowany.

Zarządzanie podatnościami: od wykrycia do potwierdzonego usunięcia

Skanowanie podatności jest sposobem wykrywania słabości, a nie kompletnym procesem ich usuwania. Kierownik powinien wymagać, aby wykryte problemy były przypisywane do konkretnych aktywów, otrzymywały priorytet i termin obsługi, a wykonane działania podlegały weryfikacji.

O pilności nie powinna decydować wyłącznie ocena CVSS. Znaczenie mają również dostępność systemu z internetu, krytyczność obsługiwanego procesu, możliwość wykorzystania podatności i informacje o jej aktywnym wykorzystywaniu. Proces musi obejmować nie tylko aktualizacje, lecz także błędne konfiguracje i komponenty pozbawione wsparcia producenta.

Jeżeli poprawki nie można wdrożyć od razu, potrzebne są udokumentowane zabezpieczenia zastępcze, na przykład ograniczenie dostępu lub wyłączenie podatnej funkcji, oraz termin ponownej oceny sytuacji. Zamknięcie zadania powinno następować po potwierdzeniu usunięcia podatności albo skutecznego ograniczenia możliwości jej wykorzystania — nie po samym przekazaniu sprawy administratorowi.

5. Odporność operacyjna: ciągłość działania/DR, obsługa incydentów oraz zarządzanie dostawcami i usługami

O odporności operacyjnej świadczy nie samo istnienie procedur, lecz zdolność organizacji do utrzymania najważniejszych usług podczas zakłócenia i ich bezpiecznego przywrócenia. Kierownik powinien wymagać konkretnych odpowiedzi: co musi działać, jak długo może być niedostępne, kto podejmuje decyzje w sytuacji kryzysowej i od jakich dostawców zależy powrót do pracy. Odpowiedzi muszą być spójne — plan awaryjny nie będzie wiarygodny, jeśli zakłada odtworzenie usługi szybciej, niż umożliwia to umowa z jej dostawcą.

Ciągłość działania i odtwarzanie po awarii — dwa różne zadania

Plan ciągłości działania (BCP) określa, jak organizacja utrzyma priorytetowe procesy mimo zakłócenia. Może przewidywać pracę w ograniczonym zakresie, alternatywny kanał obsługi lub czasowe wykonywanie części czynności ręcznie. Plan odtwarzania po awarii (DR) dotyczy przywrócenia systemów, danych i infrastruktury IT. DR wspiera ciągłość działania, ale jej nie zastępuje: sprawne serwery nie wystarczą, jeśli brakuje personelu, łączności albo dostępu do kluczowej usługi zewnętrznej.

Punktem wyjścia powinna być analiza wpływu zakłóceń na działalność (BIA). Na jej podstawie należy ustalić priorytety przywracania procesów i wspierających je systemów. Kierownik powinien wymagać zatwierdzenia dwóch parametrów: RTO, czyli docelowego czasu przywrócenia działania, oraz RPO, czyli dopuszczalnego zakresu utraty danych wyrażonego w czasie. Parametry te powinny wynikać z potrzeb działalności, a nie wyłącznie z możliwości obecnej infrastruktury.

Minimalny zakres ustaleń obejmuje warunki uruchomienia planów, osoby uprawnione do podejmowania decyzji, kolejność odtwarzania oraz zasoby potrzebne do pracy zastępczej. Procedury i dane kontaktowe muszą być dostępne również wtedy, gdy podstawowe środowisko IT nie działa. W przypadku kopii zapasowych należy wymagać nie tylko potwierdzenia ich wykonania, ale także dowodu, że można z nich odtworzyć użyteczne dane w wymaganym czasie. Kopie powinny być chronione przed usunięciem lub zaszyfrowaniem wraz ze środowiskiem produkcyjnym.

Obsługa incydentów — od zgłoszenia do bezpiecznego wznowienia pracy

Obsługa incydentów służy ograniczeniu skutków zdarzenia, ustaleniu jego zakresu i usunięciu przyczyny. Nie każdy incydent wymaga uruchomienia planu ciągłości działania, a nie każda przerwa w działalności jest skutkiem cyberataku. Procedury powinny jednak wskazywać, kiedy oba tryby działania trzeba połączyć.

Kierownik powinien wymagać jednej, uzgodnionej ścieżki zgłaszania i eskalacji incydentów, z jasno określonymi uprawnieniami do izolowania systemów, wstrzymywania usług oraz angażowania wsparcia zewnętrznego. Szczególnie ważne jest rozstrzygnięcie, kto może zaakceptować czasowe ograniczenie działalności, aby powstrzymać dalsze szkody. Organizacja potrzebuje również awaryjnego kanału komunikacji na wypadek przejęcia lub niedostępności poczty i komunikatorów.

Procedura powinna obejmować zabezpieczenie dowodów, dokumentowanie decyzji oraz ocenę obowiązków zgłoszeniowych. Trzeba z góry ustalić, kto ocenia przesłanki zgłoszenia, do jakiego organu należy je skierować i jakie terminy obowiązują organizację — z uwzględnieniem właściwych przepisów KSC, ochrony danych osobowych i regulacji sektorowych. Powrót do pracy powinien następować po potwierdzeniu, że przywracane środowisko nie odtworzy przyczyny incydentu.

Dostawcy i usługi — zależności, które muszą znaleźć się w planach

Powierzenie usługi podmiotowi zewnętrznemu nie zwalnia organizacji z odpowiedzialności za jej ciągłość. Kierownik powinien wymagać ustalenia, które usługi zewnętrzne są niezbędne do realizacji priorytetowych procesów i jakie są możliwości działania w razie ich niedostępności.

W umowach dotyczących takich usług należy zapewnić przede wszystkim:

• adekwatne zobowiązania dotyczące dostępności i odtwarzania — z rozróżnieniem czasu reakcji od czasu przywrócenia usługi;
• zasady informowania o incydentach i współpracy — umożliwiające organizacji ograniczenie szkód oraz terminowe wykonanie własnych obowiązków zgłoszeniowych;
• dostęp do informacji o zabezpieczeniach i istotnych podwykonawcach — w zakresie odpowiednim do znaczenia usługi;
• warunki zakończenia współpracy — obejmujące odzyskanie danych w użytecznym formacie, wsparcie migracji oraz zasady usunięcia pozostałych kopii.

Samo SLA nie stanowi planu ciągłości: rekompensata za niedostępność nie przywróci obsługi klientów. Dlatego dla usług krytycznych potrzebny jest wykonalny wariant zastępczy lub plan wyjścia, uwzględniający czas migracji, koszty i zależności techniczne.

6. Ludzie i świadomość: szkolenia, wymagania kompetencyjne, kultura bezpieczeństwa

Kierownik powinien wymagać, aby organizacja potrafiła wykazać nie tylko, że przeszkoliła pracowników, lecz także że przygotowała ich do bezpiecznego wykonywania konkretnych zadań. Lista obecności lub potwierdzenie ukończenia kursu dokumentuje udział, ale nie dowodzi umiejętności rozpoznania zagrożenia i właściwej reakcji. W SZBI potrzebne są trzy uzupełniające się elementy: świadomość zagrożeń, kompetencje odpowiednie do stanowiska oraz warunki sprzyjające bezpiecznym zachowaniom.

Świadomość, szkolenie i kompetencje — różne cele

Działania świadomościowe przypominają, na co uważać w codziennej pracy. Szkolenia uczą określonego sposobu postępowania, natomiast rozwój kompetencji przygotowuje do samodzielnego wykonywania zadań wymagających wiedzy i praktyki. Nie należy zastępować jednego elementu drugim: komunikat o phishingu nie przygotuje administratora do bezpiecznego utrzymania systemu, a techniczny certyfikat nie zastąpi znajomości wewnętrznych zasad organizacji.

Program dopasowany do pracy, a nie jednakowy dla wszystkich

Wspólna podstawa powinna obejmować osoby korzystające z informacji i systemów organizacji, w tym współpracowników — odpowiednio do ich zadań i zakresu dostępu. Potrzebne jest wprowadzenie przed rozpoczęciem samodzielnej pracy, późniejsze utrwalanie wiedzy oraz aktualizacje po istotnych zmianach narzędzi, zasad lub zagrożeń. Częstotliwość należy uzasadnić potrzebami organizacji, zamiast ograniczać program do corocznego kursu realizowanego wyłącznie dla formalności.

Dalsza część przygotowania powinna wynikać z charakteru obowiązków. Finanse potrzebują ćwiczeń dotyczących prób wyłudzenia płatności, kadry — bezpiecznej pracy z danymi pracowniczymi, a zespoły techniczne — umiejętności właściwych dla utrzymywanych technologii. Kadra kierownicza również musi się szkolić: rozumieć konsekwencje zagrożeń, ograniczenia zabezpieczeń i znaczenie własnych decyzji. Nie powinna traktować edukacji bezpieczeństwa jako zadania przeznaczonego wyłącznie dla personelu.

Wymagania kompetencyjne, które można zweryfikować

Dla stanowisk istotnych dla bezpieczeństwa należy określić, co dana osoba ma wiedzieć i co powinna umieć wykonać. Wystarczy czytelne zestawienie wymagań przypisanych do zadań, uzupełnione oceną przygotowania i sposobem usunięcia stwierdzonych braków. Dyplomy i certyfikaty mogą być dowodem pomocniczym, lecz nie powinny automatycznie przesądzać o gotowości do pracy.

Kierownik powinien oczekiwać, że organizacja zapewni czas i środki na naukę oraz wsparcie doświadczonych osób tam, gdzie sam kurs nie wystarcza. Zrozumienie materiału można sprawdzać na krótkich scenariuszach zawodowych lub zadaniach praktycznych. Forma i język materiałów muszą być dostępne dla odbiorców; szkolenie niezrozumiałe dla uczestnika nie spełnia swojego celu.

Kultura bezpieczeństwa zaczyna się od reakcji przełożonego

Pracownik powinien wiedzieć, gdzie zadać pytanie i jak zgłosić podejrzaną sytuację — także wtedy, gdy sam popełnił błąd. Zgłoszenie w dobrej wierze nie powinno prowadzić do upokarzania ani automatycznego karania. Nie oznacza to pobłażania świadomemu łamaniu zasad, lecz stworzenie warunków, w których problemy nie są ukrywane ze strachu.

Dotyczy to również ćwiczeń i symulacji phishingu: mają uczyć, a nie publicznie wskazywać osoby, które dały się zwieść. Po ćwiczeniu potrzebne są wyjaśnienia i wskazówki. Równie ważny jest przykład przełożonych — jeżeli sami omijają zasady albo premiują szybkość kosztem bezpieczeństwa, formalny program szkoleniowy traci wiarygodność. Kierownik powinien więc wymagać spójności między tym, czego organizacja uczy, a tym, jak rzeczywiście pozwala pracować.

7. Monitoring i pomiar skuteczności: logowanie, monitoring, KPI/KRI, testy i przeglądy zarządcze

Kierownik powinien wymagać dowodów, że SZBI działa — nie tylko potwierdzenia, że wdrożono procedury i narzędzia. Raport o liczbie zarejestrowanych zdarzeń czy przeprowadzonych kontroli nie wystarcza. Powinien pokazywać, czy organizacja wykrywa zagrożenia, czy zabezpieczenia spełniają swoje zadanie oraz które słabości wymagają decyzji lub dodatkowych środków.

Logowanie i monitoring — zapis zdarzeń to dopiero początek

Logowanie służy rejestrowaniu zdarzeń, a monitoring — ich obserwacji i analizie w celu wykrywania nieprawidłowości. Samo gromadzenie dzienników nie oznacza więc, że organizacja zauważy podejrzaną aktywność. Potrzebne są reguły wykrywania, ustalone zasady obsługi alertów oraz sprawdzenie, czy informacje z istotnych systemów rzeczywiście docierają do osób odpowiedzialnych za ich ocenę.

Kierownik powinien oczekiwać uzasadnionego zakresu logowania, obejmującego w szczególności systemy istotne dla działalności oraz zdarzenia takie jak użycie uprawnień administracyjnych, zmiany konfiguracji czy nieudane próby logowania. Dzienniki wymagają ochrony przed nieuprawnioną zmianą i dostępem, a znaczniki czasu — spójności umożliwiającej odtworzenie przebiegu zdarzeń. Okres przechowywania należy ustalić na podstawie potrzeb analitycznych, ryzyka i mających zastosowanie wymagań prawnych, z uwzględnieniem ochrony danych osobowych.

Nadzór powinien obejmować również sam mechanizm monitorowania: brak logów z ważnego systemu lub niesprawny kanał powiadamiania to luka w widoczności, nawet jeśli raport nie pokazuje żadnych incydentów. Tryb pracy monitoringu powinien odpowiadać ryzyku i znaczeniu chronionych usług.

KPI i KRI — skuteczność działań a poziom zagrożenia

KPI pokazują, jak sprawnie działają procesy i zabezpieczenia; KRI sygnalizują poziom lub zmianę ekspozycji na ryzyko. To rozróżnienie pomaga uniknąć raportowania samej aktywności. Duża liczba obsłużonych alertów nie dowodzi skuteczności, jeżeli najpoważniejsze sygnały zbyt długo pozostają bez oceny.

• Przykładowe KPI: odsetek istotnych alertów ocenionych w przyjętym czasie, czas od wykrycia zdarzenia do jego weryfikacji, udział zaplanowanych testów zakończonych i udokumentowanych.
• Przykładowe KRI: udział krytycznych systemów pozostających poza skutecznym monitoringiem, liczba poważnych ustaleń po testach nierozwiązanych w terminie, czas utrzymywania się istotnych luk w zabezpieczeniach.

Każdy wskaźnik powinien mieć jednoznaczną definicję, źródło danych, osobę odpowiedzialną za raportowanie oraz próg wywołujący określone działanie. Kierownik potrzebuje trendu i kontekstu, nie pojedynczej wartości. Spadek liczby alertów może wynikać zarówno z poprawy bezpieczeństwa, jak i z awarii zbierania danych. Warto też sprawdzać rozkład wyników — średnia potrafi ukryć pojedyncze, bardzo długie opóźnienia dotyczące najważniejszych systemów.

Testy — weryfikacja zamiast deklaracji

Testy powinny potwierdzać działanie zabezpieczeń w ustalonym zakresie, natomiast audyty oceniać SZBI względem przyjętych kryteriów. Żadna z tych metod nie zastępuje drugiej. Kierownik powinien wymagać programu weryfikacji opartego na ryzyku, uwzględniającego także istotne zmiany i wcześniejsze ustalenia. W obszarze monitoringu szczególnie użyteczne jest sprawdzenie całej ścieżki: od kontrolowanego zdarzenia, przez zapis i wygenerowanie alertu, po jego zauważenie oraz prawidłową eskalację.

Każda istotna niezgodność lub słabość powinna prowadzić do działania z przypisanym właścicielem i terminem. Zamknięcie ustalenia wymaga dowodu skuteczności poprawki, a nie wyłącznie deklaracji jej wdrożenia. Gdy jest to uzasadnione, takim dowodem powinien być ponowny test.

Przegląd zarządczy — od wyników do decyzji

Przegląd zarządczy nie powinien ograniczać się do prezentacji wskaźników. Jego zadaniem jest ocena, czy SZBI pozostaje adekwatny, wystarczający i skuteczny wobec potrzeb organizacji. Powinien uwzględniać wyniki monitorowania, testów i audytów, stan wcześniejszych działań oraz zmiany wpływające na bezpieczeństwo.

Kierownik powinien wymagać regularnych przeglądów, a także dodatkowej oceny po istotnych zdarzeniach lub zmianach. Ich wynikiem mają być udokumentowane decyzje: co należy poprawić, jakie zasoby przyznać, kto odpowiada za wykonanie i kiedy nastąpi weryfikacja efektów. Dopiero takie powiązanie pomiaru z decyzją pozwala wykorzystać monitoring do rzeczywistego doskonalenia SZBI.

8. Narzędzia dla kierownika: pytania do CISO/IT, cykliczne artefakty i plan rozwoju SZBI

Kierownik nie musi samodzielnie oceniać konfiguracji zabezpieczeń. Powinien jednak umieć ustalić, czy organizacja rozpoznaje istotne zagrożenia, realizuje uzgodnione działania i potrafi wykazać ich skuteczność. Do tego potrzebuje trzech narzędzi: zestawu pytań kontrolnych, stałego pakietu informacji zarządczej oraz planu wdrożenia z jednoznacznymi kryteriami odbioru. Deklaracja „mamy procedurę” nie zastępuje dowodu, że procedura działa.

Pytania do CISO i IT, które prowadzą do decyzji

Rozmowa o SZBI powinna kończyć się ustaleniem, co wymaga działania, kto je podejmie i w jakim terminie. CISO przedstawia perspektywę bezpieczeństwa, IT wyjaśnia możliwości i ograniczenia techniczne, a właściciele procesów określają skutki biznesowe. Kierownik powinien oczekiwać wspólnego obrazu sytuacji, nie kilku niezależnych relacji.

• Co obecnie najbardziej zagraża realizacji naszych kluczowych usług? Odpowiedź powinna wskazywać możliwe skutki dla działalności, a nie wyłącznie listę problemów technicznych.
• Które ustalenia z poprzedniego przeglądu pozostają niewykonane i dlaczego? Należy wskazać opóźnienia, przeszkody oraz decyzje potrzebne do ich usunięcia.
• Na jakiej podstawie twierdzimy, że najważniejsze zabezpieczenia działają? Warto poprosić o wynik testu, próbkę zapisów lub udokumentowaną weryfikację zamiast samego opisu rozwiązania.
• Gdzie rzeczywista praktyka odbiega od przyjętych zasad? Odpowiedź powinna ujawniać także wyjątki, rozwiązania tymczasowe i obszary, których jeszcze nie sprawdzono.
• Jakiej decyzji oczekujecie ode mnie? Każda sprawa wymagająca rozstrzygnięcia powinna zawierać warianty działania, rekomendację, koszt i konsekwencje zwłoki.

Cykliczny pakiet informacji zamiast dokumentów na żądanie

Warto ustalić jeden, powtarzalny pakiet zarządczy: krótką informację o zmianach od poprzedniego przeglądu, status uzgodnionych działań, wykaz istotnych odstępstw oraz listę decyzji do podjęcia. Raport powinien odsyłać do materiałów źródłowych, ale nie przenosić całej dokumentacji operacyjnej na biurko kierownika.

Każda pozycja wymagająca działania powinna mieć właściciela, termin i kryterium zamknięcia. „Wdrożenie zabezpieczenia” jest zbyt ogólne. Kryterium odbioru powinno określać, jaki rezultat zostanie sprawdzony i jaki dowód potwierdzi jego osiągnięcie. Dzięki temu zadania nie znikają z raportu tylko dlatego, że ktoś oznaczył je jako wykonane. W Cognity łączymy teorię z praktyką – dlatego te zagadnienia rozwijamy także w formie ćwiczeń na szkoleniach.

Częstotliwość przeglądów należy dopasować do tempa zmian i sytuacji organizacji. W okresie wdrożenia przydatny może być miesięczny przegląd postępów. Nie zastępuje on jednak niezwłocznej eskalacji istotnych problemów. Z każdego spotkania powinien pozostać krótki zapis decyzji, odpowiedzialności i terminów.

Wdrożenie etapami: od MVP do dojrzałego systemu

MVP SZBI to pierwszy działający zakres systemu, a nie zgoda na pominięcie obowiązków. Etapowanie prac nie przesuwa terminów prawnych ani zobowiązań umownych. Na początku trzeba ustalić stan wyjściowy, obowiązki mające zastosowanie do organizacji oraz luki wymagające najpilniejszej reakcji.

Etap pierwszy — uruchomienie. Priorytetem jest objęcie najważniejszych obszarów rzeczywistym nadzorem i rozpoczęcie regularnego podejmowania decyzji. Warunkiem odbioru powinny być dowody wykonania uzgodnionych działań, nie sama liczba zatwierdzonych dokumentów.

Etap drugi — stabilizacja. Organizacja rozszerza zakres systemu, porządkuje wyjątki i sprawdza, czy przyjęte rozwiązania działają powtarzalnie. Kierownik powinien wymagać wykazania tej powtarzalności w kolejnych cyklach pracy, zamiast opierać ocenę na jednorazowym sukcesie.

Etap trzeci — doskonalenie. Usprawnienia i automatyzację wybiera się na podstawie ujawnionych słabości oraz nakładu pracy. Dojrzałość oznacza trafniejsze decyzje i skuteczniejsze działanie, nie coraz obszerniejszą dokumentację.

Przygotowanie do audytu lub kontroli

Przygotowanie należy zacząć od ustalenia kryteriów i zakresu oceny. Audyt certyfikacyjny, audyt wewnętrzny i kontrola organu nie są zamienne. W szczególności certyfikat ISO/IEC 27001 sam w sobie nie przesądza o spełnieniu wszystkich obowiązków wynikających z przepisów.

Praktycznym narzędziem jest indeks dowodów łączący wymaganie z dokumentem, zapisem wykonania i osobą odpowiedzialną. Przed oceną warto sprawdzić na wybranych próbkach, czy materiały są aktualne, dostępne i zgodne z praktyką. Najważniejsza jest spójność między tym, co organizacja deklaruje, robi i potrafi udowodnić. Ujawnione braki należy rzetelnie opisać wraz z planem naprawczym; nie należy uzupełniać historii zapisami sugerującymi działania, których nie wykonano.

AI a zarządzanie ryzykiem na budowie – przewidywanie opóźnień i problemów 07 października 2026

Power BI zaawansowany – optymalizacja raportów i poprawa ich wydajności 05 października 2026