Czym jest DORA i dlaczego zmienia zasady gry
Digital Operational Resilience Act (DORA) to rozporządzenie UE (2022/2554) obowiązujące od 17 stycznia 2025 roku. DORA wprowadza jednolite wymagania dotyczące cyfrowej odporności operacyjnej dla całego sektora finansowego w Europie — od największych banków po małe fintechy.
Przed DORA wymagania cyberbezpieczeństwa w finansach były rozproszone między krajowe regulacje (w Polsce — Rekomendacja D KNF), sektorowe standardy (PCI DSS) i ogólne przepisy (NIS2, RODO). DORA harmonizuje te wymagania i dodaje nowe: testowanie odporności, zarządzanie ryzykiem stron trzecich ICT i ustandaryzowane raportowanie incydentów.
5 filarów DORA
Filar 1: Zarządzanie ryzykiem ICT
Instytucje finansowe muszą wdrożyć kompleksowy framework zarządzania ryzykiem ICT obejmujący: identyfikację zasobów i zależności, ocenę ryzyka, środki ochrony, wykrywanie zagrożeń, reagowanie na incydenty i odtwarzanie po awariach. Zarząd ponosi bezpośrednią odpowiedzialność za nadzór nad ryzykiem ICT.
Filar 2: Raportowanie incydentów ICT
Obowiązek zgłaszania poważnych incydentów ICT w ustandaryzowanym formacie: powiadomienie wstępne w 4 godziny, raport pośredni w 72 godziny, raport końcowy w 1 miesiąc. Klasyfikacja incydentów według wpływu na usługi finansowe, liczbę klientów i straty.
Filar 3: Testowanie odporności operacyjnej
Regularne testy obejmujące: skanowanie podatności, testy penetracyjne, testy scenariuszowe, testy ciągłości działania. Dla systemowo ważnych instytucji — obowiązkowe TLPT (Threat-Led Penetration Testing) co 3 lata, prowadzone przez certyfikowanych dostawców.
Filar 4: Zarządzanie ryzykiem stron trzecich ICT
Rejestr wszystkich dostawców ICT, ocena ryzyka koncentracji, klauzule umowne dotyczące bezpieczeństwa, prawo do audytu i testów, plany wyjścia (exit strategy) na wypadek utraty dostawcy. Europejskie organy nadzoru mogą bezpośrednio nadzorować krytycznych dostawców ICT.
Filar 5: Wymiana informacji o zagrożeniach
Instytucje finansowe mogą (nie muszą) uczestniczyć w programach wymiany informacji o cyberzagrożeniach. DORA określa zasady bezpiecznej wymiany wskaźników kompromitacji (IoC) i taktyk atakujących (TTP).
Harmonogram wdrożenia DORA
| Etap | Działanie | Czas |
|---|---|---|
| 1 | Gap analysis — ocena obecnego stanu vs wymagania DORA | 1-2 miesiące |
| 2 | Framework zarządzania ryzykiem ICT — polityki, procedury, role | 3-4 miesiące |
| 3 | Rejestr dostawców ICT — inwentaryzacja, ocena ryzyka, umowy | 2-3 miesiące |
| 4 | System raportowania incydentów — procesy, narzędzia, szkolenia | 2-3 miesiące |
| 5 | Program testowania — plan testów, TLPT, testy ciągłości | 2-3 miesiące |
| 6 | Ciągłe doskonalenie — audyty, aktualizacja, szkolenia | Ongoing |
Krok po kroku: Jak wdrożyć DORA
Krok 1: Gap analysis
Audyt bezpieczeństwa obejmujący ocenę obecnego stanu cyberbezpieczeństwa względem wymagań DORA. Identyfikacja luk w zarządzaniu ryzykiem ICT, raportowaniu incydentów, testowaniu odporności i zarządzaniu dostawcami.
Krok 2: Wdrożenie frameworka zarządzania ryzykiem ICT
Opracowanie polityk i procedur: rejestr zasobów ICT, metodyka oceny ryzyka, środki ochrony, plan reagowania na incydenty, plan ciągłości działania. Przypisanie odpowiedzialności na poziomie zarządu.
Krok 3: Rewizja umów z dostawcami ICT
Przegląd wszystkich umów z dostawcami technologicznymi pod kątem wymagań DORA: klauzule bezpieczeństwa, prawo do audytu, SLA dla odporności, plan wyjścia. Utworzenie centralnego rejestru dostawców ICT.
Krok 4: System raportowania incydentów
Wdrożenie procesów klasyfikacji i raportowania incydentów ICT zgodnie z harmonogramem DORA. Integracja z SOC do automatycznego wykrywania i eskalacji incydentów.
Krok 5: Program testowania odporności
Opracowanie rocznego planu testów obejmującego: skanowanie podatności, testy penetracyjne, testy scenariuszowe (DDoS, ransomware, BEC), testy ciągłości działania, TLPT dla instytucji systemowo ważnych.
Krok 6: Szkolenia i awareness
Programy szkoleniowe dla zarządu (odpowiedzialność DORA), kadry IT (procedury techniczne), wszystkich pracowników (rozpoznawanie zagrożeń) i zespołów compliance (raportowanie).
DORA a inne regulacje
DORA vs NIS2: DORA jest lex specialis — dla sektora finansowego ma pierwszeństwo przed NIS2, ale wymaga spełnienia obu w zakresie, w którym się nie pokrywają.
DORA vs PCI DSS: PCI DSS dotyczy bezpieczeństwa danych kart płatniczych, DORA — ogólnej odporności operacyjnej. Instytucje przetwarzające karty muszą spełniać oba standardy.
DORA vs Rekomendacja D KNF: Rekomendacja D obejmuje zarządzanie ryzykiem IT w bankach. DORA rozszerza zakres o testowanie odporności, zarządzanie dostawcami ICT i standaryzowane raportowanie.
Jak nFlo wspiera wdrożenie DORA
- Audyt bezpieczeństwa — gap analysis DORA, ocena dojrzałości cyberbezpieczeństwa
- Testy penetracyjne — TLPT, testy scenariuszowe, testy API bankowych
- SOC as a Service — monitoring 24/7 spełniający wymagania DORA dotyczące wykrywania i raportowania incydentów
- Wsparcie compliance NIS2 — wdrożenie wymagań DORA i NIS2
Cyberbezpieczeństwo w Twojej branży
Dowiedz się więcej o cyberbezpieczeństwie w Twojej branży:
Tematy powiązane
Zobacz również:
