Kontrowersyjna teza: sam certyfikat ISO/IEC 27001 nie gwarantuje zgodności z NIS2 i DORA — i może dać fałszywe poczucie bezpieczeństwa. Jeśli zastanawiasz się, które wymagania naprawdę „dokładają” do ISO, gdzie zarząd musi wykazać twarde dowody nadzoru, jak zorganizować zegar raportowania incydentów, jak ograniczyć koncentrację ryzyka u dostawców oraz jak zaplanować TLPT i ćwiczenia odporności, ten materiał przeprowadzi Cię krok po kroku. Otrzymasz praktyczną mapę luk (z priorytetami i właścicielami), przykłady dashboardów i RACI dla zarządu, operacyjny playbook zgłaszania incydentów z progami i SLA, gotowe checklisty klauzul umownych i szablon planu wyjścia, roczny program testów wraz z miernikami jakości oraz 100‑dniową roadmapę z OKR‑ami i wskaźnikami postępu. Celem jest szybkie i wiarygodne zamknięcie luk, ograniczenie ryzyka sankcji oraz przygotowanie kompletnego zestawu artefaktów audytowych — tak, by odpowiedzieć na realne oczekiwania regulatorów i wątpliwości interesariuszy.
Artykuł powstał na zlecenie Centre of Excellence.
ISO/IEC 27001 a wymogi NIS2 i DORA: precyzyjna mapa luk do zamknięcia
Masz ISO/IEC 27001? Dobrze. Ale czy to wystarczy na NIS2 i DORA? Krótka odpowiedź: nie. Standard daje solidny kręgosłup, ale regulacje wymagają twardych dowodów, konkretnych terminów i nacisku na zarząd, odporność operacyjną oraz raportowanie incydentów. Poniżej szybka „checklista prawdy” – co masz z ISO, czego wymagają NIS2/DORA, i co z tym zrobić od razu. Dorzucone Case Studies pokazują, gdzie firmy potykają się najczęściej.
| Obszar
|
ISO 27001 – co masz | NIS2/DORA – czego brakuje | Status/Plan (Priorytet/Właściciel) |
| Nadzór zarządu | Zarządzanie ryzykiem i role w ISMS | Udokumentowana odpowiedzialność organu nadzorczego, cykliczne raporty ryzyka i odporności | Do uzupełnienia – Wysoki / CISO + Zarząd |
| Raportowanie incydentów | Proces zarządzania incydentami | Ścisłe progi, kanały i terminy (np. wstępne zgłoszenie do 24/72h, aktualizacje, raport końcowy) | W toku – Wysoki / Security Operations |
| Ryzyko dostawców | Ocena dostawców i kontrolki z Annex A | Formalna analiza koncentracji ryzyka, kryteria krytyczności, ciągłe monitorowanie | Do wdrożenia – Wysoki / Third-Party Risk |
| Umowy z dostawcami | Klauzule bezpieczeństwa | Obowiązkowe zapisy o raportowaniu incydentów, prawie do audytu, RTO/RPO, łańcuch dostaw | W rewizji – Średni / Legal + Procurement |
| TLPT / testy odporności | Testy techniczne, pentesty ad hoc | Threat-Led Penetration Testing, scenariusze krytyczne, cykl lessons learned | Planowany pilotaż – Wysoki / Red Team |
| Ćwiczenia odporności | Ćwiczenia reakcji na incydenty | Ćwiczenia międzydziałowe i z dostawcami, testowanie planów ciągłości, komunikacja kryzysowa | Rozszerzenie zakresu – Średni / BCM + IT |
| Dowody zgodności | Zapisy ISMS i audyty wewnętrzne | Ścieżka audytowa pod NIS2/DORA, metryki i dashboardy do organu nadzoru | Do ustrukturyzowania – Średni / GRC |
Case Studies: 1) Instytucja finansowa z certyfikatem ISO 27001 zaliczyła kontrolę negatywnie, bo nie miała sformalizowanych progów i terminów raportowania incydentów – proces działał, ale brakowało wymogów regulacyjnych i dowodów eskalacji do zarządu. 2) Operator usług kluczowych spełniał Annex A w zakresie dostawców, lecz poległ na analizie koncentracji ryzyka i klauzulach o prawie do audytu – musieli renegocjować kontrakty. Real talk: bez dopięcia nadzoru zarządczego, TLPT i raportowania incydentów zgodnie z NIS2/DORA, zgodność dzisiaj nie przejdzie.
Nadzór i odpowiedzialność: jak udokumentować realne sterowanie przez zarząd
Jeśli ktoś myśli, że sam certyfikat 27001 załatwia temat, to niech zobaczy, gdzie regulator wbija szpilę: w realny nadzór zarządu i udokumentowane decyzje. Pokaż to czarno na białym jednym, prostym RACI dla decyzji, które naprawdę zmieniają profil ryzyka: – Apetyt na ryzyko: R (Risk), A (Zarząd), C (Compliance), I (IT/Bezpieczeństwo) – Budżet bezpieczeństwa: R (CISO/IT), A (Zarząd), C (Finanse), I (Risk) – Polityki bezpieczeństwa: R (CISO), A (Zarząd), C (Prawny/Compliance), I (IT/Operacje) Taki RACI daje dowód na odpowiedzialność i pokazuje, kto decyduje, kto doradza, a kto tylko jest informowany. To jest materiał, który wspiera zgodność z NIS2 i DORA, bo obrazuje, że sterowanie nie dzieje się “gdzieś”, tylko na poziomie zarządu.
Zarząd potrzebuje twardych danych, nie 30 slajdów mgły. Zrób krótki dashboard kwartalny z 5 metrykami, które mówią, czy zarządzanie ryzykiem naprawdę działa: – MTTD (czas wykrycia incydentu) i MTTR (czas przywrócenia) – Patch SLA (odsetek krytycznych poprawek w terminie) – % krytycznych dostawców z due diligence i aktualnym monitoringiem ryzyka łańcucha dostaw – Status ćwiczeń (tabletop/techniczne, wnioski i wdrożone poprawki) Dołącz krótką checklistę dowodów: – Protokoły z decyzjami zarządu (apetyt na ryzyko, budżet, polityki) – Zatwierdzone polityki i ich wersjonowanie – Potwierdzenia szkoleń zarządu z cyber i ciągłości działania – Przeglądy apetytu na ryzyko z mapą ryzyk i tolerancją. Ustal rytm: raport operacyjny miesięczny (incydenty, SLA, podatności), raport strategiczny kwartalny (ryzyko, trendy, inwestycje, dojrzałość). Dorzuć jeden mocny slajd “decyzja zarządu + ryzyko + termin + właściciel”, np.: – Decyzja: podniesienie apetytu na ryzyko dla dostępności usług krytycznych z RTO 2h do 1h – Ryzyko: wzrost kosztów i obciążenia operacyjnego – Termin: Q2 – Właściciel: CIO/CISO. To jest narracja, której oczekują audyt i nadzór: dowody odpowiedzialności, twarde KRI/KPI i jasny cykl raportowania pod NIS2 i DORA.
3. Zgłaszanie incydentów pod NIS2 i DORA: zegar, progi, kanały
Zegary są bezlitosne: pod NIS2 leci trzyczęściowa sekwencja – w 24h wysyłasz wstępne ostrzeżenie (co się dzieje i czy rośnie ryzyko), w 72h składasz zgłoszenie z twardymi faktami (wpływ, sektor, podjęte działania), a w ciągu 1 miesiąca dorzucasz raport końcowy z wnioskami i planem naprawczym. DORA pracuje w rytmie initial – intermediate – final (RTS/ITS) i odpala się przy poważnym incydencie ICT – czyli takim, który rozwala ciągłość usług, dotyka znaczącej liczby klientów, przekracza progi czasu niedostępności, powoduje istotne straty finansowe lub ryzyko systemowe. Kanały? CSIRT/kompetentny organ dla NIS2 oraz nadzór finansowy dla DORA, często przez portale zgłoszeniowe z wymaganym formatem.
- SLA procesu (detekcja → triage → klasyfikacja → zgłoszenie)
- Detekcja (SOC/IT Ops) – max 15–30 min; kanał: SIEM/SOAR.
- Triage (Incident Manager) – max 60 min; decyzja: eskalacja czy zamknięcie.
- Klasyfikacja (CISO + Risk) – max 2–4 h; ustalenie: NIS2/DORA i próg major.
- Zgłoszenie (Regulatory Lead) – NIS2: 24h/72h/1 m-c; DORA: initial/intermediate/final; kanały: CSIRT, właściwy organ, KNF/ESAs.
- Playbook – “uruchom i biegnij”
- Kto uruchamia: Duty Incident Manager po potwierdzeniu alertu P1.
- Wzór zgłoszenia: portal regulacyjny lub mail: temat “INC-P1 | UUID incydentu | data | status initial”.
- Lista danych: UUID incydentu, czas wykrycia, systemy/usługi, wektor ataku, wpływ na klientów i SLA, geografia/sektor, działania naprawcze, kontakt 24/7, plan comms.
- Klasyfikacja incydentu – kiedy “major”
- Tak, “major”: przerwa w krytycznej bankowości online > 2h, dotyczy > 10% klientów, odcięte płatności, realne straty finansowe, eskalacja do mediów.
- Nie, poniżej progu: krótkie degradacje bez wpływu na klientów, pojedynczy system wewnętrzny, szybki rollback bez strat.
Strony trzecie i koncentracja ryzyka: od due diligence do exit planów
DORA i NIS2 nie kupują wymówki „mamy certyfikat ISO 27001”. Potrzebujesz realnej kontroli nad dostawcami ICT, ich koncentracją ryzyka oraz zdolności do wyjścia (exit) bez bólu. Zacznij od klarownej macierzy tieringu dostawców: Tier 1 – krytyczny (usługa o wysokim wpływie na ciągłość i finansy, przetwarzane dane wrażliwe, niska zastępowalność), Tier 2 – ważny (istotny wpływ, dane operacyjne, średnia zastępowalność), Tier 3 – wspierający (niski wpływ, dane standardowe, łatwa zastępowalność). Kryteria oceny: wpływ usługi (RTO/RPO, krytyczne procesy), rodzaj danych (PII, finansowe, tajemnice przedsiębiorstwa), zastępowalność (czas i koszt migracji, lock-in technologiczny). Dla dostawcy oznaczonego jako ICT third-party provider – critical w logice DORA dokumentujesz: skalę zależności (liczba systemów i procesów zależnych), SPoF, regiony chmurowe, RTO/RPO, historię incydentów, wyniki testów odporności i status exit planu.
Ustal twarde zasady gry w umowach i monitoruj koncentrację ryzyka jak na żywym pulpicie. Minimalny zestaw klauzul kontraktowych: prawo do audytu/inspekcji, raportowanie incydentów w twardych SLA (czasy zgłoszeń i aktualizacji), kontrola podwykonawców (zgoda ex ante, pełna lista), gwarantowane RTO/RPO, obowiązkowe testy DR/BCP z udziałem klienta, prawo do exit i transferu danych w otwartych formatach, wsparcie migracji. Mini-dashboard koncentracji, który warto mieć co tydzień: top 5 dostawców krytycznych (udział w procesach), wspólne punkty awarii (np. jeden operator DC dla kilku usług), rozkład regionów chmurowych i availability zones, zidentyfikowane single points of failure, wskaźniki zdolności do zastąpienia (czas migracji, dostępne alternatywy). To pozwala szybko wychwycić niebezpieczne skupiska zależności, które DORA uzna za nieakceptowalne.
- Checklista umowna: audyt/inspekcje; raportowanie incydentów (czasy, kanały, treść); podwykonawcy (aprobata, łańcuch odpowiedzialności); RTO/RPO i kary umowne; testy DR/BCP; prawo do exit i utrzymanie usług podczas migracji; formaty danych i kasowanie po migracji.
- Szablon exit planu – dostawca Tier 1: kroki (freeze zmian, pełna eksportacja danych, weryfikacja integralności, dual run, przełączenie, dekonsolidacja); czas (np. T0–T+90 dni z kamieniami milowymi); dane (formaty, szyfrowanie, klucze KMS, sumy kontrolne); zasoby (zespół, budżet, narzędzia); alternatywa (kontrakt ramowy z drugim dostawcą, wstępnie przygotowane IaC); test wyjścia co 12 miesięcy z protokołem i lekcjami.
- Kryteria “ICT third-party provider – critical” wg DORA: wpływ na ciągłość i stabilność finansową; szeroka skala użycia w kluczowych procesach; przetwarzanie danych wrażliwych; ograniczona zastępowalność; historia incydentów o wysokiej wadze. Dokumentacja: karta dostawcy, ocena ryzyka, wyniki testów, mapa zależności, decyzja komitetu ryzyka.
Testowanie odporności operacyjnej: ćwiczenia, scenariusze i TLPT
Roczny plan testów to zero miejsca na zgadywanie: ustaw harmonogram, który łączy ćwiczenia stołowe (decyzyjność i komunikacja), DR/BCM (realne przełączenia i odtworzenia), testy techniczne (backupy, segmentacja, restore próbkowy) oraz TLPT realizowane co trzy lata lub częściej według profilu ryzyka. Użyj prostej tabeli scenariuszy: scenariusz | cel | systemy | mierniki sukcesu — przykłady: ransomware w płatnościach, utrata regionu chmury, awaria KMS, kompromitacja konta uprzywilejowanego. Zasady dla TLPT: zakres opieraj o krytyczne usługi, zapewnij niezależność zespołu testującego, a po wszystkim przeprowadź twardy debrief z planem naprawczym. Mierz jakość: odsetek scenariuszy zaliczonych, top 5 błędów (powtarzalne luki i gapy procesowe), czas odbudowy vs RTO. Experts’ Advice: dokumentuj kryteria zaliczenia przed startem i eskaluj każde odstępstwo od RTO/RPO jak incydent — bez pudrowania rzeczywistości.
Mini‑raport po ćwiczeniu (format, który działa): wnioski — „opóźniona decyzja o przełączeniu zwiększyła MTTR o 40%, brak automatycznego runbooka dla baz transakcyjnych, alerty z SIEM trafiły do niewłaściwej kolejki”. Trzy działania naprawcze: „wdrożyć runbook odtworzeniowy i test cron co tydzień” → właściciel: Head of SRE → termin: 30 dni; „przerejestrować playbook eskalacyjny i routing alertów” → właściciel: SOC Lead → termin: 14 dni; „ustawić próg decyzji o failoverze na podstawie SLA i BIA” → właściciel: BCM Manager → termin: 21 dni. Experts’ Advice: trzymaj wszystkie scenariusze i metryki w jednym repo (żywa „książka chaosu”), a co kwartał powtarzaj najgorszy scenariusz, aż wskaźniki RTO/RPO i MTTR będą stabilne również poza godzinami pracy.
100-dniowa roadmapa: metryki, OKR-y i zamknięcie luk
Plan 0–30/31–60/61–100 dni to nie lista zadań, tylko widoczne rezultaty spięte z NIS2 i DORA. 0–30 dni: uruchomiony proces 72h NIS2 (kanał zgłoszeń, playbook, odpowiedzialni), mapa krytycznych dostawców z oceną due diligence, baseline MTTD/MTTR z realnych alertów. 31–60 dni: zintegrowany test raportowania incydentów end-to-end (z zegarem i komunikacją do regulatora), runbook DORA dla ciągłości (RTO/RPO na systemach istotnych), kontraktowe zapisy o bezpieczeństwie i audytowalności u dostawców. 61–100 dni: redukcja MTTR o 30% dzięki automatyzacji reakcji, pokrycie due diligence 100% dostawców krytycznych, zamknięte luki H i zaplanowane L/M. Ścieżka eskalacji dla ryzyk, których nie domkniesz: formalna akceptacja ryzyka przez zarząd z datą wygaśnięcia i warunkiem (np. wdrożenie EDR w 45 dni), inaczej uruchamiasz plan awaryjny. Mini-OKR (Cel | Kluczowe Rezultaty | Właściciel | Data): Cel: zgodne raportowanie incydentów; KR1: 100% zespołów przeszkolonych; KR2: 1 test raportowania w 30 dni; Właściciel: CISO; Data: DD/MM. To jest paliwo, które przebija etykietkę ISO/IEC 27001 i pokazuje realną gotowość na NIS2 i DORA.
Mierniki, które widzą audytorzy i regulatorzy: % luk zamkniętych (H/M/L), pokrycie due diligence dostawców krytycznych, trend MTTD/MTTR, liczba wykonanych ćwiczeń (table-top, techniczne, komunikacyjne). Plan dowodowy do audytu: tabele kontroli z sekcji 1–5, protokoły z testów, raporty incydentów, zrzuty z SIEM/EDR z metrykami, umowy z dostawcami z klauzulami DORA/NIS2, matryca RTO/RPO, lista właścicieli ryzyk. Case Studies: fintech z certyfikatem ISO/IEC 27001 poległ na audycie DORA, bo nie miał 72h procesu raportowania – 30 dni później naprawili to testem z zegarem i backupowym kanałem komunikacji. Operator usług kluczowych: dopiero segmentacja systemów istotnych i twarde OKR-y zbiły MTTR o 41%, co zamknęło luki H przed kontrolą NIS2. To są namacalne rezultaty, które zwiększają zgodność i odporność, a nie tylko papier.
Najczęściej zadawane pytania
Czy organizacja bezpośrednio nieobjęta DORA powinna już teraz dostosować swoje procesy?
Tak, jeśli świadczysz usługi dla podmiotów finansowych lub jesteś w ich łańcuchu dostaw ICT, klauzule umowne i due diligence wymuszą elementy DORA. Wcześniejsze dostosowanie ogranicza ryzyko utraty kontraktów i przyspiesza audyty dostawców.
Jak pogodzić wymagania NIS2 i DORA z istniejącym ISMS, aby uniknąć podwójnej pracy?
Utwórz jeden rejestr kontroli i dowodów mapujący ISO 27001 do wymagań NIS2/DORA, a procesy (incydenty, dostawcy, testy) prowadź jako wspólne, z różnicami odzwierciedlonymi w progach, terminach i kanałach raportowania.
Jakie narzędzia praktycznie ułatwiają raportowanie incydentów w 24/72h?
SOAR/IR platformy z predefiniowanymi workflow, szablony zgłoszeń do CSIRT/nadzoru, integracja z CMDB i klasyfikacją wpływu, oraz repozytorium artefaktów (działania, czasy, decyzje) do automatycznego tworzenia raportów wstępnych/końcowych.
Jak udowodnić “kulturę zgodności” w ocenie regulatora lub audytu?
Regularne protokoły decyzji zarządu, cykliczne dashboardy KRI/KPI, wyniki ćwiczeń i planów naprawczych z realizacją, przeglądy apetytu na ryzyko, rejestr szkoleń (w tym zarządu) oraz ścieżka eskalacji i akceptacji ryzyk z datami.
Kiedy angażować zewnętrznych dostawców do TLPT i testów odporności?
Gdy testujesz usługi krytyczne, wymagane jest obiektywne spojrzenie i niezależność, lub brakuje kompetencji wewnętrznych. Zaplanuj przetarg/kontrakt min. 3–4 miesiące wcześniej, z zakresem, metrykami sukcesu i planem naprawczym.
—
Artykuł sponsorowany
