Mapa drogowa DORA 2026 dla ryzyka ICT, dostawców i TLPT

Panika wokół wyszukiwań DORA 2026 nie dotyczy tak naprawdę regulacji, lecz dowodów

Jest 08:15 w poniedziałek, a CISO średniej wielkości instytucji płatniczej ma otwarte trzy karty w przeglądarce: „lista kontrolna DORA RTS/ITS”, „szablon rejestru zewnętrznych dostawców ICT DORA” oraz „wymagania TLPT dla podmiotów finansowych”.

Menedżer ds. zgodności już zapytał, czy pakiet dla zarządu powinien zawierać najnowszy proces klasyfikacji incydentów. Dział zakupów chce wdrożyć nową platformę analityczną w chmurze. COO potrzebuje potwierdzenia, że kluczowy dostawca SaaS obsługujący bankowość nie ma ukrytej ekspozycji na podwykonawców spoza UE. Audyt wewnętrzny prosi o kalendarz testów. Dział prawny pyta, czy terminy zgłaszania naruszeń zgodnie z RODO zostały dostosowane do zgłaszania incydentów w DORA.

Nikt nie zadaje pytania teoretycznego. Pytanie brzmi: „Czy możemy to udowodnić do piątku?”.

To jest rzeczywisty problem DORA 2026. Większość podmiotów finansowych rozumie główne obowiązki: zarządzanie ryzykiem ICT, zgłaszanie incydentów związanych z ICT, testowanie cyfrowej odporności operacyjnej, zarządzanie ryzykiem związanym z zewnętrznymi dostawcami usług ICT oraz silniejszy nadzór nad krytycznymi dostawcami ICT. Najtrudniejsze jest przekształcenie regulacyjnych standardów technicznych, wykonawczych standardów technicznych i obowiązków wynikających z poszczególnych artykułów w kontrolowaną, powtarzalną i audytowalną praktykę.

Rozporządzenie DORA wymaga od podmiotów finansowych utrzymywania solidnych zdolności zarządzania ryzykiem ICT, polityk zarządzania incydentami związanymi z ICT i ich zgłaszania, testowania systemów ICT, mechanizmów kontrolnych i procesów oraz uporządkowanego nadzoru nad zewnętrznymi dostawcami usług ICT. Wymaga również proporcjonalności. Mniejsza firma inwestycyjna i duża grupa bankowa nie potrzebują identycznych modeli dowodowych, ale obie muszą wykazać, że ich podejście jest adekwatne do skali działalności, profilu ryzyka, złożoności oraz funkcji krytycznych.

Projekty DORA najczęściej zawodzą z jednego z trzech powodów. Po pierwsze, organizacja traktuje DORA jako ćwiczenie z mapowania prawnego, a nie jako model operacyjny. Po drugie, ryzyko dostawców jest dokumentowane jako lista dostawców, a nie jako zależność, możliwość zastąpienia i ryzyko koncentracji. Po trzecie, testowanie jest traktowane jako coroczny test penetracyjny, a nie jako program odporności obejmujący skanowanie podatności, testy scenariuszowe, ćwiczenia incydentowe oraz, tam gdzie ma zastosowanie, testy penetracyjne ukierunkowane na zagrożenia, powszechnie wyszukiwane jako TLPT.

Lepsze podejście polega na zbudowaniu jednego systemu dowodowego, który łączy polityki, rejestry, właścicieli, ryzyka, incydenty, dostawców, testowanie, odzyskiwanie i przegląd zarządzania. Właśnie w tym obszarze Zenith Blueprint, gotowe do użycia polityki oraz Zenith Controls Clarysec pomagają podmiotom finansowym przekształcić DORA z terminu wdrożenia w rytm operacyjny.

Zacznij od modelu operacyjnego DORA, a nie od arkusza RTS/ITS

Wiele zespołów zaczyna od arkusza kalkulacyjnego zawierającego artykuły DORA i wymagania RTS/ITS. To przydatne, ale niewystarczające. Arkusz kalkulacyjny może wskazać, co musi istnieć. Nie przypisuje właścicieli, nie określa częstotliwości przeglądów, nie przechowuje dowodów ani nie wykazuje, że mechanizm kontrolny faktycznie działa.

W Zenith Blueprint: 30-etapowej mapie drogowej audytora Clarysec odnosi się do tego w fazie zarządzania ryzykiem, w kroku 14, Polityki postępowania z ryzykiem i regulacyjne odwołania krzyżowe:

„DORA: W przypadku firm z sektora finansowego DORA wymaga ram zarządzania ryzykiem ICT bardzo zbliżonych do tego, co zrobiliśmy: identyfikować ryzyka, wdrażać środki kontrolne (i polityki) oraz je testować. DORA kładzie również nacisk na reagowanie na incydenty i raportowanie oraz nadzór nad zewnętrznymi dostawcami usług ICT.”

Praktyczny przekaz jest prosty: nie buduj „zgodności z DORA” jako równoległej biurokracji. Zbuduj opartą na ryzyku warstwę ładu ICT, która mapuje wymagania DORA na polityki, rejestry, właścicieli kontroli, zapisy testów, dowody dotyczące dostawców i przegląd zarządzania.

Praktyczny model operacyjny DORA powinien mieć pięć filarów dowodowych:

Dla regulowanych podmiotów finansowych ta struktura przekształca wdrożenie RTS/ITS w system dowodowy gotowy do audytu. W przypadku podmiotów objętych uproszczonym zarządzaniem ryzykiem ICT ten sam model można ograniczyć do mniejszej liczby dokumentów i prostszych rejestrów. Kluczowe dyscypliny pozostają takie same: identyfikuj, chroń, wykrywaj, reaguj, odzyskuj, testuj i nadzoruj dostawców.

Zarządzanie ryzykiem ICT: rejestr jest centrum dowodzenia

Oczekiwania DORA dotyczące zarządzania ryzykiem ICT wymagają od podmiotów finansowych identyfikowania, klasyfikowania i zarządzania ryzykami ICT w systemach, danych, procesach, funkcjach krytycznych lub ważnych oraz zależnościach od stron trzecich.

Typową słabością nie jest brak rejestru ryzyk. Problem polega na tym, że rejestr jest odłączony od dostawców, aktywów, incydentów i testów. DORA nie premiuje estetycznego arkusza, jeżeli nie potrafi on wyjaśnić, dlaczego dostawca wysokiego ryzyka nie ma planu wyjścia albo dlaczego krytyczna platforma obsługi płatności klientów nie została przetestowana.

Polityka Clarysec dla MŚP Polityka zarządzania ryzykiem zapewnia mniejszym podmiotom finansowym zwięzłą bazę dowodową:

„Każdy wpis dotyczący ryzyka musi zawierać: opis, prawdopodobieństwo, wpływ, punktację, właściciela oraz plan postępowania z ryzykiem.”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.2.

W przypadku większych podmiotów finansowych wersja Enterprise Clarysec Polityka zarządzania ryzykiem wymaga bardziej formalnego procesu:

„Należy utrzymywać formalny proces zarządzania ryzykiem zgodnie z ISO/IEC 27005 i ISO 31000, obejmujący identyfikację ryzyka, analizę, ocenę, postępowanie z ryzykiem, monitorowanie i komunikację.”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.

To rozróżnienie ma znaczenie. DORA jest proporcjonalna, ale proporcjonalność nie oznacza nieformalności. Mała firma płatnicza może korzystać z uproszczonego rejestru, a grupa bankowa ze zintegrowanych narzędzi GRC. W obu przypadkach audytor i tak zapyta: jakie są wasze ryzyka ICT? Kto jest ich właścicielem? Jaki jest plan postępowania z ryzykiem? Jakie dowody pokazują postęp? Jak dostawcy i funkcje krytyczne wpływają na punktację?

Silny rejestr ryzyk ICT dla DORA powinien zawierać następujące pola:

Praktyczne ćwiczenie polega na wybraniu jednej krytycznej usługi ICT, na przykład hostowanej w chmurze platformy monitorowania transakcji, i utworzeniu wpisu ryzyka w 20 minut. Opisz scenariusz awarii lub naruszenia bezpieczeństwa, oceń prawdopodobieństwo i wpływ, przypisz właściciela, wskaż powiązanych dostawców, zdefiniuj plan postępowania z ryzykiem i powiąż wpis z dowodami, takimi jak due diligence dostawcy, SLA, klauzule incydentowe, BIA, wyniki testów DR, pulpity monitorowania i przeglądy dostępu.

Ten pojedynczy wpis staje się nicią łączącą zarządzanie ryzykiem ICT w DORA, nadzór nad stronami trzecimi, wykrywanie incydentów, ciągłość i testowanie. Tak rejestr ryzyk staje się centrum dowodzenia, a nie repozytorium dokumentów.

Gotowość RTS/ITS: mapuj obowiązki na polityki, a nie na deklaracje

Praktyczne hasło wyszukiwania „lista kontrolna DORA RTS/ITS” zwykle oznacza: „Jakich dokumentów będą oczekiwać organy nadzoru?”. Podmioty finansowe powinny unikać deklarowania zgodności za pomocą ogólnych stwierdzeń. Potrzebują mapowania, które wiąże każdy obowiązek z polityką, mechanizmem kontrolnym, właścicielem i pozycją dowodową.

Polityka Clarysec dla MŚP Polityka zgodności prawnej i regulacyjnej ustanawia prosty punkt odniesienia dla ładu:

„Dyrektor generalny musi utrzymywać prosty, uporządkowany Rejestr zgodności zawierający:”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.1.1.

Dla DORA 2026 Rejestr zgodności powinien obejmować:

• Obowiązek DORA lub obszar wymagań RTS/ITS.
• Zastosowanie, w tym uzasadnienie proporcjonalności.
• Odniesienie do polityki lub procedury.
• Właściciela kontroli.
• Lokalizację dowodów.
• Częstotliwość przeglądu.
• Otwarte luki i termin działań naprawczych.
• Status raportowania do zarządu lub kierownictwa.

Jest to zgodne z podejściem Zenith Blueprint z kroku 14: mapować wymagania regulacyjne na mechanizmy kontrolne i polityki SZBI, aby nic nie umknęło. Zamiast pytać „Czy jesteśmy zgodni z DORA?”, kierownictwo może zapytać: „Które dowody DORA są przeterminowane, którzy krytyczni dostawcy nie mają planów wyjścia i które działania testowe nie wygenerowały jeszcze dowodów działań naprawczych?”.

Ryzyko stron trzecich ICT: koncentracja, możliwość zastąpienia i podwykonawcy

DORA zmieniła rozmowę o dostawcach w usługach finansowych. Nie wystarczy już zapytać, czy dostawca ma certyfikat bezpieczeństwa, ubezpieczenie albo umowę powierzenia przetwarzania danych. Podmioty finansowe muszą ocenić, czy dostawca tworzy ryzyko koncentracji, czy można go realnie zastąpić, czy wiele usług krytycznych zależy od jednego dostawcy lub dostawców powiązanych oraz czy podwykonawstwo wprowadza dodatkową ekspozycję prawną lub odpornościową.

To zagadnienie nie daje spać wielu CISO. Firma może polegać na jednym dużym dostawcy usług chmurowych w zakresie przetwarzania transakcji, analityki danych, portali klientów i wewnętrznej współpracy. Jeżeli ten dostawca doświadczy długotrwałej awarii, sporu regulacyjnego albo awarii podwykonawcy, pytanie nie brzmi wyłącznie: „Czy mamy umowę?”. Pytanie brzmi: „Czy możemy kontynuować usługi krytyczne, komunikować się z klientami i wykazać, że rozumieliśmy tę zależność, zanim doszło do awarii?”.

Polityka Clarysec dla MŚP Polityka bezpieczeństwa dostawców i stron trzecich ustanawia podstawę:

„Rejestr dostawców musi być utrzymywany i aktualizowany przez osobę kontaktową ds. administracyjnych lub zakupów. Musi obejmować:”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.4.

W przypadku programów korporacyjnych Clarysec Polityka zarządzania ryzykiem zależności od dostawców wchodzi głębiej w zależności i możliwość zastąpienia specyficzne dla DORA:

„Rejestr zależności od dostawców: VMO musi utrzymywać aktualny rejestr wszystkich krytycznych dostawców, obejmujący takie szczegóły jak świadczone usługi/produkty; czy dostawca jest jedynym źródłem; dostępni alternatywni dostawcy lub możliwość zastąpienia; aktualne warunki umowy; oraz ocenę wpływu w przypadku awarii lub naruszenia bezpieczeństwa dostawcy. Rejestr musi wyraźnie identyfikować dostawców o wysokim poziomie zależności (np. takich, dla których nie istnieje szybka alternatywa).”
Z sekcji „Wymagania wdrożeniowe”, klauzula polityki 6.1.

To właśnie dowód dotyczący dostawców, którego często brakuje w projektach DORA. Rejestr dostawców mówi, kim jest dostawca. Rejestr zależności mówi, co się stanie, gdy dostawca zawiedzie.

Zenith Blueprint, faza Controls in Action, krok 23, zabezpieczenia organizacyjne, zapewnia praktyczny proces nadzoru nad dostawcami. Zaleca przygotowanie pełnej listy dostawców, klasyfikację dostawców na podstawie dostępu do systemów, danych lub kontroli operacyjnej, weryfikację, czy oczekiwania bezpieczeństwa są osadzone w umowach, zarządzanie ryzykiem podwykonawców i ryzykiem dalszego łańcucha, zdefiniowanie procedur zmian i monitorowania oraz utworzenie procesu oceny usług chmurowych.

W Zenith Controls: The Cross-Compliance Guide środek kontrolny ISO/IEC 27002:2022 5.21, Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, jest mapowany jako kontrola zapobiegawcza wspierająca poufność, integralność i dostępność. Jest powiązany z bezpieczeństwem relacji z dostawcami oraz funkcją cyberbezpieczeństwa Identify. Łączy się z bezpieczną inżynierią, bezpiecznym tworzeniem kodu, kontrolą dostępu, testami bezpieczeństwa, zabezpieczaniem materiału dowodowego, bezpiecznym cyklem życia rozwoju oprogramowania i rozwojem realizowanym w modelu outsourcingowym.

To dokładnie odpowiada realiom nadzoru nad stronami trzecimi w DORA. Ryzyko dostawców nie dotyczy wyłącznie zakupów. Obejmuje architekturę, rozwój, reagowanie na incydenty, kontrolę dostępu, ciągłość działania i kwestie prawne.

Z perspektywy zgodności przekrojowej Zenith Controls mapuje bezpieczeństwo łańcucha dostaw ICT do GDPR Articles 28 and 32, ponieważ podmioty przetwarzające i podwykonawcy przetwarzania muszą być wybierani i nadzorowani z zastosowaniem odpowiednich środków technicznych i organizacyjnych. Wspiera oczekiwania NIS2 dotyczące bezpieczeństwa łańcucha dostaw, w tym Article 21 dotyczący środków zarządzania ryzykiem cyberbezpieczeństwa oraz Article 22 dotyczący skoordynowanych ocen ryzyka łańcucha dostaw. Silnie mapuje się na DORA Articles 28, 29 and 30, w których ryzyko związane z zewnętrznymi dostawcami ICT, ryzyko koncentracji, podoutsourcing i postanowienia umowne mają znaczenie centralne.

Normy wspierające wzmacniają materiał dowodowy. ISO/IEC 27036-3:2021 wspiera bezpieczeństwo pozyskiwania ICT i wyboru dostawców. ISO/IEC 20243:2018 wspiera integralność zaufanych produktów technologicznych i bezpieczeństwo łańcucha dostaw. ISO/IEC 27001:2022 łączy to z postępowaniem z ryzykiem i kontrolami dostawców w Annex A.

Zgłaszanie incydentów: zbuduj łańcuch eskalacji przed incydentem

Zgłaszanie incydentów w DORA nie polega wyłącznie na przekazaniu powiadomienia. Chodzi o wykrywanie, klasyfikowanie, eskalowanie, komunikowanie i wyciąganie wniosków z incydentów związanych z ICT. Podmioty finansowe muszą utrzymywać procesy zarządzania incydentami ICT i ich zgłaszania, z określonymi rolami, kryteriami klasyfikacji, ścieżkami powiadamiania i analizą poincydentalną.

Polityka Clarysec dla MŚP Polityka reagowania na incydenty łączy terminy reagowania na incydenty z wymaganiami prawnymi:

„Terminy reagowania, w tym obowiązki dotyczące odzyskiwania danych i powiadamiania, muszą być udokumentowane i dostosowane do wymagań prawnych, takich jak wymóg RODO dotyczący zgłoszenia naruszenia ochrony danych osobowych w terminie 72 godzin.”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.3.2.

W przypadku środowisk korporacyjnych Clarysec Polityka reagowania na incydenty dodaje perspektywę eskalacji danych regulowanych:

„Jeżeli incydent skutkuje potwierdzonym lub prawdopodobnym ujawnieniem danych osobowych albo innych danych regulowanych, dział prawny oraz IOD muszą ocenić zastosowanie:”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

Cytat kończy się w punkcie wyzwalającym, czyli dokładnie tam, gdzie zawodzi wiele procesów incydentowych. Jeżeli wyzwalacz jest niejasny, zespoły dyskutują o obowiązkach powiadomienia, podczas gdy zegar już tyka.

Zenith Blueprint, faza Controls in Action, krok 16, People Controls II, podkreśla zgłaszanie incydentów przez personel. Pracownicy, wykonawcy i interesariusze muszą wiedzieć, jak rozpoznawać i zgłaszać potencjalne incydenty bezpieczeństwa przy użyciu prostych kanałów, takich jak dedykowana skrzynka pocztowa, portal lub infolinia. Blueprint łączy to z GDPR Article 33, NIS2 Article 23 oraz DORA Article 17, ponieważ raportowanie regulacyjne zaczyna się od wewnętrznej świadomości i eskalacji.

W Zenith Controls środek kontrolny ISO/IEC 27002:2022 5.24, Planowanie i przygotowanie zarządzania incydentami bezpieczeństwa informacji, jest mapowany jako kontrola korygująca wspierająca poufność, integralność i dostępność, zgodna z Respond and Recover. Łączy się bezpośrednio z oceną zdarzeń, uczeniem się z incydentów, rejestrowaniem i monitorowaniem, bezpieczeństwem podczas zakłóceń, ciągłością bezpieczeństwa informacji oraz kontaktem z organami. Przewodnik mapuje to na DORA Articles 17 to 23 w zakresie zarządzania incydentami związanymi z ICT, ich klasyfikacji, raportowania i dobrowolnego powiadamiania o cyberzagrożeniach, GDPR Articles 33 and 34 w zakresie zgłaszania naruszeń oraz NIS2 Article 23 dotyczący powiadamiania o incydentach.

Proces incydentowy gotowy na DORA powinien obejmować:

• Jasne kanały przyjmowania zgłoszeń incydentów.
• Kryteria triage zdarzeń i klasyfikacji.
• Proces eskalacji poważnych incydentów związanych z ICT.
• Punkty decyzyjne dla działu prawnego, IOD i powiadomień regulacyjnych.
• Wyzwalacze powiadomień o incydentach u dostawców.
• Wymagania dotyczące zabezpieczenia materiału dowodowego.
• Zasady komunikacji z kierownictwem wykonawczym i zarządem.
• Przegląd po incydencie i wnioski.
• Powiązanie z aktualizacjami rejestru ryzyk i działaniami naprawczymi dotyczącymi kontroli.

Normy wspierające nadają strukturę. ISO/IEC 27035-1:2023 zawiera zasady planowania i przygotowania w zarządzaniu incydentami. ISO/IEC 27035-2:2023 szczegółowo opisuje kroki obsługi incydentów. ISO/IEC 22320:2018 wspiera dowodzenie, kontrolę i uporządkowaną komunikację kryzysową. Ma to znaczenie, gdy awaria ICT przeradza się w kryzys wpływający na klientów, a podmiot musi wykazać, że decyzje były terminowe, skoordynowane i oparte na dowodach.

Testowanie cyfrowej odporności operacyjnej i TLPT: nie pozwól, aby test stał się incydentem

Testowanie jest jednym z najczęściej wyszukiwanych tematów DORA 2026, ponieważ jest jednocześnie techniczne i silnie związane z ładem. Podmioty finansowe muszą testować systemy ICT, mechanizmy kontrolne i procesy. W przypadku wyznaczonych podmiotów zaawansowane testy, takie jak TLPT, stają się kluczowym wymaganiem zgodnie z DORA Article 26.

Pytanie audytowe nie brzmi wyłącznie: „Czy przeprowadziliście test?”. Brzmi: „Czy test był oparty na ryzyku, autoryzowany, bezpieczny, niezależny tam, gdzie jest to wymagane, objęty działaniami naprawczymi i powiązany z celami odporności?”.

Wersja Enterprise Clarysec Polityka testów bezpieczeństwa i działań red team jasno definiuje minimalny program testów:

„Rodzaje testów: program testów bezpieczeństwa musi obejmować co najmniej: (a) skanowanie podatności, polegające na zautomatyzowanych cotygodniowych lub comiesięcznych skanach sieci i aplikacji w celu identyfikacji znanych podatności; (b) testy penetracyjne, polegające na ręcznym, pogłębionym testowaniu określonych systemów lub aplikacji przez wykwalifikowanych testerów w celu identyfikacji złożonych słabości; oraz (c) ćwiczenia red team, polegające na scenariuszowych symulacjach rzeczywistych ataków, w tym inżynierii społecznej i innych taktyk, w celu przetestowania zdolności organizacji do wykrywania i reagowania jako całości.”
Z sekcji „Wymagania wdrożeniowe”, klauzula polityki 6.1.

To pomost między rutynowym testowaniem a dojrzałością TLPT. Skanowanie podatności wykrywa znane słabości. Testy penetracyjne potwierdzają możliwość wykorzystania. Red teaming testuje wykrywanie i reagowanie jako system. TLPT, tam gdzie ma zastosowanie, powinien być częścią zarządzanego programu testów z kontrolą zakresu, zasadami bezpieczeństwa, zarządzaniem ryzykiem produkcyjnym, utrwalaniem dowodów i śledzeniem działań naprawczych.

Zenith Blueprint, faza Controls in Action, krok 21, dotyczy ochrony systemów informatycznych podczas audytu i testów. Ostrzega, że audyty, testy penetracyjne, analizy kryminalistyczne i oceny operacyjne mogą wprowadzać ryzyko, ponieważ mogą obejmować uprawnienia podwyższone, narzędzia inwazyjne lub tymczasowe zmiany zachowania systemu. Blueprint mapuje tę kwestię na GDPR Article 32, oczekiwania DORA dotyczące testowania cyfrowej odporności operacyjnej, obawy NIS2 związane z ciągłością oraz praktyki COBIT 2019 dotyczące bezpiecznego prowadzenia audytów i ocen.

W Zenith Controls środek kontrolny ISO/IEC 27002:2022 5.35, Niezależny przegląd bezpieczeństwa informacji, jest mapowany jako kontrola zapobiegawcza i korygująca, wspierająca poufność, integralność i dostępność. Łączy się ze zgodnością z politykami, odpowiedzialnościami kierownictwa, uczeniem się z incydentów, ochroną zapisów, usuwaniem informacji, rejestrowaniem i monitorowaniem. W przypadku DORA właściwe obowiązki testowe to przede wszystkim Articles 24 to 27, w tym Article 26 dla TLPT. Wspiera to również GDPR Article 32(1)(d), który wymaga regularnego testowania i oceny środków technicznych i organizacyjnych, oraz NIS2 Article 21, który wymaga środków zarządzania ryzykiem cyberbezpieczeństwa.

Pakiet gotowości DORA TLPT powinien obejmować:

Kluczowa lekcja DORA jest taka, że dowody z testów nie mogą kończyć się na raporcie. Audytorzy zapytają, czy ustalenia zostały ocenione pod kątem ryzyka, przypisane, objęte działaniami naprawczymi i ponownie przetestowane. Mogą również sprawdzić, czy testy obejmowały funkcje krytyczne lub ważne, a nie tylko aktywa dostępne z Internetu.

Ciągłość działania i odtwarzanie po awarii: odporność musi być operacyjna

DORA jest regulacją dotyczącą cyfrowej odporności operacyjnej. Odzyskiwanie jest równie ważne jak zapobieganie. Udokumentowane ramy ryzyka ICT nie pomogą, jeżeli awaria platformy płatniczej ujawni, że docelowe czasy odtworzenia nigdy nie zostały przetestowane, drzewa kontaktowe dostawców są nieaktualne, a zespół kryzysowy nie potrafi uzgodnić, kto komunikuje się z klientami.

Polityka Clarysec dla MŚP Polityka ciągłości działania i odtwarzania po awarii ustanawia jasną bazę:

„Organizacja musi testować zarówno swoje zdolności BCP, jak i DR co najmniej raz w roku. Testy muszą obejmować:”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.1.

Wersja Enterprise Polityka ciągłości działania i odtwarzania po awarii zaczyna od wpływu biznesowego:

„Analiza wpływu na biznes (BIA) musi być przeprowadzana co najmniej raz w roku dla wszystkich krytycznych jednostek biznesowych oraz przeglądana po istotnych zmianach w systemach, procesach lub zależnościach. Wyniki BIA muszą określać:”
Z sekcji „Wymagania dotyczące ładu zarządczego”, klauzula polityki 5.2.

W przypadku DORA BIA powinna być powiązana z aktywami ICT, dostawcami, reagowaniem na incydenty i testowaniem. Jeżeli BIA identyfikuje „płatności klientów” jako funkcję krytyczną, rejestr zależności od dostawców powinien identyfikować procesorów płatności, usługi chmurowe i dostawców sieci, którzy ją wspierają. Rejestr ryzyk powinien zawierać scenariusze awarii. Plan testów powinien obejmować walidację odporności. Plan reagowania na incydenty powinien obejmować eskalację i komunikację. Test DR powinien generować dowody, a nie tylko notatkę ze spotkania.

Ta identyfikowalność przekształca zgodność z DORA w system odporności operacyjnej.

Zgodność przekrojowa: jeden zestaw dowodów, wiele pytań audytowych

Podmioty finansowe rzadko mierzą się wyłącznie z DORA. Często mają obowiązki wynikające z RODO, ekspozycję na NIS2, umowne zobowiązania bezpieczeństwa, cele ISO/IEC 27001:2022, wymagania audytu wewnętrznego, due diligence klientów, oczekiwania SOC i raportowanie ryzyka do zarządu. Rozwiązaniem nie jest tworzenie odrębnych silosów dowodowych. Rozwiązaniem jest zbudowanie przekrojowego modelu dowodowego zgodności.

Zenith Controls jest przekrojowym kompasem zgodności Clarysec. Nie tworzy nowych obowiązków. Mapuje oficjalne normy i frameworki, aby organizacje mogły zrozumieć, jak jeden obszar kontroli wspiera kilka rezultatów zgodności.

Ma to znaczenie dla budżetu i ładu. CISO może wyjaśnić zarządowi, że poprawa klasyfikacji incydentów wspiera raportowanie DORA, zgłaszanie naruszeń w RODO, obsługę incydentów NIS2 i wewnętrzną odporność. Lider zakupów może uzasadnić mapowanie zależności od dostawców, ponieważ wspiera ryzyko koncentracji DORA, due diligence podmiotów przetwarzających w RODO i bezpieczeństwo łańcucha dostaw NIS2. Kierownik testów może pokazać, że ćwiczenia red team i niezależne przeglądy wspierają testowanie DORA, ocenę kontroli w RODO i szersze zapewnienie.

Perspektywa audytu: jak asesorzy będą testować dowody DORA

Gotowość do DORA staje się realna, gdy ktoś prosi o dowody. Różni audytorzy i asesorzy podejdą do tego samego tematu z różnych perspektyw.

Audytor zorientowany na ISO/IEC 27001:2022 zacznie od logiki SZBI: zakres, ocena ryzyka, postępowanie z ryzykiem, stosowalność kontroli z Annex A, audyt wewnętrzny, przegląd zarządzania i dowody, że kontrole zostały wdrożone. W przypadku bezpieczeństwa łańcucha dostaw ICT będzie analizował polityki, klasyfikację dostawców, klauzule umowne, due diligence i bieżące monitorowanie. W przypadku zarządzania incydentami sprawdzi plan, role, ścieżki eskalacji, narzędzia i zapisy. W przypadku testowania będzie oczekiwał zaplanowanych interwałów, niezależności tam, gdzie jest właściwa, działań naprawczych i wkładu do przeglądu zarządzania.

Perspektywa audytu ISO/IEC 19011:2018 koncentruje się na wykonaniu audytu. W Zenith Controls metodyka audytu dla bezpieczeństwa łańcucha dostaw ICT wskazuje, że audytorzy badają polityki zakupowe, szablony RFP i procesy zarządzania dostawcami, aby zweryfikować, czy specyficzne dla ICT wymagania bezpieczeństwa są osadzone od pozyskania po utylizację. W przypadku zarządzania incydentami audytorzy badają plan reagowania na incydenty pod kątem kompletności i zgodności z dobrymi praktykami. W przypadku niezależnego przeglądu audytorzy szukają dowodów, że niezależne audyty lub przeglądy zostały przeprowadzone.

Perspektywa ISO/IEC 27007:2020 jest bardziej specyficzna dla audytu SZBI. Zenith Controls wskazuje, że audytorzy mogą przeprowadzać wywiady z osobami odpowiedzialnymi za zakupy, personelem bezpieczeństwa IT i menedżerami dostawców, aby ocenić zrozumienie i wykonywanie kontroli łańcucha dostaw ICT. W zakresie przygotowania do incydentów potwierdzają, że zespół reagowania na incydenty istnieje i działa operacyjnie. W przypadku niezależnego przeglądu weryfikują, czy program audytu wewnętrznego obejmuje pełny zakres SZBI i ma właściwe zasoby.

Asesor testów kierujący się NIST SP 800-115 skupi się na metodyce oceny podatności i testów penetracyjnych. Może zbadać, czy zakres testów, zasady prowadzenia działań, ustalenia, oceny istotności, działania naprawcze i ponowne testy są udokumentowane. W przypadku DORA TLPT oznacza to, że asesor nie zadowoli się prezentacją red team. Będzie oczekiwał dowodów ładu, bezpieczeństwa, głębokości technicznej i zamknięcia ustaleń.

Audytor w stylu COBIT 2019 lub ISACA zapyta, czy cele ładu zostały osiągnięte: kto jest właścicielem procesu, jak mierzy się skuteczność, jak zatwierdza się wyjątki i jak kierownictwo otrzymuje zapewnienie.

Praktyczna lista kontrolna gotowości DORA 2026

Użyj tej listy kontrolnej jako roboczej bazy do przekształcenia wyszukiwań DORA w działania.

Ład i mapowanie RTS/ITS

• Utrzymuj Rejestr zgodności DORA z obszarem obowiązku, zastosowaniem, właścicielem, dowodami, częstotliwością przeglądu i statusem luk.
• Mapuj wymagania DORA na polityki, rejestry, mechanizmy kontrolne i raportowanie zarządcze.
• Zdefiniuj uzasadnienie proporcjonalności dla uproszczonego lub skalowanego zarządzania ryzykiem ICT tam, gdzie ma zastosowanie.
• Przypisz rozliczalność kierownictwa wykonawczego za ryzyko ICT, zgłaszanie incydentów, nadzór nad stronami trzecimi i testowanie.
• Uwzględniaj status DORA w przeglądzie zarządzania i raportowaniu ryzyka do zarządu.

Zarządzanie ryzykiem ICT

• Utrzymuj rejestr ryzyk ICT z opisem, prawdopodobieństwem, wpływem, punktacją, właścicielem i planem postępowania z ryzykiem.
• Łącz ryzyka z funkcjami krytycznymi lub ważnymi.
• Łącz ryzyka z aktywami ICT, dostawcami i procesami.
• Przeglądaj ryzyka po poważnych incydentach, zmianach dostawców, zmianach technologicznych lub ustaleniach z testów.
• Śledź działania związane z postępowaniem z ryzykiem do zamknięcia albo formalnej akceptacji ryzyka.

Nadzór nad stronami trzecimi ICT

• Utrzymuj rejestr dostawców i rejestr zależności od dostawców.
• Identyfikuj dostawców wspierających funkcje krytyczne lub ważne.
• Oceniaj dostawców będących jedynym źródłem oraz możliwość ich zastąpienia.
• Przeglądaj podwykonawców i uzgodnienia dotyczące podoutsourcingu.
• Osadzaj w umowach klauzule dotyczące bezpieczeństwa, dostępu, zgłaszania incydentów, audytu i wyjścia.
• Monitoruj dostawców krytycznych co najmniej raz w roku lub po istotnych zmianach.
• Utrzymuj plany wyjścia i plany awaryjne dla dostawców o wysokim poziomie zależności.

Zarządzanie incydentami i ich zgłaszanie

• Utrzymuj procedury reagowania na incydenty z jasnymi rolami i ścieżkami eskalacji.
• Definiuj kryteria klasyfikacji incydentów ICT.
• Dostosuj wyzwalacze raportowania DORA do RODO, NIS2 i umownych obowiązków powiadamiania.
• Szkol pracowników i wykonawców w zakresie kanałów zgłaszania incydentów.
• Utrzymuj logi incydentów, zapisy decyzji i dowody.
• Przeprowadzaj przeglądy po incydentach oraz aktualizuj ryzyka i mechanizmy kontrolne.

Testowanie, red teaming i TLPT

• Utrzymuj kalendarz testów oparty na ryzyku.
• Wykonuj skanowanie podatności i testy penetracyjne w zdefiniowanych odstępach czasu.
• Stosuj scenariuszowe ćwiczenia red team do testowania wykrywania i reagowania.
• Dla gotowości TLPT zdefiniuj zakres, zasady prowadzenia działań, środki bezpieczeństwa i koordynację z dostawcami.
• Chroń systemy produkcyjne podczas testowania.
• Śledź ustalenia, działania naprawcze, ponowne testy i wnioski.
• Raportuj wyniki testów kierownictwu.

Ciągłość i odzyskiwanie

• Przeprowadzaj coroczną BIA dla krytycznych jednostek biznesowych i aktualizuj ją po istotnych zmianach.
• Definiuj cele odzyskiwania dla funkcji krytycznych i wspierających usług ICT.
• Testuj zdolności BCP i DR co najmniej raz w roku.
• Uwzględniaj scenariusze awarii dostawcy i cyberincydentu.
• Zachowuj dowody testów, luki, działania naprawcze i wyniki ponownych testów.
• Dostosuj plany ciągłości do reagowania na incydenty i komunikacji kryzysowej.

Jak Clarysec pomaga podmiotom finansowym przejść od wyników wyszukiwania do dowodów gotowych do audytu

Gotowości DORA 2026 nie osiąga się przez pobranie listy kontrolnej i liczenie, że organizacja uzupełni luki później. Wymaga ona uporządkowanego modelu operacyjnego, który łączy ryzyko, dostawców, incydenty, testowanie, ciągłość i dowody audytowe.

Podejście Clarysec łączy trzy warstwy.

Po pierwsze, Zenith Blueprint zapewnia mapę drogową wdrożenia. Krok 14 pomaga organizacjom tworzyć odwołania krzyżowe między wymaganiami regulacyjnymi a postępowaniem z ryzykiem i politykami. Krok 16 wzmacnia zgłaszanie incydentów przez personel. Krok 21 zapewnia, że audyty i testy nie zagrażają systemom produkcyjnym. Krok 23 przekształca nadzór nad dostawcami w praktyczny proces obejmujący klasyfikację, umowy, podwykonawców, monitorowanie i ocenę usług chmurowych.

Po drugie, polityki Clarysec zapewniają ład gotowy do operacyjnego zastosowania. Polityka zarządzania ryzykiem, Polityka zgodności prawnej i regulacyjnej, Polityka bezpieczeństwa dostawców i stron trzecich, Polityka zarządzania ryzykiem zależności od dostawców, Polityka reagowania na incydenty, Polityka testów bezpieczeństwa i działań red team oraz Polityka ciągłości działania i odtwarzania po awarii dostarczają zespołom konkretnych klauzul, modeli własności i oczekiwań dowodowych.

Po trzecie, Zenith Controls zapewnia mapę zgodności przekrojowej. Pokazuje, jak bezpieczeństwo łańcucha dostaw ICT, planowanie zarządzania incydentami i niezależny przegląd łączą się z DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 i praktykami testowymi NIST.

Rezultatem jest program zgodności z DORA, który można obronić podczas audytu i który jest użyteczny podczas rzeczywistego incydentu, awarii dostawcy lub testu odporności.

Następny krok: zbuduj pakiet dowodowy DORA przed kolejnym żądaniem audytowym

Jeżeli Twój zespół nadal wyszukuje „lista kontrolna DORA RTS/ITS”, „szablon zarządzania ryzykiem ICT DORA”, „nadzór nad stronami trzecimi DORA” albo „wymagania DORA TLPT”, następnym krokiem jest przekształcenie tych wyszukiwań w kontrolowane dowody.

Zacznij od czterech działań w tym tygodniu:

1. Utwórz lub zaktualizuj Rejestr zgodności DORA z wykorzystaniem modelu polityk Clarysec.
2. Wybierz jedną funkcję krytyczną i prześledź ją przez rejestr ryzyk, rejestr zależności od dostawców, proces incydentowy, BIA i plan testów.
3. Przejrzyj pięciu najważniejszych dostawców ICT pod kątem możliwości zastąpienia, podwykonawców, klauzul incydentowych i opcji wyjścia.
4. Zbuduj pakiet dowodowy testów obejmujący zakres, autoryzację, wyniki, działania naprawcze i ponowne testy.

Clarysec może pomóc we wdrożeniu tego podejścia z wykorzystaniem Zenith Blueprint, szablonów polityk i Zenith Controls, aby program DORA 2026 był praktyczny, proporcjonalny i gotowy do audytu.