Program testowania DORA: mapowanie testów na ISO 27001

Jest luty 2026 r. Dyrektor ds. bezpieczeństwa informacji (CISO) w średniej wielkości instytucji płatniczej ma za dwa dni posiedzenie zarządu, za sześć tygodni audyt nadzoru ISO/IEC 27001:2022, a w skrzynce zespołu ds. zgodności czeka żądanie nadzorcze dotyczące DORA.

Regulator nie oczekuje efektownej strategii cyberbezpieczeństwa. Żądanie jest praktyczne:

• Przedstawić program testowania cyfrowej odporności operacyjnej na 2026 r.
• Wskazać, które testy obejmują krytyczne lub istotne funkcje.
• Wykazać, w jaki sposób ustalenia są usuwane i ponownie testowane.
• Przedstawić dowody nadzoru organu zarządzającego.
• Wyjaśnić, w jaki sposób uwzględniani są zewnętrzni dostawcy usług ICT.
• Przedstawić zapisy dotyczące ocen podatności, testów scenariuszowych, testów wydajnościowych i pojemnościowych oraz testów penetracyjnych.

CISO otwiera cztery foldery. Skany podatności znajdują się w systemie zgłoszeniowym SOC. Notatki z ćwiczeń sztabowych są na dysku współdzielonym. Wyniki testów obciążeniowych należą do zespołu inżynieryjnego. Raporty z testów penetracyjnych znajdują się w zastrzeżonym repozytorium działu prawnego. Śledzenie działań naprawczych jest podzielone między Jira, e-mail i arkusz kalkulacyjny utworzony na potrzeby ubiegłorocznego audytu ISO.

Nic nie jest fikcyjne. Znaczna część tych prac ma realną wartość. Nie jest to jednak jeszcze zarządzany program testowania cyfrowej odporności operacyjnej DORA. To zbiór testów.

Ta różnica ma znaczenie w 2026 r. DORA obowiązuje od 17 stycznia 2025 r. i ustanawia jednolite ramy UE dotyczące cyfrowej odporności operacyjnej w obszarach zarządzania ryzykiem ICT, zgłaszania incydentów, testowania odporności, wymiany informacji o cyberzagrożeniach i podatnościach, zarządzania ryzykiem zewnętrznych dostawców usług ICT, wymogów umownych oraz nadzoru nad krytycznymi zewnętrznymi dostawcami usług ICT. Obejmuje szeroki zakres podmiotów finansowych, w tym instytucje kredytowe, instytucje płatnicze, firmy inwestycyjne, dostawców usług w zakresie kryptoaktywów, zakłady ubezpieczeń i inne podmioty regulowane. DORA pełni również funkcję sektorowego aktu prawnego Unii dla podmiotów finansowych, które w przeciwnym razie podlegałyby równoważnym obowiązkom cyberbezpieczeństwa wynikającym z NIS2.

Praktyczne pytanie dla zarządów, CISO, menedżerów ds. zgodności i dostawców usług ICT nie brzmi już, czy testowanie jest prowadzone. Pytanie brzmi, czy testowanie jest zaplanowane, oparte na ryzyku, udokumentowane dowodowo, objęte działaniami naprawczymi, przeglądane i możliwe do ponownego wykorzystania w ramach DORA oraz ISO/IEC 27001:2022.

Model operacyjny Clarysec został zaprojektowany właśnie z myślą o tym problemie. Korzystając z Zenith Blueprint: 30-etapowej mapy drogowej audytora, zestawu polityk Clarysec zgodnych z ISO oraz Zenith Controls: przewodnika po zgodności wieloregulacyjnej, organizacje mogą przekształcić rozproszone działania odpornościowe w kontrolowany roczny katalog testów, który spełnia oczekiwania organów nadzoru, audytorów, klientów i zarządów.

Dlaczego DORA zmienia testowanie w zagadnienie ładu organizacyjnego

DORA jednoznacznie przypisuje odpowiedzialność kierownictwu. Article 5 przypisuje organowi zarządzającemu odpowiedzialność za zarządzanie ryzykiem ICT. Article 6 wymaga solidnych, kompleksowych i dobrze udokumentowanych ram zarządzania ryzykiem ICT zintegrowanych z ogólnym systemem zarządzania ryzykiem organizacji. Article 4 wprowadza zasadę proporcjonalności, co oznacza, że wymogi należy stosować z uwzględnieniem wielkości, ogólnego profilu ryzyka oraz charakteru, skali i złożoności usług, działań i operacji.

To sprawia, że testowanie cyfrowej odporności operacyjnej jest czymś więcej niż zadaniem technicznym. Staje się dowodem, że organ zarządzający rozumie ryzyko, zatwierdził strategię, otrzymuje merytoryczne raportowanie i egzekwuje działania naprawcze.

ISO/IEC 27001:2022 stosuje podobną logikę systemu zarządzania. Punkty 4.1–4.4 wymagają, aby organizacja rozumiała kontekst, strony zainteresowane, obowiązki prawne i umowne, zakres, interfejsy i zależności. Punkty 5.1–5.3 wymagają przywództwa, dostosowania polityk, zasobów, komunikacji, przypisanych odpowiedzialności oraz raportowania do najwyższego kierownictwa. Punkt 6.1 wymaga oceny ryzyka bezpieczeństwa informacji i postępowania z ryzykiem.

Program testowania DORA powinien więc łączyć:

• Usługi biznesowe oraz krytyczne lub istotne funkcje
• Aktywa ICT, dane i zależności od stron trzecich
• Ocenę ryzyka, właścicieli ryzyka i plany postępowania z ryzykiem
• Rodzaje testów, częstotliwość i wyzwalacze
• Autoryzację, niezależność i zasady prowadzenia testów
• Ustalenia, terminy działań naprawczych i ponowne testy
• Okres przechowywania dowodów i kontrolę dostępu
• Raportowanie zarządcze i ciągłe doskonalenie

Dla mniejszych lub mniej ryzykownych podmiotów finansowych Article 16 przewiduje uproszczone ramy zarządzania ryzykiem ICT, ale uproszczone nie oznacza nieformalne. Nawet skalowane programy nadal wymagają udokumentowanego zarządzania ryzykiem ICT, monitorowania, odpornych systemów, identyfikacji źródeł ryzyka ICT i anomalii, kluczowych zależności od zewnętrznych dostawców usług ICT, środków ciągłości i odzyskiwania, regularnego testowania oraz wniosków z doświadczeń.

Innymi słowy, DORA nie premiuje liczby testów. Premiowane jest zarządzane, oparte na ryzyku testowanie, które potwierdza odporność usług o największym znaczeniu.

Co powinno znaleźć się w programie testowania DORA na 2026 r.?

Dojrzały program testowania DORA powinien funkcjonować jako roczny katalog testów. Nie powinien ograniczać się do jednego corocznego testu penetracyjnego ani stosu eksportów ze skanów podatności. Powinien obejmować testy podstawowe i zaawansowane, planowane z uwzględnieniem ryzyka, krytyczności usług, obowiązków regulacyjnych, zależności od dostawców, istotnych zmian oraz wcześniejszych ustaleń.

DORA Article 24 ustanawia program testowania cyfrowej odporności operacyjnej. Article 25 opisuje zakres testów, w tym oceny i skany podatności, analizy otwartych źródeł, oceny bezpieczeństwa sieci, analizy luk, przeglądy bezpieczeństwa fizycznego, kwestionariusze, narzędzia programowe do skanowania, przeglądy kodu źródłowego tam, gdzie jest to wykonalne, testy scenariuszowe, testowanie kompatybilności, testowanie wydajnościowe, testy end-to-end oraz testy penetracyjne. Article 26 dodaje testy penetracyjne oparte na analizie zagrożeń dla podmiotów finansowych wskazanych przez właściwe organy.

W przypadku większości organizacji praktyczny katalog opiera się na czterech rodzinach testów.

Polityka testów bezpieczeństwa i red teaming Clarysec stanowi solidną podstawę polityczną dla tego katalogu:

“Rodzaje testów: Program testów bezpieczeństwa powinien obejmować co najmniej: (a) skanowanie podatności, polegające na automatycznych cotygodniowych lub comiesięcznych skanach sieci i aplikacji w celu identyfikacji znanych podatności; (b) testy penetracyjne, polegające na ręcznych, dogłębnych testach określonych systemów lub aplikacji wykonywanych 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 całościowej zdolności organizacji do wykrywania i reagowania.”

Ta sama polityka wymaga regularnego harmonogramu:

“Harmonogram testów: Organizacja powinna prowadzić testy bezpieczeństwa według regularnego harmonogramu. Kluczowe systemy dostępne z Internetu i krytyczne aplikacje wewnętrzne muszą przechodzić testy penetracyjne co najmniej raz w roku. Zmiany wysokiego ryzyka, takie jak wdrożenie nowego systemu krytycznego lub istotne aktualizacje, wymagają testów doraźnych przed uruchomieniem w środowisku produkcyjnym i/lub krótko po nim.”

Ma to kluczowe znaczenie dla DORA. Statyczny roczny plan nie wystarczy, jeżeli podmiot wdraża nową bramkę płatniczą, migruje system podstawowy do chmury, zmienia dostawcę usług zarządzanych albo uruchamia nowy przepływ uwierzytelniania klientów. Zmiana wysokiego ryzyka musi uruchamiać dodatkowe testy.

Zbuduj roczny katalog testów jako jedno źródło prawdy

Najskuteczniejszym sposobem spełnienia wymagań DORA i ISO/IEC 27001:2022 jest utworzenie jednego kontrolowanego rocznego katalogu testów. Może znajdować się w platformie GRC, w przepływie pracy systemu zgłoszeniowego albo w kontrolowanym arkuszu kalkulacyjnym. Format jest mniej istotny niż identyfikowalność.

Każdy test powinien odpowiadać na pięć pytań audytowych:

1. Która usługa, aktywo, dostawca, aplikacja lub proces były testowane?
2. Jakie ryzyko, obowiązek lub wymaganie kontrolne wyzwoliło test?
3. Kto autoryzował i wykonał test?
4. Jakie ustalenia zostały zidentyfikowane, zaakceptowane, usunięte lub odroczone?
5. Jakie dowody potwierdzają, że test się odbył, a wynik został poddany przeglądowi?

Praktyczny katalog w stylu Clarysec obejmuje następujące pola.

Polityka audytu i monitorowania zgodności-sme - SME Clarysec podaje zwięzłą zasadę ładu, która pasuje do tej struktury:

“Każdy audyt musi obejmować określony zakres, cele, odpowiedzialny personel oraz wymagane dowody.”

Chociaż zasada została napisana dla audytów, powinna mieć zastosowanie również do testów odporności. Jeżeli skan podatności, ćwiczenie sztabowe, symulacja przełączenia awaryjnego lub test penetracyjny nie mają zdefiniowanego zakresu, celu, właściciela i wymaganych dowodów, będą słabe zarówno pod kątem DORA, jak i audytu ISO.

Ta sama polityka stanowi:

“Dowody muszą być przechowywane przez co najmniej dwa lata albo dłużej, jeżeli wymagają tego certyfikacja lub umowy z klientami.”

Dla podmiotów finansowych regulowanych przez DORA i dostawców usług ICT dwa lata należy traktować jako minimum. Obowiązki umowne, oczekiwania nadzorcze, cykle certyfikacji i dochodzenia incydentowe mogą wymagać dłuższego okresu przechowywania.

Mapowanie rodzajów testów DORA na dowody ISO 27001

Siłą zintegrowanego programu jest to, że jeden test może spełniać wiele obowiązków. Kluczowe jest właściwe tagowanie dowodów i powiązanie ich z SZBI.

Zenith Blueprint wyjaśnia to w fazie Audyt, przegląd i doskonalenie, Step 24:

“Twoja SoA powinna być spójna z Rejestrem ryzyk i Planem postępowania z ryzykiem. Sprawdź ponownie, czy każda kontrola wybrana przez Ciebie jako sposób postępowania z ryzykiem jest oznaczona w SoA jako „Applicable”.”

W przypadku programu testowania DORA katalog testów staje się pomostem między postępowaniem z ryzykiem a dowodami operacyjnymi. Deklaracja stosowania nie powinna wskazywać, że kontrola ma zastosowanie, podczas gdy dowody z testów znajdują się gdzie indziej, bez mapowania i bez zarządzania.

Ta tabela pomaga CISO odpowiedzieć na typowe pytanie dyrektora generalnego: „Czy nasze testy penetracyjne ISO i skany podatności wystarczą na potrzeby DORA?”

Odpowiedź brzmi: mogą być częścią zgodności z DORA, ale tylko wtedy, gdy są oparte na ryzyku, powiązane z krytycznymi lub istotnymi funkcjami, zarządzane polityką, śledzone w procesie działań naprawczych i raportowane kierownictwu.

Oceny podatności: ciągłe dowody, nie tylko wynik skanu

Ocena podatności jest często najłatwiejszym działaniem testowym do uruchomienia i najłatwiejszym do niewłaściwego obsłużenia. Wiele organizacji potrafi przedstawić raporty ze skanów. Mniej potrafi udowodnić, że skany obejmują właściwe aktywa, priorytetyzują usługi krytyczne, generują terminowe działania naprawcze i zasilają decyzje dotyczące postępowania z ryzykiem.

Polityka zarządzania podatnościami i poprawkami-sme - SME Clarysec zaczyna od właściwego celu:

“Identyfikować i oceniać znane podatności we wszystkich aktywach IT w sposób terminowy i spójny”

Dla DORA wspiera to identyfikację źródeł ryzyka ICT, odporne i aktualizowane systemy, monitorowanie, wykrywanie anomalii i ciągłe doskonalenie. Dla ISO/IEC 27001:2022 mapuje się bezpośrednio na 8.8 Zarządzanie podatnościami technicznymi, a także opiera się na 5.9 Inwentarz informacji i innych powiązanych aktywów, 8.16 Działania monitorujące oraz 8.32 Zarządzanie zmianą.

Solidny zapis oceny podatności powinien obejmować:

• Migawkę inwentarza aktywów używaną do określenia zakresu
• Datę skanu, narzędzie i metodę: uwierzytelnioną lub nieuwierzytelnioną
• Wyłączenia i uzasadnienie biznesowe
• Ustalenia według istotności, możliwości wykorzystania i usługi biznesowej
• Mapowanie na krytyczne lub istotne funkcje oraz typy danych
• Odniesienia do zgłoszeń i właściciela ryzyka
• SLA działań naprawczych i termin realizacji
• Wynik ponownego testu
• Wyjątki wraz z zatwierdzeniem ryzyka szczątkowego

Zenith Controls pozycjonuje 8.8 Zarządzanie podatnościami technicznymi jako kluczowy obszar dowodowy dla identyfikacji, oceny, priorytetyzacji i śledzenia działań naprawczych. Pokazuje również, dlaczego audytorzy będą testować procesy sąsiadujące. Jeżeli inwentarz aktywów jest niekompletny, pokrycie oceną podatności jest niekompletne. Jeżeli zarządzanie zmianą jest obchodzone, wdrożenie poprawek może tworzyć nowe ryzyko operacyjne. Jeżeli monitorowanie jest słabe, próby wykorzystania podatności mogą nie zostać wykryte.

Testy scenariuszowe: potwierdź podejmowanie decyzji przed rzeczywistym incydentem

Testy scenariuszowe pokazują kierownictwu, jak wygląda odporność operacyjna w praktyce. Ćwiczenie sztabowe dotyczące ransomware, symulacja awarii regionu chmurowego, ćwiczenie naruszenia dostępu uprzywilejowanego lub scenariusz awarii krytycznego dostawcy usług ICT ujawnią słabości, których nie pokaże skan.

DORA Articles 17 to 20 wymagają formalnego cyklu życia incydentu związanego z ICT: wykrycia, zarządzania, powiadomienia, zapisu, monitorowania, obsługi, działań następczych, udokumentowania analizy przyczyny źródłowej, działań naprawczych, klasyfikacji istotności, przypisania ról, eskalacji poważnych incydentów oraz raportowania w wymaganych etapach. Gdy naruszone są interesy finansowe klientów, należy poinformować klientów bez zbędnej zwłoki.

NIS2 przewiduje podobną pilność dla podmiotów objętych zakresem, w tym wczesne ostrzeżenie, powiadomienie, raportowanie pośrednie i raportowanie końcowe. Dla podmiotów finansowych objętych zakresem DORA jest sektorowym aktem prawnym dla równoważnych obowiązków zarządzania ryzykiem cyberbezpieczeństwa i raportowania. Dostawcy usług ICT, platformy SaaS, MSP i MSSP nadal muszą sprawdzić, czy bezpośrednio podlegają NIS2, czy też są umownie włączani do zapewnienia DORA przez regulowanych klientów.

Zenith Blueprint, faza Controls in Action, Step 23, przedstawia praktyczny model dowodowy:

“Wybierz niedawne zdarzenie albo przeprowadź ćwiczenie tabletop, aby zweryfikować plan. Uchwyć i zarejestruj wszystkie decyzje, role i komunikację (5.26), a następnie zaktualizuj plan o wnioski z doświadczeń (5.27).”

Test scenariuszowy DORA powinien tworzyć zapisy możliwe do prześledzenia audytowo, a nie tylko notatki ze spotkania:

• Opis scenariusza i cele
• Uczestnicy i role, w tym dział prawny, komunikacja, IT, SOC, właściciel biznesowy i kontakty po stronie dostawców
• Oś czasu wstrzyknięć scenariuszowych i decyzji
• Decyzja klasyfikacyjna i analiza progów raportowania
• Projekty komunikacji wewnętrznej i zewnętrznej
• Działania zabezpieczenia materiału dowodowego
• Wnioski z doświadczeń
• Właściciele działań i terminy realizacji
• Zaktualizowane procedury incydentowe, ciągłościowe lub komunikacyjne

Polityka ciągłości działania i odtwarzania po awarii-sme - SME Clarysec wzmacnia oczekiwanie corocznego testowania:

“Organizacja musi testować zarówno swoje możliwości BCP, jak i DR co najmniej raz w roku. Testy muszą obejmować:”

Katalog testów powinien przełożyć ten obowiązek na konkretne ćwiczenia, takie jak ćwiczenie sztabowe zarządzania kryzysowego, test odtworzenia kopii zapasowej, test przełączenia awaryjnego chmury, test drzewa kontaktów oraz symulacja zakłócenia po stronie dostawcy.

Testy wydajności, pojemności i odzyskiwania: zaniedbywany dowód odporności

Testowanie wydajności jest często traktowane jako zagadnienie inżynieryjne. W ramach DORA staje się dowodem odporności.

Platforma transakcyjna, usługa płatnicza, system likwidacji szkód, platforma tożsamości lub portal klienta nie potrzebują cyberataku, aby zawieść klientów. Wyczerpanie pojemności, nasycenie kolejek, wąskie gardła baz danych, błędnie skonfigurowane autoskalowanie lub niesprawne przełączenie awaryjne mogą spowodować takie samo zakłócenie operacyjne jak incydent bezpieczeństwa.

ISO/IEC 27001:2022 Annex A 8.6 Zarządzanie pojemnością jest podstawowym punktem odniesienia. Dowody mogą obejmować testy obciążeniowe, testy przeciążeniowe, testy degradacji usługi, walidację progów infrastruktury, testy odtworzenia kopii zapasowych oraz symulacje przełączenia awaryjnego.

Dobry zapis testu wydajnościowego i pojemnościowego powinien obejmować:

• Założenia dotyczące bazowego normalnego obciążenia i obciążenia szczytowego
• Testowane krytyczne ścieżki transakcyjne
• Testowane limity infrastruktury i chmury
• Pulpity monitorowania i progi alertów
• Tryby awarii, takie jak nasycenie kolejek lub wąskie gardła baz danych
• Znaczenie RTO i RPO, gdy testowane jest przełączenie awaryjne lub odzyskiwanie
• Wpływ biznesowy w przypadku przekroczenia progów
• Działania naprawcze, decyzje skalujące lub zmiany architektury
• Akceptację ryzyka szczątkowego pojemności przez kierownictwo

Zenith Blueprint, Step 23, łączy oczekiwania dotyczące odzyskiwania z dowodami:

“Zweryfikuj, czy docelowe czasy odtworzenia (RTO) i docelowe punkty odtworzenia (RPO) dla systemów krytycznych są zgodne z oczekiwaniami dotyczącymi ciągłości działania (5.30). Przeprowadź co najmniej jeden techniczny test odtworzeniowy lub symulację przełączenia awaryjnego i udokumentuj wyniki.”

To różnica między stwierdzeniem „mamy kopie zapasowe” a udowodnieniem, że krytyczna usługa została odtworzona w uzgodnionej tolerancji, z udokumentowanymi wynikami i widocznością dla kierownictwa.

Testy penetracyjne i red teaming: silny dowód wymaga silnej kontroli

Testy penetracyjne są bardzo wartościowym dowodem, ale niosą też ryzyko operacyjne. Źle zarządzane testowanie może wpłynąć na systemy produkcyjne, ujawnić dane wrażliwe, wywołać niekontrolowane alarmy, stworzyć problemy prawne lub zakłócić obsługę klientów.

Polityka wymagań bezpieczeństwa aplikacji-sme - SME ustanawia jasną bramkę wydania:

“Przed wdrożeniem wszystkie Aplikacje muszą przejść testy bezpieczeństwa w celu weryfikacji bazowych funkcji wymienionych powyżej.”

W przypadku aplikacji krytycznych powinno to zasilać katalog DORA jako przedprodukcyjne testy bezpieczeństwa, walidacja po uruchomieniu produkcyjnym dla zmian wysokiego ryzyka oraz okresowe testy penetracyjne oparte na ekspozycji i krytyczności.

Polityka testów bezpieczeństwa i red teaming wzmacnia łańcuch działań naprawczych:

“Działania naprawcze dotyczące ustaleń: Wszystkie zidentyfikowane podatności lub słabości muszą zostać udokumentowane w raporcie ustaleń wraz z ocenami istotności. Po otrzymaniu raportu właściciele systemów odpowiadają za utworzenie planu działań naprawczych z terminami realizacji; na przykład ustalenia krytyczne powinny zostać usunięte w ciągu 30 dni, a ustalenia o wysokiej istotności w ciągu 60 dni, zgodnie z Polityką zarządzania podatnościami i poprawkami organizacji. STC powinien śledzić postęp działań naprawczych. Ponowne testy powinny zostać wykonane w celu potwierdzenia, że problemy krytyczne zostały rozwiązane lub odpowiednio zmitygowane.”

Ta sama polityka definiuje oczekiwania dotyczące raportowania:

“Raportowanie: Po zakończeniu każdego testu powinien zostać wydany formalny raport. W przypadku testów penetracyjnych raport powinien obejmować podsumowanie dla kierownictwa, metodykę oraz szczegółowe ustalenia wraz z dowodami wspierającymi i rekomendacjami.”

Zenith Blueprint, Step 21, podkreśla również ochronę podczas audytu i testowania:

“Żaden test ani audyt nie powinien się rozpocząć bez udokumentowanego zatwierdzenia przez właścicieli systemów lub właściwych interesariuszy.”

Zasady prowadzenia testów, okna testowe, kontakty awaryjne, dostęp tymczasowy, postępowanie z danymi, rejestrowanie, procedury wycofania zmian i zatwierdzenia prawne nie są biurokracją. Są zabezpieczeniami odporności.

Uwzględnij zewnętrznych dostawców usług ICT, zanim test zakończy się niepowodzeniem

DORA czyni ryzyko związane z zewnętrznymi dostawcami usług ICT centralnym zagadnieniem odporności. Article 28 wymaga od podmiotów finansowych zarządzania ryzykiem zewnętrznych dostawców usług ICT w ramach ram zarządzania ryzykiem ICT, zachowania odpowiedzialności podczas korzystania z usług ICT, utrzymywania rejestru informacji, zgłaszania określonych uzgodnień, prowadzenia ocen przedumownych oraz korzystania z dostawców spełniających odpowiednie standardy bezpieczeństwa informacji. Articles 29 and 30 dotyczą ryzyka koncentracji, podzlecania, odzyskiwania danych, ochrony umownej, poziomów usług, wsparcia incydentowego, praw audytu, testowania awaryjnego dostawcy, udziału w testach tam, gdzie jest to właściwe, oraz ustaleń wyjścia.

ISO/IEC 27001:2022 Annex A dostarcza wspierających zabezpieczeń dotyczących dostawców, w tym 5.19 Bezpieczeństwo informacji w relacjach z dostawcami, 5.20 Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami, 5.21 Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT, 5.22 Monitorowanie, przegląd i zarządzanie zmianą usług dostawców oraz 5.23 Bezpieczeństwo informacji przy korzystaniu z usług chmurowych.

Katalog testów DORA powinien wskazywać, które testy wymagają udziału dostawcy lub dowodów od dostawcy. Przykłady obejmują:

• Założenia przełączenia awaryjnego dostawcy chmury
• Eskalację zarządzanego SOC i zabezpieczenie materiału dowodowego
• Komunikację incydentową platformy core banking
• Scenariusz niedostępności procesora płatności
• Test odtwarzania dostawcy tożsamości
• Poświadczenia testów penetracyjnych dostawcy SaaS
• Ocenę wpływu łańcucha krytycznych podwykonawców

Program, który wyklucza krytycznych dostawców usług ICT, nie przejdzie testu rzeczywistości. Usługa dostępna dla klienta może należeć do Ciebie, ale zależność odpornościowa może znajdować się w regionie chmurowym, zewnętrznym SOC, dostawcy tożsamości, dostawcy oprogramowania, procesorze płatności lub centrum danych.

Mapowanie zgodności wieloregulacyjnej: jeden zestaw dowodów, wiele obowiązków

Dobrze zaprojektowany program testowania DORA ogranicza zmęczenie audytowe. Te same dowody mogą wspierać DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 i przeglądy ładu COBIT 2019, jeżeli są odpowiednio otagowane, przechowywane i raportowane.

Nie należy pomijać GDPR. Jeżeli testy odporności obejmują dane osobowe, logi, rejestry klientów, dane tożsamości, zapisy HR, dane biometryczne lub szczególne kategorie danych, organizacja musi przestrzegać zasad GDPR, w tym zgodności z prawem, rzetelności, przejrzystości, minimalizacji danych, ograniczenia przechowywania, integralności, poufności i rozliczalności. Kopie danych testowych, wyeksportowane logi i dowody z testów penetracyjnych mogą stać się repozytoriami danych regulowanych. Program testowania powinien określać, kto może uzyskiwać do nich dostęp, jak długo są przechowywane i jak są bezpiecznie utylizowane.

Jak audytorzy będą testować ten sam program

Organ nadzoru DORA, audytor ISO, asesor oparty na NIST, recenzent COBIT i audytor klienta mogą analizować te same dowody z różnych perspektyw.

Zenith Controls jest tutaj przydatny jako kompas zgodności wieloregulacyjnej. W przypadku testów DORA Clarysec wskazuje 5.35 Niezależny przegląd bezpieczeństwa informacji, 8.8 Zarządzanie podatnościami technicznymi i 8.6 Zarządzanie pojemnością jako szczególnie ważne punkty odniesienia ISO/IEC 27001:2022 Annex A. Pomagają one właścicielom kontroli powiązać testowanie z niezależnym zapewnieniem, obsługą podatności i pojemnością operacyjną.

Polityka bezpieczeństwa informacji Clarysec wspiera również ścieżkę audytową:

“Właściciele kontroli powinni utrzymywać wyniki testów, logi oraz zapisy z przeglądów w celu wsparcia okresowych audytów.”

To zdanie powinno stać się zasadą operacyjną. Każdy właściciel testu powinien wiedzieć, co przechowywać, gdzie to przechowywać, jak to chronić i jak wiąże się to z dowodami ryzyka i kontroli.

Zbuduj pakiet dowodowy DORA–ISO w tydzień

Podmiot finansowy lub dostawca usług ICT może osiągnąć znaczący postęp w pięć dni roboczych.

Dzień 1: Zdefiniuj zakres i krytyczność

Wykorzystaj sposób myślenia wynikający z ISO/IEC 27001:2022 punktów 4.1–4.4. Zidentyfikuj strony zainteresowane, obowiązki regulacyjne, obowiązki umowne, interfejsy i zależności. Wymień usługi biznesowe, krytyczne lub istotne funkcje, kluczowe aktywa, typy danych i dostawców usług ICT.

Wynik: rejestr zakresu testów DORA.

Dzień 2: Utwórz roczny katalog testów

Wykorzystaj cztery rodziny testów: podatności, scenariusze, wydajność i penetracja. Dla każdej usługi określ, które testy mają zastosowanie, częstotliwość, właściciela, poziom niezależności i wyzwalacz. Uwzględnij wyzwalacze zmian wysokiego ryzyka.

Wynik: katalog testów cyfrowej odporności operacyjnej na 2026 r.

Dzień 3: Zmapuj kontrole i obowiązki

Zmapuj każdy test na ISO/IEC 27001:2022 Annex A, rejestr ryzyk, SoA, artykuły DORA, obowiązki dostawców i właściwe pozycje Zenith Controls. Na przykład comiesięczne zewnętrzne skany podatności mapują się na 8.8 Zarządzanie podatnościami technicznymi, postępowanie z ryzykiem, monitorowanie, zarządzanie ryzykiem ICT DORA i wyniki podatności NIST CSF.

Wynik: macierz mapowania kontroli.

Dzień 4: Ustandaryzuj foldery dowodowe

Utwórz kontrolowaną strukturę dowodów:

• 01 Plan i autoryzacja
• 02 Zakres i zasady prowadzenia testów
• 03 Wyniki surowe
• 04 Raport końcowy
• 05 Rejestr ustaleń
• 06 Zgłoszenia działań naprawczych
• 07 Dowody ponownego testu
• 08 Raportowanie zarządcze
• 09 Wnioski z doświadczeń i aktualizacje polityk

Wynik: repozytorium dowodów z zasadami przechowywania.

Dzień 5: Przejrzyj ustalenia i raportowanie

Skonsoliduj otwarte ustalenia według istotności, usługi, właściciela ryzyka i terminu realizacji. Zidentyfikuj zaległe działania naprawcze, zaakceptowane ryzyka i luki w ponownych testach. Przygotuj pulpit dla organu zarządzającego pokazujący pokrycie testami, istotne ustalenia, zaległe działania, kwestie stron trzecich i ryzyko szczątkowe.

Wynik: pulpit testów DORA i ISO gotowy dla zarządu.

Typowe pułapki programu testowania DORA

Najczęstszą przyczyną niepowodzenia nie jest brak testów. Jest nią brak ładu.

Zwróć uwagę na następujące problemy:

• Testy penetracyjne wykonywane corocznie, ale ustalenia nie są śledzone do zamknięcia
• Skany podatności uruchamiane często, ale w zakresie brakuje aktywów krytycznych
• Ćwiczenia sztabowe są przeprowadzane, ale nie ma rejestru decyzji ani planu działań z wniosków z doświadczeń
• Testy odtworzenia kopii zapasowych są zakończone, ale nie są zmapowane na RTO i RPO
• Testy obciążeniowe prowadzi zespół inżynieryjny, ale wyniki nie są raportowane do funkcji ryzyka ani zgodności
• Dostawcy usług ICT są wyłączeni z testów scenariuszowych i odtworzeniowych
• Dowody są przechowywane w folderach osobistych, wątkach czatu lub niezarządzanych dyskach
• Raporty zarządcze koncentrują się na liczbie działań, a nie na nierozwiązanym ryzyku odporności
• SoA wskazuje, że kontrola ma zastosowanie, ale nie istnieją dowody z testów
• Testowanie tworzy ryzyko produkcyjne, ponieważ autoryzacja i granice są niejasne

Każdą lukę można usunąć. Rozwiązaniem nie jest więcej przypadkowych testów. Rozwiązaniem jest jeden kontrolowany program, który łączy ryzyko, działania testowe, działania naprawcze, dowody i nadzór kierownictwa.

Co zarząd powinien rzeczywiście zobaczyć

DORA czyni odporność ICT odpowiedzialnością organu zarządzającego. Użyteczny raport dla zarządu nie powinien zawierać każdego technicznego ustalenia. Powinien odpowiadać na pytanie, czy organizacja jest wystarczająco odporna w odniesieniu do swojego apetytu na ryzyko i tolerancji zakłóceń.

Silny raport kwartalny lub półroczny obejmuje:

• Pokrycie testami krytycznych lub istotnych funkcji
• Testy zakończone w porównaniu z planowanymi
• Ustalenia krytyczne i wysokie według usługi
• Zaległe działania naprawcze według właściciela
• Wskaźnik pozytywnych wyników ponownych testów
• Ustalenia związane z dostawcami i obawy dotyczące koncentracji
• Wnioski z testów scenariuszowych wpływające na plany kryzysowe lub incydentowe
• Ryzyka pojemności wobec wzrostu biznesu i okresów szczytowych
• Ryzyka szczątkowe wymagające akceptacji kierownictwa
• Ograniczenia budżetowe, zasobowe lub narzędziowe

Taki raport staje się danymi wejściowymi do przeglądu zarządzania ISO, dowodem ładu DORA i praktycznym narzędziem decyzyjnym.

Od rozproszonych testów do strategicznej odporności

Pierwotnym problemem CISO nie był brak testowania. Organizacja miała skany, ćwiczenia sztabowe, raporty obciążeniowe i pliki PDF z testów penetracyjnych. Problem polegał na tym, że działania te nie tworzyły jeszcze jednej spójnej historii dowodowej.

Zunifikowany program testowania DORA i ISO/IEC 27001:2022 to zmienia. Ocena ryzyka napędza katalog. Katalog napędza autoryzowane testowanie. Testowanie generuje ustalenia. Ustalenia napędzają działania naprawcze i ponowne testy. Wyniki zasilają raportowanie zarządcze. Wnioski z doświadczeń aktualizują polityki, procedury, umowy i kontrole.

W ten sposób obciążenie zgodności staje się zdolnością strategiczną.

Clarysec pomaga organizacjom unikać równoległych programów zgodności. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 i COBIT 2019 nie potrzebują odrębnych wszechświatów dowodowych. Potrzebują jednego zarządzanego modelu operacyjnego, który można przedstawić przez różne perspektywy audytowe.

Nasze podejście łączy:

• Zenith Blueprint do etapowego wdrożenia ISO i gotowości do audytu
• Zenith Controls do mapowania zgodności wieloregulacyjnej w obszarze kontroli, frameworków i oczekiwań audytowych
• Polityki dla przedsiębiorstw i MŚP dotyczące testów bezpieczeństwa, monitorowania audytu, zarządzania podatnościami, bezpieczeństwa aplikacji, ciągłości i bezpieczeństwa informacji
• Praktyczne rejestry, struktury dowodowe i szablony raportowania zarządczego

Jeżeli Twoje dowody testowe DORA na 2026 r. są rozproszone między narzędziami skanującymi, folderami zespołu inżynieryjnego, notatkami z ćwiczeń sztabowych i plikami PDF z testów penetracyjnych, teraz jest czas, aby je skonsolidować.

Zacznij od jednego rocznego katalogu testów zmapowanego na postępowanie z ryzykiem ISO/IEC 27001:2022, Twoją SoA, krytyczne lub istotne funkcje, zewnętrznych dostawców usług ICT i raportowanie zarządcze. Następnie wykorzystaj Zenith Blueprint, Zenith Controls i zestaw narzędzi polityk Clarysec, aby przekształcić ten katalog w możliwy do obrony dowód audytowy.

Clarysec może pomóc zaprojektować program, zmapować kontrole, ustrukturyzować pakiet dowodowy i przygotować raport odporności na poziomie zarządu, zanim nadejdzie kolejne żądanie nadzorcze.