Znaczna część instytucji finansowych spełnia wymagania ISO/IEC 27001 w wymiarze formalnym, jednak napotyka trudności w zakresie gromadzenia dowodów i dotrzymywania terminów wymaganych przez regulatorów. DORA i NIS2 podnoszą wymagania właśnie w tych obszarach. Niniejszy przewodnik przedstawia, w jaki sposób podejście regulacyjne oparte na terminach (clock-driven) i egzekwowalnej odporności wymusza reinterpretację standardu ISO.
Omówiona zostanie strategia łącząca podejście risk-based z compliance-by-design, praktyczne mapowanie wymagań DORA/NIS2 do klauzul i Annex A, klarowna matryca RACI, operacyjna dyscyplina w zakresie incydentów, ciągłości i testów oraz zasady zarządzania łańcuchem dostaw i gotowości dowodowej. Celem jest uniknięcie dublowania kontroli, skrócenie czasu reakcji, domknięcie luk i zapewnienie sprawnej komunikacji z nadzorcą. Teza przewodnia: ISO pozostaje rdzeniem systemu, ale nowa rzeczywistość to dowody, terminy i pełna śledzalność.
Strategiczny zwrot w bezpieczeństwie: od podejścia risk-based do risk + compliance-by-design
DORA i NIS2 wprowadzają fundamentalną zmianę w sposobie pracy z ISO/IEC 27001. Kluczowe stają się terminy, dowody, odpowiedzialność zarządu i realna egzekwowalność. Samo zarządzanie ryzykiem nie wystarcza — niezbędne jest compliance-by-design osadzone w procesach, z mierzalnymi KPI/KRI, audytowalnym traceability i gotowym do przedstawienia łańcuchem decyzji. Nadzór wymaga raportowania clock-driven, czyli działań w twardych oknach czasowych. Do tego dochodzą testy odporności operacyjnej, w tym scenariusze krytyczne, oraz radykalne uszczelnienie ryzyka dostawców ICT z umowami i kontrolami o potwierdzonej skuteczności.
Kluczowe elementy nowego podejścia:
- Odpowiedzialność zarządu: formalne role, zgody na ryzyko, protokołowane decyzje i nadzór nad cyber ryzykiem
- Raportowanie clock-driven: twarde SLA na incydenty, eskalacje i zgłoszenia do regulatorów
- Testy odporności: regularne TTX, red teaming, scenariusze DDoS/RDP/BCP z wynikami jako dowód
- Łańcuch dostaw ICT: due diligence, klauzule security-by-default, ciągłe monitorowanie dostawców
Transformacja wymaga przejścia od stanu, w którym organizacja posiada polityki, ogólny ISMS, pojedyncze testy i raporty na żądanie, do stanu docelowego obejmującego dashboardy KRI dla zarządu, raportowanie w określonych oknach czasowych, cykliczne testy odporności oraz przeprojektowane umowy i kontrole dla krytycznych dostawców ICT. ISO/IEC 27001 pozostaje rdzeniem, ale praktyka to dowody, terminy i pełne traceability.
Mapa wymagań: połączenie DORA i NIS2 z ISO/IEC 27001
Mapowanie wymagań do ISO/IEC 27001 stanowi efektywną drogę do uporządkowania compliance, skrócenia audytów i sprawnego dialogu z nadzorcą. Zamiast dublować checklisty, wszystkie wymagania zostają zintegrowane w jednym Systemie Zarządzania Bezpieczeństwem Informacji. Kontroler otrzymuje jasny obraz: co jest wdrożone, kto za to odpowiada i gdzie występują luki. Dla zespołów operacyjnych mapa stanowi narzędzie priorytetyzacji — co wdrożyć, co zmierzyć, co udowodnić podczas przeglądu.
Obszary wymagające mapowania:
Zarządzanie ryzykiem ICT — odpowiada Rozdziałowi II DORA i Art. 21 NIS2, mapuje się do Klauzuli 6 ISO (ryzyko, cele) oraz Annex A: A.5 (polityki/role) i A.8 (testy/zmiany).
Zgłaszanie incydentów — odpowiada Rozdziałowi III DORA i standardom technicznym oraz Art. 23 NIS2, mapuje się do Annex A w zakresie zarządzania incydentami i monitoringu oraz Klauzuli 8 (operacje).
Ciągłość działania i DR — odpowiada Rozdziałowi II DORA (ciągłość ICT) i Art. 21(2)(d) NIS2, mapuje się do Annex A w zakresie gotowości ICT dla ciągłości i planów odtworzeniowych.
Testy odporności (w tym TLPT) — odpowiada Rozdziałowi V DORA i Art. 21(2)(g) NIS2, mapuje się do Annex A w zakresie testów bezpieczeństwa i ocen podatności oraz Klauzuli 9 (audyt/ewaluacje).
Łańcuch dostaw ICT — odpowiada Rozdziałowi IV DORA i Art. 21(2)(d) NIS2, mapuje się do Annex A w zakresie bezpieczeństwa relacji z dostawcami i exit plan.
Monitorowanie i logowanie — wymagane pośrednio przez DORA i wprost przez Art. 21(2)(e) NIS2, mapuje się do Annex A w zakresie monitoringu, rejestrowania zdarzeń i detekcji anomalii.
Praktyczne wdrożenie obejmuje wskazanie luk, przypisanie właścicieli (gap owners) z konkretnymi datami domknięcia oraz połączenie kontroli w jeden proces ISO, aby nie mnożyć wymagań i utrzymać spójność dowodów na audyt. Połączenie zgłaszania incydentów z procesem operacyjnym ISO, z jednym właścicielem raportowania i ustalonymi SLA, pozwala znacząco skrócić czas notyfikacji. Scalenie testów odporności z planem audytów i ocen podatności eliminuje dublowanie TLPT z pentestami, generując oszczędności budżetowe.
Ład i role: RACI dla zgodności DORA/NIS2 osadzonej w systemie ISO
Odpowiedzialność za zgodność z DORA/NIS2 nie ogranicza się do CISO — obejmuje całą organizację. Zarząd musi nadać kierunek, zaakceptować apetyt na ryzyko i zapewnić, że ISO/IEC 27001 funkcjonuje jako działający system, nie tylko dokumentacja na audyt. CISO prowadzi operacyjne wdrożenie, właściciele ryzyk odpowiadają za realne decyzje biznesowe, a działy prawny i compliance spinają wymagania regulacyjne z kontraktami i raportowaniem do nadzoru. Bez takiego układu kontrola nad incydentami ICT, testami odporności (TLPT) i zarządzaniem dostawcami ulega rozproszeniu.
Przypisanie odpowiedzialności według matrycy RACI:
Klasyfikacja incydentu: Zarząd zatwierdza (A), CISO odpowiada operacyjnie (R), właściciel ryzyka, szef IT/Operacji oraz dział prawny/compliance są konsultowani (C).
Zgłoszenie do nadzorcy (DORA/NIS2): CISO zatwierdza (A), szef IT/Operacji oraz dział prawny/compliance odpowiadają operacyjnie (R), zarząd i właściciel ryzyka są konsultowani (C).
Test odporności (TLPT/Red Team): CISO zatwierdza (A), szef IT/Operacji odpowiada operacyjnie (R), pozostałe role są konsultowane (C).
Przegląd umów ICT (klauzule DORA/NIS2): Zarząd zatwierdza (A), dział prawny/compliance odpowiada operacyjnie (R), pozostałe role są konsultowane (C).
Roczny przegląd ryzyka i apetytu: Zarząd zatwierdza (A), CISO i właściciel ryzyka odpowiadają operacyjnie (R), szef IT/Operacji oraz dział prawny/compliance są konsultowani (C).
Aby uniknąć sytuacji, w której wszyscy odpowiadają, a nikt nie ponosi realnej odpowiedzialności, należy przypisać role wprost do konkretnych osób i procesów oraz potwierdzić to uchwałą zarządu. Aktualny RACI powinien być przechowywany w repozytorium dowodów obok polityk ISO/IEC 27001, planów zgodności DORA/NIS2 i ścieżek raportowania incydentów.
Operacje odporności: incydenty, ciągłość i testy
Zarządzanie incydentami według NIS2
Proces raportowania incydentów opiera się na osi czasu. W ciągu 24 godzin (T+24h) należy przekazać wczesne ostrzeżenie do CSIRT lub kompetentnego organu, nawet przy niepełnej wiedzy o zdarzeniu. W ciągu 72 godzin (T+72h) wymagane jest zgłoszenie incydentu ze wstępnymi skutkami, podejrzeniem przyczyn oraz opisem działań naprawczych. W terminie do jednego miesiąca należy dostarczyć raport końcowy z ustaleniami i dowodami.
Wymagane elementy zgłoszenia:
- Klasyfikacja S1-S4 określająca wpływ i krytyczność
- Wpływ na usługi i klientów
- Geografia i jurysdykcje
- Identyfikacja dostawcy w łańcuchu (jeśli dotyczy)
- Działania mitigujące
- Kontakt 24/7 z osobą decyzyjną i kanałem kryzysowym
Ciągłość działania i Disaster Recovery
Planowanie ciągłości wymaga konkretnych parametrów RTO i RPO. Przykładowy scenariusz: awaria krytycznego SaaS płatności na 12 godzin. Przy założeniu RTO = 4h (powrót usługi w ciągu 4 godzin) i RPO = 15 min (maksymalna utrata danych transakcyjnych 15 minut), plan obejmuje: przełączenie na plan B (backupowy procesor lub tryb offline z tokenizacją i buforowaniem), komunikację z klientami (status page i push w aplikacji) oraz degradację kontrolowaną (priorytet dla płatności o wysokiej wartości, batch settlement po przywróceniu). Takie podejście łączy wymagania DORA/NIS2 z praktyką ISO/IEC 27001 — mierzalne cele zamiast deklaracji.
Warianty odzyskiwania:
Failover aktywno-pasywny — RTO 2-4h, RPO 15-30 min. Stosowany dla krytycznych płatności przy średnim koszcie przestoju.
Tryb degradacji — RTO do 1h do ograniczonej funkcji, RPO do 1h. Stosowany do utrzymania podstawowych operacji bez pełni funkcjonalności.
Rerouting do dostawcy zapasowego — RTO 1-6h, RPO 5-15 min. Stosowany gdy istnieje umowa z alternatywnym procesorem.
Testy odporności
Należy ustalić progi testowania: TLPT-light dla mniejszych podmiotów (tylko krytyczne usługi, scenariusze oparte o MITRE ATT&CK, socjotechnika opcjonalna) oraz pełny TLPT, gdy regulator tego wymaga. Zakres obejmuje ścieżkę pieniędzy, tożsamość i operacje wsparcia. Wynik stanowi raport z dowodami (artefakty, logi, ślady ataku) i plan naprawczy do 90 dni z właścicielami zadań i metrykami. Audyt ISO/IEC 27001 weryfikuje działające kontrolki i efekty, nie tylko istnienie procedur.
Dostawcy ICT i dowody: utrzymanie zgodności i gotowość na audyt
Tiering dostawców ICT stanowi podstawę kontroli ryzyka. Tier 1 (krytyczny biznesowo/operacyjnie) wymaga: prawa audytu on-site/remote, ostrych SLA incydentowych dla S1/S2, pełnej transparentności podwykonawców (flow-down) oraz sprawnego exit plan z migracją danych. Tier 2 (ważny) to skrócone klauzule, ale wciąż z mierzalnymi RTO/RPO i testami. Tier 3 (pomocniczy) — lekka kontrola bez kompromisów dla bezpieczeństwa danych.
Bieżący monitoring dostawców obejmuje: cykliczne skany podatności, aktualne atestacje (ISO/IEC 27001, SOC 2), wyniki testów penetracyjnych/TLPT oraz weryfikację zamknięć P1/P2. Organizacja staje się realnie evidence-ready, a audyt i kontrole nie stanowią zaskoczenia.
Wymagane artefakty dowodowe:
- Rejestr incydentów z klasyfikacją, decyzjami oraz ścieżką eskalacji
- Uchwały zarządu: apetyt na ryzyko, akceptacje wyjątków, zgody na outsourcing
- Mapowanie DORA/NIS2 do ISO/IEC 27001 ze statusem luk i planami domknięcia
- Plany ciągłości działania/DR wraz z wynikami testów RTO/RPO
- Raporty TLPT/pen-testów z potwierdzonymi zamknięciami P1/P2 w SLA
- Rejestr dostawców z oznaczeniem krytyczności i klauzulami (audit, SLA, sub, exit)
- Procedury raportowania do nadzorców z progami czasowymi i kontaktami 24/7
- Dowody szkoleń ról krytycznych (SOC/On-Call) z aktualnym coverage i testami w praktyce
Kluczowe metryki:
- MTTD/MTTR dla incydentów S1 — średni czas wykrycia i opanowania, z celem kwartalnym
- Odsetek krytycznych dostawców z kompletem klauzul i aktualnymi testami bezpieczeństwa
- Realizacja planów naprawczych w terminie poniżej 90 dni — procent pozycji zamkniętych terminowo
Najczęściej zadawane pytania
Od czego zacząć przy posiadaniu ISO/IEC 27001, ale niepewności co do zgodności z DORA i NIS2?
Należy rozpocząć od szybkiego mapowania kontrolnego: sporządzić listę wymogów DORA/NIS2 krytycznych czasowo (incydenty, testy, łańcuch dostaw) i przypisać je do klauzul/Annex A ISO. Wykonać gap assessment z datami domknięcia, wskazać właścicieli i mechanizmy dowodowe (artefakty). Równolegle zdefiniować ścieżkę raportowania do nadzorców i zaktualizować politykę apetytu na ryzyko pod wymogi regulacyjne.
Jak często aktualizować testy odporności i czy TLPT zawsze jest wymagany?
Minimalnie rocznie dla kluczowych usług oraz po istotnych zmianach architektury lub incydencie S1/S2. Pełny TLPT jest wymagany dla wybranych podmiotów zgodnie z DORA (na podstawie kryteriów nadzorczych). Pozostali powinni prowadzić TLPT-light lub ćwiczenia red team zgodne z profilem ryzyka i utrzymywać plan naprawczy z horyzontem do 90 dni.
Jak klasyfikować incydenty, aby spełnić jednocześnie DORA i NIS2?
Należy przyjąć jednolitą skalę wpływu (np. S1-S4) opartą o dostępność, integralność, poufność i ciągłość usług krytycznych, z progami biznesowymi (użytkownicy/klienci dotknięci, czas przestoju, wpływ finansowy). Skalę zmapować do progów notyfikacji DORA/NIS2 i osadzić w playbookach z polami raportowymi oraz kontaktami 24/7.
Jak zarząd powinien dokumentować tone from the top i akceptacje ryzyka?
Poprzez uchwały zatwierdzające apetyt na ryzyko, roczny przegląd ryzyka, decyzje o akceptacji wyjątków i priorytetyzację planów naprawczych. Dokumenty te należy przechowywać w repozytorium dowodów wraz z metrykami (MTTD/MTTR, status P1/P2) i powiązać z przeglądami skuteczności ISMS.
Jak praktycznie kontrolować ryzyko w łańcuchu dostaw ICT bez spowalniania biznesu?
Należy wprowadzić tiering dostawców, standardowe klauzule kontraktowe, lekkie oceny wstępne dla Tier 2-3 i pogłębione due diligence z testami/atestacjami dla Tier 1. Zautomatyzować monitorowanie (skany, alerty o zmianach SOC 2/ISO), stosować KPI zgodności klauzul i cykliczne przeglądy ryzyka powiązane z procesem zakupowym.
Źródła
https://coe.biz.pl/uslugi/centrum-certyfikacji-qscert/iso-27001-certyfikacja/
https://coe.biz.pl/uslugi/centrum-certyfikacji-qscert/iso-22301-certyfikacja/
