Mapowanie dowodów NIS2 do ISO 27001:2022 na 2026 rok

Problem NIS2 w 2026 roku nie dotyczy świadomości, lecz dowodów

Jest poniedziałek rano, 08:35. Maria, niedawno powołana dyrektor ds. bezpieczeństwa informacji (CISO) szybko rosnącego dostawcy usług B2B w chmurze obliczeniowej i usług zarządzanych, dołącza do kwartalnego posiedzenia zarządu poświęconego ryzyku. Na laptopie ma otwartą obszerną ocenę luk NIS2. Pierwszy slajd wygląda uspokajająco. Polityki istnieją. Ocena ryzyka istnieje. Reagowanie na incydenty jest udokumentowane. Dostawcy są ujęci w wykazie. Skany podatności są wykonywane co miesiąc.

Wtedy przewodniczący zadaje pytanie, które zmienia przebieg spotkania:

„Czy możemy udowodnić, że te środki działały w ostatnim kwartale, i czy możemy pokazać, które zabezpieczenia ISO 27001:2022, właściciele i zapisy wspierają każdy obowiązek NIS2?”

W sali zapada cisza.

Dział prawny wie, że spółka mieści się w zakresie NIS2, ponieważ świadczy zarządzane usługi ICT i usługi w chmurze obliczeniowej dla klientów z UE. Zespół ds. zgodności wie, że Article 21 wymaga technicznych, operacyjnych i organizacyjnych środków zarządzania ryzykiem cyberbezpieczeństwa. Operacje wiedzą, że zespół wdraża poprawki, przegląda dostawców i monitoruje logi. Dowody są jednak rozproszone po systemach zgłoszeniowych, eksportach z SIEM, folderach z politykami, arkuszach kalkulacyjnych, konsolach chmurowych, portalach dostawców i notatkach ze spotkań.

Nikt nie potrafi szybko pokazać możliwego do obrony łańcucha od NIS2 Article 21 do zakresu ISO 27001:2022, ryzyka, zabezpieczenia, polityki, właściciela, procedury, zapisu operacyjnego i ustalenia z audytu.

To jest realne wyzwanie na 2026 rok.

Wiele organizacji nie pyta już: „Czy jesteśmy w zakresie NIS2?”. Zadają trudniejsze pytanie: „Czy możemy udowodnić, że nasze techniczne środki NIS2 rzeczywiście działają?”. Odpowiedzią nie może być jednorazowy arkusz mapowania. Musi nią być żywy model operacyjny w ramach systemu zarządzania bezpieczeństwem informacji (SZBI), w którym obowiązki prawne są przekładane na ryzyka, polityki, zabezpieczenia, właścicieli, dowody i ciągłe doskonalenie.

Model Clarysec wykorzystuje ISO/IEC 27001:2022 jako szkielet systemu zarządzania, NIS2 Article 21 jako zestaw obowiązków regulacyjnych, klauzule polityk jako operacyjny zbiór zasad, Zenith Blueprint: 30-etapowa mapa drogowa audytora jako ścieżkę wdrożenia oraz Zenith Controls: przewodnik po zgodności międzyramowej jako mapę zgodności między ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF i podejściem zapewniającym w stylu COBIT.

Zacznij od zakresu, ponieważ dowody NIS2 zaczynają się przed zabezpieczeniami

Częstym błędem w NIS2 jest przechodzenie bezpośrednio do MFA, logowania, reagowania na incydenty i zarządzania podatnościami przed potwierdzeniem zakresu podmiotu, zakresu usług i zakresu jurysdykcyjnego.

NIS2 ma zastosowanie do objętych zakresem podmiotów publicznych i prywatnych w regulowanych sektorach, które spełniają kryteria wielkości i rodzaju działalności, przy czym niektóre typy podmiotów są objęte niezależnie od wielkości. Istotne kategorie cyfrowe i ICT obejmują dostawców usług przetwarzania w chmurze obliczeniowej, dostawców usług centrów danych, dostawców sieci dostarczania treści, dostawców usług zaufania, dostawców publicznie dostępnych usług łączności elektronicznej, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, internetowe platformy handlowe, wyszukiwarki internetowe i platformy społecznościowe.

Dla dostawców usług chmurowych, platform SaaS, MSP, MSSP i dostawców infrastruktury cyfrowej praca nad zakresem nie jest teoretyczna. Article 3 wymaga, aby państwa członkowskie rozróżniały podmioty kluczowe i ważne. Article 27 wymaga, aby ENISA prowadziła rejestr kilku dostawców cyfrowych i ICT, w tym dostawców usług DNS, rejestrów nazw TLD, dostawców usług rejestracji nazw domen, dostawców usług przetwarzania w chmurze obliczeniowej, dostawców usług centrów danych, dostawców sieci dostarczania treści, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, internetowych platform handlowych, wyszukiwarek internetowych i platform społecznościowych.

ISO 27001:2022 zapewnia właściwą strukturę. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała kwestie zewnętrzne i wewnętrzne, zainteresowane strony, wymagania, interfejsy i zależności, a następnie zdefiniowała zakres SZBI. NIS2 musi zostać ujęte właśnie tutaj, a nie pozostawione w notatce prawnej.

Praktyczny zapis zakresu NIS2 powinien obejmować:

• analizę osoby prawnej i ustanowienia w UE,
• sektor NIS2 i kategorię usługi,
• status podmiotu kluczowego lub ważnego, jeżeli został potwierdzony prawem krajowym albo wskazaniem organu,
• adekwatność wpisu do rejestru ENISA, jeżeli ma zastosowanie,
• usługi krytyczne świadczone klientom,
• systemy sieciowe i informatyczne wspierające te usługi,
• zależności od chmury obliczeniowej, centrów danych, telekomunikacji, monitorowania bezpieczeństwa, dostawców tożsamości i oprogramowania,
• powiązania z DORA, GDPR, umowami z klientami i obowiązkami sektorowymi,
• repozytoria dowodów, właścicieli systemów i cykl przeglądu.

To także miejsce, w którym należy prawidłowo oddzielić DORA. NIS2 uznaje, że jeżeli sektorowy akt prawny UE nakłada równoważne obowiązki w zakresie zarządzania ryzykiem cyberbezpieczeństwa lub zgłaszania incydentów, taki reżim sektorowy ma zastosowanie zamiast odpowiednich przepisów NIS2. W przypadku objętych zakresem podmiotów finansowych DORA jest zasadniczo właściwym reżimem cyberbezpieczeństwa i zgłaszania incydentów ICT. DORA obowiązuje od 17 stycznia 2025 r. i obejmuje zarządzanie ryzykiem ICT, zgłaszanie incydentów, testowanie cyfrowej odporności operacyjnej, ryzyko stron trzecich ICT oraz nadzór nad krytycznymi zewnętrznymi dostawcami usług ICT.

Grupa fintech może zatem mieć różne ścieżki zgodności w ramach jednej struktury korporacyjnej. Podmiot płatniczy może podlegać przede wszystkim DORA. Spółka zależna MSP może bezpośrednio podlegać NIS2. Wspólna platforma chmurowa może wspierać oba obszary. Dojrzałą odpowiedzią nie jest dublowanie zabezpieczeń. Jest nią jeden model dowodowy SZBI, który może obsługiwać wiele perspektyw regulacyjnych.

ISO 27001:2022 jako operacyjny system zgodności z NIS2

NIS2 Article 21 wymaga odpowiednich i proporcjonalnych technicznych, operacyjnych i organizacyjnych środków zarządzania ryzykiem dla systemów sieciowych i informatycznych oraz zapobiegania wpływowi incydentów na odbiorców usług i inne usługi albo minimalizowania tego wpływu.

ISO 27001:2022 dobrze nadaje się do operacyjnego wdrożenia tego wymagania, ponieważ wymusza trzy dyscypliny.

Po pierwsze, ład zarządczy. Klauzule 5.1 do 5.3 wymagają zaangażowania najwyższego kierownictwa, zgodności z kierunkiem strategicznym, zapewnienia zasobów, komunikacji, przypisania odpowiedzialności oraz udokumentowanej polityki bezpieczeństwa informacji. Jest to bezpośrednio zgodne z NIS2 Article 20, który wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia.

Po drugie, postępowanie z ryzykiem. Klauzule 6.1.1 do 6.1.3 wymagają powtarzalnego procesu oceny ryzyka, właścicieli ryzyka, kryteriów oceny ryzyka, opcji postępowania z ryzykiem, doboru zabezpieczeń, Deklaracji stosowania, planu postępowania z ryzykiem oraz zatwierdzenia ryzyka szczątkowego.

Po trzecie, kontrola operacyjna. Klauzula 8.1 wymaga, aby organizacja planowała, wdrażała i kontrolowała procesy SZBI, utrzymywała udokumentowane informacje, kontrolowała zmiany oraz zarządzała procesami, produktami i usługami dostarczanymi z zewnątrz, które są istotne dla SZBI.

To przekształca NIS2 z prawnej listy kontrolnej w operacyjny model kontroli.

Każdy wiersz wymaga właściciela, źródła zapisów i metody próbkowania. Jeżeli ich brakuje, organizacja ma aspirację kontrolną, a nie działające zabezpieczenie.

Polityka to miejsce, w którym NIS2 staje się zachowaniem operacyjnym

Polityki są często traktowane jak szablony. W przypadku NIS2 jest to niebezpieczne. Regulatora ani audytora nie przekona folder z politykami, jeżeli polityki nie przypisują właścicielstwa, nie definiują zapisów, nie łączą się z ryzykami i nie generują dowodów.

Organizacyjna Polityka zgodności prawnej i regulacyjnej ustanawia podstawę w klauzuli 6.2.1:

Wszystkie obowiązki prawne i regulacyjne muszą być mapowane na konkretne polityki, zabezpieczenia i właścicieli w ramach systemu zarządzania bezpieczeństwem informacji (SZBI).

Ta klauzula jest pomostem między NIS2 a ISO 27001:2022. NIS2 Article 21 nie jest po prostu wymieniony jako wymaganie zewnętrzne. Jest rozkładany na obowiązki wynikające z polityk, mapowany na zabezpieczenia, przypisywany właścicielom i testowany poprzez dowody.

Dla mniejszych organizacji wersja MŚP Polityki zgodności prawnej i regulacyjnej zachowuje tę samą koncepcję w lżejszej formie. Klauzula 5.1.1 wymaga:

Dyrektor Generalny musi utrzymywać prosty, uporządkowany rejestr zgodności obejmujący:

To zdanie jest celowo praktyczne. MŚP nie potrzebują złożonego wdrożenia GRC, aby zacząć. Potrzebują rejestru zgodności, który ujmuje obowiązek, zastosowanie, właściciela, politykę, dowody i cykl przeglądu.

Postępowanie z ryzykiem przekształca następnie obowiązek w działanie. Organizacyjna Polityka zarządzania ryzykiem, klauzula 6.4.2, stanowi:

Menedżer ryzyka zapewnia, aby plany postępowania z ryzykiem były realistyczne, ograniczone w czasie i mapowane na zabezpieczenia z załącznika A ISO/IEC 27001.

Dla MŚP Polityka zarządzania ryzykiem — MŚP, klauzula 5.1.2, określa minimalny użyteczny zapis ryzyka:

Każdy wpis ryzyka musi obejmować: opis, prawdopodobieństwo, wpływ, punktację, właściciela i plan postępowania z ryzykiem.

Te klauzule są istotne, ponieważ NIS2 jest wyraźnie oparta na ryzyku i proporcjonalności. Article 21 oczekuje, że środki będą odzwierciedlały stan wiedzy technicznej, właściwe normy, koszt wdrożenia, ekspozycję na ryzyko, wielkość, prawdopodobieństwo i wagę incydentu, w tym wpływ społeczny i gospodarczy. Rejestr ryzyk bez właścicieli i planów postępowania z ryzykiem nie może potwierdzić proporcjonalności.

Organizacyjna Polityka bezpieczeństwa informacji dopełnia zasadę dowodową w klauzuli 6.6.1:

Wszystkie wdrożone zabezpieczenia muszą być możliwe do prześledzenia audytowo, wspierane udokumentowanymi procedurami oraz zachowanymi dowodami ich działania.

Na tym polega różnica między posiadaniem programu NIS2 a posiadaniem programu dowodowego NIS2.

Ścieżka Clarysec od mapowania do działania

Zenith Blueprint jest wartościowy, ponieważ odzwierciedla sposób myślenia audytorów. Nie pytają oni wyłącznie, czy zabezpieczenie istnieje. Pytają, dlaczego zostało wybrane, gdzie jest udokumentowane, jak działa, kto jest jego właścicielem, jakie dowody potwierdzają jego działanie i jak organizacja je doskonali.

W fazie zarządzania ryzykiem krok 13 nakazuje zespołom dodać identyfikowalność między ryzykami, zabezpieczeniami i klauzulami:

✓ Mapuj zabezpieczenia na ryzyka: w planie postępowania z ryzykiem w rejestrze ryzyk wskazano konkretne zabezpieczenia dla każdego ryzyka. Możesz dodać do każdego ryzyka kolumnę „Odniesienie do zabezpieczenia z załącznika A” i wpisać numery zabezpieczeń.

Dla NIS2 oznacza to, że rejestr ryzyk i Deklaracja stosowania powinny pokazywać, dlaczego mają zastosowanie zabezpieczenia takie jak 8.8 Zarządzanie podatnościami technicznymi, 5.19 Bezpieczeństwo informacji w relacjach z dostawcami oraz 5.24 Planowanie i przygotowanie zarządzania incydentami.

Krok 14 Zenith Blueprint czyni mapowanie regulacyjne jednoznacznym:

Dla każdej regulacji, jeżeli ma zastosowanie, można utworzyć prostą tabelę mapowania (na przykład jako załącznik do raportu), która zawiera kluczowe wymagania bezpieczeństwa danej regulacji oraz odpowiadające im zabezpieczenia/polityki w SZBI.

Zapobiega to fragmentacji. Bezpieczeństwo danych osobowych w GDPR, zgłaszanie incydentów w NIS2, testowanie odporności ICT w DORA oraz zobowiązania bezpieczeństwa wobec klientów mogą opierać się na tych samych dowodach: przeglądach uprawnień dostępu, usuwaniu podatności, zapisach logowania, testach kopii zapasowych, przeglądach dostawców i raportach incydentów.

Krok 19 przechodzi od projektu do działania:

Powiąż każdy z tych dokumentów z odpowiednim zabezpieczeniem w SoA lub podręczniku SZBI. Będą one służyć jako dowód wdrożenia i wewnętrzne odniesienie.

Zestaw dokumentacji kroku 19 obejmuje bezpieczeństwo urządzeń końcowych, zarządzanie dostępem, uwierzytelnianie, bezpieczne konfiguracje bazowe, logowanie i monitorowanie, zarządzanie poprawkami, zarządzanie podatnościami, planowanie pojemności oraz raportowanie operacji IT. Są to dokładnie te dokumenty operacyjne, które są potrzebne, aby techniczne środki NIS2 były audytowalne.

Krok 26 wyjaśnia, jak należy gromadzić dowody z audytu:

Podczas gromadzenia dowodów zapisuj swoje ustalenia. Odnotuj, gdzie elementy są zgodne z wymaganiem (ustalenia pozytywne), a gdzie nie są zgodne (potencjalne niezgodności lub obserwacje).

Dla NIS2 oznacza to próbkowanie dowodów, zanim poprosi o nie regulator, oceniający po stronie klienta albo audytor certyfikacyjny.

Rola Zenith Controls w zgodności międzyramowej

Zenith Controls nie jest odrębnymi ramami kontroli. To przewodnik Clarysec po zgodności międzyramowej, służący do mapowania zabezpieczeń ISO/IEC 27001:2022 i ISO/IEC 27002:2022 na powiązane zabezpieczenia, oczekiwania audytowe i zewnętrzne ramy. Pomaga zespołom zrozumieć, jak jedno zabezpieczenie ISO 27001:2022 może wspierać NIS2, DORA, GDPR, NIST CSF 2.0 i zapewnienie w stylu COBIT.

Trzy zabezpieczenia ISO 27001:2022 są szczególnie ważne dla mapowania dowodów NIS2.

Zabezpieczenie 5.1 Polityki bezpieczeństwa informacji jest punktem wejścia, ponieważ NIS2 Article 21 obejmuje analizę ryzyka i polityki bezpieczeństwa systemów informacyjnych. Jeżeli techniczny środek NIS2 nie znajduje odzwierciedlenia w polityce, trudno nim zarządzać i trudno go konsekwentnie audytować.

Zabezpieczenie 5.36 Zgodność z politykami, zasadami i standardami bezpieczeństwa informacji jest testem rzeczywistości. Łączy wymagania polityk z faktyczną zgodnością z wewnętrznymi zasadami, standardami i obowiązkami zewnętrznymi. W terminologii NIS2 jest to miejsce, w którym organizacja pyta, czy robi to, co deklaruje jej mapowanie Article 21.

Zabezpieczenie 8.8 Zarządzanie podatnościami technicznymi jest jednym z najtrudniejszych obszarów testowych na 2026 rok. Zarządzanie podatnościami jest bezpośrednio istotne dla bezpiecznego pozyskiwania, rozwoju, utrzymania, obsługi podatności i ich ujawniania. Wspiera również testowanie i remediację DORA, rozliczalność bezpieczeństwa w GDPR, rezultaty Identify i Protect w NIST CSF oraz próbkowanie audytu ISO 27001.

Normy wspierające mogą doprecyzować projekt bez wymogu dodatkowych certyfikacji. ISO/IEC 27002:2022 zawiera wytyczne wdrożeniowe dla zabezpieczeń z załącznika A. ISO/IEC 27005 wspiera zarządzanie ryzykiem bezpieczeństwa informacji. ISO/IEC 27017 wspiera bezpieczeństwo chmury obliczeniowej. ISO/IEC 27018 wspiera ochronę danych osobowych umożliwiających identyfikację osoby w scenariuszach podmiotu przetwarzającego w chmurze publicznej. ISO 22301 wspiera ciągłość działania. ISO/IEC 27035 wspiera zarządzanie incydentami. ISO/IEC 27036 wspiera bezpieczeństwo relacji z dostawcami.

Celem nie jest więcej norm dla samych norm. Celem jest lepszy projekt dowodów.

Przykład praktyczny: zbuduj pakiet dowodowy NIS2 dla podatności

Rozważmy platformę SaaS Marii. Obsługuje ona klientów produkcyjnych z UE i zależy od usług w chmurze obliczeniowej, komponentów open source, potoków CI/CD oraz zarządzanego monitorowania. Jej raport z luk wskazuje „wdrożone zarządzanie podatnościami”, ale dowody są rozproszone między skanerami, Jira, GitHub, narzędziami konfiguracji chmury i zgłoszeniami zmian.

Pakiet dowodowy gotowy na NIS2 można zbudować w jednym skoncentrowanym sprincie.

Krok 1: Zdefiniuj scenariusz ryzyka

Ryzyko: możliwa do wykorzystania podatność w aplikacji dostępnej z Internetu, zależności lub komponencie chmurowym powoduje zakłócenie usługi, nieuprawniony dostęp lub ujawnienie danych klienta.

Rejestr ryzyk powinien obejmować opis, prawdopodobieństwo, wpływ, punktację, właściciela i plan postępowania z ryzykiem. Plan postępowania z ryzykiem powinien odwoływać się do zabezpieczenia ISO 27001:2022 8.8 Zarządzanie podatnościami technicznymi oraz powiązanych zabezpieczeń dotyczących inwentarza aktywów, bezpiecznego rozwoju oprogramowania, logowania, kontroli dostępu, zarządzania dostawcami i reagowania na incydenty.

Krok 2: Zmapuj ryzyko na NIS2 Article 21

Ryzyko wspiera wymagania Article 21 dotyczące bezpiecznego pozyskiwania, rozwoju i utrzymania, obsługi i ujawniania podatności, analizy ryzyka, obsługi incydentów, bezpieczeństwa łańcucha dostaw oraz oceny skuteczności zabezpieczeń.

Krok 3: Osadź zasady operacyjne w polityce

Należy użyć procedury zarządzania podatnościami, standardu bezpiecznego rozwoju oprogramowania, wymagań zarządzania poprawkami, polityki testów bezpieczeństwa oraz zasad dotyczących dowodów z audytu.

Organizacyjna Polityka testów bezpieczeństwa i red teamingu, klauzula 6.1, stanowi:

Rodzaje testów: program testów bezpieczeństwa musi obejmować co najmniej: (a) skanowanie podatności, polegające na zautomatyzowanych cotygodniowych lub comiesięcznych skanach sieci i aplikacji w celu identyfikacji znanych podatności; (b) testy penetracyjne, polegające na ręcznym, pogłębionym testowaniu określonych systemów lub aplikacji przez wykwalifikowanych testerów w celu identyfikacji złożonych słabości; oraz (c) ćwiczenia red team, polegające na scenariuszowych symulacjach rzeczywistych ataków, w tym inżynierii społecznej i innych taktyk, w celu przetestowania zdolności organizacji do wykrywania i reagowania jako całości.

Ta klauzula tworzy możliwą do obrony bazę testowania. Jest również zgodna z oczekiwaniem DORA dotyczącym cyklicznego, opartego na ryzyku testowania cyfrowej odporności operacyjnej dla objętych zakresem podmiotów finansowych.

Krok 4: Zdefiniuj metadane dowodów

Polityka audytu i monitorowania zgodności — MŚP, klauzula 6.2.3, stanowi:

Metadane (np. kto je zebrał, kiedy i z którego systemu) muszą być udokumentowane.

W przypadku dowodów dotyczących podatności pakiet powinien ujmować:

• nazwę i konfigurację skanera,
• datę i godzinę skanu,
• zakres aktywów i wyłączenia,
• ustalenia krytyczne i wysokie,
• numer zgłoszenia i właściciela,
• decyzję o poprawce lub mitygacji,
• decyzję o akceptacji ryzyka, jeżeli ma zastosowanie,
• datę remediacji,
• skan walidacyjny,
• link do zapisu zmiany,
• właściciela wyjątku i datę wygaśnięcia.

Krok 5: Dodaj dowody z logowania

Polityka logowania i monitorowania — MŚP, klauzula 5.4.4, obejmuje logi systemowe takie jak:

Logi systemowe: zmiany konfiguracji, działania administracyjne, instalacje oprogramowania, aktywność wdrażania poprawek

Samo zgłoszenie poprawki może nie potwierdzać, że zmiana została wykonana. Logi konfiguracji, działania administracyjne i zapisy instalacji oprogramowania wzmacniają łańcuch dowodowy.

Krok 6: Przeprowadź audyt próbki

Wybierz pięć krytycznych lub wysokich podatności z poprzedniego kwartału. Dla każdej pozycji zweryfikuj, czy aktywo znajdowało się w inwentarzu, skaner wykrył ustalenie, zgłoszenie zostało otwarte w terminie SLA, przypisano właściciela, remediacja odpowiadała wadze i możliwości wykorzystania, logi pokazują zmianę, walidacja potwierdza zamknięcie, a każdy wyjątek ma zatwierdzenie właściciela ryzyka wraz z datą wygaśnięcia.

Taki sprint tworzy gotowy na NIS2 pakiet dowodowy podatności oraz próbkę audytu wewnętrznego ISO 27001:2022.

Bezpieczeństwo dostawców to zarządzanie ekosystemem

NIS2 Article 21 wymaga bezpieczeństwa łańcucha dostaw, w tym aspektów bezpieczeństwa dotyczących relacji z bezpośrednimi dostawcami i dostawcami usług. Oczekuje również, że organizacje będą uwzględniać podatności dostawców, jakość produktów, praktyki cyberbezpieczeństwa dostawców oraz praktyki bezpiecznego rozwoju oprogramowania.

To właśnie w tym miejscu pierwsza wersja raportu z luk Marii była najsłabsza. Zawierała wykaz dostawców, ale nie potwierdzała due diligence, klauzul bezpieczeństwa w umowach, monitorowania ani gotowości do wyjścia.

Polityka bezpieczeństwa dostawców i stron trzecich zapewnia oparcie w polityce. Powiązane wdrożenie może być wspierane przez Politykę bezpiecznego rozwoju oprogramowania, Politykę świadomości i szkoleń w zakresie bezpieczeństwa informacji, Politykę zarządzania podatnościami i poprawkami, Politykę zabezpieczeń kryptograficznych, Politykę kontroli dostępu oraz Politykę pracy zdalnej.

Jeden rejestr dowodów dostawców może wspierać NIS2, DORA i ISO 27001:2022.

Ta tabela zapobiega dublowaniu kwestionariuszy, dublowaniu rejestrów i sprzecznemu właścicielstwu zabezpieczeń.

Jeden przepływ obsługi incydentów dla NIS2, DORA i GDPR

NIS2 Article 23 wymaga, aby istotne incydenty były zgłaszane bez zbędnej zwłoki. Ustanawia etapową oś czasu: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o incydencie, zgłoszenie incydentu w ciągu 72 godzin wraz ze wstępną oceną wagi lub wpływu oraz dostępnymi wskaźnikami naruszenia (IOC), aktualizacje pośrednie na żądanie oraz raport końcowy nie później niż miesiąc po zgłoszeniu incydentu.

DORA ma podobny cykl życia dla podmiotów finansowych: wykrycie, klasyfikacja, logowanie, ocena wagi, eskalacja, komunikacja z klientem, zgłoszenie do organu, analiza przyczyny źródłowej i remediacja. GDPR dodaje analizę naruszenia ochrony danych osobowych, w tym role administratora i podmiotu przetwarzającego, wpływ na osoby, których dane dotyczą, oraz 72-godzinną oś czasu powiadomienia, jeżeli ma zastosowanie.

Prawidłowy projekt nie obejmuje trzech procesów incydentowych. Obejmuje jeden przepływ obsługi incydentów z regulacyjnymi ścieżkami decyzyjnymi.

Polityka reagowania na incydenty — MŚP, klauzula 5.4.1, stanowi:

Wszystkie dochodzenia dotyczące incydentów, ustalenia i działania korygujące muszą być zapisane w rejestrze incydentów utrzymywanym przez Dyrektora Generalnego.

Solidny rejestr incydentów powinien obejmować:

Powiązania z GDPR nie należy lekceważyć. Właściwe organy NIS2 mogą informować organy nadzorcze GDPR, jeżeli nieskuteczności w zarządzaniu ryzykiem cyberbezpieczeństwa lub zgłaszaniu incydentów mogą wiązać się z naruszeniem ochrony danych osobowych. SZBI powinien zatem włączać ocenę prywatności do wstępnej kwalifikacji incydentów, a nie traktować jej jako późniejszego dodatku.

Jak audytorzy i regulatorzy będą testować dowody NIS2

Organizacja gotowa na 2026 rok powinna oczekiwać, że to samo zabezpieczenie będzie testowane z różnych perspektyw.

Audytor ISO 27001:2022 zacznie od SZBI. Zapyta, czy obowiązki NIS2 zostały zidentyfikowane jako wymagania zainteresowanych stron, czy zakres SZBI obejmuje właściwe usługi i zależności, czy ryzyka są oceniane i objęte postępowaniem, czy Deklaracja stosowania uzasadnia mające zastosowanie zabezpieczenia oraz czy zapisy potwierdzają działanie.

Właściwy organ NIS2 skupi się na rezultatach prawnych. Może zapytać, czy wszystkie środki Article 21 zostały uwzględnione, czy zabezpieczenia są odpowiednie i proporcjonalne, czy kierownictwo zatwierdziło i nadzoruje te środki oraz czy zgłaszanie incydentów może spełnić wymagane terminy.

Organ nadzorczy DORA, w przypadku objętych zakresem podmiotów finansowych, będzie testować zarządzanie ryzykiem ICT, klasyfikację incydentów, testowanie odporności, ryzyko stron trzecich, uzgodnienia umowne, ryzyko koncentracji i strategie wyjścia.

Przeglądający GDPR będzie testować, czy techniczne i organizacyjne środki chronią dane osobowe, czy ocena naruszenia jest wbudowana w obsługę incydentów, czy role administratora i podmiotu przetwarzającego są jasne oraz czy istnieją zapisy rozliczalności.

Oceniający w stylu NIST CSF 2.0 lub COBIT 2019 skupi się na ładzie zarządczym, własności ryzyka, metrykach wyników, stanach bieżących i docelowych, zdolności procesów oraz zgodności z apetytem organizacji na ryzyko.

Organizacyjna Polityka audytu i monitorowania zgodności, klauzula 3.4, ujmuje cel dowodów:

Generowanie możliwych do obrony dowodów i ścieżki audytowej na potrzeby zapytań regulacyjnych, postępowań prawnych lub wniosków klientów o zapewnienie.

To jest standard operacyjny, do którego zespoły NIS2 powinny dążyć.

Rozliczalność kierownictwa: zarząd nie może delegować NIS2 poza siebie

NIS2 Article 20 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorowały ich wdrożenie i odbywały szkolenia. Członkowie organów zarządzających mogą ponosić odpowiedzialność za naruszenia, zgodnie z krajowymi zasadami odpowiedzialności.

Jest to zgodne z wymaganiami przywództwa ISO 27001:2022. Najwyższe kierownictwo musi zapewnić, aby polityka i cele bezpieczeństwa informacji były zgodne z kierunkiem strategicznym, włączyć wymagania SZBI do procesów biznesowych, zapewnić zasoby, komunikować znaczenie, przypisać odpowiedzialności i promować ciągłe doskonalenie.

Zarząd nie potrzebuje surowych eksportów ze skanerów ani pełnych logów SIEM. Potrzebuje zapewnienia umożliwiającego podejmowanie decyzji.

Kwartalny pakiet dowodowy NIS2 dla zarządu powinien obejmować:

1. zmiany zakresu i statusu regulacyjnego,
2. najważniejsze ryzyka NIS2 i status postępowania z nimi,
3. pulpit skuteczności zabezpieczeń Article 21,
4. istotne incydenty, sytuacje bliskie incydentowi i decyzje raportowe,
5. wyjątki dotyczące ryzyka dostawców i chmury obliczeniowej,
6. ustalenia audytu wewnętrznego, działania korygujące i zaległe dowody.

Taki pakiet zapewnia kierownictwu informacje potrzebne do zatwierdzania środków, kwestionowania wyjątków i akceptacji ryzyka szczątkowego.

Model operacyjny Clarysec na 2026 rok

Przełożenie technicznych środków NIS2 na działania operacyjne z wykorzystaniem ISO 27001:2022 wymaga prostego, lecz zdyscyplinowanego modelu:

• ujęcia obowiązków NIS2, DORA, GDPR i obowiązków umownych w SZBI,
• mapowania obowiązków na ryzyka, polityki, zabezpieczenia, właścicieli i dowody,
• wykorzystania Deklaracji stosowania jako źródła prawdy o zabezpieczeniach,
• budowy pakietów dowodowych dla obszarów Article 21 o wysokim ryzyku,
• integracji zgłaszania incydentów w jednym przepływie regulacyjnym,
• traktowania bezpieczeństwa dostawców jako cyklu życia, a nie kwestionariusza,
• przeprowadzania audytów wewnętrznych na rzeczywistych próbkach,
• raportowania skuteczności zabezpieczeń organom zarządzającym,
• doskonalenia na podstawie incydentów, ustaleń z audytu, testów i zmian regulacyjnych.

Dla Marii punktem zwrotnym było uświadomienie sobie, że nie potrzebuje odrębnego projektu NIS2. Potrzebuje silniejszego silnika dowodowego SZBI.

Polityki Clarysec, Zenith Blueprint i Zenith Controls są zaprojektowane do wspólnego działania. Polityki definiują oczekiwane zachowania i zapisy. Zenith Blueprint zapewnia 30-etapową ścieżkę wdrożenia i audytu. Zenith Controls dostarcza mapowanie zgodności międzyramowej, dzięki czemu NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF i zapewnienie w stylu COBIT mogą być zarządzane jako jeden spójny program.

Następny krok: zbuduj mapę dowodów NIS2 do ISO 27001:2022

Jeżeli Twoje prace nad NIS2 nadal znajdują się w arkuszu luk, 2026 rok jest momentem, aby przełożyć je na działanie operacyjne.

Zacznij od jednego technicznego środka wysokiego ryzyka, takiego jak zarządzanie podatnościami, obsługa incydentów albo bezpieczeństwo dostawców. Zmapuj go na ryzyka ISO 27001:2022, polityki, zabezpieczenia z załącznika A, właścicieli, procedury i dowody. Następnie pobierz próbkę zapisów z ostatniego kwartału i zadaj trudne pytanie: czy to zadowoliłoby regulatora, oceniającego po stronie klienta i audytora ISO 27001:2022?

Clarysec może pomóc zbudować tę odpowiedź przy użyciu biblioteki polityk, Zenith Blueprint i Zenith Controls.

Celem nie jest więcej dokumentacji. Celem są możliwe do obrony, powtarzalne dowody na to, że techniczne środki NIS2 rzeczywiście działają.