DORA i NIS2 w praktyce: jak ISO/IEC 27001 i ISO 22301 pomagają uniknąć kar i chaosu operacyjnego

Mapa wymagań DORA/NIS2 do ISO 27001 i ISO 22301: konkretne kontrolki i dowody

DORA i NIS2 mają zero litości dla chaosu: albo masz procesy i dowody, albo szykuj się na stres przy kontroli. Poniżej masz prostą matrycę: przepis → cel → kontrolka ISO → artefakt. Weź to jak checklistę do wdrożenia i audytu. Zastosuj: zgłaszanie incydentów, testy DR/BCM, zarządzanie dostawcami ICT, zarządzanie ryzykiem i SoA, dołóż krytyczne procesy (np. płatności, bankowość online, rozliczenia). Eksperci często powtarzają: minimalna dokumentacja, maksymalna powtarzalność – piszesz tylko to, co realnie wykonujesz i co da się pokazać inspektorowi. Experts’ Advice: nie dubluj procedur między ISO 27001 i ISO 22301; trzymaj jedną Politykę IR z aneksem do BCP, a w SoA wpisz, gdzie leży dowód.

Wymóg (DORA/NIS2): Zgłoszenie incydentu istotnego → Cel: szybka informacja do nadzorcy → ISO 27001: A.5.24–A.5.28 (IR, dowody) → ISO 22301: 8.4 (plany/komunikacja BCP) → Dowód: procedura IR, rejestr incydentów, logi zgłoszeń (czas reakcji, kanał, potwierdzenie).
Wymóg: Testy odporności/DR → Cel: weryfikacja gotowości → ISO 27001: A.5.30 (ICT readiness for BC) → ISO 22301: 8.5 (program ćwiczeń) → Dowód: raport z testu DR, listy kontrolne, wnioski po ćwiczeniach, zadania naprawcze w Jirze.
Wymóg: Zarządzanie dostawcami ICT → Cel: kontrola łańcucha dostaw → ISO 27001: A.5.19–A.5.21 → ISO 22301: 8.4 (umowy kryzysowe) → Dowód: due diligence, SLA, prawo audytu, raporty KPI/KRI, plan wyjścia z kontraktu.
Wymóg: Zarządzanie ryzykiem i SoA → Cel: świadomy dobór kontrolek → ISO 27001: 6.1.2–6.1.3 → ISO 22301: 8.2 (BIA i ocena ryzyka) → Dowód: rejestr ryzyk, SoA z uzasadnieniami, mapy ryzyka dla procesów krytycznych.
Wymóg: Ciągłość dla procesów krytycznych (np. płatności) → Cel: utrzymanie usług → ISO 27001: A.5.29–A.5.31 (BC, redundancja, kopie) → ISO 22301: 8.3–8.6 (strategie, RTO/RPO, testy) → Dowód: BCP runbook, RTO/RPO w SLA, raport backup/restore.

Zobacz: https://coe.biz.pl/uslugi/centrum-certyfikacji-qscert/iso-27001-certyfikacja/ 

Roadmapa 90 dni do zgodności operacyjnej: priorytety, szybkie zwycięstwa i artefakty

Plan 0–30 dni: cel — porządek i widoczność. Zadania: inwentarz aktywów (IT/OT/SaaS), rejestr ryzyk z priorytetami, szablony IR/BCP (prosty playbook i lista kontaktów), szybki rejestr incydentów, uruchomienie repozytorium dowodów (np. Git/SharePoint). RACI: CISO(A), Owner(R), IT/Legal/BCM(C/I). Wynik: działające rejestry, szkice polityk, jasno nazwany backlog braków. Quick wins: metryki KPI/KRI w wersji lite (MTTD/MTTR, liczba incydentów, status testów), klasyfikacja informacji 3-poziomowa, matryca ról do IR/BCP.

Plan 31–60 dni: cel — kontrolki krytyczne. Zadania: SoA (mapa kontroli do ISO/IEC 27001 + odniesienia do resilience z ISO 22301), doprecyzowane procedury incydentowe z eskalacją i oknami raportowania, wymagania dla dostawców w umowach (SLA, notyfikacja, testy DR, prawo audytu), playbook IR + BCP dla 3 procesów krytycznych. RACI: CISO(R), IT(A), Legal(C), biznes(I). Wynik: SoA zatwierdzone, playbook IR opublikowany, klauzule w T&C wdrożone, pierwsza wersja dashboardu KPI/KRI.

Plan 61–90 dni: cel — weryfikacja i dowody. Zadania: test tabletop (IR+BCP), techniczny DR test wybranego systemu, urealnienie dashboardu KPI/KRI, audyty wewnętrzne wybranych kontroli, przegląd ryzyk i plan poprawek. RACI: BCM(R), Risk(C), Audit(I), IT(A). Wynik: raporty z testów, uzupełnione repo dowodów, zaakceptowany plan działań korygujących.

Zależności: bez inwentarza aktywów i rejestru ryzyk nie da się ustawić sensownego SoA ani priorytetów testów DR. Klauzule dostawców muszą być podpisane przed testem tabletop/DR, inaczej brakuje zakresu i zgód. Dashboard KPI/KRI ma sens dopiero po wdrożeniu podstawowych rejestrów i playbooków.

Blokery: brak Ownerów procesów, “shadow IT” bez inwentarza, kontrakty bez SLA i notyfikacji, rozmyte RACI. Go/No-Go: idziemy dalej, jeśli działa repo dowodów, mamy SoA z akceptacją ryzyka, oraz przeprowadzony minimum jeden test tabletop. Komunikacja postępu: jeden slajd z 5 wskaźnikami — MTTD/MTTR, odsetek kontroli z SoA wdrożonych, status klauzul dostawców, pokrycie BCP procesów krytycznych, liczba dowodów w repo na tydzień. To jest paliwo, które realnie ogranicza ryzyko kar i chaosu w operacjach.

Ocena ryzyka, SoA i polityki: jak zbudować trzon ISMS/BCMS bez nadmiaru papierologii

Tu nie ma miejsca na korporacyjny bełkot: zacznij od konkretów. Ustal kryteria ryzyka (akceptowalne poziomy wpływu i prawdopodobieństwa), zinwentaryzuj aktywa i procesy krytyczne (mapa usług, zależności, właściciele), przeprowadź ocenę ryzyka na poziomie usługi, dobierz kontrolki ISO/IEC 27001 i plany ciągłości ISO 22301, a decyzje uwiarygodnij w SoA (Statement of Applicability). To ma wspierać DORA oraz NIS2 w realnym działaniu: mniejszy chaos podczas incydentu, szybszy RTO/RPO, brak kar za puste deklaracje. Zamiast spisu pobożnych życzeń — krótkie, ostre reguły: polityka bezpieczeństwa informacji, ciągłość działania, zarządzanie dostawcami, obsługa incydentów, kopie zapasowe i DR. Experts’ Advice: przypnij każdy wymóg do właściciela procesu i metryki (np. % testów DR zaliczonych), inaczej zniknie w operacyjnej mgle.

Format ma być jednolinijkowy, żeby audytor nie utknął w tabeli: „System płatniczy – ransomware → przerwa usług; Kontrolki: A.5.24–A.5.27, A.5.30; RTO 2h/RPO 15m; Właściciel: CTO; Ryzyko resztkowe: średnie; Plan: segmentacja + test DR kwartalnie.” W SoA trzymaj żelazną dyscyplinę: decyzja „wdrożono” lub „nie dotyczy” z jednym zdaniem uzasadnienia, bez kopiowania treści polityk. Przykłady: „A.8.16 wdrożono — obowiązkowe MFA dla wszystkich uprzywilejowanych kont”, „A.5.36 nie dotyczy — brak przetwarzania danych kartowych w naszym środowisku”. Experts’ Advice: co kwartał przeglądaj rejestr ryzyk i SoA razem z BCP/DR; jeśli metryki spadają (np. czasy odtworzenia), od razu podbijaj priorytet działań korygujących — to realnie wzmacnia zgodność z DORA i NIS2 oraz ogranicza ryzyko operacyjne.

Zarządzanie incydentami, RTO/RPO i ćwiczenia: playbook odporności gotowy do użycia

Masz dość teorii? Oto playbook odporności, który da się uruchomić od ręki. Proces działa zawsze tak samo: wykrycie → triage → decyzja → izolacja → obejście (BCP) → komunikacja → zgłoszenia → powrót do normy → wnioski. Dla każdego systemu przypisz RTO i RPO plus klarowne progi eskalacji (np. czas braku usługi, liczba klientów dotkniętych). Przykładowy scenariusz: ransomware w core-banking — izolujesz segment, przełączasz krytyczne operacje na tryb manualny, RTO 2h, RPO 15m, komunikat do klientów w T+90 min, zawiadamiasz właściwy CSIRT/nadzorcę w wymaganym oknie (24–72 h), wracasz do pracy po weryfikacji integralności; wnioski: MFA na jump hosts, test restore kwartalnie. Taki układ wpisuje się w ISO/IEC 27001 (zarządzanie incydentami, ciągłość) i ISO 22301 (BCM), a przy okazji oswaja wymagania DORA oraz NIS2 dotyczące raportowania incydentów, odporności operacyjnej i testów DR.

1. Wy wykrywasz: SIEM/EDR podnosi alert, SIRT potwierdza incydent i nadaje priorytet (P1–P3) według wpływu na usługi krytyczne.
2. Triage i decyzja: ocena zasięgu, wybór strategii (kontynuować czy wyłączać), uruchomienie BCP oraz przypisanie właścicieli zadań (IT Ops, Bezpieczeństwo, Biznes, PR, Prawny).
3. Izolacja i obejście: segmentacja, odłączenie zasobów, przełączenie na manual fallback lub DR; rejestracja czasu dla RTO/RPO.
4. Komunikacja i zgłoszenia: aktualizacje dla klientów, interesariuszy i regulatora (CSIRT/nadzorca) w ramach okien wymagań; jedna osoba prowadzi single source of truth.
5. Powrót i wnioski: odtwarzanie, walidacja integralności, akceptacja biznesowa, lessons learned, twarde działania korygujące (np. MFA, segmentacja, backupy offline).

Ćwiczenia są paliwem odporności: tabletop co miesiąc (warianty ryzyk, decyzje, komunikacja), techniczne DR co pół roku (failover/failback, odtwarzanie danych), oraz weryfikacja powiadomień — aktualna lista kontaktów, szybki “dry run” z mierzeniem czasu. 5-punktowa checklista sukcesu: 1) zdefiniowane RTO/RPO per system, 2) gotowe playbooki z właścicielami ról, 3) działające backupy i regularny restore test, 4) spójna komunikacja kryzysowa i ścieżka raportowania, 5) zamknięte działania korygujące po każdym teście/incydencie. Dzięki temu minimalizujesz ryzyko kar regulacyjnych, unikasz chaosu operacyjnego i realnie budujesz odporność organizacji.

Łańcuch dostaw i outsourcing ICT w DORA/NIS2: due diligence, klauzule i monitoring

Jeśli podpisujesz umowy z vendorami “w ciemno”, prosisz się o kłopoty. Zacznij od klasyfikacji dostawców: którzy wpływają na usługi krytyczne (płatności, kanały klienta, SOC/NOC, backup), a którzy obsługują peryferia. Dla krytycznych wymagaj twardych dowodów: ISO/IEC 27001, SOC 2, wyniki testów, aktualny SBOM i cykl łat (patch SLA). W umowach wpisz zgodę na audyt, jawność listy subprocesorów, zasady SLA/KPI/KRI (dostępność, MTTR, % testowanych kopii, alerty), obowiązkowy udział w DR/BCP oraz konkretny exit/portability plan z terminami migracji i wsparciem. Mierz wszystko na bieżąco: dashboardy, alerting, przeglądy kwartalne i raporty z ćwiczeń. To nie papierologia – to minimalny pakiet, który faktycznie dowozi zgodność z DORA i NIS2 oraz chroni przed karami i operacyjnym bałaganem.

• Klasyfikacja krytyczności — matryca wpływu na procesy, definicja “krit.” w kontrakcie, obowiązki raportowe, przegląd kwartalny.
• Due diligence cyber — certyfikaty ISO 27001/SOC 2, testy, SBOM, wymagania patch, zgoda na audyt, przeglądy bezpieczeństwa.
• Łańcuch podwykonawców — pełna lista, zgoda na suboutsourcing i powiadomienia, rejestr zmian łańcucha.
• SLA/KPI/KRI — dostępność, MTTR, % backupów, alerty, kary umowne i progi eskalacji, dashboard + alerting.
• Testy i ćwiczenia — udział w DR/BCP, dowody z ćwiczeń, cykliczne raporty.
• Exit/portability — plan wyjścia, format danych, escrow, terminy migracji, wsparcie przy wyjściu, przegląd scenariuszy rocznie.

Koncentracja ryzyka to cichy zabójca: single-vendor wygląda wygodnie, ale jedna awaria i leżysz. Ustal alternatywnego dostawcę, minimalny dual-sourcing w krytycznych komponentach, replikację danych i scenariusz przeniesienia usług w 30–72h. Dowody i artefakty (umowy, wyniki testów, raporty z ćwiczeń, listy subprocesorów, SBOM, przeglądy) trzymaj w jednym repo z kontrolą dostępu i wersjonowaniem (np. GRC/SharePoint/Confluence) – szybki dostęp = szybsza reakcja podczas incydentu i audytu. Wnioski: trzy filary to twarde wymagania kontraktowe, mierzalny monitoring i gotowy plan wyjścia. Dzięki temu spełniasz DORA/NIS2 bez paniki i bez wstydu przed audytorem.

Najczęstsze pytania

Czy muszę mieć certyfikat ISO, aby spełnić DORA/NIS2?

Nie, ale wdrożenie kontroli zgodnych z ISO 27001/22301 ułatwia wykazanie zgodności. Certyfikat pomaga jako dowód dojrzałości, lecz nie jest jedynym sposobem na spełnienie wymagań.

Jakiej wielkości organizacje powinny wdrożyć pełny BIA i testy DR?

Każda z usług krytycznych powinna mieć BIA i test DR. Mniejsze firmy mogą zacząć od uproszczonego BIA (top 5 procesów) i jednego scenariusza DR, rozszerzając zakres iteracyjnie.

Co uznaje nadzorca za “dowód” zgodności w praktyce?

Spójne artefakty: rejestry (ryzyk, incydentów), SoA z uzasadnieniami, procedury/playbooki, raporty z testów i dowody wykonania (logi zgłoszeń, protokoły ćwiczeń, podpisane przeglądy).

Jak szybko można zbudować minimalny proces zgłaszania incydentów?

W 1–2 tygodnie: ustal kanał zgłoszeń, szablon incydentu, kryteria istotności, listę kontaktów, harmonogram raportowania i prosty workflow triage–eskalacja–zamknięcie + repozytorium dowodów.

Jak wpiąć dostawców chmurowych w nasz cykl testów odporności?

Wymagaj udziału w ćwiczeniach (tabletop/DR), dostępu do raportów z testów, metryk SLA/KRI, zgody na audyt/dowody oraz scenariusza exit z próbą odtworzenia danych co najmniej raz w roku.

Artykuł powstał na zlecenie https://coe.biz.pl/