
Termin na wdrożenie unijnego rozporządzenia DORA (Digital Operational Resilience Act) minął w styczniu 2025 roku. Dziś, w 2026 roku, organy nadzoru nie pytają już o plany wdrożeniowe. Pytają o dowody. Kontrole skupiają się na twardej weryfikacji tego, czy instytucje finansowe oraz wspierający ich dostawcy ICT (Information and Communication Technology) potrafią utrzymać ciągłość działania w obliczu realnych cyberataków.
Zgodność na papierze to przeszłość. Jeśli Twoja organizacja mierzy się obecnie z widmem weryfikacji przez regulatora, ten artykuł pomoże Ci zmapować braki. Przygotowaliśmy kompleksową checklistę DORA, która weryfikuje odporność operacyjną Twojej infrastruktury krok po kroku.
Dlaczego w 2026 roku DORA to już nie tylko teoria?
DORA zmieniła ramy współpracy na linii sektor finansowy – dostawcy IT. Banki, ubezpieczyciele czy fundusze inwestycyjne nie mogą już przenieść odpowiedzialności za cyberbezpieczeństwo na zewnętrzny software house czy dostawcę chmury. Wymagają oni od swoich partnerów żelaznych gwarancji, nierzadko narzucając konieczność zrealizowania audytu DORA, aby wykazać zgodność całego łańcucha dostaw.
Jeśli jesteś dostawcą ICT i nie potrafisz udowodnić swojej odporności operacyjnej, ryzykujesz wypadnięcie z łańcucha dostaw lukratywnego sektora finansowego.
Checklista DORA 2026 – 5 filarów, o które zapyta audytor
Rozporządzenie DORA opiera się na pięciu głównych filarach. Poniższa checklista pomoże Ci upewnić się, że Twój „Evidence Pack” (pakiet dowodów) dla audytora jest kompletny.
1. Zarządzanie ryzykiem ICT (ICT Risk Management)
Audytor nie zapyta, czy masz politykę bezpieczeństwa. Zapyta, jak ona działa w praktyce i czy obejmuje całe środowisko informatyczne.
- Mapowanie zasobów: Czy posiadasz aktualną inwentaryzację wszystkich systemów informatycznych, ról i krytycznych aktywów informacyjnych?
- Analiza ryzyka: Czy regularnie aktualizujesz mapę ryzyk dla środowiska IT i chmurowego?
- Procedury ciągłości działania (BCP/DRP): Czy zdefiniowano parametry RTO (Recovery Time Objective) i RPO (Recovery Point Objective) dla procesów krytycznych?
- Backupy: Czy potrafisz przedstawić audytorowi logi z udanych testów odtwarzania danych (test restore)?
2. Raportowanie incydentów (Incident Reporting)
Rozporządzenie narzuca rygorystyczne ramy czasowe na zgłaszanie poważnych incydentów.
- Klasyfikacja: Czy wdrożyłeś mechanizm odróżniania incydentów krytycznych od standardowych awarii?
- Czas reakcji: Czy jesteś w stanie wysłać wstępne powiadomienie do organu nadzoru w ciągu 24 godzin od wykrycia zdarzenia?
- Ciągły monitoring: Czy dysponujesz scentralizowanym narzędziem do zarządzania alertami, np. zlecając logi do dedykowanego Security Operations Center (SOC)?
3. Testowanie odporności operacyjnej (Resilience Testing)
Skanowanie podatności to dziś za mało. DORA wymaga regularnych i zaawansowanych testów zabezpieczeń.
- Testy penetracyjne: Czy przeprowadzasz je regularnie dla wszystkich krytycznych systemów i aplikacji?
- TLPT (Threat-Led Penetration Testing): W przypadku największych podmiotów, czy realizowane są zaawansowane testy oparte na analizie rzeczywistych zagrożeń (tzw. Red Teaming)?
- Zarządzanie podatnościami: Czy istnieje ustrukturyzowany proces patchowania i izolacji systemów wycofanych z użycia (End-of-Life)?
4. Zarządzanie ryzykiem dostawców zewnętrznych (TPRM)
To najczęstszy powód oblewania audytów DORA. Instytucja finansowa musi kontrolować podmioty, z którymi współpracuje.
- Rejestr dostawców: Czy posiadasz pełny wykaz umów z dostawcami usług ICT?
- Prawo do audytu: Czy w renegocjowanych kontraktach z dostawcami zawarto klauzule pozwalające na audytowanie ich środowisk (Right to Audit)?
- Strategia wyjścia (Exit Strategy): Czy wiesz, jak w rozsądnym czasie zmigrować kluczowe usługi od obecnego dostawcy (np. chmury obliczeniowej) do alternatywnego, bez zatrzymywania biznesu?
5. Udostępnianie informacji o zagrożeniach (Information Sharing)
- Współpraca sektorowa: Czy Twoja organizacja bierze udział w inicjatywach zrzeszających ekspertów w celu wymiany wskaźników kompromitacji (IoC) i taktyk atakujących?
DORA a NIS2 – gdzie przecinają się kompetencje?
Obecnie wiele organizacji zastanawia się, której dyrektywie podlegają, i jak połączyć procesy utrzymania zgodności (tzw. Compliance). Podczas gdy DORA to tzw. lex specialis (prawo nadrzędne dla sektora finansowego), o tyle NIS2 ma szerszy zasięg. Obie regulacje posiadają jednak mocne punkty styku.
| Obszar | DORA (Sektor Finansowy i ICT) | NIS2 (Sektory Kluczowe i Ważne) |
| Główny cel | Cyfrowa odporność operacyjna i ciągłość działania usług finansowych. | Podniesienie ogólnego poziomu cyberbezpieczeństwa w UE. |
| Podejście do dostawców | Wymaga rygorystycznego zarządzania ryzykiem zewnętrznych dostawców ICT i rejestrów (TPRM). | Kładzie duży nacisk na bezpieczeństwo całego łańcucha dostaw. |
| Raportowanie incydentów | Raporty wstępne, okresowe i końcowe o bardzo wysokim priorytecie. | Wczesne ostrzeżenie (24h), zgłoszenie (72h), raport końcowy. |
Zarówno audyt NIS2, jak i weryfikacja pod kątem DORA wymagają solidnych fundamentów technologicznych. Jeśli mądrze zaplanujesz architekturę, wiele procedur (np. zarządzanie logami i tożsamością) spełni wymogi obu dyrektyw jednocześnie. Przeczytaj więcej, jak zaplanować wdrożenie dyrektywy NIS2 w zaledwie 90 dni.
Kto ma to wszystko spiąć? Rola vCISO w procesie zgodności
Spełnienie wymogów DORA i NIS2 to projekt o skali architektonicznej i organizacyjnej. Rekrutacja in-house doświadczonego Dyrektora ds. Cyberbezpieczeństwa (CISO) na obecnym, wysoce konkurencyjnym rynku pracy to ogromny koszt i wielomiesięczny proces.
Optymalnym kosztowo i procesowo rozwiązaniem dla firm w 2026 roku staje się wynajęcie eksperta z zewnątrz. Usługa vCISO (Virtual Chief Information Security Officer) zapewnia organizacji dostęp do specjalisty (lub całego zespołu), który:
-
Przekłada wymogi prawne i język audytorów na backlog zadań dla działów IT i DevOps.
-
Zarządza politykami dostępu, kopiami zapasowymi i systemami ochrony przed atakami na łańcuch dostaw.
-
Przejmuje odpowiedzialność za raportowanie do zarządu i nadzór nad procedurami.
Bez kompetentnego „lidera projektu”, wdrożenie DORA często kończy się chaosem procesowym i zakupem drogich, niekompatybilnych ze sobą narzędzi w panice przed audytem.
Chcesz mieć pewność, że Twoje systemy zdadzą egzamin przed weryfikatorami i nie wypadniesz z łańcucha dostaw swoich kluczowych klientów? Chętnie pomogę Ci ustalić priorytety działań — czy chciałbyś, abym opisał, jak krok po kroku wygląda nasz proces przygotowania do kompleksowego audytu DORA lub NIS2? Wystarczy, że się z nami skontaktujesz.

Jestem administratorem systemów i specjalistą ds. cyberbezpieczeństwa z ponad 10-letnim doświadczeniem w zarządzaniu infrastrukturą IT, serwerami Linux, usługami cloud oraz ochroną systemów produkcyjnych.
Na co dzień w ZdalnyAdmin.com.pl zajmuję się audytami bezpieczeństwa, testami penetracyjnymi, wdrożeniami SOC, hardeningiem serwerów oraz reagowaniem na incydenty bezpieczeństwa.
Pracowałem z infrastrukturą obsługującą sklepy e-commerce, systemy finansowe, aplikacje SaaS oraz środowiska o podwyższonych wymaganiach dostępności i bezpieczeństwa.
W swoich publikacjach dzielę się praktycznym doświadczeniem z zakresu cyberbezpieczeństwa, DevOps i administracji systemami — bez marketingowych uproszczeń, za to z naciskiem na realne scenariusze i obowiązujące regulacje (NIS2, DORA, ISO 27001).