DORA w praktyce: odporność to nie dokument polityki

DORA obowiązuje od 17 stycznia 2025 roku. Żadnych okresów przejściowych, żadnych przedłużeń. Organy nadzorcze zbierają Rejestry Informacji, przeglądają frameworki zarządzania ryzykiem ICT i wydają obserwacje. Pierwsze powiadomienia o Threat-Led Penetration Testing trafiają do organizacji w 2026 roku.

Jeśli Twoja organizacja działa w sektorze finansowym - albo dostarcza usługi ICT podmiotom finansowym - to rozporządzenie już Cię dotyczy lub bezpośrednio kształtuje to, czego Twoi klienci będą od Ciebie wymagać. A co organy nadzorcze i klienci zaczynają znajdować, to ta sama luka wszędzie: organizacje, które mają dokumentację, ale nie potrafią obronić tego, co za nią stoi.

To jest problem wart rozwiązania.

Kto faktycznie jest w zakresie

DORA obejmuje szeroki katalog podmiotów finansowych: banki, ubezpieczycieli, firmy inwestycyjne, instytucje płatnicze, dostawców usług kryptoaktywów i wiele innych (Art. 2). To oczywista część.

Mniej oczywista jest konsekwencja dla dostawców ICT. Firmy technologiczne świadczące krytyczne usługi podmiotom finansowym podlegają bezpośredniemu nadzorowi w przypadku wyznaczenia ich przez Europejskie Urzędy Nadzoru jako krytycznych zewnętrznych dostawców ICT. Ale nawet przed takim wyznaczeniem, DORA zmienia relację między podmiotami finansowymi a ich dostawcami technologicznymi na poziomie kontraktowym - zobowiązania bezpieczeństwa, prawa audytu, okna powiadamiania o incydentach, klauzule pomocy przy wyjściu. Jeśli dostarczasz infrastrukturę chmurową, zarządzane usługi bezpieczeństwa lub jakąkolwiek funkcję ICT, od której zależy regulowany podmiot finansowy, Twoi klienci są zobowiązani nałożyć na Ciebie te wymagania. DORA dociera do Twoich drzwi przez ich kontrakty.

Zrozumienie, po której stronie tej relacji się znajdujesz - albo czy jesteś po obu stronach jednocześnie - to punkt startowy.

Zarząd odpowiada osobiście

Jedną z najważniejszych zmian, które DORA wprowadza, jest miejsce, w którym umieszcza odpowiedzialność. Art. 5 nie wskazuje na CISO ani dział IT. Wskazuje bezpośrednio na organ zarządzający.

Zarząd musi definiować, zatwierdzać i nadzorować framework zarządzania ryzykiem ICT (Art. 5(2)). Członkowie zarządu są indywidualnie zobowiązani do utrzymywania wystarczającej wiedzy, aby oceniać ryzyko ICT i rozumieć jego biznesowy wpływ (Art. 5(4)). Organy nadzorcze mają uprawnienia do podjęcia działań wobec indywidualnych członków zarządu, nie tylko wobec instytucji jako całości.

W praktyce oznacza to, że dwie rzeczy muszą istnieć i być możliwe do wykazania: wyznaczony executive odpowiedzialny za framework zarządzania ryzykiem ICT oraz udokumentowany apetyt na ryzyko, który był faktycznie zatwierdzony na poziomie zarządu - nie zdelegowany w dół organizacji i podpisany przez kogoś trzy szczeble poniżej osób, które będą o to pytane.

Jeśli nie potrafisz odpowiedzieć na pytanie “który członek zarządu zatwierdził Wasz apetyt na ryzyko ICT i co on stanowi” w ciągu pięciu minut - to jest pierwsza luka do zamknięcia.

Gdy dochodzi do incydentu, dwa zegary startują jednocześnie

Struktura raportowania incydentów w Art. 17-19 wymaga trójstopniowego procesu dla poważnych incydentów ICT: zgłoszenie wstępne, aktualizacja pośrednia, raport końcowy. Regulatory Technical Standards ESA określają napięte terminy - zgłoszenie wstępne w ciągu czterech godzin od sklasyfikowania incydentu jako poważny (i nie później niż 24 godziny od pierwszego uświadomienia sobie zdarzenia), aktualizacja pośrednia w ciągu 72 godzin, raport końcowy w ciągu miesiąca.

Oto co zaskakuje organizacje: te zegary startują od momentu uświadomienia i klasyfikacji - nie od momentu rozwiązania, nie od zakończenia postmortem, nie od chwili, gdy masz pewność co do tego, co się wydarzyło.

Powstaje bezpośredni konflikt. Ten sam zespół zarządzający aktywnym outagem lub śledztwem po naruszeniu jest jednocześnie odpowiedzialny za przygotowanie i złożenie strukturyzowanych powiadomień do organów nadzorczych. Bez wstępnie przypisanych ról, wstępnie zatwierdzonych szablonów i przećwiczonego workflow, jedno z tych dwóch zadań ucierpi - i zazwyczaj to obowiązek regulacyjny jest depriorytetyzowany w gorącej fazie incydentu.

Raport końcowy zgodnie z Art. 19 musi też zawierać potwierdzony root cause poparty technicznym dowodem, pełną ocenę wpływu, lessons learned i skutki transgraniczne tam, gdzie mają zastosowanie. Nie można tego dobrze skonstruować pod presją bez udokumentowanego evidence trail budowanego podczas samego incydentu - war-room notes, timelines systemów, decision logi z nazwiskami i sygnaturami czasowymi.

Organizacje, które radzą sobie z tym konsekwentnie, zrobiły przed każdym realnym incydentem jedną prostą rzecz: przeprowadziły symulację, zmierzyły ją, znalazły miejsce załamania i zamknęły luki w odpowiedzialności. Takie przygotowanie kosztuje jedno popołudnie. Alternatywa kosztuje znacznie więcej.

Rejestr dostawców to teraz dokument regulacyjny

Art. 28-30 wymaga od podmiotów finansowych prowadzenia Rejestru Informacji obejmującego każde ustalenie kontraktowe z zewnętrznym dostawcą ICT - nie tylko tymi największymi, wszystkimi. Rejestr musi rozróżniać między dostawcami wspierającymi funkcje krytyczne lub ważne a tymi, którzy tego nie robią, i musi być przekazywany do właściwego organu nadzorczego.

Kontrakty z dostawcami funkcji krytycznych muszą zawierać konkretne zabezpieczenia: zobowiązania bezpieczeństwa, prawa audytu, zdefiniowane okna powiadamiania o incydentach, kontrole nad podzlecaniem i pomoc przy wyjściu. Art. 28(1)(a) jest jednoznaczny - outsourcing nie przenosi odpowiedzialności regulacyjnej - podmiot finansowy pozostaje w pełni odpowiedzialny niezależnie od tego, co zlecił na zewnątrz.

Praktyczna lekcja z organizacji, które przez to przeszły: wiele z nich odkryło istotne ryzyko koncentracji ICT, którego wcześniej nie mierzyło. Jeden dostawca chmury wspierający kilka funkcji krytycznych. Zarządzana usługa bezpieczeństwa współdzielona przez podmioty w ramach grupy. Jeden dostawca, którego awaria kaskadowałaby przez kilka regulowanych usług jednocześnie. Art. 29 ma na celu właśnie ujawnienie tej koncentracji - nie jako ćwiczenie biurokratyczne, ale dlatego, że organ nadzorczy, który to znajdzie podczas badania, zapyta dlaczego nie było to zarządzane.

Praktyczny punkt startowy: przeprowadź tiering i zbieranie dowodów najpierw na pięciu najbardziej krytycznych dostawcach. Szybciej ujawni luki w postanowieniach kontraktowych i brakujące dowody niż jakakolwiek wewnętrzna analiza luk.

W testowaniu chodzi o evidence trail, nie o sam test

DORA ustanawia warstwowy program testowania (Art. 24-26): coroczne ćwiczenia scenariuszowe dla wszystkich podmiotów w zakresie, regularne vulnerability assessmenty i testy penetracyjne systemów krytycznych oraz - dla wyznaczonego podzbioru podmiotów - Threat-Led Penetration Testing zgodny z frameworkiem TIBER-EU.

Większość organizacji prowadzi jakąś formę testowania. Czego często brakuje, to dyscyplina wokół tego, co następuje po teście: findings udokumentowane w jednym miejscu, właściciele remediacji przypisani z egzekwowalnymi terminami, dowód, że problemy zostały faktycznie zamknięte, a nie jedynie odnotowane. Organ nadzorczy przeglądający Twój program testowania nie jest zainteresowany przede wszystkim tym, czy przeprowadziłeś test. Jest zainteresowany tym, czy test wyprodukował obronialny zapis tego, co znalazłeś i co z tym zrobiłeś.

Wymóg TLPT dotyczy tylko podmiotów formalnie wyznaczonych przez organy nadzorcze na podstawie kryteriów systemowego znaczenia. Jeśli nie otrzymałeś powiadomienia, nie jesteś aktualnie zobowiązany do jego przeprowadzenia. Ale kryteria wyznaczenia mogą ewoluować i zrozumienie frameworku teraz jest tańsze niż scramblowanie się do przygotowania później.

Pytanie, które wszystko przecina

Zdejmij regulacyjną strukturę i pytanie staje się proste: jeśli jutro coś poważnego stanie się z Twoimi systemami ICT, czy możesz wykazać organowi nadzorczemu, że byłeś przygotowany, że zareagowałeś poprawnie i że Twój evidence trail się utrzyma?

Przygotowany oznacza zatwierdzony przez zarząd framework ryzyka ICT z udokumentowanym apetytem na ryzyko, który ktoś z nazwiskiem faktycznie podpisał. Przetestowaną procedurę raportowania incydentów z przećwiczonymi terminami, nie tylko napisaną. Rejestr dostawców odzwierciedlający dzisiejszą rzeczywistość operacyjną. Program testowania z rejestrem findings, którym ktoś aktywnie zarządza. Ustrukturyzowane raporty o ryzyku ICT na poziomie zarządu w zdefiniowanym cyklu, z udokumentowanymi decyzjami akceptacji ryzyka.

Nic z tego nie wymaga konkretnej platformy. Wszystko wymaga decyzji, które zostały podjęte, zatwierdzone i zrealizowane - nie tylko zredagowane.

Prawdziwa wartość DORA to nie obowiązek compliance - to mechanizm wymuszający. Daje zespołom bezpieczeństwa i ryzyka, oraz dostawcom ICT, którzy im służą, konkretny powód do budowania struktur governance, dyscyplin rehearsal i architektur dowodowych, które sprawiają, że odporność operacyjna jest realna. Organizacje, które najmniej odczują następny poważny incydent ICT, to te, które potraktowały DORA jako okazję do faktycznego zbudowania tych rzeczy - nie tylko ich opisania.

Eugene Titaev - marzec 2026