NIS2 i DORA są bardzo praktycznymi regulacjami, których wdrożenie nie polega wyłącznie na „wyprodukowaniu następnych papierów” ale wymagają konkretnych działań w organizacji. Obszary wymagające działań obejmują: zarządzanie ryzykiem, tożsamości i dostępy, monitoring, reakcję na incydenty oraz kontrolę dostawców IT.
Dla osób odpowiedzialnych za IT i bezpieczeństwo najważniejsze jest, aby przełożyć wymagania regulacyjne na decyzje architektoniczne i plan działań, który da się wdrożyć bez zatrzymywania procesów biznesowych. Procesy i procedury opisane w NIS2 czy DORA mają działać i przynosić konkretne korzyści, a nie leżeć ładnie opisane w dokumentach na półce.
W ISCG podchodzimy do tego praktycznie: od szybkiej analizy luk (gap analysis), przez priorytetyzację, po wdrożenia i utrzymanie mechanizmów bezpieczeństwa w środowiskach opartych o Microsoft. Celem jest przygotowanie sprawnie działających procesów, przećwiczenie ich w praktyce (w szczególności procedur reagowania na incydent) i jako efekt uboczny dostajemy gotowość do audytu środowiska.
Zgodność to architektura bezpieczeństwa, nie same procedury
NIS2 i DORA kładą nacisk na zarządzanie ryzykiem oraz zdolności operacyjne: wykrywanie zdarzeń, ograniczanie skutków, ciągłość działania i raportowanie incydentów. Procedury reagowania na incydent muszą działać również wtedy, gdy incydent wydarzy się w nocy albo w weekend (z naszego doświadczenia wynika, że zwykle wtedy uruchamiane są ataki).
W NIS2 obowiązki raportowania opisano etapowo — m.in. wczesne ostrzeżenie w 24 godziny i zgłoszenie w 72 godziny od momentu „uzyskania wiedzy o incydencie” (awareness).
DORA bardzie dokładnie opisuje wymagania operacyjne dla instytucji finansowych: ramy zarządzania ryzykiem ICT, testowanie odporności, rola zarządu oraz wymagania wobec dostawców usług ICT (third party).
W praktyce potrzebujesz spójnego modelu zarządzania obejmującego: tożsamość, dostęp, monitoring, proces reagowania na incydenty oraz kontrola dostawców. Dokumentacja tych procesów ma sens jeśli te procesy faktycznie są wdrażane.
NIS2 a DORA – operacyjne różnice z perspektywy działu IT
Obie regulacje mają wspólny cel: zwiększyć odporność na incydenty. Różnią się jednak zakresem i akcentami.
NIS2 obejmuje szeroką grupę organizacji w wielu sektorach (podmioty kluczowe i ważne). Dla wielu firm oznacza to pierwsze „twarde” wymagania w obszarze incydentów, monitoringu czy ryzyka.
DORA dotyczy sektora finansowego oraz firm świadczących dla niego usługi IT. Podkreślony jest tu obszar zarzadzania dostawcami: wymagania w umowach, prawo do audytu, współpraca przy incydentach i plan awaryjny na wypadek zakończenia współpracy. W DORA mocniej podkreślono też odpowiedzialność zarządu za ramy zarządzania ryzykiem ICT.
Jeśli działasz w finansach albo pracujesz dla tej branży, DORA zwykle oznacza szybsze wejście w szczegóły i większą precyzję wdrożeń.
Checklista wdrożenia: krok po kroku do gotowości
1) Inwentaryzacja i zarządzanie ryzykiem ICT
Zacznij od obrazu: co jest krytyczne i od czego zależy.
- Zidentyfikuj krytyczne funkcje biznesowe i systemy, które je wspierają (aplikacje, bazy, integracje, uprawnienia).
- Uporządkuj tożsamości i dostęp: MFA jako minimum, docelowo role, zasady dostępu i podejście do kont uprzywilejowanych.
- Ustal podstawowy standard klasyfikacji informacji (co jest wrażliwe, co podlega ochronie, co można współdzielić).
2) Monitorowanie i raportowanie incydentów
NIS2 wymaga etapowego raportowania (m.in. 24h/72h), więc musisz mieć gotowy proces i narzędzia.
- Zapewnij centralną widoczność zdarzeń (logi, alerty, korelacje).
- Ustal progi i kryteria „significant incident”, żeby zespół wiedział, co eskalować.
- Przetestuj proces reagowania (IR) i komunikacji — jako realny przebieg działań.
3) Zabezpieczenie łańcucha dostaw IT
DORA mocno naciska na dostawców ICT: umowy, audytowalność, wymagania i scenariusze awaryjne.
- Zbuduj rejestr dostawców (chmura, outsourcing IT, vendorzy aplikacji, integratorzy).
- Ustal minimalne wymagania: SLA, prawo audytu, zasady obsługi incydentów i współpracy przy audytach.
- Przygotuj założenia strategii wyjścia (exit strategy), jeśli dostawca przestaje spełniać wymagania.
4) Ciągłość działania i odtwarzanie
W kryzysie liczy się to, czy potrafisz odtworzyć działania procesów biznesowych.
- Zweryfikuj backupy i odtwarzanie oraz to, czy były testowane.
- Ustal priorytety RTO/RPO przynajmniej dla kluczowych usług.
- Dopilnuj właścicieli procesów — bez tego decyzje będą się rozmywać.
Chcesz sprawdzić gotowość Twojego środowiska na NIS2/DORA bez przeciągania projektu?
Audit-readiness w 2–4 tygodnie: jak to ułożyć bez dezorganizacji zespołu
Jeśli celem jest szybkie przygotowanie się do audytu, dobrze działa rytm krótkich sprintów. Każdy tydzień ma jasny rezultat.
Tydzień 1: scope + aktywa + ryzyko
Mapa krytycznych usług, właściciele i zależności, lista dostawców oraz „top ryzyk” i braków.
Tydzień 2: tożsamość + dostęp + monitorowanie
Przegląd MFA, kont uprzywilejowanych i zasad dostępu. Minimalny standard logowania i detekcji oraz progi eskalacji.
Tydzień 3: dostawcy ICT + umowy + wymagania audytowe
Rejestr dostawców, luki w umowach i plan: co renegocjować oraz w jakiej kolejności.
Tydzień 4: plan remediacji + harmonogram
Lista prac „must-do”, priorytety, zasoby i odpowiedzialności (np. w oparciu o RACI). Na koniec stan gotowości — co jest wdrożone, co w toku i gdzie potrzebna decyzja zarządu.
Jak zacząć audyt bez przeciągania projektu
Żeby zaplanować gap analysis bez długiej fazy wstępnej, potrzebujemy kilku danych wejściowych:
- Mapa kluczowych procesów biznesowych i powiązanych systemów IT.
- Stan tożsamości i dostępów (MFA, konta uprzywilejowane, zasady dostępu).
- Zarys backupu i DR (co jest testowane i jak często).
- Lista kluczowych dostawców ICT oraz informacja, kto odpowiada za relację i umowę.
To zwykle wystarcza, żeby ustalić zakres audytu, priorytety i plan działań.
FAQ – Najczęstsze pytania o NIS2 i DORA
Czy DORA zastępuje NIS2 w sektorze finansowym?
DORA jest regulacją sektorową dla finansów i szeroko pokrywa odporność cyfrową (ICT risk, incydenty, testy, dostawcy). Nie oznacza to, że NIS2 „znika”, ale dla instytucji finansowych główny ciężar wymagań operacyjnych realizuje DORA.Jakie są wymagania raportowania incydentów w NIS2 (24h/72h)?
NIS2 opisuje raportowanie etapowe — m.in. wczesne ostrzeżenie w 24 godziny i zgłoszenie w 72 godziny od momentu „awareness”. W praktyce potrzebujesz narzędzi i procesu, które pozwalają działać w tych oknach czasowych.Czy posiadanie narzędzi (np. EDR/SIEM) gwarantuje zgodność?
Nie. Narzędzia są elementem układanki, ale zgodność wymaga procesu: kto reaguje, w jakim czasie, jakie są progi eskalacji, jak raportujecie i jak kontrolujecie dostawców.Skąd mam wiedzieć, czy moja organizacja to podmiot „kluczowy” czy „ważny” w NIS2?
To zależy od sektora i kryteriów w dyrektywie (załączniki) oraz parametrów organizacji. Najlepiej zrobić krótką kwalifikację prawno-organizacyjną i przełożyć wynik na scope IT.Co dokładnie oznacza obowiązek ochrony łańcucha dostaw w DORA?
Rejestr dostawców ICT, wymagania w umowach (w tym współpraca w audytach), ciągły nadzór oraz strategia wyjścia. To obszary, które regularnie wracają w wymaganiach dla rynku.Od czego zacząć, jeśli nie mamy dojrzałych polityk bezpieczeństwa?
Od inwentaryzacji i gap analysis: aktywa → ryzyko → priorytety → minimalny standard kontroli i monitoringu. Dokumentację dopinaj później, gdy fundament już działa.Porozmawiajmy o gotowości Twojego IT na NIS2 i DORA
Poznaj nasze pozostałe usługi
Aplikacje biznesowe
Usługi dla aplikacji oraz gotowe rozwiązania w obszarze cyfryzacji procesów i nowoczesnego środowiska pracy.
Nowoczesne i kompleksowe wsparcie w obszarze cyberbezpieczeństwa dla Twojej firmy.
Cyberbezpieczeństwo
Pełne wsparcie i optymalizacja infrastruktury IT, zapewniające stabilny rozwój Twojego biznesu.
Infrastruktura IT
Bezpieczeństwo wdrożenia i utrzymania usług Microsoft 365 oraz Azure, które umożliwiają elastyczne zarządzanie i optymalizację kosztów.