Czym jest DORA i dlaczego dotyczy firm technologicznych spoza finansów
Digital Operational Resilience Act obowiązuje od 17 stycznia 2025 roku. Pierwsze skojarzenie: banki, ubezpieczyciele, instytucje finansowe. To prawda — ale niepełna.
Art. 28-44 DORA nakłada na podmioty finansowe obowiązek zarządzania ryzykiem dostawców ICT. Jeśli Twoja organizacja dostarcza oprogramowanie lub usługi technologiczne do banku, fintecha, instytucji płatniczej lub ubezpieczyciela — jesteś w łańcuchu dostaw objętym regulacją. Instytucja finansowa ma ustawowy obowiązek ocenić Twoje kontrole bezpieczeństwa i udokumentować wyniki tej oceny.
W praktyce: rośnie liczba kwestionariuszy bezpieczeństwa od klientów finansowych, rośnie poziom szczegółowości pytań, pojawiają się żądania dokumentacji technicznej której wcześniej nikt nie wymagał. Nie dlatego że klient nagle stał się bardziej dociekliwy — dlatego że regulacja zobowiązuje go do zadania tych pytań.
Co DORA wymaga — i czego audytor szuka w praktyce
Art. 9 DORA wymaga wdrożenia kontroli bezpieczeństwa systemów ICT: kontroli dostępu opartej na minimalnych uprawnieniach, zarządzania tożsamościami cyfrowymi, ochrony integralności zmian wdrożeniowych. Językiem regulacji “systemy ICT” obejmują narzędzia używane w działalności — w tym systemy CI/CD.
Art. 10 wymaga mechanizmów wykrywania anomalnych aktywności: nieautoryzowanych uruchomień, modyfikacji konfiguracji, eksfiltracji danych przez złośliwy kod w workflow.
To co jest w tekście regulacji, a to czego szuka audytor — to nie to samo. Regulacja nie specyfikuje narzędzi. Audytor nie pyta “czy macie politykę”. Pyta: pokażcie logi, pokażcie konfigurację, pokażcie że to faktycznie działa. Brak dokumentacji technicznej jest traktowany jak brak kontroli — nawet jeśli kontrola faktycznie istnieje i działa.
Pułapka organizacji które “są bezpieczne” ale nie mają dowodów
DORA jest regulacją opartą na zasadzie rozliczalności. Nie wystarczy że pipeline jest zabezpieczony. Nie wystarczy że ktoś wie że jest zabezpieczony. Trzeba móc to udowodnić — w formie artefaktów które audytor może zweryfikować niezależnie.
Organizacje które wdrożyły kontrole bez dokumentowania ich działania odkrywają to podczas pierwszego audytu klienta finansowego: godziny spędzone na zbieraniu logów, eksportowaniu konfiguracji, tłumaczeniu jak działa pipeline — ad hoc, pod presją czasu odpowiedzi. Wynik jest zazwyczaj niespójny, bo dokumentacja tworzona post-factum nigdy nie jest tak kompletna jak dokumentacja generowana automatycznie przy każdym uruchomieniu.
Incydent bezpieczeństwa bez udokumentowanych mechanizmów kontrolnych jest znacznie trudniejszy do obrony przed regulatorem i klientem niż incydent w organizacji z kompletnymi dowodami. To asymetria której nie da się wyeliminować po fakcie.
Co konkretnie powinny produkować systemy wytwórcze
Na poziomie pipeline’u DORA przekłada się na kilka konkretnych kategorii dowodów których oczekują audytorzy:
Integralność artefaktów: dowód że to co wylądowało na produkcji to dokładnie to co zbudował pipeline — niemodyfikowane między buildem a deploymentem. Kryptograficzne podpisywanie artefaktów i weryfikacja podpisów przed deploymentem.
Ślad dostępu i zmian: kto uruchomił workflow, kiedy, z jakim triggerem, jakie zmiany weszły. Traceability od commita do deploymentu, z zachowanymi logami przez wymagany okres retencji.
Zarządzanie poświadczeniami: brak statycznych sekretów w konfiguracji CI/CD — czyli OIDC zamiast kluczy AWS/Azure przechowywanych jako zmienne środowiskowe.
Wyniki skanowania: udokumentowane wyniki analizy zależności, skanowania obrazów, testów bezpieczeństwa — nie jako jednorazowe raporty, ale jako artefakty generowane przy każdym deployu.
To nie jest lista kontrolna do odhaczenia. To opis tego czego wymaga audytor który przychodzi z mandatem DORA i prosi o “pokaz mi jak to działa”.
Harmonogram i skala ryzyka
DORA jest w pełni obowiązującym prawem od stycznia 2025. KNF ma uprawnienia do nakładania sankcji — dla podmiotów finansowych kary mogą sięgać 1% dziennego globalnego obrotu. Dla dostawców ICT przewidziane są osobne mechanizmy nadzorcze przy kolejnych nowelizacjach.
Ale dla firmy technologicznej sprzedającej do finansów ryzyko jest inne: nie sankcje bezpośrednie, tylko utrata kontraktu. Instytucja finansowa która nie może udokumentować że zweryfikowała swojego dostawcę ICT — sama narusza wymogi DORA. Żaden compliance officer dużego banku nie zaakceptuje dostawcy który nie jest w stanie odpowiedzieć na pytania audytowe.
CI/CD Hardening Sprint dostarcza pipeline z automatycznym generowaniem Evidence Pack przy każdym deployu — gotowy do odpowiedzi na audyt DORA zanim pytanie padnie.
Czytaj również: