Od czego zacząć pierwsze wdrożenie DORA? Pierwsze wdrożenie DORA zaczyna się od zrozumienia, które funkcje są krytyczne i jacy dostawcy ICT je wspierają – a nie od pisania polityk. Bez tej mapy nie da się ani zbudować rejestru informacji, ani wyznaczyć celów odtworzeniowych, ani zaplanować testów. Ta lista destyluje wdrożenie w pięć działań startowych i pięć błędów, które najczęściej kosztują czas.
Definicja kanoniczna: DORA (Digital Operational Resilience Act) to rejestr informacji DORA nakładające na podmioty finansowe i ich dostawców ICT jednolite wymogi odporności operacyjnej cyfrowej w pięciu filarach, obowiązujące bezpośrednio od 17 sty 2025.
Ten artykuł jest dla organizacji stykającej się z DORA po raz pierwszy: porządkuje kolejność działań i wskazuje pułapki, w które najłatwiej wpaść, gdy reżim jest nowy.
DORA – 5 do i 5 nie – w skrócie:
- DORA obowiązuje bezpośrednio od 17 sty 2025 i obejmuje pięć filarów: zarządzanie ryzykiem ICT, raportowanie incydentów, testowanie odporności, zarządzanie ryzykiem stron trzecich i wymianę informacji.
- Punkt wyjścia wdrożenia to inwentaryzacja funkcji krytycznych i wspierających je zasobów ICT – z niej wynika reszta obowiązków.
- Rejestr informacji o dostawcach ICT to fundament filaru czwartego i jeden z pierwszych elementów, których oczekuje nadzór.
- Testowanie odporności, w tym TLPT dla znaczących podmiotów, to warstwa techniczna, której nie zastąpi żaden dokument.
- Najczęstszy błąd to traktowanie DORA jako projektu czysto prawnego i pominięcie realnej zdolności technicznej.
- Patronusec jako akredytowany QSA z zespołem pentesterów wspiera wdrożenie DORA, ze szczególnym naciskiem na warstwę techniczną.
Spis treści
Dlaczego wdrożenie zaczyna się od funkcji krytycznych, a nie od polityk?
Wdrożenie DORA zaczyna się od funkcji krytycznych, bo to one wyznaczają zakres wszystkich pozostałych obowiązków: które zasoby ICT chronić, jakie cele odtworzeniowe ustawić, co testować i które umowy z dostawcami są najistotniejsze. Polityka napisana bez tej mapy opisuje organizację, której się nie rozumie.
Funkcja krytyczna to działalność, której zakłócenie miałoby poważny wpływ na zdolność podmiotu do świadczenia usług lub na stabilność. DORA buduje niemal wszystkie wymogi wokół ochrony i odtwarzania właśnie tych funkcji. Zanim zdefiniujesz ramy ryzyka ICT (filar pierwszy), musisz wiedzieć, co jest krytyczne i jakie zasoby to wspierają.
Właściwa kolejność jest więc odwrotna do intuicyjnej. Zamiast „napiszmy polityki, których wymaga DORA”, właściwe podejście brzmi: „ustalmy funkcje krytyczne i ich zależności ICT, a potem zbudujmy wokół nich ramy, rejestr, testy i raportowanie”. Polityki są ważne, ale są konsekwencją mapy, nie jej substytutem.
Polityka DORA napisana przed zmapą funkcji krytycznych opisuje życzenia, nie organizację – a audyt sprawdza, czy ramy ryzyka odpowiadają realnym zależnościom, nie czy dokument brzmi poprawnie.
Top 5 rzeczy, które trzeba zrobić w pierwszej kolejności
Pięć zadań poniżej wyznacza właściwą kolejność startu wdrożenia DORA. Wspólny mianownik: najpierw zrozum, co chronisz i od kogo zależysz, a dopiero potem buduj dokumenty i zdolności.
- Zinwentaryzuj funkcje krytyczne i wspierające je zasoby ICT. To fundament. Ustal, które funkcje są krytyczne i jakie systemy, dane oraz usługi je wspierają. Ta mapa determinuje zakres ram ryzyka, testów i celów odtworzeniowych.
- Zbuduj rejestr informacji o dostawcach ICT. Spisz wszystkie umowy z dostawcami ICT, w tym zależności od podwykonawców. Rejestr to wymóg filaru czwartego i jeden z pierwszych elementów, których oczekuje nadzór – a jego budowa ujawnia zależności, o których organizacja często nie wie.
- Osadź ramy zarządzania ryzykiem ICT z zaangażowaniem zarządu. DORA wymaga, by organ zarządzający był realnie zaangażowany w ramy ryzyka ICT. Wyznacz właściciela, ustal proces identyfikacji, ochrony, wykrywania i odtwarzania wokół funkcji krytycznych.
- Ustanów proces klasyfikacji i raportowania incydentów. Zbuduj zdolność wykrywania, klasyfikacji i raportowania poważnych incydentów ICT w twardych terminach wymaganych przez DORA. To warstwa mieszana: procedura plus realna zdolność wykrywania.
- Zaplanuj program testowania odporności. Ustal regularne testy, a jeśli jesteś znaczącym podmiotem – przygotuj się na zaawansowane testowanie penetracyjne oparte na zagrożeniach (TLPT). To warstwa techniczna wymagająca kompetencji pentesterskich i narzędzi.
Top 5 rzeczy, których należy unikać
Poniższe pięć błędów najczęściej opóźnia lub podważa pierwsze wdrożenie DORA. Wspólny mianownik: mylenie dokumentu z realną zdolnością i traktowanie DORA jak jednorazowego projektu prawnego.
❌ Traktowanie DORA jako projektu wyłącznie prawnego. Kancelaria opracuje klauzule i rejestr, ale testowanie odporności i TLPT to praca techniczna. Dokument opisujący, że „testujemy”, nie jest testem – to najczęstsza luka odsłaniana przez nadzór.
❌ Zakładanie „nie jesteśmy bankiem, więc nas to nie dotyczy”. Dostawca ICT i jego podwykonawca odczuwają DORA przez umowy. Ignorowanie tego mechanizmu zostawia organizację nieprzygotowaną, gdy klient z sektora finansowego przenosi wymogi w dół łańcucha.
❌ Budowanie rejestru informacji „na ostatnią chwilę”. Rejestr składa się corocznie, a jego rzetelne zbudowanie ujawnia zależności od podwykonawców, o których nikt nie wiedział. Zostawiony na koniec, blokuje terminowe złożenie i odsłania braki w zarządzaniu dostawcami.
❌ Ustawianie celów odtworzeniowych „z sufitu”. RTO i RPO deklarowane bez oparcia w analizie wpływu na biznes i bez testu to liczby, które brzmią bezpiecznie, ale zawodzą w dniu incydentu. Cel odtworzeniowy niepoparty realną zdolnością jest fikcją.
❌ Traktowanie DORA jako jednorazowego projektu. DORA to obowiązek ciągły: coroczny rejestr, regularne testy, aktualizacja ram ryzyka. Organizacja, która „wdroży i zapomni”, traci zgodność między cyklami – a nadzór egzekwuje ją na bieżąco.
Patronusec Insight: Z naszego doświadczenia projektowego wynika, że organizacje wdrażające DORA po raz pierwszy najczęściej przeceniają warstwę dokumentacyjną, a niedoceniają technicznej. Polityki i klauzule powstają szybko, bo są policzalne i znane; testowanie odporności odkłada się „na później”, bo wymaga kompetencji, których w firmie nie ma. Tymczasem to właśnie filar trzeci – testowanie, w tym TLPT – jest miejscem, gdzie audyt najłatwiej odsłania różnicę między deklaracją a zdolnością. Rekomendujemy zaplanować warstwę techniczną od początku, równolegle z prawną, a nie jako etap końcowy.
Jak połączyć te działania w spójny plan wdrożenia?
Spójny plan wdrożenia DORA łączy pięć działań startowych w logiczną sekwencję: od mapy funkcji krytycznych, przez rejestr i ramy ryzyka, po raportowanie i testowanie, a następnie w cykl utrzymania. Kolejność wynika z zależności – każdy element opiera się na poprzednim.
Rekomendowana sekwencja:
- Mapa i zakres. Funkcje krytyczne, wspierające zasoby ICT, ustalenie roli w łańcuchu (podmiot finansowy, dostawca, podwykonawca).
- Rejestr i dostawcy. Rejestr informacji, przegląd i uzupełnienie umów, identyfikacja zależności od podwykonawców.
- Ramy i governance. Ramy zarządzania ryzykiem ICT z zaangażowaniem zarządu, oparte na mapie funkcji krytycznych.
- Incydenty i testy. Proces klasyfikacji i raportowania oraz program testowania odporności, w tym przygotowanie do TLPT dla znaczących podmiotów.
- Utrzymanie. Coroczny rejestr, regularne testy, aktualizacja ram – DORA jako proces ciągły, nie projekt.
Kluczowe jest równoległe prowadzenie warstwy prawnej i technicznej. Rejestr, umowy i polityki (warstwa prawna) można budować równocześnie ze zdolnością wykrywania i testowania (warstwa techniczna) – pod warunkiem, że od początku zaplanowano dla każdej właściwe kompetencje. Plan, który najpierw domyka dokumenty, a warstwę techniczną zostawia na koniec, ryzykuje odsłonięciem luki tuż przed audytem.
Patronusec wspiera organizacje w budowie takiego planu w ramach usługi DORA – ze szczególnym naciskiem na testowanie odporności i TLPT, gdzie jako QSA z zespołem pentesterów łączymy kompetencje audytora i testera.
FAQ – Jak wdrożyć DORA
Od czego konkretnie zacząć wdrożenie DORA?
Od inwentaryzacji funkcji krytycznych i wspierających je zasobów ICT. To fundament, z którego wynika zakres ram ryzyka, celów odtworzeniowych, testów i priorytetów w zarządzaniu dostawcami. Zaczynanie od pisania polityk bez tej mapy prowadzi do dokumentów opisujących organizację, której się nie rozumie – i luk odsłanianych przez audyt.
Czym jest rejestr informacji i dlaczego jest priorytetem?
Rejestr informacji to zestawienie wszystkich umów z dostawcami ICT, w tym zależności od podwykonawców, składane corocznie organowi nadzoru. Jest priorytetem, bo to jeden z pierwszych elementów, których oczekuje nadzór, a jego rzetelne zbudowanie ujawnia zależności technologiczne, o których organizacja często nie wie.
Czy każdy podmiot musi przeprowadzać TLPT?
Nie. Zaawansowane testowanie penetracyjne oparte na zagrożeniach (TLPT) DORA przewiduje dla znaczących podmiotów, wskazanych na podstawie kryteriów przez organy nadzoru. Pozostałe podmioty prowadzą regularne testy odporności o mniejszej głębokości. Niezależnie od TLPT, testowanie odporności jako takie jest wymogiem filaru trzeciego dla wszystkich w zakresie.
Dlaczego nie wystarczy potraktować DORA jako projektu prawnego?
Bo DORA łączy warstwę prawną (polityki, klauzule, rejestr) z techniczną (testowanie, monitoring, odtwarzanie). Kancelaria opracuje warstwę prawną, ale testowanie odporności i realna zdolność odtworzenia to praca techniczna, której dokument nie zastąpi. Traktowanie DORA jako projektu wyłącznie prawnego zostawia lukę odsłanianą przez nadzór.
Jak ustawić realistyczne cele odtworzeniowe (RTO/RPO)?
Cele odtworzeniowe wyprowadza się z analizy wpływu na biznes (BIA), a następnie weryfikuje testem. RTO i RPO deklarowane bez tego oparcia to liczby, które brzmią bezpiecznie, ale zawodzą w dniu incydentu. Realistyczny cel to taki, który organizacja faktycznie osiąga w ćwiczeniu odtworzeniowym, nie tylko deklaruje w dokumencie.
Jak Patronusec wspiera pierwsze wdrożenie DORA?
Prowadzimy przez pełną sekwencję: od mapy funkcji krytycznych i rejestru dostawców, przez ramy ryzyka i proces incydentów, po testowanie odporności i TLPT. Jako QSA z zespołem pentesterów szczególnie wzmacniamy warstwę techniczną, którą organizacje najczęściej niedoceniają. Po bezpłatnej rozmowie scope-assessment przedstawiamy plan wdrożenia i wycenę.
Warto przeczytać
Ścieżka lektury dla tematu wdrożenia DORA:
- DORA dla początkujących – co zmienia, kogo dotyczy i jak zacząć – fundament: pełne wprowadzenie do reżimu.
- Plan ciągłości działania w 5 krokach – zdolność odtworzenia wymagana w filarze pierwszym.
- Co powinien zawierać raport z testów ciągłości działania (BCM) – jak dokumentować testy odporności.
- NIS2 – 5 rzeczy do zrobienia i 5 do uniknięcia – pokrewny reżim dla podmiotów spoza sektora finansowego.
DORA – bezpłatna konsultacja
Patronusec jako akredytowany QSA z zespołem pentesterów wspiera wdrożenie DORA, łącząc warstwę prawną z techniczną. Umów bezpłatną konsultację, aby uporządkować kolejność działań i uniknąć typowych błędów pierwszego wdrożenia.
