KSC NIS2 czy DORA? Jak sektor finansowy musi pogodzić obie regulacje?

Sektor finansowy znajduje się w wyjątkowej sytuacji regulacyjnej. Podczas gdy cała gospodarka przygotowuje się na rewolucję związaną z nowelizacją ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), wdrażającą dyrektywę NIS2, instytucje finansowe muszą jednocześnie sprostać wymogom innego, znacznie bardziej rygorystycznego aktu prawnego – Rozporządzenia DORA (Digital Operational Resilience Act). Pojawia się kluczowe pytanie: które z tych regulacji są ważniejsze i czy wdrożenie jednej zwalnia nas z drugiej?

Odpowiedź nie jest prosta, ale jest jednoznaczna: to nie jest kwestia „albo-albo”, ale „jak pogodzić oba”. KSC/NIS2 to ogólne, horyzontalne prawo dotyczące cyberbezpieczeństwa, podczas gdy DORA to lex specialis – prawo specjalistyczne, wertykalne, stworzone precyzyjnie dla sektora finansowego. Oznacza to, że podmioty finansowe muszą realizować bardziej szczegółowe wymogi DORA, jednocześnie nie tracąc z oczu ogólnych ram KSC/NIS2.

Czym dokładnie jest rozporządzenie DORA i kogo ono dotyczy?

DORA, czyli Rozporządzenie w sprawie operacyjnej odporności cyfrowej sektora finansowego, to rozporządzenie Unii Europejskiej, które wchodzi w życie w styczniu 2025 roku. Jego nadrzędnym celem jest ujednolicenie i wzmocnienie zarządzania ryzykiem związanym z technologiami informacyjno-komunikacyjnymi (ICT) w całym unijnym sektorze finansowym.

W przeciwieństwie do dyrektywy NIS2, która musi być wdrożona do prawa krajowego (jak nasza ustawa o KSC), DORA jako rozporządzenie działa wprost we wszystkich krajach członkowskich. Obejmuje ona nie tylko tradycyjne podmioty, takie jak banki, firmy ubezpieczeniowe czy domy maklerskie, ale także (co jest rewolucją) kluczowych zewnętrznych dostawców usług ICT, takich jak dostawcy chmury publicznej czy wyspecjalizowanych systemów transakcyjnych. nFlo, jako integrator specjalizujący się w regulacjach sektorowych, rozpoznaje DORA jako kluczowy czynnik zmiany dla całej branży.

Jaka jest prawna relacja między KSC/NIS2 a DORA?

Relacja ta opiera się na klasycznej zasadzie prawa: Lex specialis derogat legi generali (prawo szczegółowe uchyla prawo ogólne). KSC/NIS2 jest prawem ogólnym (horyzontalnym), które ustanawia bazowy poziom cyberbezpieczeństwa dla wielu sektorów gospodarki. DORA jest prawem szczegółowym (wertykalnym), które precyzyjnie reguluje sektor finansowy.

W praktyce oznacza to, że jeśli DORA reguluje jakiś obszar (np. zarządzanie dostawcami ICT lub testowanie odporności) w sposób bardziej szczegółowy niż KSC/NIS2, to podmiot finansowy musi stosować rygorystyczne wymogi DORA. W pozostałych obszarach, których DORA nie pokrywa tak szczegółowo, podmiot finansowy nadal podlega ogólnym przepisom KSC/NIS2. Nie można więc zignorować żadnej z tych regulacji.

Czy wdrożenie wymogów KSC/NIS2 oznacza, że jesteśmy zgodni z DORA?

Absolutnie nie. Takie myślenie to pułapka, która może być bardzo kosztowna. Wdrożenie KSC/NIS2 można potraktować jako dobry fundament, ale DORA stawia na nim znacznie wyższe i bardziej skomplikowane mury. Obie regulacje opierają się na tej samej filozofii zarządzania ryzykiem i obie kładą nacisk na bezpieczeństwo łańcucha dostaw, ale poziom szczegółowości w DORA jest nieporównywalnie wyższy.

Przykładowo, KSC/NIS2 wymaga „wdrożenia polityki analizy ryzyka” i „odpowiednich środków”. DORA precyzyjnie definiuje, co musi zawierać System Zarządzania Ryzykiem ICT, jak ma wyglądać klasyfikacja incydentów i jakie konkretnie testy odporności należy przeprowadzać. Potraktowanie zgodności z KSC/NIS2 jako celu końcowego sprawi, że organizacja finansowa nie spełni nawet połowy wymogów DORA.

Jakie są kluczowe filary DORA, które wykraczają poza standard KSC/NIS2?

DORA opiera się na pięciu kluczowych filarach, z których większość jest znacznie bardziej rygorystyczna niż ich odpowiedniki w KSC/NIS2. Różnice te pokazują, dlaczego sektor finansowy musi podejść do tematu w sposób szczególny.

1. Zarządzanie Ryzykiem ICT: DORA wymaga wdrożenia kompleksowych ram zarządzania ryzykiem ICT, które są integralną częścią ogólnego zarządzania ryzykiem w organizacji. Poziom szczegółowości polityk, procedur i wymaganych narzędzi jest bardzo wysoki.
2. Raportowanie Incydentów: Podobnie jak KSC/NIS2, DORA wymaga raportowania incydentów. System klasyfikacji i progi raportowania w DORA są jednak unikalne dla sektora finansowego i bardzo precyzyjnie zdefiniowane.
3. Testowanie Odporności Cyfrowej: To jedna z największych różnic. KSC/NIS2 mówi ogólnie o „testach i audytach”. DORA idzie o krok dalej, wymagając od kluczowych podmiotów przeprowadzania okresowych, zaawansowanych testów penetracyjnych opartych na analizie zagrożeń (TLPT – Threat-Led Penetration Testing).
4. Zarządzanie Ryzykiem Stron Trzecich (TPPs): To rewolucja. KSC/NIS2 wymaga zarządzania łańcuchem dostaw. DORA wprowadza pełne ramy zarządzania ryzykiem związanym z zewnętrznymi dostawcami ICT, łącznie z wymogiem posiadania strategii wyjścia (exit strategy).
5. Udostępnianie Informacji: DORA zachęca do tworzenia mechanizmów wymiany informacji o cyberzagrożeniach w sektorze.

Na czym polegają zaawansowane testy odporności (TLPT) wymagane przez DORA?

To nie jest standardowy test penetracyjny, który organizacja zleca raz w roku, aby „odhaczyć” zgodność. TLPT to znacznie bardziej zaawansowana forma testowania, znana również jako Red Teaming. Polega ona na symulacji realnego, zaawansowanego ataku (typu APT) wymierzonego w krytyczne funkcje biznesowe firmy.

Testy TLPT muszą być przeprowadzane co najmniej raz na trzy lata na kluczowych podmiotach. Są one realizowane przez zewnętrznych, certyfikowanych testerów (Red Team), którzy na podstawie analizy realnych zagrożeń (Threat Intelligence) próbują skompromitować organizację, testując jej pełną odporność – technologię, procesy i ludzi. To znacznie więcej niż standardowe testy penetracyjne infrastruktury czy aplikacji webowych.

Jak DORA zmienia zasady zarządzania dostawcami (TPPs) w porównaniu do KSC/NIS2?

Zarządzanie łańcuchem dostaw (SCRM) jest ważne w KSC/NIS2. W DORA jest ono absolutnie krytyczne i centralne. DORA mówi nie tylko o „dostawcach”, ale o „stronach trzecich świadczących usługi ICT” (Third-Party Providers – TPPs).

KSC/NIS2 wymaga, aby firma audytowała swoich dostawców i zawierała w umowach klauzule bezpieczeństwa. DORA idzie o wiele dalej. Wymaga od podmiotów finansowych posiadania pełnej strategii zarządzania ryzykiem TPPs, która musi obejmować m.in.:

• Bardzo rygorystyczną ocenę ryzyka przed podpisaniem umowy.
• Precyzyjne klauzule umowne (znacznie szersze niż w KSC/NIS2).
• Pełne prawo do audytu dostawcy.
• Strategię wyjścia (exit strategy): Firma musi mieć udokumentowany plan, jak zakończyć współpracę z kluczowym dostawcą (np. dostawcą chmury) i przenieść usługi gdzie indziej bez zakłócania ciągłości operacyjnej.

Co najważniejsze, DORA wprowadza bezpośredni nadzór regulatorów (tzw. Forum Nadzorcze) nad dostawcami ICT uznanymi za „krytycznych” dla sektora finansowego. Oznacza to, że regulator może kontrolować nie tylko bank, ale także jego dostawcę chmury.

Czy system monitoringu SOC 24/7 jest potrzebny do zgodności z DORA?

Tak, i to jeszcze bardziej niż w przypadku KSC/NIS2. Zdolność do szybkiego wykrywania i raportowania incydentów jest fundamentem DORA. Rozporządzenie wymaga wdrożenia bardzo szczegółowych mechanizmów wykrywania anomalii i incydentów oraz ich natychmiastowej klasyfikacji.

Wymóg raportowania w 24h z KSC/NIS2  jest już ogromnym wyzwaniem operacyjnym. DORA dokłada do tego skomplikowaną matrycę klasyfikacji zdarzeń. W praktyce, jedynym sposobem na spełnienie tych wymogów jest posiadanie dojrzałego Security Operations Center (SOC), które monitoruje infrastrukturę w trybie 24/7.

Taki SOC musi być jednak skonfigurowany pod kątem DORA – jego systemy (SIEM/SOAR) i analitycy muszą być przeszkoleni, aby klasyfikować incydenty nie tylko według ogólnych reguł, ale według precyzyjnej taksonomii wymaganej przez nadzór finansowy (np. KNF).

Czy można wdrożyć KSC/NIS2 i DORA w ramach jednego projektu?

Jest to nie tylko możliwe, ale wręcz rekomendowane i najbardziej efektywne kosztowo. Próba prowadzenia dwóch oddzielnych projektów zgodności doprowadzi do chaosu, powielania pracy i gigantycznych kosztów. Obie regulacje, mimo różnic w szczegółowości, opierają się na tym samym fundamencie: zarządzaniu ryzykiem.

Model wdrożenia START – CORE – RESILIENCE , który nFlo stosuje dla KSC/NIS2, można idealnie zreplikować dla DORA.

• Faza START: Zaczyna się tak samo – od audytu i analizy ryzyka, ale od razu przeprowadzanej pod kątem obu regulacji.
• Faza CORE: Budowa SZBI  jest fundamentem. Zamiast tworzyć politykę SCRM (dla KSC/NIS2), od razu tworzy się bardziej rozbudowaną „Strategię Zarządzania Ryzykiem TPPs” (dla DORA).
• Faza RESILIENCE: Zamiast „zwykłego” SOC, od razu wdraża się SOC dostosowany do wymogów raportowania DORA. Zamiast standardowych pentestów, planuje się zaawansowane testy TLPT.

Podejście zintegrowane pozwala zbudować jeden, spójny system zarządzania bezpieczeństwem, który spełnia wymogi obu aktów prawnych.

Dlaczego do wdrożenia DORA potrzebny jest partner znający specyfikę finansową?

Wdrożenie KSC/NIS2 wymaga partnera, który łączy kompetencje GRC i technologię. Wdrożenie DORA wymaga tego samego, ale na znacznie wyższym poziomie specjalizacji. Nie wystarczy tu znajomość ogólnych norm ISO. Potrzebny jest partner, który rozumie specyfikę sektora finansowego, wytyczne KNF i EBA oraz samą logikę DORA.

Rynek jest podzielony na firmy GRC (konsulting „papierowy”) oraz integratorów IT (wdrożenia „pudełek”). Sektor finansowy potrzebuje partnera end-to-end, który potrafi płynnie połączyć te światy.

Partner taki jak nFlo, posiadający w swoim portfolio zarówno usługi GRC (doradztwo w zakresie regulacji sektorowych, jak DORA czy wytyczne KNF ), jak i zaawansowane usługi cybersecurity (testy penetracyjne, wdrożenia SIEM/SOC ), jest w stanie przeprowadzić instytucję finansową przez cały, skomplikowany proces. Taki partner potrafi zarówno przeprowadzić audyt GRC pod kątem DORA, jak i technicznie zrealizować wymóg zaawansowanych testów TLPT czy wdrożyć SOC zdolny do raportowania zgodnego z wymogami KNF.

Porównanie Wymogów: KSC/NIS2 vs. DORA

Poniższa tabela przedstawia kluczowe różnice w podejściu obu regulacji. Dla sektora finansowego DORA jest zawsze wymogiem nadrzędnym.