Incydent ransomware o godzinie 18:00. Pytanie zespołu compliance: czy raportujemy do KNF z DORA, do CSIRT KNF z KSC, do obu, a może jeszcze do UODO z RODO? Odpowiedź zależy od trzech rzeczy — kategorii podmiotu, klasyfikacji incydentu i tego, czy zostały naruszone dane osobowe. W tym wpisie cyklu DORA vs NIS2 układamy procedurę krok po kroku, opierając się o art. 18 i 19 rozporządzenia (UE) 2022/2554 (DORA), art. 11 i 12 znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 20 t.j., zmiana Dz.U. 2026 poz. 252) oraz art. 33 RODO.

Co to jest „poważny incydent" w DORA i KSC?

Definicja jest kluczowa, bo decyduje o uruchomieniu ścieżki raportowania — i jest ujęta inaczej w obu reżimach.

DORA — art. 18 ust. 1 — wymienia sześć kryteriów klasyfikacji wpływu incydentu, których spełnienie (zwykle łącznie, w stopniu określonym w RTS wydawanych przez EUN na podstawie art. 18 ust. 3 DORA) sprawia, że incydent ICT jest „poważny":

Litera Kryterium DORA art. 18 ust. 1 Co oceniać
a) Klienci i kontrahenci Liczba lub znaczenie klientów lub kontrahentów finansowych, kwota lub liczba transakcji oraz skutki reputacyjne
b) Czas trwania Czas trwania incydentu związanego z ICT, w tym przerwa w świadczeniu usług
c) Zasięg geograficzny Zasięg geograficzny, w szczególności gdy dotyczy więcej niż dwóch państw członkowskich
d) Utrata danych Utrata danych w kontekście dostępności, autentyczności, integralności lub poufności
e) Krytyczność usług Krytyczność usług dotkniętych incydentem, w tym transakcji i operacji
f) Skutki gospodarcze Bezpośrednie i pośrednie koszty i straty — w kategoriach bezwzględnych i względnych

KSC — art. 2 pkt 7 KSC — definiuje „incydent poważny" jako incydent, który powoduje lub może spowodować poważne obniżenie jakości lub przerwanie ciągłości świadczenia usługi przez podmiot kluczowy lub podmiot ważny, straty finansowe dla tego podmiotu lub poważną szkodę materialną lub niematerialną innym osobom. Konkretne progi określa:

  • rozporządzenie wykonawcze Komisji (UE) 2024/2690 z 17 października 2024 r. — dla dostawców usług DNS, rejestrów TLD, dostawców chmury, centrów danych, dostawców usług zarządzanych w zakresie cyberbezpieczeństwa (MSSP), dostawców usług zarządzanych (MSP), platform handlowych, wyszukiwarek i platform społecznościowych;
  • rozporządzenie Rady Ministrów wydawane na podstawie art. 11 ust. 4 KSC — dla pozostałych podmiotów. Art. 11 ust. 4 KSC wymienia cztery kryteria, którymi rozporządzenie ma się kierować: liczba użytkowników, których dotyczy zakłócenie świadczenia usługi; czas oddziaływania incydentu; zasięg geograficzny; inne czynniki charakterystyczne dla danego sektora lub podsektora.

Konstrukcja jest podobna, ale ostre różnice są dwie. Po pierwsze — DORA ma kryterium „skutki gospodarcze" (lit. f), KSC nie. Po drugie — DORA explicite wskazuje „znaczenie klientów lub kontrahentów" (lit. a) i skutki reputacyjne, KSC mówi tylko o „liczbie użytkowników".

Trzy etapy raportowania — porównanie terminów

To jest oś, na której dwa reżimy mają najbardziej zbliżoną konstrukcję, ale inną podstawę liczenia czasu.

Etap KSC art. 11 ust. 1 KSC DORA art. 19 ust. 4 DORA
1. Wczesne ostrzeżenie / wstępne powiadomienie ≤24 godz. od momentu wykrycia (pkt 4) termin w RTS (art. 19 ust. 4 lit. a + art. 20 DORA)
2. Pełne zgłoszenie / sprawozdanie śródokresowe ≤72 godz. od momentu wykrycia (pkt 4a) termin w RTS (art. 19 ust. 4 lit. b + art. 20 DORA)
3. Sprawozdanie końcowe ≤1 miesiąc od dnia zgłoszenia (pkt 4c) po zakończeniu analizy przyczyn źródłowych (art. 19 ust. 4 lit. c + RTS)

Podstawowa różnica techniczna polega na zegarze startowym. W KSC art. 11 ust. 1 pkt 4 zegar 24 godzin biegnie od momentu wykrycia — niezależnie od dnia tygodnia, godziny i tego, czy klasyfikacja jako „poważnego" już zapadła. W DORA terminy określają regulacyjne i wykonawcze standardy techniczne (RTS i ITS) wydawane przez Europejskie Urzędy Nadzoru na podstawie art. 20 DORA — i polityka klasyfikacji powinna uwzględniać ich aktualne wersje, bez wpisywania konkretnych godzin na sztywno.

Dla zespołu compliance praktyczna konsekwencja jest taka: harmonogram dyżurów 24/7 i procedura uruchamiania zgłoszenia muszą zakładać najkrótszy z możliwych terminów — czyli w polskich realiach 24-godzinne okno KSC, jeżeli podmiot mu podlega.

Kto jest adresatem zgłoszenia?

Adresat różni się — i to jest detal, który najczęściej powoduje błędy proceduralne.

W KSC — art. 11 ust. 1 pkt 4 i 4a — adresatem jest właściwy CSIRT sektorowy. To jest jednostka techniczno-operacyjna nadzoru, ustanowiona zgodnie z art. 44 KSC dla każdego sektora wymienionego w załącznikach nr 1 i 2 do ustawy. Dla sektora bankowości i infrastruktury rynków finansowych jest to CSIRT KNF.

W DORA — art. 19 ust. 1 — adresatem jest odpowiedni właściwy organ w rozumieniu art. 46 DORA, czyli organ nadzoru sektorowego. W warunkach polskich dla większości podmiotów finansowych jest to Komisja Nadzoru Finansowego (KNF). Dla istotnych instytucji kredytowych raportowanie odbywa się dwustopniowo — do krajowego organu, a ten przekazuje EBC (art. 19 ust. 1 akapit trzeci DORA).

To trzeba wyraźnie zapisać w mapie adresatów: CSIRT KNF (technika) ≠ KNF (regulator). Zgłoszenie incydentu w trybie KSC trafia do CSIRT, ale w razie naruszenia przepisów to organ właściwy może wszcząć postępowanie nadzorcze (art. 53 KSC) i nałożyć karę z art. 73 KSC. W trybie DORA ścieżka raportowania prowadzi bezpośrednio do organu nadzoru.

Cztery scenariusze podmiotowe — kto raportuje gdzie

Z naszego doświadczenia najczęstsze pytanie zespołów compliance dotyczy nie samych terminów, ale tego, którą ścieżką pójść. Cztery typowe sytuacje:

Scenariusz 1 — bank krajowy lub oddział banku zagranicznego. Należy do sektora bankowości i infrastruktury rynków finansowych z załącznika nr 1 do KSC. Art. 8i ust. 1 KSC wyłącza stosowanie art. 11 KSC w zakresie zgłaszania incydentów (z wyjątkiem ust. 1 pkt 5 — współdziałanie z CSIRT i przechowywanie dowodów). W praktyce — bank raportuje incydent ICT wyłącznie po ścieżce DORA (art. 19) do KNF. Z KSC zostaje obowiązek współdziałania z CSIRT KNF w trakcie obsługi incydentu.

Scenariusz 2 — instytucja płatnicza (KIP, MIP, BUP), AISP, EMI lub CASP. Te podmioty są wprost objęte DORA jako podmioty finansowe (art. 2 ust. 1 rozporządzenia 2022/2554) — ale nie są wymienione w sektorze bankowości i infrastruktury rynków finansowych załącznika nr 1 do KSC. Dla nich art. 8i ust. 1 KSC nie ma zastosowania wprost. Konsekwencja: jeżeli podmiot wpada w KSC z innego tytułu (np. jako duży podmiot z innego sektora, jako MSSP albo jako podmiot zarządzania usługami ICT), dwie ścieżki raportowania działają równolegle — DORA art. 19 do KNF i KSC art. 11 do CSIRT KNF. Warto przy tym pamiętać, że art. 23 DORA (rozszerzenie na incydenty płatnicze) wymienia konkretnie banki (instytucje kredytowe), instytucje płatnicze, AISP i instytucje pieniądza elektronicznego — CASP są objęci DORA jako podmiot finansowy z art. 2 ust. 1 i raportują z art. 19, ale nie z art. 23. Tę pułapkę szczegółowo omawiamy w wpisie Art. 8i KSC i lex specialis DORA.

Scenariusz 3 — podmiot kluczowy lub ważny spoza sektora finansowego (np. dostawca chmury, MSSP, energetyka, zdrowie, woda). Tylko KSC art. 11 — ścieżka 24h/72h/1 miesiąc do CSIRT sektorowego.

Scenariusz 4 — podmiot ważny będący podmiotem publicznym. Art. 12c KSC wprowadza wyłączenie: do podmiotu ważnego będącego publicznym nie stosuje się przepisów o przekazywaniu wczesnego ostrzeżenia, sprawozdania okresowego, sprawozdania z postępu obsługi incydentu i sprawozdania końcowego. Pozostaje obsługa incydentu (art. 11 ust. 1 pkt 1), klasyfikacja (pkt 3), zgłoszenie incydentu poważnego w 72 godzinach (pkt 4a), współdziałanie z CSIRT (pkt 5) i usuwanie podatności (pkt 6).

Co z incydentami płatniczymi?

Art. 23 DORA jest detalem łatwym do przeoczenia — a istotnie zmienia konstrukcję raportowania w sektorze płatniczym.

Art. 23 DORA rozszerza zakres rozdziału III DORA na incydenty operacyjne lub incydenty bezpieczeństwa związane z płatnościami w bankach (instytucjach kredytowych), instytucjach płatniczych, dostawcach świadczących usługę dostępu do informacji o rachunku (AISP) i instytucjach pieniądza elektronicznego. Z naszego doświadczenia wymaga to przeglądu wewnętrznych procedur — często równolegle prowadzone były dwa odrębne procesy raportowe (PSD2 i ICT) i pod DORA naturalnym ruchem jest ich konsolidacja.

To ważne dla podmiotów, które dotąd raportowały incydenty płatnicze do KNF na podstawie art. 32g ustawy o usługach płatniczych — od 17 stycznia 2025 r. (rozpoczęcie stosowania DORA) ścieżka jest skonsolidowana w art. 19 DORA.

Sześć obowiązkowych elementów procesu zarządzania (DORA art. 17) i sześć elementów wczesnego ostrzeżenia (KSC art. 12 ust. 1)

Oba reżimy wymagają formalnego procesu zarządzania incydentami — i tu różnica jest funkcjonalna, nie ilościowa.

DORA art. 17 ust. 3 wymaga sześciu obowiązkowych elementów procesu (lit. a–f):

  • Wskaźniki wczesnego ostrzegania — lit. a.
  • Procedury identyfikowania, śledzenia, rejestrowania, kategoryzowania i klasyfikowania incydentów — lit. b.
  • Przydzielenie ról i obowiązków — lit. c.
  • Plany działań informacyjnych — lit. d.
  • Zgłaszanie poważnych incydentów kadrze kierowniczej i organowi zarządzającemu — lit. e.
  • Procedury reagowania na incydenty — lit. f.

KSC art. 12 ust. 1 wymienia sześć obowiązkowych elementów wczesnego ostrzeżenia (czyli treści zgłoszenia, nie samego procesu): dane podmiotu zgłaszającego; dane osoby dokonującej zgłoszenia; dane osoby uprawnionej do wyjaśnień; moment wystąpienia i wykrycia incydentu oraz czas trwania; wskazanie, czy incydent został wywołany działaniem bezprawnym lub w złej wierze; określenie, czy incydent dotyczy innych państw członkowskich UE.

To są dwa różne wymiary regulacyjne. DORA art. 17 mówi: jaki proces wewnętrzny. KSC art. 12 mówi: co konkretnie wpisać w zgłoszenie. Dla podmiotu objętego oboma reżimami praktyczna implikacja jest taka, że wewnętrzna procedura musi spełniać 6 elementów art. 17 DORA, a szablon zgłoszenia musi mieć 6 elementów art. 12 ust. 1 KSC — to są dwa osobne dokumenty.

Pełne zgłoszenie — co zawiera w każdym z reżimów

KSC art. 12 ust. 3 — pełne zgłoszenie składane w ciągu 72 godzin obejmuje pięć kategorii informacji: opis wpływu incydentu na świadczenie usługi (z wskazaniem usługi, liczby użytkowników, zasięgu geograficznego, wpływu na inne podmioty); opis przyczyn i sposobu przebiegu incydentu wraz z prawdopodobnymi skutkami; informacje o podjętych działaniach zapobiegawczych; informacje o podjętych działaniach naprawczych; aktualizacja danych z wczesnego ostrzeżenia. Art. 12 ust. 5 KSC wprowadza ulgę proceduralną: podmiot przekazuje informacje znane mu w chwili zgłoszenia i uzupełnia je w trakcie obsługi incydentu.

DORA art. 19 ust. 4 lit. b — sprawozdanie śródokresowe sporządza się, gdy zmienia się status incydentu lub pojawiają się nowe informacje. Po nim mogą następować dalsze aktualizacje. Konkretne wzory zgłoszeń i terminy określają RTS i ITS wydane na podstawie art. 20 DORA.

W praktyce — dla podmiotu objętego oboma reżimami — szablony pełnego zgłoszenia (KSC) i sprawozdania śródokresowego (DORA) różnią się treścią, ale obie ścieżki wymagają tych samych danych źródłowych: skutki, przyczyna, środki zaradcze.

Informowanie klientów — dwie podstawy prawne

Każdy z reżimów wprowadza obowiązek informowania klientów lub użytkowników, ale na innej przesłance.

DORA art. 19 ust. 3 akapit pierwszy stanowi: „W przypadku gdy wystąpi poważny incydent związany z ICT, który ma wpływ na interesy finansowe klientów, podmioty finansowe bez zbędnej zwłoki, gdy tylko się o nim dowiedzą, informują swoich klientów o poważnym incydencie związanym z ICT oraz o środkach, które podjęto w celu złagodzenia negatywnych skutków takiego incydentu". Przesłanka — „wpływ na interesy finansowe klientów".

KSC art. 11 ust. 2b — podmiot kluczowy lub ważny informuje użytkowników o incydencie poważnym, jeżeli ma on niekorzystny wpływ na świadczenie tych usług. Niezależnie — art. 11 ust. 2a KSC wymaga informowania o poważnym cyberzagrożeniu (przed wystąpieniem incydentu) i o możliwych środkach zapobiegawczych.

Te dwa obowiązki są równoległe. Dla banku objętego art. 8i KSC standardem jest art. 19 ust. 3 DORA. Dla podmiotu spoza sektora bankowości — art. 11 ust. 2a i 2b KSC. Dla instytucji płatniczej obie podstawy mogą znaleźć zastosowanie jednocześnie.

A co z RODO?

Jeżeli incydent obejmuje dane osobowe — uruchamia się trzecia, niezależna ścieżka.

Art. 33 RODO wymaga zgłoszenia naruszenia ochrony danych osobowych do Prezesa Urzędu Ochrony Danych Osobowych (UODO) w terminie 72 godzin od stwierdzenia naruszenia — bez konieczności klasyfikacji jako „poważnego" w rozumieniu DORA czy KSC. To trzecia ścieżka, niezależna od KSC i DORA.

Sama dyrektywa NIS2 w art. 35 wprost przewiduje równoległe stosowanie obowiązków NIS2 i RODO przy zdarzeniach łączących obie regulacje. Z naszego doświadczenia incydent ransomware z eksfiltracją danych klientów to zwykle trzy zgłoszenia — DORA (do KNF), KSC (do CSIRT KNF) i RODO (do UODO) — chyba że art. 8i ust. 1 KSC wyłącza ścieżkę KSC dla danego podmiotu.

Strategicznie istotny jest art. 76c ust. 1 KSC: jeżeli za czyn zagrożony karą z art. 73 lub 73a KSC nałożono prawomocnie karę przez Prezesa UODO, organ KSC nie wszczyna postępowania, poprzestając na pouczeniu. To „tarcza anty-RODO" działa wyłącznie po stronie kar — sam obowiązek zgłoszenia do obu organów pozostaje niezależny.

Najważniejsze działania przed pierwszym realnym incydentem

Z naszego doświadczenia firmy, które dobrze radzą sobie z reżimem incydentowym DORA + KSC, mają sześć stałych elementów w swoich procedurach:

  • Mapa decyzyjna podmiotu — czy jesteśmy w sektorze bankowości i infrastruktury rynków finansowych (art. 8i KSC działa)? Czy jesteśmy IP/EMI/AISP/CASP (art. 8i nie działa wprost)? Czy jesteśmy w innym sektorze kluczowym lub ważnym? Decyzja zarządu wpisana do protokołu posiedzenia.
  • Procedura reakcji na incydent — opis ról, ścieżki eskalacji, decyzji klasyfikacyjnej (DORA art. 18 oraz KSC art. 11 ust. 4 wraz z aktualnymi RTS i rozporządzeniami wykonawczymi), treści komunikatów.
  • Szablony zgłoszeń — wczesnego ostrzeżenia (art. 12 ust. 1 KSC), pełnego zgłoszenia (art. 12 ust. 3 KSC), sprawozdania końcowego (art. 12a KSC), wstępnego powiadomienia DORA (wzór z RTS art. 20 DORA), sprawozdania śródokresowego DORA, sprawozdania końcowego DORA.
  • Lista kontaktowa 24/7 — minimum dwóch osób z art. 9 ust. 1 pkt 1 KSC, przeszkolonych z procedury, z dostępem do systemu S46 (KSC) i kanału raportowania DORA.
  • Tabletop exercises — ćwiczenia symulacyjne raz w roku, w których zarząd i zespół incident response przechodzą przez pełną ścieżkę zgłoszenia w wszystkich aktywnych reżimach.
  • Dokumentacja incydentów — rejestr wszystkich zgłoszeń, sprawozdań, pism od CSIRT i organu nadzoru, decyzji organu — przechowywany zgodnie z art. 10 ust. 7 KSC przez minimum 2 lata.

Dwa pierwsze elementy są punktem startu — bez decyzji klasyfikacyjnej zarządu i jasnej procedury, w realnym kryzysie firma traci 6–12 godzin na ustalenie, którą ścieżką iść. Przy zegarze 24 godzin to oznacza, że na samo zgłoszenie pozostaje już bardzo mało czasu.

Jak możemy Ci pomóc?

Mapowanie obowiązków incydentowych DORA i KSC w jednym podmiocie — szczególnie w fintechu, który jest objęty DORA i może wpadać do KSC z innego tytułu — jest jednym z najbardziej złożonych projektów regulacyjnych roku 2026. Z naszego doświadczenia największą oszczędnością czasu jest jednolita procedura reakcji na incydent, która od pierwszego momentu uruchamia wszystkie aktywne ścieżki raportowania równolegle — bez prób ustalania „która jest ważniejsza". W Legal Geek wspieramy podmioty finansowe i nie-finansowe w opracowaniu procedury incydentowej obsługującej DORA, KSC i RODO w jednym workflow oraz prowadzimy tabletop exercises symulujące pełną kaskadę raportowania. Jeżeli chcesz sprawdzić, czy Twoja organizacja jest gotowa na pierwszy realny incydent w nowym reżimie — napisz do nas.

W kolejnym wpisie cyklu rozkładamy karę osobistą zarządu — KSC do 300% wynagrodzenia + sankcje DORA z prawa polskiego.

Co dalej w cyklu?

Źródła

  • Rozporządzenie (UE) 2022/2554 (DORA), art. 17–23 — EUR-Lex
  • Ustawa o KSC, art. 11, 12, 12a, 12b, 12c (Dz.U. 2026 poz. 20 t.j.) — ISAP
  • Dyrektywa (UE) 2022/2555 (NIS2), art. 23 i 35 — EUR-Lex
  • Rozporządzenie wykonawcze KE (UE) 2024/2690 — EUR-Lex
  • RODO, art. 33–34 — EUR-Lex