DORA uchroniła was przed NIS2. Przed CRA nie uchroni.

TL;DR. 11 września CRA uruchamia 24-godzinny termin zgłoszenia. Obowiązek wisi na produkcie, więc wyłączenie DORA spod NIS2 nigdy do niego nie sięga.

Kluczowe wnioski

Co naprawdę zaczyna się 11 września. CRA weszło w życie 10 grudnia 2024 r.
Dlaczego wyłączenie DORA tu nie sięga. To jest miejsce zasługujące na większą niż zwykle precyzję, bo rozumowanie prowadzące do złej odpowiedzi jest rozumowaniem naprawdę dobrym — tylko przeniesionym o jedno rozporządzenie za daleko.
Czy jesteście producentem? Nikt za was na to nie odpowiedział. Uczciwe stanowisko brzmi tu: kwestia jest otwarta, a nie rozstrzygnięta, a bank, który poczeka na rozstrzygnięcie, poczeka poza termin.
Zderzenie zegarów. Załóżmy na chwilę, że analiza wskazuje objęcie co najmniej jednego artefaktu.

Za trzydzieści dziewięć dni rozporządzenie o cyberodporności uruchamia dwudziestoczterogodzinny zegar zgłoszeniowy, a wyłączenie, po które sięga każdy bank, go nie zatrzymuje. Zapytajcie instytucję finansową, czy stosuje się NIS2, a odpowiedź przyjdzie bez zająknięcia: DORA jest lex specialis, artykuł 4 NIS2 ustępuje wszędzie tam, gdzie akt sektorowy pokrywa to samo pole, a bank zgłasza incydenty ICT swojemu organowi właściwemu, nie zaś zespołowi CSIRT. Ta odpowiedź jest prawidłowa. I zaraz zostanie udzielona — błędnie — na pytanie dotyczące zupełnie innego rozporządzenia. CRA nie reguluje podmiotów. Reguluje produkty i nakłada obowiązki na tego, kto je wytwarza. W jego przepisie o zakresie nie ma wyłączenia dla usług finansowych, ponieważ wyłączenie napisane dla prawa podmiotów nie ma się czego uchwycić w prawie produktowym. Od 11 września 2026 r. bank udostępniający oprogramowanie na rynku jest winien ENISA wczesne ostrzeżenie w ciągu dwudziestu czterech godzin — i jest je winien obok DORA, a nie zamiast niej.

Streszczenie dla zarządu

To data działająca, nie horyzont. Artykuł 14 stosuje się od 11 września 2026 r. Reszta CRA czeka do 11 grudnia 2027 r., a błąd planistyczny mieszka w odległości między tymi dwoma faktami.

O zakresie decyduje to, co dostarczacie, a nie to, czym jesteście. Wyłączenia CRA to inne reżimy produktowe — wyroby medyczne, pojazdy, lotnictwo, wyposażenie morskie. Bankowości tam nie ma i nigdy być nie miało.

Wyzwalaczem jest wykorzystanie, nie dotkliwość. Aktywnie wykorzystywana podatność uruchamia zegar, nawet jeśli żaden klient nie ucierpiał i nic nie stanowiłoby poważnego incydentu w rozumieniu DORA.

Dziś nikt tego nie posiada. Zgłoszenie DORA mieszka w odporności operacyjnej. Zgłoszenie CRA mieszka u tego, kto uchodzi za producenta — rola, której większość banków nigdy nie przydzieliła.

Co naprawdę zaczyna się 11 września

CRA weszło w życie 10 grudnia 2024 r. z etapowym harmonogramem stosowania i to właśnie etapowość gubi się po drodze.

Pełne stosowanie — zasadnicze wymogi cyberbezpieczeństwa z załącznika I, ocena zgodności, oznakowanie CE, dokumentacja techniczna — przypada na 11 grudnia 2027 r. Notyfikacja jednostek oceniających zgodność otworzyła się 11 czerwca 2026 r. Między nimi leży data istotna w tym kwartale: 11 września 2026 r., gdy zaczynają się obowiązki zgłoszeniowe z artykułu 14.

Struktura zgłoszenia jest trójstopniowa i ciaśniejsza, niż brzmi przy pierwszym czytaniu.

Wczesne ostrzeżenie w ciągu 24 godzin od powzięcia przez producenta wiedzy o aktywnie wykorzystywanej podatności albo o poważnym incydencie mającym wpływ na bezpieczeństwo produktu.
Pełne zgłoszenie w ciągu 72 godzin, zawierające szczegóły techniczne oraz podjęte środki naprawcze lub łagodzące.
Sprawozdanie końcowe w ciągu 14 dni od udostępnienia środka naprawczego dla aktywnie wykorzystywanej podatności albo w ciągu miesiąca od zgłoszenia w przypadku poważnego incydentu.

Zgłoszenia przechodzą przez jednolitą platformę zgłoszeniową CRA prowadzoną przez ENISA. Producent składa raz — do CSIRT wyznaczonego jako koordynator w państwie członkowskim swojej głównej siedziby; platforma równocześnie udostępnia zgłoszenie ENISA, a przyjmujący CSIRT przekazuje je dalej do CSIRT na terytoriach, gdzie produkt jest dystrybuowany. Ta konstrukcja jednego złożenia usuwa administracyjną wymówkę, ale nie łagodzi terminu.

Zwróćcie uwagę na wyzwalacz. Nie dotkliwość i nie wpływ na klienta — wykorzystanie. Podatność aktywnie wykorzystywana w realnym środowisku otwiera obowiązek 24-godzinny bez względu na to, czy ktokolwiek ucierpiał, i bez względu na to, czy te same fakty zakwalifikowałyby się gdzie indziej jako poważny incydent.

Dlaczego wyłączenie DORA tu nie sięga

To jest miejsce zasługujące na większą niż zwykle precyzję, bo rozumowanie prowadzące do złej odpowiedzi jest rozumowaniem naprawdę dobrym — tylko przeniesionym o jedno rozporządzenie za daleko.

Artykuł 4 NIS2 zawiera mechanizm ustąpienia: jeżeli sektorowy akt unijny wymaga od podmiotów przyjęcia środków zarządzania ryzykiem cyberbezpieczeństwa albo zgłaszania poważnych incydentów, a wymogi te są co najmniej równoważne co do skutku, odpowiednie przepisy NIS2 nie mają zastosowania. DORA jest dokładnie takim aktem. Instytucja kredytowa zarządza więc ryzykiem ICT i zgłasza poważne incydenty na podstawie DORA, a równoległe obowiązki NIS2 ustępują. Każdy dział spraw regulacyjnych wyrecytuje to z pamięci.

Trzy rzeczy łamią tę analogię, gdy tylko przenieść ją na CRA.

Mechanizm mieszka wewnątrz NIS2. Artykuł 4 to przepis dyrektywy (UE) 2022/2555 wyłączający przepisy dyrektywy (UE) 2022/2555. Nie jest ogólną zasadą, wedle której reżim sektorowy podmiotu finansowego wypiera wszystko pozostałe. Nie może sięgnąć do rozporządzenia (UE) 2024/2847 i niczego tam wyłączyć, bo nic w CRA mu nie podlega.

CRA reguluje produkty, nie podmioty. DORA i NIS2 pytają obie: jakim jesteście rodzajem organizacji. CRA pyta: co wprowadziliście do obrotu. To różne pytania, a argumenty o równoważności między nimi nie utrzymują się: reżim zgłoszeniowy DORA w żadnym sensie nie jest „równoważny co do skutku" obowiązkowi producenta ostrzeżenia CSIRT, że dostarczony artefakt jest wykorzystywany, bo chronią różne populacje. DORA chroni system finansowy poprzez organ nadzoru. Artykuł 14 chroni wszystkich, którzy uruchamiają produkt, poprzez sieć CSIRT.

Wyłączenia mają inny kształt. Przepis o zakresie CRA wyjmuje produkty objęte innym sektorowym prawodawstwem produktowym — wyroby medyczne na podstawie rozporządzeń (UE) 2017/745 i 2017/746, pojazdy na podstawie rozporządzenia (UE) 2019/2144, lotnictwo cywilne na podstawie rozporządzenia (UE) 2018/1139, wyposażenie morskie na podstawie dyrektywy 2014/90/UE — a nadto części zamienne wytworzone według identycznych specyfikacji oraz produkty opracowane wyłącznie do celów bezpieczeństwa narodowego lub obronności. Nie ma wyłączenia dla usług finansowych ani dla produktów wytwarzanych przez podmioty regulowane przez DORA. To nie jest przeoczenie, które naprawią wytyczne. To jest to, co dzieje się, gdy prawodawca pisze prawo produktowe: nie wyjmuje branż, wyjmuje inne reżimy produktowe.

Tabela 1: trzy reżimy i który ustępuje

	DORA	NIS2	CRA
Reguluje	Podmioty finansowe	Podmioty kluczowe i ważne	Produkty z elementami cyfrowymi
Obowiązek spoczywa na	Instytucji	Instytucji	Producencie
Wyzwalacz zgłoszenia	Incydent zaklasyfikowany jako poważny	Poważny incydent	Aktywnie wykorzystywana podatność lub poważny incydent
Zgłoszenie trafia do	Organu właściwego	CSIRT lub organu właściwego	CSIRT głównej siedziby oraz ENISA
Wypierany dla banków?	Nie — to on jest lex specialis	Tak, przez artykuł 4 NIS2	Nie — nic go nie wypiera

Czy jesteście producentem? Nikt za was na to nie odpowiedział

Uczciwe stanowisko brzmi tu: kwestia jest otwarta, a nie rozstrzygnięta, a bank, który poczeka na rozstrzygnięcie, poczeka poza termin.

CRA sięga produktów z elementami cyfrowymi udostępnianych na rynku — dostarczanych do dystrybucji lub użytku w ramach działalności handlowej. Z tego sformułowania natychmiast wynikają dwie konsekwencje.

Cena nie jest kryterium. Oprogramowanie dostarczane nieodpłatnie mieści się w zakresie, jeżeli jest dostarczane w ramach działalności handlowej. Własne ujęcie Komisji w sprawie otwartego oprogramowania obraca się wokół działalności handlowej, a nie zapłaty; bank zaś rozprowadzający aplikację po to, by pozyskiwać i obsługiwać płacących klientów, nie działa poza ramami działalności handlowej. Odruch „aplikację oddajemy za darmo, więc nie sprzedajemy produktu" to najczęstszy powód, dla którego tej teczki nie otwarto, i najsłabszy z dostępnych argumentów.

Oprogramowanie ściśle wewnętrzne naprawdę jest poza zakresem. Produkty nieudostępniane na rynku — platforma systemu centralnego, narzędzia wewnętrzne, wszystko, co nigdy nie jest dostarczane poza instytucję — nie są objęte. To realne i znaczące wyłączenie i właśnie dlatego ekspozycja jest węższa, niż sugeruje panikarska wersja tej analizy.

Pytanie nie brzmi zatem, czy bank mieści się w zakresie jako podmiot. Brzmi: jakie konkretnie artefakty dostarcza. Cztery kategorie zasługują na inwentaryzację, zanim ktokolwiek dojdzie do wniosku:

Aplikacja bankowości mobilnej, dystrybuowana ogółowi społeczeństwa przez sklepy z aplikacjami. Czy aplikacja skierowana do klienta jest produktem dostarczonym do użytku, czy jedynie interfejsem do usługi świadczonej przez bank — to pytanie naprawdę sporne, i jest ono sporne, a nie rozstrzygnięte na korzyść banku.
Artefakty dla programistów: SDK, biblioteki klienckie, narzędzia API i implementacje referencyjne publikowane dla klientów korporacyjnych lub partnerów. Te znacznie bardziej przypominają dostarczone produkty niż interfejs usługi.
Projekty open source publikowane i utrzymywane przez instytucję w ramach jej działalności handlowej, gdzie mogą też uruchomić się przepisy o opiekunie (steward).
Oprogramowanie white-label lub wbudowane, które bank przekazuje dalej partnerom pod własną nazwą — najszybsza droga od użytkownika do producenta w każdym unijnym reżimie produktowym.

Uczciwa postawa planistyczna nie polega na ogłoszeniu wniosku. Polega na zinwentaryzowaniu artefaktów, spisaniu uzasadnionego stanowiska co do każdego z nich i na zdolności okazania tego rozumowania, gdy CSIRT zapyta, dlaczego żadne zgłoszenie nie wpłynęło.

Zderzenie zegarów

Załóżmy na chwilę, że analiza wskazuje objęcie co najmniej jednego artefaktu. Operacyjnie zmienia się nie istnienie procesu incydentowego — banki go mają — lecz to, że na tym samym zdarzeniu działają teraz dwa procesy o różnych parametrach.

Podatność w SDK opublikowanym przez bank przechodzi w stan aktywnego wykorzystania. DORA pyta, czy jest to poważny incydent związany z ICT dotykający instytucji; jeśli tak, zgłoszenie wstępne idzie do organu właściwego w ciągu czterech godzin od tej klasyfikacji i w każdym razie w ciągu 24 godzin od powzięcia wiedzy, a za nim sprawozdanie pośrednie i końcowe. Artykuł 14 pyta o coś zupełnie innego — czy wykorzystywany jest produkt, który ta instytucja wytworzyła — i uruchamia własne 24-godzinne wczesne ostrzeżenie do CSIRT i ENISA.

Te dwa mogą się rozejść w obie strony i właśnie to czyni pojedynczy scalony proces niebezpiecznym.

Wykorzystywana podatność w dostarczonym SDK, która nie powoduje żadnego zakłócenia własnych usług banku, może w ogóle nie być poważnym incydentem w rozumieniu DORA, a jednocześnie leżeć w samym środku artykułu 14. I odwrotnie: ciężka awaria platformy zbudowanej wewnętrznie to zgłoszenie DORA bez jakiegokolwiek wymiaru CRA, bo nic nie zostało wprowadzone do obrotu. Zbudowanie jednego przepływu zakładającego, że oba zawsze odpalają razem, produkuje jednocześnie fałszywe negatywy i zbędny szum regulacyjny.

Tabela 2: co ustalić przed 11 września

Pytanie	Co przesądza w waszej ekspozycji
Jakie artefakty dostarczamy poza instytucję?	Zakres ustala się per produkt; odpowiedź na poziomie podmiotu nie istnieje
Czy dla każdego mamy udokumentowane stanowisko co do statusu producenta?	Nieudokumentowane założenie nie jest obroną
Gdzie jest nasza główna siedziba na potrzeby CSIRT?	Przesądza, który krajowy CSIRT przyjmie złożenie
Czy jesteśmy zarejestrowani na jednolitej platformie zgłoszeniowej ENISA?	24 godziny nie wystarczą, by odkryć krok rejestracyjny
Czy „aktywnie wykorzystywana" ma właściciela w triage'u?	Wyzwalacz różni się od każdej skali dotkliwości, której już używacie
Kto składa o 3:00 w niedzielę?	Oba zegary chodzą w czasie rzeczywistym, nie w godzinach pracy

Liczba, która ustawia priorytet

Naruszenie zasadniczych wymogów z załącznika I oraz obowiązków z artykułów 13 i 14 zagrożone jest administracyjnymi karami pieniężnymi do 15 mln EUR albo 2,5 % całkowitego rocznego światowego obrotu, w zależności od tego, która kwota jest wyższa. Pozostałe obowiązki producentów, importerów i dystrybutorów leżą stopień niżej, przy 10 mln EUR albo 2 %, a przekazanie organom informacji nieprawidłowych lub wprowadzających w błąd — przy 5 mln EUR albo 1 %.

Przeczytajcie najwyższy stopień obok pracy, do której jest przypięty. Ustalenie, czy cztery kategorie artefaktów mieszczą się w zakresie, zarejestrowanie się na platformie zgłoszeniowej i dodanie jednej gałęzi do istniejącego podręcznika triage'u to skromne przedsięwzięcie, z wyznaczonym właścicielem i pięciotygodniowym rozbiegiem. Nie jest porównywalne z programem oceny zgodności i dokumentacji technicznej czekającym w grudniu 2027 r. Asymetria między ekspozycją a kosztem naprawy jest całym argumentem i jest to ów rzadki argument zgodnościowy, który przeżywa zetknięcie z naradą priorytetową.

Podręcznik operacyjny

Pięć ruchów, a pierwszy z nich nie jest opinią prawną.

Zinwentaryzujcie to, co opuszcza budynek. Nie systemy — artefakty. Wszystko, co instytucja dostarcza komukolwiek na zewnątrz, w tym bezpłatne aplikacje, opublikowane biblioteki i repozytoria open source. Większość banków takiego wykazu nie ma, bo żadna wcześniejsza regulacja o niego nie prosiła.
Zajmijcie stanowisko dla każdego artefaktu, na piśmie. Producent albo nie, i dlaczego. Wartość nie tkwi w trafieniu w każdą linijkę; tkwi w posiadaniu rozumowania poprzedzającego incydent, a nie skonstruowanego po nim.
Zarejestrujcie się na jednolitej platformie zgłoszeniowej już teraz. Rejestracja, poświadczenia i wyznaczony składający to dokładnie ten rodzaj warunku wstępnego, który pozostaje niewidoczny, dopóki zegar 24 godzin już nie idzie.
Rozdzielcie wyzwalacz w triage'u. Dodajcie jedno wyraźne pytanie — czy produkt, który wytwarzamy, jest aktywnie wykorzystywany — oceniane niezależnie od klasyfikacji poważnego incydentu w DORA. Niezależność jest sednem: zagnieżdżone sprawdzenie dziedziczy niewłaściwy próg.
Zacznijcie prace nad SBOM pod datę grudnia 2027 r. Załącznik I wymaga wykazu materiałów oprogramowania w powszechnie używanym formacie nadającym się do odczytu maszynowego, obejmującego co najmniej zależności najwyższego poziomu. Ten obowiązek jest szesnaście miesięcy przed nami i jest tym samym problemem wyliczenia, na którym instytucje już przewracają się po stronie kryptograficznej.

Wzorzec nie jest nowy. Reżim redaguje się z myślą o konkretnej branży, instytucje finansowe czytają nazwę branży i wnioskują, że teczka należy do kogoś innego. CRA napisano dla producentów urządzeń i dostawców oprogramowania. Mimo to sięga banku — w tym wąskim miejscu, w którym bank akurat jednym z nich jest. A wyłączenie, po które wszyscy sięgną najpierw, wpisano do innej ustawy, w innym celu, i tutaj nie ma zastosowania.

Najczęściej zadawane pytania

Zgłaszamy na podstawie DORA. Czy to nie wystarcza?
Nie. DORA wypiera równoległe obowiązki NIS2 poprzez mechanizm ustąpienia z samego artykułu 4 NIS2. Mechanizm ten jest wewnętrzny wobec NIS2 i nie wywołuje skutków wobec rozporządzenia (UE) 2024/2847. CRA nakłada obowiązki na producentów produktów, nie na podmioty finansowe, więc nie ma czego argument lex specialis mógłby wyprzeć.

Czy nasza aplikacja bankowości mobilnej mieści się w zakresie?
To właśnie jest pytanie naprawdę otwarte i należy na nie odpowiedzieć świadomie, a nie przyjąć odpowiedź z góry. Aplikacja to oprogramowanie z połączeniem transmisji danych, dostarczane publiczności w ramach działalności handlowej — takie jest brzmienie przepisu. Kontrargument głosi, że jest ona interfejsem do usługi regulowanej, a nie produktem dostarczonym do użytku. Udokumentujcie stanowisko; nie opierajcie się na tym, że jest bezpłatna, bo cena nie jest kryterium.

Co dokładnie uruchamia zegar 24 godzin?
Powzięcie wiedzy o podatności waszego produktu, która jest aktywnie wykorzystywana, albo o poważnym incydencie mającym wpływ na bezpieczeństwo produktu. Wyzwalaczem jest wykorzystanie, nie dotkliwość i nie wpływ na klienta — dlatego nie pokrywa się z klasyfikacją poważnego incydentu w DORA.

Do kogo faktycznie składamy?
Przez jednolitą platformę zgłoszeniową CRA przy ENISA, do CSIRT wyznaczonego jako koordynator w państwie członkowskim waszej głównej siedziby. ENISA otrzymuje je równocześnie, a przyjmujący CSIRT dzieli się nim z CSIRT na innych terytoriach, gdzie produkt jest dystrybuowany. Jedno złożenie, nie kilka.

Czy we wrześniu zaczyna się coś jeszcze?
Nie. Wyłącznie obowiązki zgłoszeniowe z artykułu 14. Zasadnicze wymogi cyberbezpieczeństwa, obowiązek SBOM, ocena zgodności, dokumentacja techniczna i oznakowanie CE stosują się wszystkie od 11 grudnia 2027 r. Traktowanie września jako całej teczki jest lustrzanym odbiciem ignorowania jej.

Ile kosztuje pomyłka w ustaleniu zakresu?
Naruszenia artykułów 13 i 14 oraz zasadniczych wymogów z załącznika I zagrożone są karami do 15 mln EUR albo 2,5 % całkowitego rocznego światowego obrotu, w zależności od tego, która kwota jest wyższa. Bardziej bezpośredni koszt jest proceduralny: pominiętego wczesnego ostrzeżenia nie da się naprawić wstecz, a moment, w którym instytucja odkrywa, że była producentem, nie powinien być momentem, w którym CSIRT pyta, dlaczego żadne zgłoszenie nie wpłynęło.

Bibliografia

Parlament Europejski i Rada Unii Europejskiej, 2024. Rozporządzenie (UE) 2024/2847 w sprawie horyzontalnych wymogów cyberbezpieczeństwa w odniesieniu do produktów z elementami cyfrowymi (rozporządzenie o cyberodporności). Bruksela: Dziennik Urzędowy Unii Europejskiej. Dostępne pod adresem: Parlament Europejski i Rada Unii Europejskiej, 2024..
Komisja Europejska, 2026. Rozporządzenie o cyberodporności — obowiązki zgłoszeniowe. Bruksela: Dyrekcja Generalna ds. Sieci Komunikacyjnych, Treści i Technologii. Dostępne pod adresem: Komisja Europejska, 2026..
Komisja Europejska, 2026. Rozporządzenie o cyberodporności — streszczenie tekstu legislacyjnego. Bruksela: Dyrekcja Generalna ds. Sieci Komunikacyjnych, Treści i Technologii. Dostępne pod adresem: Komisja Europejska, 2026..
Parlament Europejski i Rada Unii Europejskiej, 2022. Dyrektywa (UE) 2022/2555 w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii (dyrektywa NIS 2). Bruksela: Dziennik Urzędowy Unii Europejskiej. Dostępne pod adresem: Parlament Europejski i Rada Unii Europejskiej, 2022..
Parlament Europejski i Rada Unii Europejskiej, 2022. Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA). Bruksela: Dziennik Urzędowy Unii Europejskiej. Dostępne pod adresem: Parlament Europejski i Rada Unii Europejskiej, 2022..

Ostatnia weryfikacja 2026-08-16.

Opublikuj ponownie ten artykuł

DORA uchroniła was przed NIS2. Przed CRA nie uchroni. — Sebastien Rousseau

11 września CRA uruchamia 24-godzinny termin zgłoszenia. Obowiązek wisi na produkcie, więc wyłączenie DORA spod NIS2 nigdy do niego nie sięga.

Ten artykuł jest objęty licencją Creative Commons Attribution 4.0 International. Ponowna publikacja wymaga przypisania do kanonicznego adresu URL.

DORA uchroniła was przed NIS2. Przed CRA nie uchroni. — Sebastien Rousseau

11 września CRA uruchamia 24-godzinny termin zgłoszenia. Obowiązek wisi na produkcie, więc wyłączenie DORA spod NIS2 nigdy do niego nie sięga.

Originally published at https://sebastienrousseau.com/pl/2026-08-03-cyber-resilience-act-article-14-reporting-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER