W firmach z sektora finansowego temat DORA pojawia się zwykle w jednym z dwóch momentów: albo zarząd dostaje pytanie od nadzoru czy audytora, albo ktoś w organizacji zauważa, że rozporządzenie już obowiązuje i trzeba sprawdzić, na jakim etapie jest firma. Rzadko ktokolwiek zaczyna od pełnej gotowości.
Problem w tym, że DORA nie jest jednym, wąskim tematem. Dotyka zarządzania ryzykiem ICT, umów z dostawcami technologii, testowania odporności operacyjnej, zgłaszania incydentów i nadzoru nad podmiotami trzecimi. To sprawia, że pierwsza rozmowa z wykonawcą bywa trudna, jeśli firma nie ma jeszcze uporządkowanego obrazu własnej sytuacji.
Dobrym punktem odniesienia może być najpierw wybór właściwej ścieżki DORA, a dopiero później rozmowa o konkretnym zakresie.
Dlaczego DORA trudniej opisać niż inne tematy compliance
Wiele firm ma już doświadczenie z RODO albo audytami bezpieczeństwa i próbuje przenieść ten sam sposób myślenia na DORA. To częściowo działa, ale DORA ma jedną istotną różnicę: mocno koncentruje się na relacji z dostawcami usług ICT, a nie tylko na wewnętrznych procesach firmy.
Oznacza to, że firma musi umieć opisać nie tylko siebie, ale też swoje otoczenie dostawcze: kto hostuje systemy, kto obsługuje krytyczne aplikacje, jakie umowy już istnieją i czy zawierają elementy wymagane przez rozporządzenie. To inny punkt startowy niż w większości rozmów o zgodności.
Kliknij grafikę, aby otworzyć ją w pełnym rozmiarze. Mapa pokazuje główne obszary, które warto uporządkować przed pierwszą rozmową o DORA: status podmiotu, dostawców ICT, ryzyko, incydenty i testowanie odporności.
Co warto ustalić przed rozmową
Zanim firma wyśle zapytanie, pomaga rozdzielić temat na kilka niezależnych obszarów. Nie trzeba mieć gotowych odpowiedzi na wszystko — ważne jest wiedzieć, które informacje są dostępne, a które trzeba dopiero zebrać.
| Obszar | Co warto ustalić | Dlaczego to pomaga |
|---|---|---|
| Status podmiotu | Czy firma jest podmiotem finansowym objętym DORA, a jeśli działa jako dostawca ICT — czy rozmowa wynika z wymagań klientów z sektora finansowego | Determinuje zakres obowiązków i typ rozmowy |
| Skala organizacji | Wielkość firmy, liczba systemów krytycznych, struktura grupy | Wpływa na proporcjonalność wymagań |
| Dostawcy ICT | Lista dostawców obsługujących kluczowe systemy, w tym chmurowych | Umowy z dostawcami to jeden z głównych obszarów DORA |
| Zarządzanie ryzykiem | Czy istnieje udokumentowany proces zarządzania ryzykiem ICT | Pokazuje punkt startowy: budowa od zera czy aktualizacja |
| Incydenty | Czy firma ma procedurę zgłaszania incydentów ICT | Pomaga ustalić, czy obecny sposób reagowania na incydenty wymaga dalszego uporządkowania |
| Testowanie odporności | Czy prowadzono wcześniej testy ciągłości działania lub bezpieczeństwa | Wpływa na zakres dalszych prac |
| Termin | Czy presja wynika z nadzoru, audytu, czy wewnętrznej decyzji | Pomaga ustalić priorytety pierwszej rozmowy |
Ta lista nie zastępuje analizy prawnej ani technicznej. Ma pomóc uniknąć sytuacji, w której pierwsza rozmowa z wykonawcą zaczyna się od pytań, na które firma mogła odpowiedzieć wcześniej we własnym zakresie.
Dostawcy ICT to osobny temat, nie dodatek
Częstym błędem jest traktowanie dostawców jako mało istotnego elementu zapytania. W praktyce to jeden z centralnych tematów DORA. Rozporządzenie kładzie duży nacisk na to, jak firma zarządza relacją z dostawcami usług ICT, szczególnie tymi obsługującymi funkcje krytyczne.
Przed rozmową warto więc mieć choćby wstępną listę: kto hostuje systemy, kto zapewnia oprogramowanie kluczowe dla działalności, czy są to dostawcy jednorazowi czy stali partnerzy, i czy obecne umowy odnoszą się do kwestii bezpieczeństwa, ciągłości działania albo audytu.
Firma, która nie ma takiej listy, nie musi jej tworzyć w pełni przed pierwszym kontaktem. Wystarczy zaznaczyć, że ten obszar jest jeszcze nierozpoznany — to też jest konkretna informacja dla wykonawcy.
Kiedy zacząć od audytu, a kiedy od wyceny
Jeżeli firma nie ma jeszcze pewności, czy i w jakim zakresie DORA jej dotyczy, albo nie wie, jak wygląda jej obecny poziom zarządzania ryzykiem ICT, naturalnym punktem wyjścia jest audyt gotowości DORA. Taka diagnoza pozwala rozdzielić obszary już uporządkowane od tych, które wymagają pracy.
Jeżeli natomiast firma zna swój status, ma rozeznanie w obszarach wymagających zmian i chce ustalić zakres prac, harmonogram oraz orientacyjne warunki, bliżej jej do rozmowy o wycenie wdrożenia DORA.
Skala projektu DORA rzadko wynika z samej wielkości firmy. Częściej decyduje o niej liczba dostawców krytycznych i to, jak daleko firma jest od udokumentowanego zarządzania ryzykiem ICT.
Krótka checklista przed wysłaniem zapytania
- Czy wiadomo, czy firma jest bezpośrednio objęta DORA, czy działa jako dostawca dla podmiotów objętych rozporządzeniem?
- Czy istnieje lista dostawców ICT obsługujących systemy krytyczne?
- Czy firma ma udokumentowany proces zarządzania ryzykiem ICT?
- Czy istnieje procedura zgłaszania incydentów, czy trzeba ją dopiero zbudować?
- Czy prowadzono wcześniej testy odporności operacyjnej lub bezpieczeństwa?
- Czy presja czasu wynika z nadzoru, audytu zewnętrznego, czy wewnętrznej decyzji zarządu?
- Kto w firmie koordynuje temat i ma dostęp do informacji z IT, compliance i działu prawnego?
Najczęstsze błędy na starcie
Pierwszy błąd to zapytanie skupione wyłącznie na systemach IT, bez wspomnienia o dostawcach i umowach. DORA w dużej mierze dotyczy właśnie relacji z podmiotami trzecimi, więc pominięcie tego wątku prowadzi do zbyt wąskiej odpowiedzi wykonawcy.
Drugi błąd to brak rozróżnienia między rolą podmiotu finansowego a rolą dostawcy usług ICT. To dwie różne perspektywy, z których każda wymaga innego zakresu rozmowy.
Trzeci błąd to traktowanie DORA jako czysto technicznego tematu IT, bez udziału osób odpowiedzialnych za umowy, zakupy i zarządzanie ryzykiem. W praktyce potrzebne informacje pochodzą zwykle z kilku działów jednocześnie.
Przykład słabego i lepszego zapytania
Słabe zapytanie:
Musimy wdrożyć DORA. Proszę o wycenę.
Lepsze zapytanie:
Jesteśmy instytucją finansową korzystającą z kilku dostawców chmurowych do systemów krytycznych. Mamy podstawowe procedury bezpieczeństwa, ale nie mamy udokumentowanego zarządzania ryzykiem ICT ani jasnej procedury zgłaszania incydentów. Chcemy najpierw ustalić, jak daleko jesteśmy od gotowości i co powinno być priorytetem.
Drugie zapytanie nie rozstrzyga jeszcze zakresu prac, ale pokazuje kontekst dostawcowy, obecny stan procesów i główny cel rozmowy. To wystarczy, żeby wykonawca mógł zadać właściwe pytania od razu, zamiast zaczynać od podstaw.
Podsumowanie
Rozmowa o DORA przebiega sprawniej, gdy firma potrafi opisać nie tylko siebie, ale też swoje otoczenie dostawcze: kto obsługuje systemy krytyczne, jakie umowy już istnieją i na jakim etapie jest zarządzanie ryzykiem ICT.
Nie trzeba mieć gotowych odpowiedzi na każdy punkt przed pierwszym kontaktem. Ważniejsze jest rozpoznanie, które obszary są już uporządkowane, a które dopiero wymagają pracy — i czy naturalnym pierwszym krokiem jest diagnoza obecnego stanu, czy rozmowa o zakresie i warunkach wdrożenia.