Przegląd zarządzania ISO 27001 jako dowód dla zarządu w kontekście NIS2 i DORA

Jest 08:00 w poniedziałkowy poranek w lutym 2026 r. Maria, dyrektor ds. bezpieczeństwa informacji (CISO) szybko rosnącej europejskiej spółki fintech, otwiera wiadomość e-mail od dyrektora generalnego (CEO) o temacie: „PILNE: przygotowanie dla zarządu”. W załączniku znajduje się link do informacji o wielomilionowej sankcji w euro nałożonej na podstawie Dyrektywy NIS2, dotyczącej nie tylko nieskutecznych zabezpieczeń, lecz także zaniedbań organu zarządzającego.

Pytanie CEO jest krótkie i niewygodne:

„Czy możemy udowodnić, że zarząd aktywnie nadzoruje ryzyko cyberbezpieczeństwa, a nie tylko otrzymuje aktualizacje z IT?”

O 08:30 dyrektor finansowy (CFO) dołącza kwestionariusz audytu klienta. Przewodniczący rady chce jednostronicowego podsumowania rozliczalności za cyberbezpieczeństwo przed kolejnym posiedzeniem komitetu ryzyka. Dyrektor technologiczny (CTO) pyta, czy incydent u dostawcy zmienia pakiet dowodowy dla klientów w kontekście DORA. Tymczasem Maria patrzy na cztery kwestie, które na pierwszy rzut oka wyglądają operacyjnie: nierozwiązany wyjątek dotyczący dostępu uprzywilejowanego, dwa opóźnione działania korygujące, niepowodzenie ćwiczenia typu tabletop oraz lukę w umowie z dostawcą.

To nie są odrębne problemy. To problemy z dowodami ładu zarządczego.

W 2026 r. organizacje podlegające NIS2, DORA, GDPR, programom zapewnienia dla klientów oraz rygorowi certyfikacji ISO/IEC 27001:2022 mierzą się z pytaniem ostrzejszym niż „Czy mamy zabezpieczenia?”.

Prawdziwe pytanie brzmi:

Czy kierownictwo potrafi wykazać, że dokonało przeglądu ryzyka cyberbezpieczeństwa, zrozumiało jego konsekwencje, podjęło decyzje, przypisało działania, sfinansowało działania naprawcze, zaakceptowało ryzyko szczątkowe tam, gdzie było to uzasadnione, oraz monitorowało realizację?

Taki dowód nie wynika wyłącznie z pliku PDF z polityką. Wynika z uporządkowanego przeglądu zarządzania ISO/IEC 27001:2022 pkt 9.3, opartego na danych wejściowych, protokołach, decyzjach, zapisach akceptacji ryzyka, działaniach korygujących oraz śladach dowodowych.

Dlaczego ISO 27001 pkt 9.3 jest dziś dowodem dla zarządu

Słaby przegląd zarządzania to przygotowana w pośpiechu prezentacja, kilka metryk i podpis. Silny przegląd zarządzania to kontrolowane zdarzenie ładu zarządczego, w którym decyzje kierownictwa stają się dowodami.

ISO/IEC 27001:2022 pkt 9.3 wymaga, aby najwyższe kierownictwo przeglądało system zarządzania bezpieczeństwem informacji w zaplanowanych odstępach czasu w celu zapewnienia jego ciągłej przydatności, adekwatności i skuteczności. Przegląd musi uwzględniać wcześniejsze działania, zmiany kwestii wewnętrznych i zewnętrznych, zmiany potrzeb i oczekiwań stron zainteresowanych, informacje zwrotne dotyczące wyników, wyniki audytów, realizację celów, wyniki oceny ryzyka, status postępowania z ryzykiem oraz możliwości ciągłego doskonalenia.

To właśnie takiej struktury oczekują dziś od ładu zarządczego cyberbezpieczeństwem zarządy, organy regulacyjne, klienci i audytorzy.

W przypadku podmiotów kluczowych i ważnych objętych NIS2, Article 20 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie oraz odbywały szkolenia. Article 21 wymaga proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, bezpiecznego rozwoju oprogramowania, oceny skuteczności, cyberhigieny, kryptografii, bezpieczeństwa kadr, kontroli dostępu, zarządzania aktywami, MFA tam, gdzie jest to właściwe, oraz działań korygujących bez zbędnej zwłoki.

W przypadku podmiotów finansowych DORA przypisuje ład zarządczy ryzykiem ICT bezpośrednio organowi zarządzającemu. DORA Article 5 wymaga, aby organ zarządzający definiował, zatwierdzał i nadzorował ramy zarządzania ryzykiem ICT oraz pozostawał za nie odpowiedzialny. Obejmuje to tolerancję ryzyka ICT, plany ciągłości działania i odtwarzania, plany audytów, budżet, szkolenia, polityki dotyczące zewnętrznych dostawców ICT, kanały zgłaszania poważnych incydentów oraz środki korygujące. Article 6 wymaga udokumentowanych ram zarządzania ryzykiem ICT, które są przeglądane co najmniej raz w roku oraz po poważnych incydentach związanych z ICT, instrukcjach nadzorczych, testach, audytach lub istotnych zmianach.

GDPR dodaje warstwę rozliczalności. Article 5(2) wymaga, aby administratorzy byli odpowiedzialni za przestrzeganie zasad ochrony danych i potrafili wykazać tę zgodność. Article 32(1)(d) oczekuje procesu regularnego testowania, oceniania i ewaluacji skuteczności środków technicznych i organizacyjnych.

Prawidłowo zaprojektowany przegląd zarządzania jest miejscem, w którym te obowiązki się zbiegają.

Presja regulacyjna stojąca za agendą przeglądu

NIS2 i DORA nie posługują się identycznym językiem. DORA pełni także funkcję sektorowego aktu prawnego UE dla objętych nim podmiotów finansowych w zakresie nakładających się obowiązków dotyczących cyberbezpieczeństwa i raportowania. Oba akty prowadzą jednak do tego samego rezultatu w obszarze ładu zarządczego: najwyższe kierownictwo musi zatwierdzać, nadzorować, zapewniać zasoby i korygować zarządzanie ryzykiem cybernetycznym.

NIS2 ma szerokie zastosowanie do średnich i większych podmiotów w sektorach objętych regulacją, a w niektórych przypadkach niezależnie od wielkości. Załącznik I obejmuje dostawców infrastruktury cyfrowej, takich jak dostawcy usług chmurowych, dostawcy usług centrów danych, dostawcy sieci dostarczania treści, dostawcy usług zaufania, dostawcy publicznych usług łączności elektronicznej, dostawcy usług zarządzanych oraz dostawcy zarządzanych usług bezpieczeństwa. Państwa członkowskie miały obowiązek ustanowić wykazy podmiotów kluczowych i ważnych do 17 kwietnia 2025 r.

Stawka egzekwowania przepisów jest znacząca. W przypadku naruszeń związanych ze środkami zarządzania ryzykiem cyberbezpieczeństwa z Article 21 lub zgłaszaniem incydentów z Article 23 maksymalne administracyjne kary pieniężne mogą wynieść co najmniej 10 000 000 EUR albo 2% światowego rocznego obrotu w przypadku podmiotów kluczowych oraz co najmniej 7 000 000 EUR albo 1,4% światowego rocznego obrotu w przypadku podmiotów ważnych, w zależności od tego, która kwota jest wyższa.

DORA obowiązuje od 17 stycznia 2025 r. i obejmuje szeroki ekosystem sektora finansowego, w tym instytucje kredytowe, instytucje płatnicze, instytucje pieniądza elektronicznego, firmy inwestycyjne, dostawców usług w zakresie kryptoaktywów, ubezpieczycieli, reasekuratorów, systemy obrotu, agencje ratingowe, dostawców usług finansowania społecznościowego, repozytoria sekurytyzacji oraz zewnętrznych dostawców usług ICT. DORA jest proporcjonalna, ale proporcjonalność nie oznacza nieformalności. Nawet mniejsze podmioty finansowe potrzebują zapisów pokazujących, że ład zarządczy ryzykiem ICT jest skalowany, świadomy, udokumentowany i poddawany przeglądom.

Dlatego przegląd zarządzania nie może pozostać formalnością certyfikacyjną. Stał się jednym z najbardziej praktycznych mechanizmów dowodowych dla rozliczalności NIS2, ładu zarządczego ryzykiem ICT w DORA, rozliczalności GDPR oraz due diligence klientów.

Fundament polityk Clarysec dla dyscypliny przeglądów

Clarysec traktuje przegląd zarządzania jako pakiet dowodowy dla zarządu, a nie ceremonialne coroczne spotkanie.

Polityka bezpieczeństwa informacji wyraźnie wskazuje przegląd zarządzania ISO 27001:

Działania w ramach przeglądu zarządzania (zgodnie z ISO/IEC 27001 pkt 9.3) należy przeprowadzać co najmniej raz w roku i muszą one obejmować:

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.3.

Ta sama polityka definiuje oczekiwania dowodowe:

Przegląd kluczowych wskaźników efektywności bezpieczeństwa (KPI), incydentów, ustaleń z audytu oraz statusu ryzyka

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.3.2.

I łączy przegląd z decyzjami kierownictwa:

Decyzje dotyczące aktualizacji zakresu, zabezpieczeń i alokacji zasobów

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.3.3.

Ten ostatni punkt jest kluczowy. Przegląd zarządzania nie jest prezentacją. Jest forum decyzyjnym.

Polityka ról i odpowiedzialności w ramach ładu zarządczego dodaje zasadę identyfikowalności:

Ład zarządczy musi wspierać integrację z innymi dyscyplinami (np. ryzykiem, prawem, IT, HR), a decyzje dotyczące SZBI muszą być możliwe do prześledzenia do ich źródła (np. zapisów audytowych, rejestrów przeglądów, protokołów spotkań).

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.5.

Polityka przypisuje także odpowiedzialność za eskalację:

Uczestniczy w przeglądach zarządzania SZBI i eskaluje decyzje wymagające zatwierdzenia na poziomie zarządu.

Z sekcji „Role i odpowiedzialności”, klauzula polityki 4.1.3.

W mniejszych organizacjach tę samą logikę ładu zarządczego należy skalować, a nie ignorować. Polityka ról i odpowiedzialności w ramach ładu zarządczego dla MŚP stanowi:

Wszystkie istotne decyzje dotyczące bezpieczeństwa, wyjątki i eskalacje muszą być rejestrowane oraz możliwe do prześledzenia.

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.5.

Polityka audytu i monitorowania zgodności dla MŚP zapewnia, że ustalenia z działań zapewniających trafiają do kierownictwa:

Ustalenia z audytu i aktualizacje statusu muszą być uwzględniane w procesie przeglądu zarządzania SZBI.

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.4.3.

A Polityka zarządzania ryzykiem dla MŚP ustanawia rytm dla wysokich ryzyk:

Przegląda najwyższe ryzyka kwartalnie z Koordynatorem ds. Ryzyka.

Z sekcji „Role i odpowiedzialności”, klauzula polityki 4.1.3.

Rezultatem jest praktyczny rytm: kwartalny przegląd najwyższych ryzyk, roczny lub zaplanowany przegląd zarządzania zgodny z pkt 9.3 oraz przeglądy uruchamiane po istotnych incydentach, audytach, testach odporności, niepowodzeniach dostawców, zmianach regulacyjnych lub istotnych zmianach biznesowych.

Zbuduj pakiet dowodowy dla zarządu przed spotkaniem

Zenith Blueprint: 30-etapowa mapa drogowa audytora omawia przegląd zarządzania w fazie Audyt, przegląd i doskonalenie, krok 28: Przegląd zarządzania. Zaleca zespołom przygotowanie wymaganych danych wejściowych przed spotkaniem:

ISO 27001 określa kilka wymaganych danych wejściowych do przeglądu zarządzania. Przygotuj krótki raport
lub prezentację obejmującą te punkty:

Z fazy Audyt, przegląd i doskonalenie, krok 28: Przegląd zarządzania.

Blueprint podkreśla wcześniejsze działania, zmiany kwestii zewnętrznych i wewnętrznych, wyniki i skuteczność SZBI, wyniki audytów, wyniki monitorowania i pomiarów, cele bezpieczeństwa, incydenty, niezgodności, możliwości doskonalenia, potrzeby zasobowe oraz działania następcze po wcześniejszych decyzjach.

Ostrzega również, że przegląd musi prowadzić do działania:

Decyzje i działania: To kluczowe — przegląd zarządzania nie jest tylko prezentacją;
chodzi w nim o podejmowanie decyzji.

Z fazy Audyt, przegląd i doskonalenie, krok 28: Przegląd zarządzania.

Pakiet dowodowy dla zarządu powinien być wystarczająco zwięzły dla kadry kierowniczej, ale wystarczająco szczegółowy dla audytorów.

Przekształć dane wejściowe ISO w dowody dla NIS2 i DORA

Fintech Marii potrzebuje jednej agendy, która spełni oczekiwania audytorów certyfikacyjnych ISO, klientów dostosowanych do DORA, pytań o zakres NIS2 oraz wymagań nadzoru zarządu. Najprościej osiągnąć to przez przełożenie każdego wejścia pkt 9.3 na pytanie z zakresu ładu zarządczego.

Ostatni wiersz nie zastępuje wymaganych danych wejściowych ISO 27001 do przeglądu. To praktyczne rozszerzenie Clarysec na potrzeby ładu zarządczego w 2026 r., ponieważ DORA, NIS2 i rzeczywista rozliczalność zarządu wymagają dowodów, że kierownictwo rozważyło, czy bezpieczeństwo dysponuje wystarczającą liczbą osób, środkami finansowymi, narzędziami i uprawnieniami.

90-minutowy przegląd zarządzania dla dostawcy fintech SaaS

Rozważmy spółkę Marii: dostawcę fintech SaaS z klientami w UE. Oferuje usługi monitorowania transakcji, korzysta z dużego dostawcy chmury, opiera się na zewnętrznym SOC, przetwarza dane osobowe i niedawno wdrożyła dwóch nowych klientów płatniczych. Przygotowuje się do audytu nadzoru ISO/IEC 27001:2022, przeglądu klienta dostosowanego do DORA oraz oceny zakresu NIS2.

Skoncentrowany 90-minutowy przegląd zarządzania może wyglądać następująco.

1. Zacznij od obowiązków i zmian kontekstu

Dla MŚP Polityka zgodności prawnej i regulacyjnej dla MŚP zapewnia prosty punkt wyjścia:

Dyrektor Generalny (GM) musi utrzymywać prosty, uporządkowany Rejestr zgodności zawierający:

Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.1.1.

Pakiet przeglądowy powinien podsumować, czy organizacja mieści się w zakresie NIS2, czy DORA ma zastosowanie bezpośrednie lub przez zobowiązania przeniesione od klienta, czy zmieniło się przetwarzanie danych w ramach GDPR oraz czy zmieniły się umowne obowiązki bezpieczeństwa.

Przykłady:

• Nowa umowa z klientem z UE wymaga powiadomienia klienta o incydencie bezpieczeństwa w ciągu 72 godzin.
• Wniosek klienta o due diligence dostosowany do DORA wymaga rejestrów stron trzecich ICT, dowodów strategii wyjścia oraz zapisów eskalacji incydentów.
• Ocena NIS2 identyfikuje potencjalne ryzyko klasyfikacji, ponieważ jedna usługa wspiera działania zarządzanego bezpieczeństwa w państwie członkowskim.
• Nowa funkcja analityczna zmienia inwentarz danych GDPR, ponieważ przetwarza identyfikatory online.

Decyzje kierownictwa powinny zatwierdzić aktualizację rejestru zgodności, przypisać funkcji prawnej i GRC walidację klasyfikacji NIS2 z lokalnym doradcą prawnym oraz wymagać pakietu dowodowego DORA dla klientów do następnego kwartału.

2. Przedstaw decyzje dotyczące ryzyka i Deklaracji stosowania

Faza zarządzania ryzykiem w Zenith Blueprint, krok 13: Planowanie postępowania z ryzykiem i Deklaracja stosowania, podkreśla zatwierdzenie przez kierownictwo:

Decyzje dotyczące postępowania z ryzykiem oraz SoA powinny być przeglądane i zatwierdzane przez najwyższe kierownictwo.

Z fazy zarządzania ryzykiem, krok 13: Planowanie postępowania z ryzykiem i Deklaracja stosowania.

Przegląd nie powinien zasypywać zarządu każdym ryzykiem. Powinien pokazać najważniejsze ryzyka, status postępowania, wyjątki, opóźnione działania oraz ryzyka szczątkowe wymagające zatwierdzenia.

Tworzy to identyfikowalny łańcuch od oceny ryzyka, przez postępowanie z ryzykiem, po decyzję kierownictwa.

3. Przejrzyj incydenty, sytuacje bliskie incydentowi i gotowość raportowania

NIS2 Article 23 wymaga etapowego raportowania znaczących incydentów, w tym wczesnego ostrzeżenia w ciągu 24 godzin, powiadomienia w ciągu 72 godzin oraz raportu końcowego w ciągu miesiąca od powiadomienia o incydencie, wraz z raportowaniem postępu w przypadku incydentów trwających. DORA Articles 17 to 19 wymagają wykrywania, klasyfikacji, eskalacji, komunikacji, raportowania, analizy przyczyny źródłowej i doskonalenia w odniesieniu do incydentów związanych z ICT.

Przegląd zarządzania powinien obejmować znaczące incydenty, sytuacje bliskie incydentowi, wyniki klasyfikacji, przyczyny źródłowe, czas wykrycia, czas eskalacji, czas odtworzenia, gotowość do powiadamiania klientów, gotowość do raportowania organom, wnioski oraz działania korygujące.

Zenith Blueprint, w fazie Zabezpieczenia w działaniu, krok 16: Bezpieczeństwo osobowe II, wyjaśnia, dlaczego zgłoszenia pracowników muszą zasilać ład zarządczy:

Na koniec Control 6.8 musi zasilać cykl ciągłego doskonalenia SZBI. Zgłoszenia
generowane przez personel powinny być przeglądane podczas przeglądu zarządzania (pkt 9.3) i
wykorzystywane do identyfikacji nieskuteczności polityk, takich jak zakończenie współpracy, zwrot aktywów lub naruszenia NDA.

Z fazy Zabezpieczenia w działaniu, krok 16: Bezpieczeństwo osobowe II.

Jeśli konto byłego pracownika pozostało aktywne po zakończeniu współpracy, zarząd nie powinien traktować tego jako pojedynczego zgłoszenia. To dowód możliwej słabości w HR, IT, kontroli dostępu, zarządzaniu aktywami, monitorowaniu i działaniach korygujących.

4. Przejrzyj dostawców, chmurę i gotowość wyjścia

DORA Article 28 czyni ryzyko ICT związane ze stronami trzecimi częścią ram zarządzania ryzykiem ICT. Podmioty finansowe pozostają w pełni odpowiedzialne za zgodność, gdy usługi ICT są zlecane na zewnątrz. Muszą utrzymywać aktualny rejestr umów ICT, rozróżniać funkcje krytyczne lub ważne, przeprowadzać due diligence, zarządzać ryzykiem koncentracji, zabezpieczać prawa do audytu i inspekcji oraz utrzymywać strategie wyjścia.

NIS2 Article 21 również wymaga bezpieczeństwa łańcucha dostaw, w tym bezpieczeństwa relacji z dostawcami, podatności specyficznych dla dostawców, praktyk cyberbezpieczeństwa dostawców oraz środków korygujących.

W przeglądzie zarządzania raportowanie dostawców nie może być załącznikiem zakupowym. Musi stanowić dowód dla zarządu.

Uwzględnij zmiany dotyczące dostawców krytycznych, status due diligence, luki umowne, przegląd współodpowiedzialności w chmurze, ryzyko koncentracji, wyniki strategii wyjścia, współpracę dostawców przy incydentach oraz działania korygujące wynikające z ocen dostawców. Jeśli kierownictwo zatwierdza dalsze korzystanie z dostawcy wysokiego ryzyka, protokół powinien odnotować uzasadnienie, środki kompensujące, datę przeglądu oraz odpowiedzialnego właściciela.

Zarząd Marii otrzymuje jedną konkretną kwestię dotyczącą dostawcy: kluczowy dostawca platformy doświadczył niewielkiego incydentu, który nie podlegał zgłoszeniu. Dane klientów nie zostały naruszone, ale zdarzenie ujawniło ryzyko koncentracji. CEO przypisuje CTO wykonanie studium wykonalności drugiego dostawcy do następnego kwartału i przeznacza 25 000 EUR na ocenę. Ta jedna udokumentowana decyzja wykazuje nadzór nad ryzykiem łańcucha dostaw, alokację zasobów i działania następcze.

Jak Zenith Controls łączy dowody

Zenith Controls: przewodnik po zgodności przekrojowej Clarysec pomaga zespołom wyjaśnić, dlaczego dowody zabezpieczeń ISO mają znaczenie w różnych frameworkach.

W przypadku przeglądu zarządzania ISO/IEC 27002:2022 zabezpieczenie 5.4, Obowiązki kierownictwa, jest kotwicą ładu zarządczego. Wspiera kierunek wyznaczany przez kierownictwo, rozliczalność, zapewnienie zasobów i nadzór. Zenith Controls łączy zabezpieczenie 5.4 ze wspierającymi zabezpieczeniami ISO/IEC 27002:2022, które często pojawiają się w dowodach z przeglądu zarządzania.

Ten zestaw zabezpieczeń daje Marii spójną opowieść o zgodności przekrojowej. Dowody z przeglądu zarządzania mogą wspierać certyfikację ISO/IEC 27001:2022, nadzór z NIS2 Article 20, środki zarządzania ryzykiem z NIS2 Article 21, ład zarządczy ICT z DORA Article 5, przegląd ram zarządzania ryzykiem ICT z DORA Article 6, testowanie cyfrowej odporności operacyjnej z DORA Articles 24 to 27, GDPR Article 32(1)(d), wyniki GOVERN w NIST CSF 2.0 oraz cele ładu zarządczego COBIT 2019.

Niezależny przegląd i monitorowanie zgodności zasługują na szczególną uwagę. Przegląd zarządzania bez niezależnych dowodów staje się samoopisem. ISO/IEC 27002:2022 zabezpieczenie 5.35 daje zarządowi obiektywne zapewnienie poprzez audyty wewnętrzne, oceny zewnętrzne, podsumowania testów penetracyjnych, obserwacje z audytów certyfikacyjnych oraz przeglądy skuteczności zabezpieczeń. Zabezpieczenie 5.36 przekształca „mamy politykę” w „wiemy, czy ludzie i systemy stosują politykę”.

Jak audytorzy przetestują Twój przegląd zarządzania

Przegląd zarządzania zgodny z pkt 9.3 jest jednym z pierwszych miejsc, do których zaglądają audytorzy, gdy oceniają, czy ład zarządczy jest rzeczywisty. Różni audytorzy zadają różne pytania, ale wszyscy szukają identyfikowalności.

Typowa słabość nie polega na tym, że spotkanie się nie odbyło. Polega na tym, że spotkanie niczego nie zmieniło. Audytorzy chcą widzieć decyzje, właścicieli, terminy, oczekiwane dowody i zapisy zamknięcia.

Wyniki, które dowodzą nadzoru kierownictwa

Dane wejściowe tworzą przegląd. Wyniki dowodzą ładu zarządczego.

Co najmniej zapis z przeglądu zarządzania powinien obejmować:

1. Zatwierdzone decyzje
   Przykłady obejmują zatwierdzenie gotowości do certyfikacji, aktualizację zakresu SZBI, zmianę procesów zgłaszania incydentów, wymaganie naprawy umowy z dostawcą lub akceptację ryzyka szczątkowego do określonej daty.

2. Przypisane działania
   Każde działanie wymaga właściciela, terminu realizacji, priorytetu, oczekiwanego dowodu i rytmu przeglądu.

3. Zapisy akceptacji ryzyka
   Zaakceptowane ryzyka powinny wskazywać właściciela ryzyka, uzasadnienie, poziom ryzyka szczątkowego, środki kompensujące, datę wygaśnięcia i próg eskalacji.

4. Decyzje zasobowe
   Należy odnotować budżet, etaty, narzędzia, szkolenia, wsparcie audytu zewnętrznego, ocenę prawną, ćwiczenia typu tabletop lub działania zapewnienia dotyczące dostawców.

5. Aktualizacje polityk i zabezpieczeń
   Należy ująć zmiany dotyczące kontroli dostępu, reagowania na incydenty, ciągłości działania, zarządzania dostawcami, szyfrowania, bezpiecznego rozwoju oprogramowania, rejestrowania, zarządzania podatnościami lub okresu przechowywania danych.

6. Zatwierdzenia działań korygujących
   Niezgodności i ustalenia z audytu powinny stać się działaniami korygującymi z określonym właścicielem, terminem i oczekiwaniami dowodowymi.

7. Mechanizm działań następczych
   Kolejny przegląd powinien rozpoczynać się od statusu tych decyzji.

Dla MŚP Polityka bezpieczeństwa informacji dla MŚP wzmacnia potrzebę powiązania certyfikacji, regulacji i zmian biznesowych:

Ta polityka musi być przeglądana przez Dyrektora Generalnego (GM) co najmniej raz w roku, aby zapewnić ciągłą zgodność z wymaganiami certyfikacyjnymi ISO/IEC 27001, zmianami regulacyjnymi (takimi jak GDPR, NIS2 i DORA) oraz zmieniającymi się potrzebami biznesowymi.

Z sekcji „Wymagania dotyczące przeglądu i aktualizacji”, klauzula polityki 9.1.1.

To zdanie oddaje realia 2026 r. Przegląd zarządzania musi łączyć SZBI, zmianę regulacyjną, klientów, dostawców, incydenty, ryzyko, zasoby i strategię biznesową w jedną pętlę ładu zarządczego.

Typowe niepowodzenia przeglądu zarządzania w 2026 r.

Najczęstsze niepowodzenia są przewidywalne.

Po pierwsze, przegląd jest zbyt techniczny. Najwyższe kierownictwo otrzymuje liczby podatności i wolumeny alertów, ale nie ryzyko biznesowe, ekspozycję regulacyjną, wpływ na klienta ani warianty decyzji.

Po drugie, brakuje rejestru decyzji. W protokole zapisano „omówiono ryzyko dostawcy”, ale nie odnotowano, czy kierownictwo zaakceptowało ryzyko, wymagało działań naprawczych, zatwierdziło budżet albo przypisało termin.

Po trzecie, akceptacja ryzyka szczątkowego jest nieformalna. Ryzyko pozostaje otwarte przez miesiące, ponieważ „biznes o nim wie”, ale nie ma zatwierdzenia właściciela, uzasadnienia, daty wygaśnięcia ani wyzwalacza przeglądu.

Po czwarte, ustalenia z audytu nie docierają do kierownictwa. Raporty audytu wewnętrznego pozostają w folderach GRC, podczas gdy kierownictwo widzi tylko zielone podsumowanie statusu.

Po piąte, dostawcy i dostawcy chmury są traktowani oddzielnie od wyników SZBI. W ramach DORA i NIS2 ryzyko ICT związane ze stronami trzecimi stanowi kluczowy dowód ładu zarządczego.

Po szóste, incydenty są raportowane jako zdarzenia operacyjne, ale nie są przeglądane pod kątem systemowego doskonalenia. Przyczyny źródłowe, wnioski i działania korygujące muszą zasilać przegląd zarządzania.

Po siódme, brakuje rejestru wcześniejszych działań. Audytorzy zapytają, co stało się z decyzjami z ubiegłego roku. Jeśli odpowiedź jest rozproszona po e-mailach i zgłoszeniach, historia ładu zarządczego słabnie.

Jedna pętla ładu zarządczego, wiele obowiązków

Praktyczny model Clarysec jest prosty:

1. Zakres i obowiązki
   Wykorzystaj zakres SZBI, strony zainteresowane, rejestr zgodności, obowiązki wobec klientów oraz zależności od dostawców, aby określić, co przegląd musi obejmować.

2. Dowody ryzyka i zabezpieczeń
   Wykorzystaj rejestr ryzyk, Deklarację stosowania, dowody wdrożenia zabezpieczeń, KPI oraz monitorowanie zgodności.

3. Dane wejściowe zapewnienia
   Uwzględnij audyty wewnętrzne, niezależne przeglądy, testy penetracyjne, oceny dostawców, audyty klientów i ustalenia certyfikacyjne.

4. Dane wejściowe odporności operacyjnej
   Uwzględnij incydenty, sytuacje bliskie incydentowi, testy ciągłości działania, wyniki kopii zapasowych, ćwiczenia odtwarzania po awarii, wnioski z zarządzania kryzysowego i gotowość raportowania.

5. Decyzje kierownictwa
   Rejestruj akceptację ryzyka, alokację zasobów, zmiany zakresu, zmiany zabezpieczeń, decyzje dotyczące dostawców, działania korygujące i cele strategiczne.

6. Zachowanie dowodów
   Przechowuj protokoły, pakiety, zatwierdzenia, akceptacje ryzyka i dowody zamknięcia w kontrolowanym repozytorium.

7. Rytm działań następczych
   Przeglądaj wysokie ryzyka kwartalnie, prowadź zaplanowane przeglądy zarządzania zgodne z pkt 9.3 i uruchamiaj dodatkowe przeglądy po istotnych incydentach, zmianach dostawców, audytach, testach lub zmianach regulacyjnych.

W ten sposób jeden przegląd zarządzania może obsłużyć certyfikację ISO/IEC 27001:2022, rozliczalność organu zarządzającego w NIS2, ład zarządczy ryzykiem ICT w DORA, rozliczalność GDPR, przegląd GOVERN w NIST CSF, nadzór zarządu w COBIT 2019 oraz due diligence klientów.

Przygotuj kolejny przegląd zarządzania do audytu

Zarząd Marii nie potrzebował kolejnego technicznego pulpitu. Potrzebował możliwych do obrony dowodów, że ryzyko cyberbezpieczeństwa zostało przejrzane, zrozumiane, rozstrzygnięte, sfinansowane i zmniejszone.

Twoja organizacja potrzebuje tego samego.

Zacznij w tym miesiącu:

• Zbuduj pakiet dowodowy dla pkt 9.3.
• Przypisz każdy punkt agendy do ryzyka, obowiązku, KPI, ustalenia z audytu, incydentu, kwestii dostawcy lub działania korygującego.
• Rejestruj każdą decyzję z właścicielem, terminem, uzasadnieniem i oczekiwanym dowodem.
• Użyj rejestru wcześniejszych działań jako pierwszego punktu agendy w kolejnym przeglądzie.
• Zachowaj protokoły, zatwierdzenia, akceptacje ryzyka i zapisy zamknięcia w kontrolowanym repozytorium.

Clarysec może pomóc szybko wdrożyć ten model, wykorzystując Zenith Blueprint, zestaw polityk Clarysec oraz Zenith Controls jako kompas zgodności przekrojowej dla ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF, COBIT 2019 i gotowości do audytu.

Jeśli Twój przegląd zarządzania nadal jest obowiązkiem wykonywanym wyłącznie dla zgodności, czas przekształcić go w strategiczny element ładu zarządczego. Pobierz zestawy narzędzi Clarysec, przygotuj pakiet dowodowy dla zarządu i spraw, aby kolejny przegląd stał się dowodem, że kierownictwo rzeczywiście nadzoruje ryzyko cyberbezpieczeństwa.