Support 24/7: +48 61 646 07 77
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.
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.
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 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.
Co robimy:
Efektem jest pełna kontrola ryzyka w łańcuchu dostaw i przewidywalna zmiana usługodawcy.
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:
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
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:
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):
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:
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):
Zakres zgodnie z DORA:
Czy wspieracie środowiska on-prem, private cloud i public cloud (AWS/Azure/GCP)?
Oczywiście, że tak!
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.