Regulacje NIS2 i DORA fundamentalnie zmieniają podejście firm do zarządzania cyberbezpieczeństwem i ryzykiem ICT. Kompleksowe wymagania obejmują zarówno poziom organizacyjny, jak i techniczny, wymuszając realną współpracę zarządów z działami IT oraz compliance. Skuteczna implementacja tych przepisów decyduje o ciągłości działania i odporności operacyjnej w środowisku cyfrowym.
Spis treści
- Wprowadzenie do NIS2 i DORA
- Kluczowe wymagania Dyrektyw NIS2
- DORA: Preskryptywne Zarządzanie Ryzykiem ICT
- Zarządzanie zgodnością w organizacjach
- Wpływ NIS2 i DORA na kulturę cyberbezpieczeństwa
- Przygotowanie do wdrożenia: Krok po kroku
Wprowadzenie do NIS2 i DORA
Dyrektywa NIS2 oraz rozporządzenie DORA to dwa kluczowe europejskie akty prawne, które fundamentalnie zmieniają sposób, w jaki organizacje powinny podchodzić do cyberbezpieczeństwa i odporności cyfrowej. Choć oba regulacje dotyczą zarządzania ryzykiem w środowisku cyfrowym, ich zakres, cel oraz sposób implementacji różnią się w istotny sposób. NIS2 (Dyrektywa w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii) jest następczynią pierwotnej dyrektywy NIS z 2016 r. i stanowi ogólnounijny „framework” podnoszący poziom bezpieczeństwa sieci i systemów informatycznych w szerokim wachlarzu sektorów – od energetyki, transportu, zdrowia, po administrację publiczną i cyfrową infrastrukturę krytyczną. Jej celem jest zminimalizowanie rozdrobnienia wymogów między państwami członkowskimi, narzucenie bardziej rygorystycznych standardów zarządzania ryzykiem oraz wzmocnienie mechanizmów współpracy i wymiany informacji o incydentach pomiędzy podmiotami i organami nadzorczymi. DORA (Digital Operational Resilience Act) z kolei to rozporządzenie bezpośrednio obowiązujące we wszystkich krajach UE, zaprojektowane specjalnie dla sektora finansowego i jego dostawców usług ICT. Jego zadaniem jest zapewnienie, że instytucje finansowe – od banków, przez firmy inwestycyjne, po ubezpieczycieli i fintechy – będą w stanie utrzymywać ciągłość kluczowych procesów nawet w obliczu poważnych incydentów cybernetycznych, awarii systemów czy zakłóceń w usługach dostawców technologicznych. NIS2 nakreśla szerokie minimum wymogów cyberbezpieczeństwa dla wielu branż, natomiast DORA schodzi dużo głębiej w specyfikę funkcjonowania instytucji finansowych, obejmując m.in. testy odporności (np. testy „threat‑led”), szczegółowe ramy zarządzania ryzykiem ICT, wymogi względem outsourcingu technologicznego i nadzór nad tzw. kluczowymi dostawcami usług ICT (np. dużymi dostawcami chmury). W praktyce NIS2 i DORA tworzą dwa zazębiające się, ale rozłączne poziomy regulacyjne: NIS2 – horyzontalny, obejmujący wiele sektorów kluczowych i ważnych dla gospodarki, a DORA – wertykalny, skoncentrowany na jednym, lecz wysoce wrażliwym sektorze finansowym, który jest kręgosłupem całej gospodarki i atrakcyjnym celem cyberprzestępców.
Różnice między NIS2 i DORA widoczne są również w konstrukcji prawnej, sposobie wdrożenia i stopniu szczegółowości wymagań. NIS2 jako dyrektywa wymaga transpozycji do prawa krajowego, co oznacza, że poszczególne państwa członkowskie – w tym Polska – muszą przyjąć własne ustawy i rozporządzenia, doprecyzowujące m.in. zakres podmiotowy, mechanizmy nadzoru, wysokość kar oraz procedury raportowania incydentów. Może to prowadzić do pewnych różnic interpretacyjnych pomiędzy jurysdykcjami, choć rdzeń wymogów pozostaje wspólny. DORA jako rozporządzenie stosuje się bezpośrednio i jednakowo we wszystkich państwach UE, co ogranicza ryzyko rozbieżności i zwiększa przewidywalność dla podmiotów działających transgranicznie, w tym dla międzynarodowych grup kapitałowych. W obu aktach pojawiają się podobne motywy – silniejsza rola zarządów i najwyższego kierownictwa w nadzorze nad ryzykiem ICT, obowiązek systematycznych analiz ryzyka, stosowania adekwatnych środków technicznych i organizacyjnych, prowadzenia planów ciągłości działania i planów reagowania na incydenty, jak również ścisłe ramy raportowania poważnych zdarzeń do właściwych organów. Jednak DORA idzie o krok dalej, narzucając np. wymóg bardziej zaawansowanych testów penetracyjnych opartych na realistycznych scenariuszach zagrożeń, obowiązek szczegółowego katalogowania i monitorowania wszystkich relacji outsourcingowych ICT oraz ocenę koncentracji ryzyka u kluczowych dostawców technologicznych. Z perspektywy cyberbezpieczeństwa oznacza to, że organizacje objęte wyłącznie NIS2 muszą zbudować solidny, ale raczej „ogólny” system zarządzania ryzykiem cyfrowym i reakcją na incydenty, natomiast podmioty podlegające DORA muszą dodatkowo udowodnić wysoki poziom dojrzałości operacyjnej, zdolność wykonywania zaawansowanych testów odporności, a także utrzymywać znacznie bardziej sformalizowane relacje z dostawcami ICT. To z kolei przekłada się na konieczność ścisłej współpracy działów bezpieczeństwa, IT, ciągłości działania, compliance i zarządów, a także na większą integrację cyberbezpieczeństwa z ogólną strategią biznesową oraz zarządzaniem ryzykiem korporacyjnym (ERM). NIS2 i DORA nie funkcjonują więc w próżni – są bezpośrednią odpowiedzią na rosnącą skalę ataków ransomware, łańcuchowych ataków na dostawców technologicznych, kampanii APT oraz rosnącą zależność gospodarki od złożonych ekosystemów cyfrowych. Zrozumienie ich założeń, zakresu i odmiennych punktów ciężkości jest niezbędne, aby prawidłowo zmapować obowiązki regulacyjne, zaprojektować adekwatną architekturę bezpieczeństwa oraz uniknąć dublowania procesów i kosztów w organizacjach, które mogą być jednocześnie objęte obiema regulacjami.
Kluczowe wymagania Dyrektyw NIS2
Dyrektywa NIS2 znacząco rozszerza oraz precyzuje wymagania wobec podmiotów kluczowych i ważnych z perspektywy funkcjonowania gospodarki i bezpieczeństwa państw członkowskich UE. Po pierwsze, obejmuje znacznie szerszy katalog sektorów – od energetyki, transportu, zdrowia, infrastruktury cyfrowej i usług pocztowych, przez dostawców wody pitnej i ścieków, po administrację publiczną oraz określone kategorie dostawców usług ICT, centrów danych czy dostawców usług w chmurze. Jednocześnie NIS2 wprowadza podejście oparte na wielkości i znaczeniu organizacji – większość średnich i dużych przedsiębiorstw z sektorów krytycznych automatycznie podlega regulacji, nawet jeśli wcześniej nie była formalnie klasyfikowana jako operator usług kluczowych. W praktyce oznacza to, że wiele organizacji po raz pierwszy musi wdrożyć dojrzały system zarządzania bezpieczeństwem informacji i raportowania incydentów. Kluczowym filarem NIS2 jest zarządzanie ryzykiem bezpieczeństwa sieci i systemów informatycznych. Regulacja oczekuje wdrożenia kompleksowego zestawu środków technicznych i organizacyjnych, które uwzględniają aktualny stan wiedzy, specyfikę usług oraz poziom ryzyka. Wśród przykładowych wymogów można wskazać implementację polityk bezpieczeństwa informacji, systematyczne zarządzanie podatnościami i łatkami, stosowanie segmentacji sieci i zasady najmniejszych uprawnień, szyfrowanie danych w spoczynku i w tranzycie, a także monitorowanie bezpieczeństwa w trybie ciągłym (np. poprzez SOC lub usługi MSSP). Szczególny nacisk kładziony jest na bezpieczeństwo łańcucha dostaw – organizacje muszą analizować ryzyka związane z dostawcami, podwykonawcami i partnerami technologicznymi, definiować kryteria bezpieczeństwa w umowach oraz prowadzić okresowe oceny tych relacji. Ustawodawca akcentuje też konieczność uwzględnienia odporności na ataki na oprogramowanie i sprzęt, w tym na komponenty typu open source, co wymaga budowy przejrzystego inwentarza zasobów i komponentów (Software/Hardware Bill of Materials) oraz procesów oceny wiarygodności dostawców.
NIS2 wprowadza daleko idące wymagania dotyczące ładu korporacyjnego i odpowiedzialności kierownictwa za cyberbezpieczeństwo. Członkowie organów zarządzających muszą nie tylko „formalnie” zatwierdzać polityki, ale również aktywnie nadzorować wdrażanie środków bezpieczeństwa oraz zapewnić, że cyberbezpieczeństwo jest integralną częścią strategii biznesowej i zarządzania ryzykiem całej organizacji. Dyrektywa nakłada obowiązek regularnych szkoleń dla kadry kierowniczej w zakresie ryzyk i dobrych praktyk ICT, a w niektórych przypadkach przewiduje odpowiedzialność osobistą za rażące zaniedbania. Kolejnym kluczowym obszarem są procedury zgłaszania i obsługi incydentów. NIS2 harmonizuje terminy i standardy raportowania, wymagając m.in. wstępnego zgłoszenia znaczącego incydentu do właściwego CSIRT lub organu krajowego w krótkim, 24-godzinnym terminie od jego wykrycia, następnie raportu szczegółowego (zwykle w ciągu 72 godzin) oraz końcowego sprawozdania po zakończeniu analiz i działań naprawczych. Oczekuje się, że organizacje będą dysponowały jasno opisanym, przećwiczonym procesem zarządzania incydentami – od wykrycia i klasyfikacji, przez eskalację i komunikację z interesariuszami, po działania naprawcze i lessons learned. Dyrektywa wymaga także przygotowania oraz testowania planów ciągłości działania i planów reagowania kryzysowego, w tym scenariuszy cyberataków, utraty dostępności systemów, zakłóceń w łańcuchu dostaw czy awarii kluczowej infrastruktury IT/OT. W tym kontekście NIS2 kładzie nacisk na interoperacyjność rozwiązań oraz koordynację działań z innymi podmiotami w sektorze i z administracją publiczną, aby umożliwić szybkie reagowanie na incydenty o charakterze transgranicznym. Niezwykle istotne są również obowiązki dokumentacyjne i dowodowe – organizacje muszą być w stanie wykazać przed organem nadzorczym, że stosują adekwatne środki, utrzymują aktualną dokumentację polityk, procedur, rejestrów incydentów, wyników analiz ryzyka i audytów bezpieczeństwa. NIS2 przewiduje dotkliwe sankcje administracyjne za naruszenia obowiązków, co dodatkowo wzmacnia presję na realne, a nie tylko formalne wdrożenie systemów bezpieczeństwa. W wielu przypadkach wymogi NIS2 będą wymagały integracji istniejących frameworków (np. ISO 27001, ISO 22301, NIST CSF) z nowymi procesami regulacyjnymi, a także wypracowania spójnego modelu współpracy między zespołami IT, bezpieczeństwa, compliance, prawnym i biznesem w jednej, całościowej architekturze zarządzania cyberryzykiem.
DORA: Preskryptywne Zarządzanie Ryzykiem ICT
DORA (Digital Operational Resilience Act) wprowadza dla sektora finansowego wyjątkowo preskryptywne podejście do zarządzania ryzykiem ICT, znacząco wykraczające poza ogólne ramy dyrektyw takich jak NIS2. Nie pozostaje na poziomie wysokopoziomowych zasad, ale w wielu obszarach precyzyjnie określa, co instytucje finansowe muszą zrobić, w jaki sposób mają organizować procesy, jak dokumentować decyzje oraz jak często testować swoją odporność. Kluczowym punktem wyjścia jest kompleksowe ramowe zarządzanie ryzykiem ICT, obejmujące cały cykl życia systemów i usług – od planowania i projektowania, przez wdrożenie i eksploatację, aż po wycofanie z użycia. DORA wymaga, aby zarządzanie ryzykiem ICT nie było wyłącznie domeną działu IT lub bezpieczeństwa, ale integralnym elementem ogólnej strategii zarządzania ryzykiem operacyjnym i strategicznym w organizacji. Instytucje objęte regulacją muszą zdefiniować apetyt na ryzyko ICT, progi tolerancji na zakłócenia, a następnie przełożyć je na konkretne mechanizmy kontroli, wskaźniki monitorujące (KRI, KPI) oraz scenariusze reagowania na incydenty. Preskryptywność DORA przejawia się także w wyraźnym rozróżnieniu pomiędzy prewencją, wykrywaniem, reagowaniem i odtwarzaniem usług, przy czym każda z tych faz musi być ujęta w dokumentowanych politykach, procedurach i planach, zatwierdzanych na poziomie zarządu. Regulacja kładzie silny nacisk na zasadę „security by design i by default” – nowe rozwiązania, systemy i usługi finansowe powinny być projektowane w oparciu o analizę ryzyka ICT oraz posiadać z góry zdefiniowane mechanizmy kontroli, a nie być łatane dodatkowymi zabezpieczeniami dopiero po wdrożeniu. Wymogi DORA wyraźnie rozszerzają perspektywę z klasycznego cyberbezpieczeństwa na szerszą odporność operacyjną, obejmując nie tylko ataki zewnętrzne, ale także awarie, błędy konfiguracyjne, przerwy w dostępności usług chmurowych czy problemy u kluczowych dostawców technologicznych.
Jednym z najbardziej charakterystycznych elementów DORA jest podejście do ryzyka związanego z podmiotami trzecimi świadczącymi usługi ICT. Regulacja nakazuje traktować dostawców rozwiązań chmurowych, operatorów centrów danych, dostawców oprogramowania, a nawet fintechowych podwykonawców jako integralną część łańcucha odporności cyfrowej. Organizacje finansowe muszą mieć szczegółową mapę zależności od zewnętrznych dostawców, w tym klasyfikację tzw. „kluczowych dostawców usług ICT”, a następnie opracować strategię zarządzania ryzykiem outsourcingu, która obejmuje nie tylko etap wyboru kontrahenta, ale także klauzule umowne, monitorowanie jakości usług, prawo do audytu, plany wyjścia (exit plans) oraz testowanie scenariuszy nagłego zakończenia współpracy. DORA przewiduje nawet możliwość objęcia nadzorem regulacyjnym niektórych kluczowych dostawców ICT na poziomie ponadnarodowym, co ma ograniczyć zjawisko koncentracji ryzyka w kilku globalnych podmiotach chmurowych. Równolegle regulacja szczegółowo opisuje wymagania dotyczące testowania odporności cyfrowej – od standardowych testów technicznych, przez analizy podatności i testy planów ciągłości działania, po zaawansowane testy typu TLPT (Threat-Led Penetration Testing), w których scenariusze ataku bazują na aktualnych taktykach i technikach stosowanych przez realnych przeciwników. DORA wskazuje częstotliwość, zakres i podmioty uczestniczące w takich testach, a także wymaga, by wyniki były formalnie analizowane, omawiane na poziomie zarządu i przekładane na konkretne plany remediacji z terminami realizacji. Bardzo istotna jest również warstwa raportowania i zgłaszania incydentów ICT – instytucje muszą posiadać jednolity proces klasyfikacji incydentów, kryteria uznawania zdarzenia za „poważny incydent operacyjny”, a także mechanizmy szybkiego powiadamiania właściwych organów nadzoru, często w bardzo krótkich oknach czasowych. DORA wymaga wreszcie, by wszystkie te mechanizmy – od analizy ryzyka, przez outsourcing i testy, po raportowanie – były nie tylko opisane na papierze, ale faktycznie wdrożone, mierzalne i regularnie doskonalone w ramach cyklicznych przeglądów, w których aktywnie uczestniczy zarząd oraz kluczowe funkcje kontrolne (ryzyko, compliance, audyt wewnętrzny).
Zarządzanie zgodnością w organizacjach
Zarządzanie zgodnością z NIS2 i DORA wymaga od organizacji przejścia z podejścia punktowego, opartego na pojedynczych projektach bezpieczeństwa, do spójnego, holistycznego systemu compliance, który integruje wymagania regulacyjne z istniejącymi ramami zarządzania ryzykiem i ładem korporacyjnym. W praktyce oznacza to konieczność zbudowania struktury odpowiedzialności, procesów, narzędzi oraz mierników obejmujących pełen cykl życia ryzyka ICT – od identyfikacji i oceny, przez wdrożenie zabezpieczeń, po monitoring, doskonalenie i raportowanie. Organizacje powinny rozpocząć od przeprowadzenia szczegółowej analizy luki (gap analysis) w odniesieniu do aktualnie funkcjonujących polityk, procedur i systemów bezpieczeństwa informacji, uwzględniając jednocześnie inne obowiązujące regulacje, takie jak RODO, wytyczne EBA, EIOPA czy EBC. Kluczowe jest zmapowanie wymogów NIS2 i DORA na konkretne procesy biznesowe i IT, aby uniknąć powielania działań, sprzeczności w dokumentacji oraz nadmiernej biurokracji, która nie przekłada się na realne podniesienie poziomu bezpieczeństwa. W organizacjach objętych obiema regulacjami (np. duże grupy kapitałowe z podmiotami finansowymi i niefinansowymi) szczególne znaczenie ma zbudowanie wspólnego „szkieletu” systemu zarządzania bezpieczeństwem i odpornością operacyjną, który będzie uzupełniany o specyficzne wymagania sektorowe. Governance compliance powinien opierać się na jasno zdefiniowanych rolach: zarządu, komitetu ds. ryzyka/bezpieczeństwa, CISO, działu prawnego i compliance, audytu wewnętrznego oraz właścicieli procesów biznesowych – każdy z tych podmiotów musi mieć określone obowiązki w kontekście NIS2 i DORA, w tym odpowiedzialność za podejmowanie decyzji, zatwierdzanie polityk, nadzór i raportowanie. Szczególnie istotne jest formalne umocowanie roli CISO i zapewnienie mu niezależności oraz dostępu do zarządu, co wynika bezpośrednio z wymogów w zakresie nadzoru kierownictwa nad ryzykiem ICT. Równolegle organizacja powinna zbudować katalog polityk i procedur – od ogólnej polityki bezpieczeństwa informacji, przez politykę zarządzania ryzykiem ICT, politykę ciągłości działania i odtwarzania po awarii, politykę zarządzania dostawcami ICT, aż po szczegółowe standardy w zakresie kontroli dostępu, zarządzania podatnościami, backupu, testów bezpieczeństwa i szkoleń pracowników. Każdy dokument powinien mieć przypisanego właściciela, cykl przeglądu oraz mierniki skuteczności (KPI/KRI), które będą wykorzystywane do raportowania na poziomie zarządu. Jednocześnie, aby zarządzanie zgodnością nie stało się jedynie ćwiczeniem „papierowym”, konieczna jest ścisła integracja tych dokumentów z praktyką operacyjną – polityki mają być realnym punktem odniesienia dla administratorów systemów, zespołów SOC, działów zakupów czy HR, a nie tylko zbiorem zapisów przygotowanych na potrzeby audytu lub kontroli. W tym celu warto budować katalog wymogów kontrolnych (control framework), który łączy wymagania NIS2, DORA i innych regulacji z konkretnymi kontrolami technicznymi i organizacyjnymi – dzięki temu możliwe jest jednoznaczne wykazanie, które mechanizmy bezpieczeństwa realizują wskazane artykuły i paragrafy przepisów.
Efektywne zarządzanie zgodnością w kontekście NIS2 i DORA oznacza również stworzenie spójnego mechanizmu monitorowania, raportowania i doskonalenia, w którym dane o incydentach, wynikach testów, audytach i przeglądach ryzyka są konsolidowane i przekładane na konkretne działania naprawcze. Oba akty prawne kładą duży nacisk na procesowe podejście do raportowania incydentów, w tym terminy zgłoszeń, zakres informacji oraz kanały komunikacji z organami nadzoru i CSIRT-ami krajowymi. Organizacje muszą ustanowić procedury obsługi incydentów, które precyzyjnie określają role (np. zespół reagowania na incydenty, komunikacja kryzysowa, prawnicy, PR), progi istotności, ścieżki eskalacji oraz sposób dokumentowania działań – tak, aby w razie kontroli można było wykazać zgodność nie tylko z samym obowiązkiem zgłoszenia, ale też z wymaganiami dotyczącymi reakcji i odtwarzania usług. W przypadku DORA nabiera to szczególnego znaczenia w relacjach z dostawcami ICT – podmioty finansowe muszą wykazać, że posiadają mechanizmy nadzoru nad kluczowymi dostawcami, w tym umowy kontraktowe zawierające wymogi dotyczące bezpieczeństwa, audytu, raportowania incydentów i prawa do przeprowadzania testów. Zarządzanie zgodnością staje się więc procesem międzyorganizacyjnym, obejmującym cały łańcuch dostaw cyfrowych usług. Z perspektywy operacyjnej warto wdrożyć zautomatyzowane narzędzia GRC (Governance, Risk & Compliance), które umożliwiają centralne zarządzanie rejestrem ryzyk, kontrolami, incydentami, zadaniami naprawczymi oraz dowodami zgodności – takie platformy znacząco ułatwiają przygotowanie się do kontroli nadzorców i audytów zewnętrznych, a także ograniczają ryzyko „ręcznych błędów” w dokumentacji. Istotnym elementem jest także kultura organizacyjna – NIS2 i DORA przenoszą dużą część odpowiedzialności na najwyższe kierownictwo, ale bez zaangażowania pracowników na każdym poziomie organizacji (od administratorów po użytkowników biznesowych) formalna zgodność nie przełoży się na realną odporność cyfrową. Dlatego zarządzanie zgodnością musi obejmować system szkoleń ukierunkowanych na role, regularne kampanie podnoszące świadomość, testy socjotechniczne, ćwiczenia typu tabletop oraz symulacje kryzysowe z udziałem zarządu. Wreszcie, organizacje powinny traktować zarządzanie zgodnością jako proces ciągły, a nie jednorazowy projekt wdrożeniowy – zmieniające się otoczenie regulacyjne, nowe wytyczne organów nadzoru, pojawiające się zagrożenia i technologie (np. chmura, AI, IoT) wymagają cyklicznej weryfikacji przyjętych rozwiązań, aktualizacji rejestru ryzyk i dostosowywania środków bezpieczeństwa. W tym kontekście regularne audyty wewnętrzne i niezależne przeglądy bezpieczeństwa pełnią funkcję „bezpiecznika”, który umożliwia wczesne wykrycie niezgodności i luk, zanim zostaną one ujawnione przez incydent lub kontrolę regulatora, a także budują zaufanie interesariuszy do dojrzałości organizacji w obszarze cyberbezpieczeństwa i odporności cyfrowej.
Wpływ NIS2 i DORA na kulturę cyberbezpieczeństwa
NIS2 i DORA w praktyce wymuszają na organizacjach odejście od traktowania cyberbezpieczeństwa jako „problemu działu IT” na rzecz podejścia, w którym bezpieczeństwo staje się elementem kultury organizacyjnej i codziennych decyzji biznesowych. Dyrektywa NIS2, obejmując szerokie spektrum sektorów i wymagając osobistej odpowiedzialności członków kierownictwa, zmienia sposób myślenia zarządów o ryzyku cyfrowym – z kosztu ubocznego na strategiczny czynnik przewagi konkurencyjnej i ciągłości działania. Podobnie DORA, kierowana do sektora finansowego, zmusza instytucje do włączenia odporności cyfrowej w rdzeń modeli operacyjnych, co oznacza, że bezpieczeństwo informacji i dostępność systemów stają się kluczowymi KPI raportowanymi na poziomie zarządu. W obu regulacjach rośnie nacisk na „tone from the top”: wymagane są nie tylko formalne polityki, ale także realne zaangażowanie najwyższego kierownictwa – od zatwierdzania strategii zarządzania ryzykiem ICT, przez udział w przeglądach incydentów, po sponsorowanie inicjatyw szkoleniowych. Przekłada się to na zmianę oczekiwań wobec liderów – muszą rozumieć podstawowe pojęcia cyberbezpieczeństwa, umieć interpretować raporty ryzyka i zadawać właściwe pytania ekspertom technicznym, a nie jedynie polegać na ich rekomendacjach. Organizacje, które poważnie podchodzą do zgodności z NIS2 i DORA, zaczynają definiować bezpieczeństwo jako wspólną odpowiedzialność – od zarządu, przez menedżerów liniowych, po każdego użytkownika systemów IT – co naturalnie wymusza rozwój kultury zgłaszania incydentów, transparentności i ciągłego doskonalenia procesów. Znacząco rośnie rola szkoleń i podnoszenia świadomości, które przestają być jednorazowym, formalnym „odhaczeniem” e-learningu, a stają się stałym elementem budowania kompetencji cyfrowych: krótkie, częste kampanie phishingowe, warsztaty scenariuszowe z udziałem biznesu, symulacje reakcji kryzysowych czy ćwiczenia typu „table-top” angażujące zarząd i kluczowe działy. NIS2 i DORA podkreślają także konieczność dokumentowania dowodów na faktyczne stosowanie procedur, a nie tylko ich istnienie na papierze; to przesuwa akcent z compliance deklaratywnego na compliance oparte na mierzalnych zachowaniach i powtarzalnych nawykach pracowników.
Wymogi regulacyjne obu aktów mają również głęboki wpływ na sposób, w jaki organizacje postrzegają współpracę między działami oraz relacje z dostawcami i partnerami technologicznymi. Obowiązki związane z zarządzaniem łańcuchem dostaw, testami odporności oraz raportowaniem incydentów wymuszają ściślejszą współpracę między IT, bezpieczeństwem, ryzykiem, prawnym, HR, zakupami, a w sektorze finansowym – także z zespołami odpowiedzialnymi za zgodność regulacyjną i relacje z nadzorcą. DORA w szczególności wprowadza kulturę systematycznego testowania, w tym zaawansowanych testów typu threat-led penetration testing (TLPT), które wymagają od biznesu gotowości do konfrontowania się z realnymi słabościami procesów – łącznie z akceptacją, że testy mogą zakłócić komfort pracy, jeśli mają odzwierciedlać rzeczywiste scenariusze ataków. Z perspektywy kultury organizacyjnej oznacza to przesunięcie akcentu z unikania problemów na aktywne ich wyszukiwanie, omawianie i eliminowanie w kontrolowany sposób, zanim zostaną wykorzystane przez cyberprzestępców. NIS2, obejmując szerszy ekosystem podmiotów krytycznych, skłania z kolei do budowania kultury współdzielenia informacji o zagrożeniach i incydentach w ramach branży oraz pomiędzy organizacjami a organami państwowymi – co w praktyce przekłada się na rozwój procesów threat intelligence, udział w sektorowych ISAC-ach oraz bardziej otwartą komunikację między konkurentami w zakresie bezpieczeństwa. Obie regulacje podnoszą także rangę zarządzania dostawcami: od prostego sprawdzenia certyfikatów przechodzimy do trwałych relacji opartych na wspólnych testach bezpieczeństwa, audytach on-site i wymaganiu od kluczowych partnerów podobnego poziomu dojrzałości bezpieczeństwa. Z czasem prowadzi to do „rozlewania się” kultury cyberbezpieczeństwa poza formalne granice organizacji – w kierunku całego łańcucha wartości, w tym outsourcingu, chmury i podmiotów przetwarzających dane. W efekcie NIS2 i DORA działają jak katalizator zmiany mentalności: bezpieczeństwo przestaje być postrzegane jako hamulec innowacji, a staje się warunkiem ich bezpiecznego skalowania, fundamentem zaufania klientów i regulatorów oraz naturalnym elementem projektowania nowych produktów i usług („security & resilience by design”).
Przygotowanie do wdrożenia: Krok po kroku
Przygotowanie organizacji do wdrożenia wymogów NIS2 i DORA warto potraktować jak program transformacji, a nie pojedynczy projekt IT. Pierwszym krokiem jest jednoznaczne określenie zakresu regulacyjnego: identyfikacja, czy organizacja jest podmiotem kluczowym lub ważnym w rozumieniu NIS2, a także które jednostki biznesowe i spółki z grupy kapitałowej są objęte DORA. Na tym etapie potrzebna jest współpraca działu prawnego, compliance, bezpieczeństwa IT/OT oraz biznesu, aby zmapować linie produktowe, usługi świadczone klientom, krytyczne procesy operacyjne oraz infrastrukturę techniczną. W praktyce oznacza to sporządzenie inwentaryzacji systemów i usług, które mają znaczenie dla ciągłości działania, wraz z ich zależnościami (np. kluczowe aplikacje, centra danych, dostawcy chmury, operatorzy telekomunikacyjni). Na tej podstawie można określić, które procesy będą priorytetowe w dalszych etapach wdrożenia i jakie ryzyka regulacyjne wiążą się z ewentualnymi lukami. Drugim istotnym krokiem jest przeprowadzenie szczegółowej analizy luk (gap analysis) względem wymogów obu regulacji – osobno dla NIS2 i DORA, a następnie w formie zintegrowanej mapy wymagań. Analiza powinna objąć obszary takie jak zarządzanie ryzykiem ICT, governance i zaangażowanie zarządu, zarządzanie incydentami, plany ciągłości działania i odtwarzania (BCP/DRP), zarządzanie dostawcami, testy bezpieczeństwa, szkolenia i świadomość, raportowanie i wskaźniki. Warto posłużyć się matrycą, w której do każdego przepisu i artykułu przypisane są istniejące polityki, procedury, narzędzia oraz role odpowiedzialne, a następnie ocenić poziom zgodności (np. zgodne, częściowo zgodne, brak). Taka matryca staje się fundamentem planu naprawczego (remediation plan), który określa konkretne inicjatywy, priorytety, harmonogram oraz budżet. W tym samym czasie należy wypracować docelowy model governance, w którym jasno zdefiniowane są role i odpowiedzialności: kto odpowiada za cyberbezpieczeństwo na poziomie zarządu, kto za operacyjne zarządzanie ryzykiem ICT, jaką pozycję i niezależność ma CISO, a także w jaki sposób raportowane są wskaźniki ryzyka i dojrzałości. W odniesieniu do DORA konieczne jest włączenie tematów ICT do ram zarządzania ryzykiem operacyjnym (ORM) oraz dostosowanie już istniejących komitetów ryzyka do regularnego przeglądu ryzyka ICT.
Kolejny krok to zbudowanie spójnego planu wdrożeniowego, który łączy wymagania NIS2 i DORA w jednym programie odporności cyfrowej, tak aby uniknąć dublowania działań. W praktyce oznacza to stworzenie programu projektów obejmujących: aktualizację polityk i procedur, wdrożenie lub konfigurację narzędzi technicznych (np. SIEM, SOAR, systemy zarządzania incydentami, rozwiązania do zarządzania podatnościami), rozwój procesów raportowania oraz wdrożenie szkoleń i kampanii świadomościowych. Dla niektórych organizacji będzie to też oznaczało konieczność formalizacji istniejących „dobrych praktyk” w postaci polityk, standardów i instrukcji operacyjnych. Szczególne znaczenie ma obszar zarządzania incydentami: należy ujednolicić definicje incydentu istotnego w rozumieniu NIS2 i „major incident” w rozumieniu DORA, opracować procedury klasyfikacji, eskalacji i raportowania, a także techniczne playbooki reakcji. Równolegle trzeba zbudować lub zmodernizować plany ciągłości działania i odtwarzania usług – w NIS2 kładzie się nacisk na zapewnienie ciągłości usług istotnych dla społeczeństwa, w DORA na utrzymanie krytycznych funkcji biznesowych i usług płatniczych, inwestycyjnych czy ubezpieczeniowych. Plany te powinny być oparte na analizie wpływu na biznes (BIA), określając dopuszczalny czas przestoju (RTO) i poziom utraty danych (RPO) dla kluczowych systemów. Istotnym etapem jest uporządkowanie relacji z dostawcami: należy przeprowadzić przegląd umów pod kątem wymogów NIS2 i DORA (klauzule dotyczące bezpieczeństwa, ciągłości działania, prawa do audytu, wymogów raportowania incydentów, lokalizacji danych), zidentyfikować dostawców krytycznych i wysokiego ryzyka oraz wdrożyć proces kwalifikacji i okresowej oceny bezpieczeństwa dostawców. Wymagania DORA w zakresie nadzoru nad dostawcami ICT i rejestrowania umów często oznaczają konieczność wdrożenia lub rozbudowy narzędzi do zarządzania trzecią stroną (TPRM). Ostatnim kluczowym komponentem przygotowania jest zaplanowanie testów odporności – od regularnych testów penetracyjnych i skanów podatności, przez ćwiczenia typu tabletop dla zarządu i zespołów reagowania, aż po zaawansowane testy typu TLPT (Threat-Led Penetration Testing) wymagane przez DORA dla wybranych podmiotów. Kluczowe jest, aby testy nie były celem samym w sobie, lecz generowały mierzalne wnioski do planów doskonalenia oraz zasilały cykl zarządzania ryzykiem. W tle całego programu powinien działać mechanizm komunikacji wewnętrznej – wyjaśniający pracownikom cel zmian, ich wpływ na codzienną pracę oraz oczekiwane postawy. Tylko wtedy wdrożenie NIS2 i DORA przestaje być „projektem regulacyjnym”, a staje się rzeczywistym fundamentem budowy trwałej odporności cyfrowej organizacji.
Podsumowanie
Zrozumienie wymogów NIS2 i DORA jest kluczowe dla budowy odporności cyfrowej w organizacjach. Obie dyrektywy, mimo różnic, skupiają się na wzmocnieniu ochrony IT oraz zapewnieniu zgodności. Sukces jest możliwy dzięki współpracy działów IT z zarządem i wypracowaniu kultury cyberbezpieczeństwa. Przygotowanie do wdrożenia nowych norm zwiększy poziom bezpieczeństwa i pomoże skuteczniej przeciwdziałać zagrożeniom cyfrowym. Pamiętaj, że implementacja wymaga staranności i przemyślanego podejścia, zwłaszcza w kontekście zarządzania ryzykiem ICT oraz integracji z dotychczasowymi procedurami w organizacji.
