Wdrożenie DORA – zgodność ICT

Przygotowujemy instytucje finansowe i ich dostawców (SaaS, software house, cloud) do spełnienia wymagań rozporządzenia DORA. Sprawdzimy i ocenimy luki, wdrożymy kluczowe polityki i procesy (ryzyko ICT, incydenty, testy odporności, ciągłość działania, dostawcy) oraz uporządkujemy infrastrukturę: monitoring 24/7, backupy, HA i komplet dokumentów dla audytu.

Rozporządzenie DORA - jak wdrażamy zgodność

Od oceny luk do gotowości na audyt!

Na starcie robimy zwięzły gap assessment pod DORA: oceniamy dojrzałość w obszarach ryzyka ICT, zarządzania incydentami, ciągłości działania (BCM/DRP), testów odporności oraz zarządzania dostawcami. Wyniki zamieniamy w klarowną roadmapę z priorytetami, właścicielami i metrykami.

Następnie wdrażamy polityki i procedury, porządkujemy technikę: monitoring 24/7 i alerty, kopie zapasowe z testami odtworzeń, HA/geo-redundancję, rejestry (ryzyk, incydentów, zmian), runbooki i playbooki. Przygotowujemy szablony raportów DORA (4h/24h/72h/1 mies.), wymagane zapisy w SLA/umowach z dostawcami i plan wyjścia (exit).

Audyt

Identyfikujemy luki DORA oraz ryzyka w procesach i infrastrukturze ICT.

Projektowanie

Tworzymy polityki, procedury, rejestry i roadmapę realizacji z KPI.

Wdrożenie planu

Wdrażamy procesy i narzędzia (ryzyko, incydenty, BCM/DRP, monitoring 24/7, backupy, HA) oraz kompletujemy dowody dla audytu.

Symulacje incydentów

Ćwiczymy scenariusze, testujemy odporność (tabletop/TLPT) i utrwalamy raportowanie wymagane przez DORA.

Od czego zacząć wdrożenie DORA?

Audyt DORA (gap assessment)

Kompleksowy przegląd procesów i ICT z mapą luk, priorytetami i klarowną roadmapą

Audyt DORA (gap assessment) to uporządkowany przegląd Twoich procesów i infrastruktury względem pięciu filarów DORA. Pracujemy na dokumentach i konfiguracjach, rozmawiamy z zespołem, sprawdzamy architekturę, logi, RTO/RPO i progi alertów.

 

Obejmujemy m.in. ryzyko i incydenty, ciągłość działania (BCM/DRP), monitoring 24/7, backup/HA, tożsamości i dostępy (IAM), podatności/patching, rejestry oraz współpracę z dostawcami.

 

Wynikiem jest mapa luk z oceną wpływu, podział na quick wins i projekty, oraz roadmapa z właścicielami i KPI + lista brakujących polityk/procedur/rejestrów (evidence pack). Dzięki temu wiesz, co zrobić najpierw i dlaczego.

Polityki, procedury i rejestry DORA

Gotowe, dopasowane szablony: ryzyko ICT, incydenty, BCM/DRP, testy odporności, rejestry i evidence pack

  • Polityki i standardy – zarządzanie ryzykiem ICT, incydentami, ciągłością działania (BCM/DRP), testami odporności, bezpieczeństwem dostawców i umów.
  • Procedury operacyjne (SOP + runbooki) – detekcja/triage/klasyfikacja incydentów, raportowanie 4h/24h/72h/1 mies., CAB/zmiany, testy odtworzeń, patch management, komunikacja kryzysowa.
  • Rejestry wymagane przez DORA – ryzyk, incydentów, zasobów, zmian, dostępów (IAM), podatności, dostawców/umów, wyjątków akceptacyjnych.
  • Załączniki i formularze – matryca RACI, kryteria istotności, KPI/KRI, wzory raportów (KNF/ESAs), checklisty audytowe, klauzule do SLA (RTO/RPO, exit plan, prawo audytu).
  • Formaty i integracja – Word/Google Docs, Confluence, Jira/Service Desk; wersjonowanie w Git i czytelne mapowanie do istniejących narzędzi.

Efektektem musi być spójny, praktyczny zestaw dokumentów i artefaktów, na których realnie pracuje zespół – a nie tylko „papier pod audyt”.

Wdrożenie techniczne pod DORA

Monitoring 24/7 i alerty, backupy z testami odtworzeń, HA/hardening, centralne logi/SIEM oraz runbooki operacyjne

Wdrożenie techniczne pod DORA to przełożenie wymagań regulacji na konkretne kontrole w Twojej infrastrukturze – tak, żeby dało się tym zarządzać, mierzyć i audytować. Na rynku panuje ogromny chaos. Wiele firm doradczych i kancelarii prawnych sprzedaje pakiety dokumentów DORA za dziesiątki tysięcy złotych, obiecując pełną zgodność. Problem pojawia się w momencie pierwszej weryfikacji technicznej lub zapytania od instytucji finansowej.

 

  • Monitoring 24/7 i alerty – metryki, logi i testy syntetyczne, progi Critical/High/Warning/Info, eskalacje on-call i playbooki reakcji.
  • Backupy z testami odtworzeń – zasada 3-2-1, szyfrowanie, kopie niezmienialne (WORM), cykliczne restore-drille pod zdefiniowane RTO/RPO. Kopie są odporne na ransomware oraz próby celowego usunięcia danych przez osoby z uprawnieniami administratora.
  • HA / DR – klastrowanie i automatyczne przełączenia, segmentacja, runbooki awaryjne i regularne próby failover. Projektujemy i utrzymujemy środowiska High Availability odporne na całkowity paraliż pojedynczego centrum danych.
  • Hardening i dostępy – baseline (np. CIS), MFA/PAM, rotacja sekretów, okna patchowania i skan podatności z remediacją.
  • Centralne logi / SIEM – jednolite zasilanie logów, korelacje detekcji, retencja zgodna z polityką i gotowe raporty dla audytu.
  • Runbooki operacyjne – krok-po-kroku dla incydentów i zmian, powiązane z klasyfikacją zdarzeń oraz wzorami raportów 4h/24h/72h/1 mies.

Incydenty i raportowanie (KNF/ESAs)

Proces 4h/24h/72h/1 mies., progi istotności, formularze i automatyzacje - wraz z gotowymi wzorami komunikatów.

  1. Co raportujemy?
    Zdarzenia spełniające progi istotności (wpływ na klientów/usługi, czas niedostępności, utrata danych, rozprzestrzenienie, łańcuch dostaw).
  2. Jak decydujemy?
    Matryca kryteriów + checklista „report/no-report”, właściciel decyzji i ślad akceptacji.
  3. Jak zgłaszamy?
    Gotowe formularze i kanały do właściwego nadzoru (KNF/ESAs), numer referencyjny, rejestr incydentów.
  4. Co automatyzujemy?
    Z SIEM/monitoringu tworzony jest draft zgłoszenia w ITSM (pola, timestampy, metryki wpływu), wersjonowanie w Confluence/Git.
  5. Jak komunikujemy?
    Szablony komunikatów do klientów/partnerów, Q&A dla PR, integracja ze status page i planem komunikacji kryzysowej.
  6. Jak domykamy?
    Raport końcowy z RCA, działania korygujące, aktualizacja runbooków i KPI/KRI.

Zarządzanie dostawcami ICT i exit plan

Due diligence, klauzule DORA w SLA, ciągłe monitorowanie ryzyka oraz praktyczny plan wyjścia z usług

Co robimy:

  • Due diligence (przed startem): szybka ocena dostawcy, checklista zgodności DORA/NIS2, weryfikacja certyfikatów, łańcucha poddostawców i przepływów danych.
  • Nadzór (w trakcie współpracy): KPI/KRI, progi incydentów i ścieżki eskalacji, rejestr ryzyk dostawców, cykliczne przeglądy i aktualny evidence pack.
  • Klauzule w SLA (esencja): RTO/RPO i dostępność, prawo audytu, notyfikacja zmian poddostawców, lokalizacja/przenoszalność danych, zasady raportowania incydentów. Tworzymy także kompletną ewidencję dostawców i łańcucha podwykonawców zgodnie z art. 28 rozporządzenia DORA, przygotowaną do corocznego raportowania do KNF.
  • Exit plan (bez przestojów): projektujemy i dokumentujemy scenariusze migracji danych oraz zmiany dostawców chmurowych bez paraliżu bieżących operacji biznesowych.

 

Efektem jest pełna kontrola ryzyka w łańcuchu dostaw i przewidywalna zmiana usługodawcy.

DORA dla zewnętrznych dostawców usług ICT

Jak spełnić wymogi banków i obronić kontrakty

Rozporządzenie DORA nakłada na banki, instytucje płatnicze i ubezpieczycieli obowiązek rygorystycznego nadzoru nad łańcuchem podwykonawców (Third-Party Risk Management). Jeśli dostarczasz do sektora finansowego oprogramowanie SaaS, platformę transakcyjną, CRM, hosting lub usługi programistyczne, Twój klient zażąda od Ciebie twardych dowodów na spełnianie wymogów DORA.

 

Brak udokumentowanej odporności cyfrowej oznacza zablokowanie płatności lub natychmiastowe zerwanie kontraktu.

 

Punkty wsparcia dla dostawców ICT:

 

  • Wsparcie w wypełnianiu kwestionariuszy bankowych. Pomagamy przejść przez rozbudowane formularze compliance (często liczące po 150–200 pytań), które przysyłają działy bezpieczeństwa instytucji finansowych.
  • Wdrożenie klauzul DORA do umów i SLA. Precyzujemy wskaźniki RTO i RPO, zasady prawa do audytu ze strony banku i KNF, powiadamianie o zmianie podwykonawców oraz scenariusz bezpiecznego wyjścia z usług (exit plan).
  • Kompletny evidence pack dla audytora. Przygotowujemy gotowy zestaw zrzutów konfiguracji, raportów z testów podatności i logów, który możesz od ręki przedstawić instytucji finansowej jako dowód zgodności.

Dlaczego DORA z inżynierami infrastruktury, a nie samą kancelarią prawną?

Procesy, infrastruktura i evidence pack, które przejdą audyt i wytrzymają incydent

Wspieramy instytucje finansowe i ich dostawców w praktycznym wdrożeniu DORA. Łączymy warstwę proceduralną (Compliance Manager) z techniczną (inżynierowie): monitoring 24/7, backupy z testami odtworzeń, HA/DR i twarde runbooki. Porządkujemy rejestry, mapujemy wymagania do RTS/ITS, automatyzujemy raportowanie (4h/24h/72h/1 mies.) i przygotowujemy pełny evidence pack. Działamy w private i public cloud, blisko zespołów bezpieczeństwa i software house’ów.

Evidence pack gotowy na audyt

Monitoring 24/7

Backupy z testami odtworzeń

Raportowanie do KNF/ESAs

HA/DR i hardening

SLA & dostawcy

FAQ

Co zrobić, jeśli kupiliśmy już pakiet dokumentacji DORA od kancelarii, ale nadal nie mamy wdrożenia technicznego?

To częsty przypadek. Zgłaszają się do nas firmy, które posiadają kompletne polityki w plikach tekstowych, ale ich infrastruktura nie spełnia podstawowych wymogów audytora (brak centralizacji logów, brak testów odtworzeniowych, brak monitoringu 24/7). W takim scenariuszu nie zaczynamy od zera. Przeglądamy stworzone dokumenty, wyłapujemy luki i konfigurujemy systemy, serwery oraz narzędzia monitoringowe tak, aby realnie odzwierciedlały zapisy procedur.

Kto ponosi osobistą odpowiedzialność za brak zgodności z DORA?

Zgodnie z art. 5 rozporządzenia DORA pełną i ostateczną odpowiedzialność za zarządzanie ryzykiem technologii informacyjno-komunikacyjnych ponosi organ zarządzający instytucji finansowej (zarząd). Odpowiedzialności tej nie można przenieść na dział IT ani zewnętrznych dostawców. Członkowie zarządu muszą regularnie podnosić swoje kompetencje w obszarze cyberbezpieczeństwa, zatwierdzać ramy zarządzania ryzykiem oraz nadzorować plany ciągłości działania.

Czym różni się Wasze wdrożenie DORA od samej dokumentacji - co realnie dostarczacie?

Nie drukujemy polityk, tylko wdrażamy działające procesy i kontrole.

Co konkretnie dostarczamy:

  • Gap assessment → mapa luk, priorytety, roadmapa i KPI/KRI.
  • Zestaw polityk/procedur + rejestry (ryzyko, incydenty, BCM/DRP, testy, dostawcy) dopasowane do Was.
  • Skonfigurowane kontrole techniczne: monitoring 24/7 i alerty, backupy z testami, HA/DR, centralne logi/SIEM, IAM/hardening.
  • Incydenty i raportowanie: workflow 4h/24h/72h/1 mies., formularze i szablony komunikatów.
  • Dostawcy: due diligence, klauzule DORA do SLA, plan exit.
  • Evidence pack + runbooki i krótkie szkolenia dla zespołu.

Jak wygląda pierwszy krok współpracy i jakie dane potrzebujecie na start?

Krótka rozmowa startowa (30–45 min) + NDA. Ustalamy zakres, właścicieli procesów i dostęp read-only. Wysyłamy checklistę i formaty eksportów.

Na start potrzebujemy (minimum):

  • Lista systemów/usług krytycznych + właściciele i RTO/RPO.
  • Schemat architektury (on-prem/cloud/kontenery) i główne integracje.
  • Obecne polityki/procedury (incydenty, BCM/DRP, backup, patching) – jeśli są.
  • Monitoring/logi: przykładowe alerty, SLO/SLA, używane narzędzia (ITSM/SIEM).
  • Backup/DR: harmonogram, ostatnie testy odtworzeń.
  • Dostawcy: wykaz + kluczowe SLA/umowy, incydenty z ostatnich 12 mies.

Czy DORA już w pełni obowiązuje i jak wyglądają bieżące kontrole?

Tak, rozporządzenie DORA obowiązuje w pełnym zakresie od 17 stycznia 2025 roku i nie przewiduje żadnych okresów przejściowych. Wszystkie instytucje finansowe oraz kluczowi dostawcy ICT muszą spełniać wymogi techniczne tu i teraz.

Co to oznacza w praktyce:

  • Bieżące kontrole KNF – nadzorca weryfikuje odporność operacyjną w trakcie planowych inspekcji oraz po zgłoszeniu poważnych incydentów
    ICT
  • Cykliczny rejestr umów ICT – instytucje finansowe mają obowiązek stałego prowadzenia i corocznej aktualizacji rejestru informacji o dostawcach usług technologicznych.
  • Sztywny reżim incydentów – obowiązuje raportowanie zdarzeń cybernetycznych według osi czasowej 4h (wstępne) / 24h (pośrednie) / 72h (szczegółowe) / 1 miesiąc (raport końcowy).
  • Weryfikacja podwykonawców (4th-party) – banki i fintechy weryfikują nie tylko bezpośrednich partnerów, ale cały łańcuch poddostawców infrastruktury.

Czy możecie zintegrować procesy DORA z naszymi narzędziami (Jira/ServiceNow, SIEM, monitoring, ITSM)?

Tak. Integrujemy procesy DORA z Waszym stackiem bez wymiany narzędzi lub rekomendujemy zmianę na przyszłość.

Co robimy w praktyce:

  • Jira / ServiceNow (ITSM): typy zgłoszeń Incident/Problem/Change, pola dla DORA, SLA/KPI, automatyczne eskalacje on-call, szablony raportów i checklisty RCA.

  • SIEM & logi (np. Splunk, Elastic, Sentinel, QRadar): mapowanie reguł → severity DORA, webhooks do ITSM, dołączanie kontekstu (ID zdarzenia, dowody, timeline) i auto-tworzenie draftów zgłoszeń.

  • Monitoring/APM (Prometheus+Alertmanager, Grafana): progi Critical/High/Warning/Info, tagowanie usług, routing alertów, zrzuty dashboardów do „evidence pack”.

  • CMDB / katalog usług: krytyczność, właściciele, RTO/RPO, powiązania (ERP/PIM/WMS), zależności dostawców — pod raportowanie istotności.

  • Runbooki i wiedza (Confluence/Knowledge Base): przyciski „Execute runbook”, checklisty komunikacji (KNF/ESAs, klienci, PR), wersjonowanie zmian.

  • SSO/RBAC & audyt: OIDC/SAML, role i uprawnienia na zasadzie least privilege, pełny ślad zmian i retencja zgodna z polityką.

  • Standardy integracji: OpenTelemetry, syslog, API/webhooki — wpinamy się w to, co już macie.

Jak przebiega Audyt DORA (gap assessment) i jaki jest jego zakres?

Przebieg audytu (w skrócie):

  1. Kick-off + NDA → zakres, właściciele, dostęp read-only.
  2. Przegląd dokumentów & wywiady → polityki, procedury, rejestry.
  3. Przegląd konfiguracji → monitoring, backup/DR, logi/SIEM, IAM, patching.
  4. Ocena dojrzałości & scoring → luki, wpływ/ryzyko, quick wins.
  5. Raport & roadmapa → priorytety, właściciele, KPI/KRI.

Zakres zgodnie z DORA:

  • Ryzyko ICT, incydenty i raportowanie (4h/24h/72h/1 mies.).
  • Testy odporności (BCM/DRP, restore-drille, tabletop/TLPT koordynowane).
  • Zarządzanie dostawcami ICT (due diligence, SLA, prawo audytu, exit).
  • Dowody / rejestry (ryzyk, incydentów, zmian, dostępów, umów, aktywów).
  • Warstwa techniczna: monitoring 24/7 i alerty, backupy (3-2-1/WORM), HA/DR, IAM/MFA, logi/SIEM, podatności/patching.

Czy wspieracie środowiska on-prem, private cloud i public cloud (AWS/Azure/GCP)?

Oczywiście, że tak!

  • Private cloud: nasz i klienta (VMware/Proxmox/K8s) — projekt, hardening, HA/DR, monitoring, backup/restore-drille.
  • Public cloud (AWS/Azure/GCP): landing zone, IAM/MFA, S3/Blob/WORM, obserwowalność, automatyzacje raportowania DORA.
  • On-prem: tylko zdalnie (architektura, konfiguracje, audyty, runbooki) — bez prac fizycznych w DC.

Czy dostawca oprogramowania SaaS lub software house musi zgłaszać incydenty do KNF?

Dostawca ICT zgłasza poważny incydent bezpośrednio swojemu klientowi (np. bankowi lub fintechowi) zgodnie z rygorystycznymi terminami zapisanymi w umowie SLA. Dopiero podmiot finansowy dokonuje formalnego zgłoszenia do KNF. Jednakże bank wymaga od dostawcy pełnych danych technicznych (timeline, wpływ na dane, wektor ataku), dlatego dostawca musi posiadać procedury umożliwiające przygotowanie takiego raportu w ciągu kilku godzin.

Czym różni się standardowy backup od wymogów DORA?

DORA wymaga, aby kopie zapasowe były odizolowane logicznie lub fizycznie od sieci produkcyjnej, zabezpieczone przed nadpisaniem (np. mechanizmem WORM) oraz regularnie testowane w procesie odtworzenia środowiska. Samo wykonywanie kopii bez udokumentowanych, cyklicznych prób przywracania danych i pomiaru wskaźników RTO/RPO nie spełnia wymogów audytu nadzorczego.

Co możemy dla Ciebie zrobić?

Porozmawiajmy. Napisz do nas!