ISO 27001 versus NIS2 - różnice i plan działania

ISO 27001 versus NIS2: sprawdź różnice, zakres obowiązków i plan połączenia zgodności z kontrolą ryzyka oraz dowodami dla zarządu i regulatora w Polsce.

Certyfikat ISO nie zwalnia organizacji z obowiązków wynikających z NIS2. Jednocześnie firma objęta NIS2, która reaguje wyłącznie przez dopisywanie polityk i procedur, może spełnić część wymagań formalnych, ale nadal nie panować nad realną ekspozycją na incydent. W dyskusji ISO 27001 versus NIS2 kluczowe jest więc nie pytanie, który standard wybrać, lecz jak zbudować jeden model zarządzania ryzykiem, który dostarcza dowodów dla audytora, regulatora i zarządu - a przede wszystkim działa podczas ataku lub przestoju.

ISO 27001 versus NIS2 - dwa różne mechanizmy kontroli

ISO/IEC 27001 jest międzynarodową normą określającą wymagania dla systemu zarządzania bezpieczeństwem informacji, czyli SZBI. Jej istotą jest cykl zarządzania: ustalenie kontekstu organizacji, ocena ryzyka, dobór zabezpieczeń, nadzór nad ich skutecznością, audyty wewnętrzne oraz ciągłe doskonalenie. Certyfikacja jest co do zasady dobrowolna, choć może być wymagana przez klienta, grupę kapitałową, postępowanie zakupowe lub umowę.

NIS2 to natomiast unijna dyrektywa ustanawiająca minimalne wymagania cyberbezpieczeństwa dla wskazanych sektorów i podmiotów. Po implementacji do prawa krajowego obowiązki mają charakter ustawowy. Obejmują zarządzanie ryzykiem, zgłaszanie incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw oraz odpowiedzialność organów zarządzających. Szczegółowy zakres, kwalifikacja podmiotów i sankcje zależą od przepisów wdrażających dyrektywę w Polsce.

Różnica ma konsekwencje operacyjne. ISO 27001 pyta, czy organizacja prowadzi spójny i audytowalny system zarządzania bezpieczeństwem. NIS2 pyta również, czy podmiot objęty regulacją wdrożył wskazane środki, potrafi szybko obsłużyć incydent oraz wykaże to przed właściwym organem. Certyfikat może być wartościowym dowodem dojrzałości, ale nie jest automatycznym potwierdzeniem zgodności z NIS2.

Co łączy oba podejścia

W obu ramach punktem wyjścia jest ryzyko, a nie sama lista narzędzi. Organizacja musi wiedzieć, jakie procesy świadczy, od jakich aktywów zależą, jakie scenariusze przerwania usług są najbardziej kosztowne oraz które podatności mogą zostać wykorzystane w praktyce. W środowisku produkcyjnym będzie to często połączenie IT, OT, zdalnego dostępu serwisowego, dostawców automatyki i segmentów sieci, których nie można po prostu wyłączyć na czas prac.

Zarówno ISO 27001, jak i NIS2 wymagają też kontroli odpowiedzialności. Właściciel ryzyka, właściciel systemu, zespół SOC, administrator, dostawca i zarząd muszą rozumieć swoje role. Sama polityka bezpieczeństwa bez przypisanego działania, terminu, SLA i dowodu wykonania nie ogranicza ryzyka.

Gdzie kończy się podobieństwo

ISO 27001 pozostawia organizacji szeroką możliwość dopasowania zabezpieczeń do wyniku analizy ryzyka. Załącznik A do normy stanowi katalog środków kontroli, lecz organizacja uzasadnia ich zastosowanie lub wyłączenie w deklaracji stosowania. To dobre rozwiązanie dla firm o zróżnicowanych modelach działania, pod warunkiem że analiza ryzyka nie jest jedynie dokumentem przygotowanym na audyt.

NIS2 jest bardziej preskryptywna w obszarach istotnych dla odporności usług. Akcentuje między innymi zarządzanie incydentami, obsługę podatności, kopie zapasowe, odtwarzanie, zarządzanie kryzysowe, bezpieczeństwo dostawców, cyberhigienę, szkolenia i stosowanie kryptografii tam, gdzie jest to adekwatne. Szczególny ciężar spoczywa na zarządzie: powinien zatwierdzać środki zarządzania ryzykiem, nadzorować ich wdrożenie i posiadać wystarczającą wiedzę, aby wykonywać tę odpowiedzialność.

Najważniejsze różnice dla zarządu, IT i compliance

Dla zarządu ISO 27001 jest przede wszystkim mechanizmem ładu i powtarzalności. Pokazuje, czy organizacja potrafi podejmować decyzje o ryzyku w sposób udokumentowany i kontrolowany. NIS2 podnosi stawkę, ponieważ niedojrzałość procesu może oznaczać naruszenie obowiązku regulacyjnego, konsekwencje finansowe oraz ryzyko osobistej odpowiedzialności osób zarządzających w granicach określonych prawem.

Dla zespołów technicznych największa różnica dotyczy dowodów działania. W ISO można wykazać funkcjonowanie procesu zarządzania podatnościami poprzez procedurę, rejestr ryzyk, raporty skanowania i próbkę zamkniętych działań. Przy NIS2 warto dodatkowo wykazać, czy krytyczne luki są triagowane według SLA, czy wyjątki mają właściciela i datę wygaśnięcia, czy ekspozycja internetowa jest stale monitorowana oraz czy remediacja obejmuje systemy wspierające usługi krytyczne.

Dla compliance problemem bywa mylenie zakresu certyfikatu z zakresem regulacji. Certyfikat ISO 27001 może obejmować konkretną spółkę, lokalizację, usługę lub centrum danych. NIS2 odnosi się do podmiotu i jego działalności objętej przepisami. Przedstawienie certyfikatu jako pełnej odpowiedzi na NIS2 bez analizy zakresu organizacyjnego, zależności usług i wymogów krajowych tworzy pozorne bezpieczeństwo.

Istotne są również terminy raportowania incydentów. NIS2 wprowadza model wieloetapowego raportowania poważnych incydentów, a krajowe przepisy doprecyzowują tryb oraz właściwe kanały. Organizacja musi więc przetestować nie tylko techniczne wykrycie zdarzenia, lecz także ścieżkę decyzji: kto kwalifikuje incydent, kto ocenia wpływ, kto zatwierdza komunikację i skąd pobierane są wiarygodne dane do zgłoszenia.

Jak wykorzystać ISO 27001 jako fundament zgodności z NIS2

Najefektywniejsze podejście nie polega na budowie dwóch oddzielnych programów. Należy potraktować SZBI jako warstwę zarządczą, a wymagania NIS2 jako zestaw obowiązków, które trzeba odwzorować na konkretne procesy, zabezpieczenia i dowody. W praktyce oznacza to mapowanie istniejących polityk oraz kontroli na wymagania regulacyjne, a następnie weryfikację ich wykonania w środowisku produkcyjnym.

Program warto rozpocząć od ustalenia rzeczywistego zakresu. Nie wystarczy lista aplikacji w CMDB, jeśli krytyczna usługa zależy od niezinwentaryzowanego łącza, konta uprzywilejowanego dostawcy, serwera kopii zapasowych albo stacji inżynierskiej OT. Zespół powinien połączyć inwentaryzację aktywów z mapą przepływów danych, właścicielami procesów i zależnościami od podmiotów trzecich.

Następnie potrzebna jest ocena luk oparta na dowodach. Deklaracja, że MFA jest wdrożone, nie odpowiada na pytanie, czy obejmuje konta administracyjne, VPN, dostęp do chmury i zdalny serwis. Procedura tworzenia kopii zapasowych nie potwierdza, że da się odtworzyć kluczową usługę w wymaganym czasie. Test odtworzeniowy, próbka logów, wynik pentestu, konfiguracja segmentacji i zapis z ćwiczenia incydentowego są dowodami o większej wartości niż rozbudowany dokument bez weryfikacji.

W planie remediacji należy oddzielić działania natychmiastowe od zmian strukturalnych. Krytyczna podatność dostępna z internetu, wspólne konto administratora lub brak separacji sieci biurowej od OT wymagają kontrolowanej, lecz szybkiej reakcji. Z kolei przebudowa IAM, wdrożenie centralnego logowania czy uporządkowanie zarządzania dostawcami mogą wymagać programu wielomiesięcznego, budżetu i decyzji architektonicznych.

Przydatne mierniki dla zarządu to nie liczba napisanych polityk, lecz między innymi:

• udział aktywów krytycznych z potwierdzonym właścicielem i klasyfikacją;
• liczba otwartych luk krytycznych oraz czas ich zamknięcia względem SLA;
• odsetek krytycznych systemów objętych monitoringiem i testami odtworzenia;
• liczba dostawców wysokiego ryzyka z oceną bezpieczeństwa oraz planem działań;
• wyniki ćwiczeń incydentowych, w tym czas kwalifikacji i eskalacji zdarzenia.

Scenariusze, w których certyfikat nie wystarcza

Organizacja może posiadać dojrzały SZBI, a mimo to mieć problem z NIS2. Dzieje się tak na przykład wtedy, gdy zakres certyfikacji nie obejmuje kluczowej usługi regulowanej albo gdy kontrola dostawców zatrzymuje się na ankiecie bez wymagań kontraktowych, monitoringu i egzekwowania działań naprawczych.

Częsty scenariusz dotyczy również SOC. Procedura reagowania na incydenty może spełniać wymagania ISO, ale zespół nie ma pełnej widoczności logów z infrastruktury krytycznej, chmury, systemów tożsamości lub OT. Wtedy czas wykrycia i kwalifikacji incydentu jest zbyt długi, a obowiązek raportowy staje się trudny do wykonania pod presją czasu.

Odwrotna sytuacja także występuje. Firma wdraża wymagania NIS2 jako pilny projekt regulacyjny, przygotowuje polityki i przeprowadza szkolenia, ale nie tworzy trwałego mechanizmu przeglądów zarządczych, audytów wewnętrznych i obsługi niezgodności. Po pierwszym audycie luka zaczyna narastać ponownie. ISO 27001 pomaga utrzymać dyscyplinę, ponieważ wymusza cykliczne sprawdzanie skuteczności systemu.

Dla organizacji o wysokiej krytyczności operacyjnej właściwym celem jest wspólny model: SZBI porządkuje odpowiedzialność i cykl kontroli, NIS2 określa regulacyjny poziom oczekiwań, a testy techniczne oraz monitoring potwierdzają, czy zabezpieczenia działają poza dokumentacją. SprintTech realizuje takie programy od analizy ekspozycji i oceny luk, przez kontrolowaną remediację, po dowody procesów i raportowanie zarządcze.

Najlepszym pierwszym krokiem nie jest zakup certyfikatu ani kopiowanie polityk. Jest nim ustalenie, które usługi organizacja musi utrzymać, jakie scenariusze mogą je zatrzymać i czy obecne kontrole dostarczą wiarygodnego dowodu działania, gdy incydent rzeczywiście wystąpi.