Praktyczne przewodniki po regulacjach cyberbezpieczeństwa i wymaganiach zgodności dla firm działających w Polsce i Unii Europejskiej. Wyjaśniamy NIS2, ustawę o KSC, DORA, Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework oraz powiązane obowiązki w prosty, biznesowy sposób.
Kary za NIS2. Co zarząd musi wiedzieć o nowej dyrektywie?
Kary za NIS2 mogą sięgać milionów euro albo procentu globalnego rocznego obrotu, ale dla zarządu najważniejsze nie są same liczby. NIS2 przenosi cyberbezpieczeństwo na poziom odpowiedzialności kierownictwa: zarząd ma zatwierdzać środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie, rozumieć obowiązki zgłaszania incydentów i zapewnić dowody zgodności. Kara grozi nie tylko za sam incydent, ale za brak właściwego zarządzania ryzykiem, brak raportowania, ignorowanie zaleceń organu lub brak realnych kontroli.
Opracowanie: Zespół redakcyjny CCyber
Kary za NIS2 mogą być bardzo wysokie, ale zarząd nie powinien traktować dyrektywy wyłącznie jako tematu sankcji. NIS2 wymaga, aby organizacje objęte regulacją miały realny system zarządzania ryzykiem cyber, procedury zgłaszania incydentów, nadzór nad dostawcami, ciągłość działania, szkolenia, kontrolę dostępu, bezpieczeństwo łańcucha dostaw i dowody wdrożenia. Dyrektywa wskazuje, że dla podmiotów kluczowych maksymalna kara ma wynosić co najmniej 10 000 000 EUR albo 2% całkowitego światowego rocznego obrotu, zależnie od tego, która kwota jest wyższa. Dla podmiotów ważnych próg wynosi co najmniej 7 000 000 EUR albo 1,4% obrotu. Szczegółowe zasady w Polsce trzeba jednak sprawdzać w krajowej ustawie wdrażającej NIS2, ponieważ dyrektywa jest wdrażana przez prawo krajowe.
Lipiec 2026
NIS2 jest dyrektywą Unii Europejskiej. Oznacza to, że państwa członkowskie muszą wdrożyć jej wymagania do prawa krajowego. Sama dyrektywa określa minimalny poziom wymagań, w tym minimalny poziom maksymalnych kar, ale szczegółowy tryb kontroli, organ nadzoru, procedury, definicje krajowe i szczegółowe sankcje wynikają z ustawy wdrażającej w danym państwie.
Dla zarządu praktyczny wniosek jest prosty: nie wystarczy znać tekst dyrektywy. Trzeba sprawdzić trzy rzeczy:
W Polsce wdrożenie NIS2 jest powiązane z ustawą o krajowym systemie cyberbezpieczeństwa i jej nowelizacją. Dlatego w praktyce zarząd powinien pracować na aktualnym tekście krajowej ustawy, a nie tylko na ogólnych prezentacjach o NIS2.
Dla podmiotów kluczowych dyrektywa przewiduje, że naruszenia obowiązków dotyczących środków zarządzania ryzykiem cyber i zgłaszania incydentów mogą podlegać administracyjnym karom pieniężnym o maksymalnym poziomie co najmniej:
Dla podmiotów ważnych dyrektywa przewiduje maksymalny poziom kar co najmniej:
To bardzo ważne sformułowanie. NIS2 wskazuje minimalny poziom maksymalnych kar, który państwa członkowskie muszą zapewnić. Krajowe przepisy mogą zawierać własne rozwiązania, procedury, przeliczenia, kary okresowe, zasady dla administracji publicznej i dodatkowe środki nadzorcze.
Nie każdy incydent oznacza automatycznie karę. Cyberbezpieczeństwo nie polega na obietnicy, że incydent nigdy się nie wydarzy. Regulacja patrzy raczej na to, czy organizacja zarządzała ryzykiem odpowiednio do swojej skali, sektora, zagrożeń i wpływu na usługi.
Ryzyko kary rośnie, gdy firma:
Najważniejszy komunikat dla zarządu: organ nie będzie oceniał tylko tego, że coś się stało. Będzie oceniał, czy firma działała rozsądnie, proporcjonalnie, terminowo i z dowodami.
NIS2 wymaga środków technicznych, operacyjnych i organizacyjnych. To nie jest tylko firewall albo antywirus. To cały system zarządzania ryzykiem cyber.
Do obszarów ryzyka należą między innymi:
NIS2 wprowadza rygorystyczne terminy zgłaszania istotnych incydentów. W uproszczeniu organizacja powinna przygotować się na:
Praktyczny problem polega na tym, że firma musi mieć proces, który działa w stresie. Nie da się przygotować dobrego zgłoszenia w 24 godziny, jeśli wcześniej nie wiadomo, kto decyduje, kto zbiera fakty, kto kontaktuje CSIRT, kto informuje zarząd i kto prowadzi komunikację.
NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyber i nadzorowały ich wdrożenie. Zarząd nie może ograniczyć się do stwierdzenia „IT się tym zajmuje”.
W praktyce zarząd powinien mieć:
Ryzyko sankcji rośnie, gdy firma otrzyma zalecenia, nakazy albo wyniki audytu i nie podejmie działań. NIS2 przewiduje szeroki katalog środków nadzorczych, nie tylko kary pieniężne.
Organ może w praktyce wymagać między innymi:
W zgodności z NIS2 duże znaczenie mają dowody. Firma może mieć dobre działania techniczne, ale jeśli nie potrafi ich udokumentować, trudno będzie obronić swoje podejście przed organem, audytorem albo klientem.
Dowody mogą obejmować:
NIS2 wyraźnie podnosi cyberbezpieczeństwo do poziomu zarządu. Nie chodzi o to, że każdy członek zarządu ma sam konfigurować systemy. Chodzi o to, że zarząd ma rozumieć ryzyko, zatwierdzać kierunek działań, nadzorować wdrożenie i zapewnić zasoby.
NIS2 wymaga, aby państwa członkowskie zapewniły możliwość pociągnięcia osób odpowiedzialnych albo przedstawicieli prawnych podmiotu kluczowego do odpowiedzialności za naruszenie obowiązków zapewnienia zgodności. Dyrektywa przewiduje też możliwość czasowego zakazu pełnienia funkcji zarządczych w określonych przypadkach dotyczących podmiotów kluczowych, zgodnie z prawem krajowym i gwarancjami proceduralnymi.
To nie oznacza, że każda awaria albo każdy incydent automatycznie prowadzi do osobistej odpowiedzialności członka zarządu. Oznacza jednak, że zarząd powinien traktować cyberbezpieczeństwo jako obowiązek nadzorczy, a nie tylko techniczne zadanie IT.
NIS2 rozróżnia podmioty kluczowe i ważne. To rozróżnienie wpływa między innymi na poziom nadzoru, podejście organów i maksymalne poziomy kar.
To zwykle organizacje z sektorów o najwyższej krytyczności, których zakłócenie może mieć szczególnie istotny wpływ na społeczeństwo, gospodarkę, bezpieczeństwo publiczne albo ciągłość ważnych usług.
To organizacje objęte regulacją, które również muszą wdrożyć wymagania NIS2, ale podlegają innemu modelowi nadzoru i niższym minimalnym progom maksymalnych kar.
Zarząd nie powinien zgadywać kategorii. Powinien zlecić formalną analizę podlegania, która obejmuje sektor, wielkość firmy, rodzaj świadczonych usług, zależności grupowe, kraj działalności i przepisy krajowe.
NIS2 obejmuje szeroki zakres sektorów. Komisja Europejska wskazuje, że dyrektywa ustanawia ramy dla 18 krytycznych sektorów w Unii Europejskiej.
Zakres regulacji może zależeć od szczegółów krajowych, wielkości organizacji i rodzaju usługi. Dlatego analiza podlegania powinna być pierwszym krokiem.
Po poważnym incydencie organ lub klient może zapytać nie tylko o to, co się stało. Pytania zwykle dotyczą przygotowania organizacji przed incydentem.
Najgorsza odpowiedź brzmi: „nie wiemy”, „nie było właściciela”, „nie było procedury”, „nie testowaliśmy”, „nie mamy dowodów”.
Najlepsza odpowiedź brzmi: „mieliśmy proces, znamy zakres, zgłosiliśmy w terminie, mamy logi, mamy raport, mamy decyzje zarządu, mamy plan naprawczy i potrafimy pokazać dowody”.
Najpierw trzeba ustalić, czy firma podlega regulacji i w jakiej roli.
Analiza powinna obejmować:
Dowód do przygotowania: raport analizy podlegania NIS2 i decyzja zarządu o dalszych działaniach.
Firma powinna porównać obecny stan z wymaganiami NIS2. Chodzi o praktyczne luki, a nie tylko listę dokumentów.
Sprawdź:
Dowód do przygotowania: NIS2 gap analysis z priorytetami i planem działań.
Zarząd potrzebuje widzieć cyberbezpieczeństwo jako ryzyko biznesowe. Rejestr ryzyk powinien pokazywać wpływ na usługi, klientów, przychody, ciągłość działania i zgodność.
Rejestr powinien zawierać:
Dowód do przygotowania: rejestr ryzyk cyber zatwierdzony lub okresowo przeglądany przez zarząd.
Firma musi wiedzieć, jak działać w pierwszych godzinach incydentu. NIS2 wymaga szybkiego raportowania, więc proces musi być przećwiczony.
Plan powinien wskazywać:
Dowód do przygotowania: incident response plan i raport z ćwiczenia tabletop.
NIS2 mocno podkreśla bezpieczeństwo łańcucha dostaw. Firma powinna wiedzieć, którzy dostawcy są krytyczni i jakie ryzyka wnoszą.
Program dostawców powinien obejmować:
Dowód do przygotowania: rejestr dostawców i raport oceny ryzyka łańcucha dostaw.
Zarząd powinien otrzymywać regularny, zrozumiały raport. Nie musi zawierać nadmiaru technicznych szczegółów, ale musi pokazywać ryzyko, decyzje i postęp.
Raport powinien obejmować:
Dowód do przygotowania: cykliczny dashboard NIS2 dla zarządu.
IT może wdrażać wiele kontroli, ale odpowiedzialność dotyczy całej organizacji: zarządu, ryzyka, prawników, dostawców, finansów, HR, komunikacji i ciągłości działania.
Kary są ważne, ale lepsze pytanie brzmi: czy firma potrafi zapewnić ciągłość usług, zgłosić incydent w terminie i pokazać dowody zarządzania ryzykiem?
Firma zakłada, że NIS2 jej nie dotyczy, bo nie jest dużą infrastrukturą krytyczną. Tymczasem zakres NIS2 jest szerszy niż wcześniejsze regulacje.
Bez dowodów trudno pokazać, że środki zostały wdrożone, testowane i nadzorowane.
Terminy zgłaszania są krótkie. Bez ćwiczenia firma może stracić cenne godziny na ustalanie ról i kanałów komunikacji.
Dostawcy ICT, chmury, oprogramowania, integratorzy i firmy outsourcingowe mogą być źródłem istotnego ryzyka.
NIS2 wymaga, aby członkowie organów zarządzających mieli wiedzę potrzebną do rozumienia ryzyka i praktyk zarządzania ryzykiem cyber.
Zarząd może zaakceptować ryzyko, ale powinien robić to świadomie, na podstawie danych, a nie przez brak decyzji.
Firma technologiczna świadczy usługi dla klientów z sektora ochrony zdrowia i przemysłu. Zarząd początkowo uznaje, że NIS2 dotyczy głównie operatorów infrastruktury krytycznej, więc temat odkłada na później. Po analizie okazuje się, że firma może być istotnym dostawcą w łańcuchu usług objętych wymaganiami klientów, a część obowiązków NIS2 będzie wpływać na umowy, audyty i oczekiwania bezpieczeństwa.
Firma wykonuje gap analysis. Największe luki to brak formalnego rejestru ryzyk, nieprzetestowany incident response, brak cyklicznego access review, słabe dowody backupu, brak oceny dostawców i brak raportowania cyber do zarządu. Zespół IT miał wiele dobrych praktyk, ale nie były one uporządkowane ani udokumentowane.
Zarząd zatwierdza 90-dniowy plan: analiza podlegania, rejestr ryzyk, tabletop, MFA dla kont krytycznych, test restore, program dostawców i dashboard. Po trzech miesiącach firma nie jest „gotowa na wszystko”, ale ma dowody, właścicieli i plan. To znacząco zmniejsza ryzyko sankcji, ale też zwiększa odporność biznesową.
ccyber.io pomaga zarządom i zespołom bezpieczeństwa przygotować organizację do NIS2 w sposób praktyczny, mierzalny i nastawiony na dowody. Nie zaczynamy od dokumentów dla dokumentów. Zaczynamy od podlegania, ryzyka, usług krytycznych, incydentów, dostawców i odpowiedzialności zarządu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Board Readiness Workshop. W krótkim warsztacie można ustalić, czy firma podlega NIS2, jakie są najważniejsze ryzyka, co musi wiedzieć zarząd, jakie decyzje są potrzebne i które działania warto rozpocząć natychmiast.
Dla podmiotów kluczowych dyrektywa wskazuje maksymalny poziom kar co najmniej 10 000 000 EUR albo 2% światowego rocznego obrotu. Dla podmiotów ważnych co najmniej 7 000 000 EUR albo 1,4% obrotu. Szczegóły wynikają z prawa krajowego.
Tak, NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyber, nadzorowały ich wdrożenie i mogły ponosić odpowiedzialność za naruszenia, zgodnie z prawem krajowym.
Nie każdy incydent oznacza automatycznie karę. Ryzyko kary rośnie, gdy firma nie miała adekwatnych środków, nie zgłosiła incydentu, zignorowała zalecenia albo nie potrafiła pokazać dowodów.
Podmiot kluczowy ma zwykle większą krytyczność i podlega mocniejszemu nadzorowi oraz wyższemu poziomowi kar. Podmiot ważny również musi spełniać wymagania, ale podlega innemu modelowi nadzoru i niższym progom kar.
Najpierw zlecić analizę podlegania NIS2, potem gap analysis, rejestr ryzyk, plan działań, plan zgłaszania incydentów i dashboard nadzorczy.
Tak. Dyrektywa wymaga, aby członkowie organów zarządzających odbywali szkolenia, które pozwolą im rozumieć ryzyka cyber i oceniać praktyki zarządzania tym ryzykiem.
ISO 27001 może bardzo pomóc, bo porządkuje zarządzanie bezpieczeństwem informacji, ryzykiem, kontrolami i ciągłym doskonaleniem. Nie zastępuje jednak automatycznie analizy NIS2, obowiązków incydentowych i wymagań krajowych.
Zacznij od czterech rzeczy: analiza podlegania, rejestr ryzyk, plan incydentowy z terminami 24 i 72 godziny oraz raport dla zarządu z priorytetami i budżetem.
Kary za NIS2 są wysokie, ale największa zmiana nie polega wyłącznie na wysokości sankcji. Największa zmiana polega na tym, że cyberbezpieczeństwo staje się formalnym tematem zarządu, nadzoru, dowodów i odpowiedzialności organizacyjnej.
Zarząd powinien rozumieć, czy firma podlega NIS2, jakie usługi są krytyczne, jakie ryzyka są najważniejsze, czy firma potrafi zgłosić incydent w terminie, czy dostawcy są pod kontrolą i czy istnieją dowody wdrożenia środków bezpieczeństwa.
Najlepszą odpowiedzią na ryzyko kar nie jest panika ani sama dokumentacja. Najlepszą odpowiedzią jest praktyczny program NIS2 readiness: analiza podlegania, gap analysis, rejestr ryzyk, incident response, dostawcy, szkolenia, testy, metryki i regularny nadzór zarządu.
Cyber Resilience Act: co oznacza dla producentów software i hardware
Cyber Resilience Act oznacza, że producenci software i hardware sprzedający produkty z elementami cyfrowymi na rynku UE muszą projektować je bezpiecznie, oceniać ryzyko cyber, prowadzić dokumentację techniczną, zarządzać podatnościami, zapewniać aktualizacje bezpieczeństwa, określić okres wsparcia, przygotować ocenę zgodności, oznakowanie CE i raportować aktywnie wykorzystywane podatności oraz poważne incydenty.
Opracowanie: Zespół redakcyjny CCyber
Cyber Resilience Act, czyli CRA, to unijne rozporządzenie, które zmienia sposób tworzenia i sprzedawania produktów cyfrowych w UE. Dotyczy producentów software i hardware, jeśli ich produkty z elementami cyfrowymi są wprowadzane na rynek Unii Europejskiej. W praktyce CRA wymaga, aby cyberbezpieczeństwo było wbudowane w produkt od projektu, a nie dodawane dopiero po incydencie. Producent musi ocenić ryzyko cyber, wdrożyć wymagania bezpieczeństwa, kontrolować komponenty, obsługiwać podatności, dostarczać aktualizacje, przygotować dokumentację techniczną, przejść ocenę zgodności, oznaczyć produkt CE i raportować określone podatności oraz incydenty.
Lipiec 2026
Cyber Resilience Act to unijne rozporządzenie ustanawiające horyzontalne wymagania cyberbezpieczeństwa dla produktów z elementami cyfrowymi. Celem CRA jest zwiększenie bezpieczeństwa produktów software i hardware dostępnych na rynku UE oraz ograniczenie ryzyka wynikającego z podatności, braku aktualizacji i słabej konfiguracji domyślnej.
CRA jest ważne, ponieważ dotychczas wiele produktów cyfrowych trafiało na rynek bez wystarczającego poziomu bezpieczeństwa, bez jasnego okresu wsparcia, bez sprawnego procesu aktualizacji i bez transparentnej obsługi podatności. CRA zmienia ten model. Producent ma odpowiadać za bezpieczeństwo produktu nie tylko w dniu sprzedaży, ale także w okresie wsparcia.
W praktyce CRA wymaga, aby produkt był:
CRA dotyczy produktów z elementami cyfrowymi udostępnianych na rynku UE. Może obejmować zarówno produkty końcowe, jak i komponenty software lub hardware wprowadzane oddzielnie na rynek.
Największe obowiązki ma producent. CRA może jednak dotyczyć także innych operatorów gospodarczych w łańcuchu dostaw.
Najważniejsze pytanie brzmi: czy Twoja firma wprowadza produkt z elementami cyfrowymi na rynek UE pod własną nazwą lub znakiem towarowym? Jeśli tak, CRA może być bezpośrednio istotne.
To jedno z najczęstszych pytań. CRA nie jest klasyczną regulacją dla każdej usługi SaaS jako samodzielnej usługi online. Jednocześnie CRA może objąć rozwiązania zdalnego przetwarzania danych, jeśli są zaprojektowane i rozwijane przez producenta lub pod jego odpowiedzialnością oraz są niezbędne, aby produkt z elementami cyfrowymi wykonywał jedną ze swoich funkcji.
Przykład: jeśli urządzenie IoT działa tylko z chmurą producenta, ta część chmurowa może być istotna dla oceny produktu. Jeśli firma sprzedaje wyłącznie usługę SaaS bez produktu z elementami cyfrowymi w rozumieniu CRA, wymaga to osobnej analizy. Nie warto przyjmować automatycznie, że „SaaS zawsze podlega” albo „SaaS nigdy nie podlega”.
Praktyczna decyzja: każda firma SaaS, cloud-connected, IoT, embedded lub produktowa powinna wykonać krótką analizę zakresu CRA.
Dla producentów software CRA oznacza konieczność przejścia od podejścia „naprawimy, jeśli klient zgłosi problem” do podejścia product security by design. Bezpieczeństwo musi wejść do backlogu, procesu rozwoju, testów, release managementu, dokumentacji, obsługi podatności i komunikacji z użytkownikami.
Dla producentów hardware CRA oznacza, że bezpieczeństwo nie kończy się na fizycznym urządzeniu. Trzeba uwzględnić firmware, bootloader, komunikację, interfejsy, aktualizacje, komponenty, aplikacje towarzyszące, chmurę producenta i dokumentację dla użytkownika.
Pierwszy krok to analiza zakresu. Firma powinna ustalić, czy produkt jest produktem z elementami cyfrowymi, czy jest udostępniany na rynku UE oraz jaką rolę pełni firma: producenta, importera, dystrybutora, dostawcy komponentu lub podwykonawcy.
Dowód do przygotowania: analiza zakresu CRA dla każdego produktu lub rodziny produktów.
Produkt może należeć do kategorii domyślnej, ważnej albo krytycznej. Ta klasyfikacja wpływa na procedurę oceny zgodności i potencjalny udział jednostki notyfikowanej.
Sprawdź:
Dowód do przygotowania: karta klasyfikacji produktu pod CRA.
Ocena ryzyka cyber jest podstawą wdrażania wymagań. Producent powinien wiedzieć, jakie zagrożenia dotyczą produktu, jakie dane i funkcje są krytyczne oraz jakie zabezpieczenia są potrzebne.
Ocena powinna obejmować:
Dowód do przygotowania: product cybersecurity risk assessment.
CRA wymaga, aby produkt spełniał zasadnicze wymagania bezpieczeństwa. W praktyce chodzi między innymi o zabezpieczenia domyślne, kontrolę dostępu, minimalizację powierzchni ataku, ochronę danych, odporność na nadużycia i możliwość bezpiecznych aktualizacji.
Wymagania trzeba przełożyć na konkretne zadania produktowe:
Dowód do przygotowania: rejestr wymagań CRA mapowany do funkcji, kontroli i dowodów.
Producent nie może ignorować komponentów zewnętrznych. Jeżeli produkt używa bibliotek, pakietów, firmware, modułów, systemów operacyjnych lub komponentów hardware, trzeba ocenić ich wpływ na bezpieczeństwo produktu.
W praktyce potrzebne są:
Dowód do przygotowania: SBOM, rejestr komponentów i proces monitorowania podatności.
CRA wymaga, aby producent obsługiwał podatności produktu w okresie wsparcia. To oznacza proces, nie jednorazowe działanie.
Proces powinien obejmować:
Dowód do przygotowania: vulnerability handling procedure i rejestr podatności produktowych.
Producent powinien mieć możliwość dostarczania aktualizacji bezpieczeństwa. W zależności od typu produktu mogą to być aktualizacje automatyczne, aktualizacje firmware, pakiety instalacyjne, aktualizacje aplikacji mobilnej lub poprawki komponentów.
Trzeba ustalić:
Dowód do przygotowania: polityka aktualizacji bezpieczeństwa i opis okresu wsparcia.
Dokumentacja techniczna będzie jednym z najważniejszych dowodów zgodności. Powinna pokazywać, jak produkt spełnia wymagania CRA i jak producent zarządza ryzykiem.
Dokumentacja powinna zawierać między innymi:
Dowód do przygotowania: technical documentation pack dla produktu.
Przed wprowadzeniem produktu na rynek producent musi przeprowadzić odpowiednią procedurę oceny zgodności. Dla wielu produktów może to być samoocena, ale dla części produktów ważnych i krytycznych procedura będzie bardziej wymagająca.
Do ustalenia:
Dowód do przygotowania: conformity assessment file, EU declaration of conformity i decyzja o procedurze oceny.
Po wykazaniu zgodności producent może oznaczyć produkt CE i przekazać użytkownikowi wymagane informacje oraz instrukcje. Informacje powinny pozwalać na bezpieczną instalację, konfigurację, eksploatację i utrzymanie produktu.
Informacje dla użytkownika powinny obejmować:
Dowód do przygotowania: instrukcje użytkownika, deklaracja zgodności i oznakowanie CE.
CRA weszło w życie.
Zaczęły obowiązywać przepisy dotyczące notyfikacji jednostek oceniających zgodność.
Zaczynają obowiązywać obowiązki raportowania aktywnie wykorzystywanych podatności i poważnych incydentów mających wpływ na bezpieczeństwo produktów z elementami cyfrowymi.
Zaczynają być stosowane główne obowiązki CRA.
Produkty wprowadzone na rynek przed 11 grudnia 2027 r. zasadniczo będą objęte głównymi obowiązkami CRA wtedy, gdy od tej daty zostaną istotnie zmodyfikowane. Obowiązki raportowania dotyczą jednak także produktów już udostępnionych na rynku UE.
Od 11 września 2026 r. producenci będą musieli raportować aktywnie wykorzystywane podatności oraz poważne incydenty wpływające na bezpieczeństwo produktu z elementami cyfrowymi.
Zgłoszenia mają być składane przez CRA Single Reporting Platform zarządzaną przez ENISA. W praktyce producent musi mieć wewnętrzny proces, który pozwala szybko ustalić, czy zdarzenie podlega zgłoszeniu, zebrać fakty i podjąć decyzję.
Dowód do przygotowania: CRA vulnerability and incident reporting playbook.
CRA nie zastępuje innych regulacji. Dotyczy przede wszystkim bezpieczeństwa produktu z elementami cyfrowymi. NIS2 dotyczy cyberodporności organizacji i usług w określonych sektorach. DORA dotyczy odporności cyfrowej sektora finansowego i dostawców ICT w tym ekosystemie. RODO dotyczy ochrony danych osobowych.
Firma technologiczna może podlegać kilku wymaganiom jednocześnie. Przykład: producent aplikacji może mieć obowiązki CRA dla produktu, wymagania NIS2 jako dostawca dla podmiotu kluczowego oraz wymagania RODO, jeśli przetwarza dane osobowe.
Przygotuj listę produktów software i hardware, które firma rozwija, sprzedaje lub udostępnia na rynku UE.
Dowód: product inventory.
Dla każdego produktu ustal, czy jest produktem z elementami cyfrowymi oraz jaka jest rola firmy.
Dowód: CRA applicability analysis.
Określ, czy produkt należy do kategorii domyślnej, ważnej lub krytycznej.
Dowód: product classification memo.
Wykonaj ocenę ryzyka produktu i określ wymagania bezpieczeństwa.
Dowód: product cybersecurity risk assessment.
Wdroż lub uporządkuj secure SDLC, kontrolę zależności, SBOM i testy bezpieczeństwa.
Dowód: secure SDLC policy, SBOM, wyniki SAST, DAST, SCA i testów manualnych.
Przygotuj proces obsługi podatności i punkt kontaktowy dla zgłoszeń.
Dowód: vulnerability handling procedure i coordinated vulnerability disclosure policy.
Określ okres wsparcia produktu oraz sposób dostarczania aktualizacji bezpieczeństwa.
Dowód: support period statement i security update policy.
Przygotuj dokumentację techniczną, dowody i procedurę oceny zgodności.
Dowód: technical documentation, conformity assessment file i EU declaration of conformity.
CRA dotyczy zarówno software, jak i hardware. Aplikacje, komponenty, firmware i produkty z chmurą producenta mogą wymagać analizy.
Główne obowiązki będą stosowane od 11 grudnia 2027 r., ale procesy, dokumentacja, SBOM, aktualizacje i obsługa podatności wymagają czasu. Obowiązki raportowania zaczynają się wcześniej.
CRA wymaga pracy prawnej, ale nie jest tylko dokumentacją. Trzeba zmienić proces rozwoju produktu, testy, release management, zarządzanie podatnościami i komunikację z użytkownikami.
Jeśli nikt nie odpowiada za product security, wymagania CRA będą rozproszone między legal, engineering, QA, support i zarząd.
Produkt może być podatny przez bibliotekę, firmware, zależność open source, komponent hardware albo usługę zewnętrzną. Bez listy komponentów firma nie wie, co ma aktualizować.
Adres e-mail do supportu nie wystarczy. Producent powinien mieć proces triage, priorytetyzacji, naprawy, komunikacji i dowodów.
Dokumentacja techniczna powinna powstawać równolegle z projektem. Tworzenie jej po fakcie jest droższe i często nie pokazuje realnych decyzji bezpieczeństwa.
Firma produkuje urządzenie IoT dla rynku europejskiego. Urządzenie ma firmware, aplikację mobilną, panel administratora i chmurę producenta, bez której część funkcji nie działa. Firma dotychczas skupiała się na funkcjach i czasie wejścia na rynek, a bezpieczeństwo było sprawdzane głównie na końcu projektu.
Po analizie CRA okazuje się, że firma musi przygotować ocenę ryzyka produktu, dokumentację techniczną, proces aktualizacji firmware, listę komponentów, obsługę podatności, okres wsparcia i informacje dla użytkowników. Dodatkowo trzeba ustalić, czy produkt należy do kategorii domyślnej, ważnej lub krytycznej.
Firma zaczyna od 90-dniowego planu. Najpierw tworzy listę komponentów, robi threat modeling, wdraża SCA dla software, przygotowuje proces CVD i porządkuje aktualizacje bezpieczeństwa. Następnie tworzy strukturę dokumentacji technicznej i mapuje wymagania CRA do kontroli oraz dowodów.
Największa zmiana nie polega na dodaniu jednego testu. Największa zmiana polega na tym, że bezpieczeństwo produktu staje się stałym procesem zarządzanym przez product, engineering, security, legal i zarząd.
ccyber.io pomaga producentom software i hardware przygotować produkty do Cyber Resilience Act w sposób praktyczny, techniczny i biznesowy. Łączymy perspektywę regulacji, product security, secure development, podatności, dokumentacji i oceny zgodności.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest CRA Product Readiness Workshop. Pozwala szybko ustalić, które produkty są objęte CRA, jakie są największe luki, jakie dowody trzeba przygotować i jak zaplanować prace przed terminami 2026 i 2027.
Nie. CRA dotyczy zarówno software, jak i hardware, jeśli są produktami z elementami cyfrowymi udostępnianymi na rynku UE.
Tak, aplikacja mobilna może być produktem z elementami cyfrowymi, jeśli jest udostępniana na rynku UE i spełnia kryteria rozporządzenia.
Nie automatycznie. Samodzielna usługa SaaS może wymagać innej analizy niż produkt z elementami cyfrowymi. CRA może jednak objąć zdalne przetwarzanie danych powiązane z produktem, jeśli jest niezbędne dla funkcji produktu.
Nie. Wiele produktów będzie mogło przejść samoocenę. Produkty ważne i krytyczne mogą wymagać bardziej rygorystycznej procedury oceny zgodności, w tym udziału jednostki notyfikowanej.
Najpierw przygotuj listę produktów i wykonaj analizę, czy podlegają CRA. Dopiero potem klasyfikuj produkt, oceniaj ryzyko, planuj wymagania i dokumentację.
CRA wymaga skutecznego zarządzania podatnościami produktu i jego komponentów. W praktyce SBOM jest jednym z najważniejszych narzędzi do kontroli składników software i reagowania na podatności.
Obowiązki raportowania aktywnie wykorzystywanych podatności i poważnych incydentów zaczynają obowiązywać od 11 września 2026 r.
Producent powinien przygotować ocenę ryzyka cyber produktu, secure development, proces obsługi podatności, aktualizacje bezpieczeństwa, dokumentację techniczną, procedurę oceny zgodności, informacje dla użytkownika i dowody spełnienia wymagań.
Cyber Resilience Act zmienia cyberbezpieczeństwo produktów cyfrowych z dobrej praktyki w wymóg rynkowy. Producent software lub hardware nie może ograniczyć się do deklaracji, że produkt jest bezpieczny. Musi mieć proces, dokumentację, dowody, aktualizacje i obsługę podatności przez okres wsparcia.
Dla producentów software CRA oznacza secure SDLC, SBOM, testy, vulnerability handling, CVD, aktualizacje i dokumentację. Dla producentów hardware oznacza bezpieczne firmware, kontrolę interfejsów, bezpieczne aktualizacje, zabezpieczenia domyślne, okres wsparcia i dokumentację techniczną.
Najlepsza strategia to zacząć od analizy zakresu i klasyfikacji produktów. Następnie trzeba wykonać gap analysis, ocenę ryzyka, wdrożyć proces product security i przygotować dowody zgodności. Firmy, które zaczną wcześniej, będą miały przewagę w sprzedaży B2B, audytach klientów i wejściu produktów na rynek UE.
Jak przygotować zarząd na NIS2? Praktyczne wskazówki
Przygotowanie zarządu na NIS2 nie polega na jednorazowej prezentacji prawnej. Zarząd powinien wiedzieć, czy firma podlega NIS2 lub KSC, jakie ryzyka cyber są najważniejsze, kto odpowiada za program zgodności, jakie środki trzeba zatwierdzić, jak raportować incydenty, jak kontrolować dostawców i jakie dowody będą potrzebne podczas audytu, kontroli lub rozmowy z klientem.
Opracowanie: Zespół redakcyjny CCyber
Żeby przygotować zarząd na NIS2, firma powinna zrobić pięć rzeczy: ustalić, czy podlega NIS2 lub krajowym przepisom wdrażającym dyrektywę, wyjaśnić zarządowi odpowiedzialność za nadzór nad ryzykiem cyber, przygotować rejestr najważniejszych ryzyk, pokazać luki względem wymaganych środków bezpieczeństwa i doprowadzić do konkretnych decyzji zarządu. Zarząd nie musi znać technicznych szczegółów konfiguracji systemów. Musi jednak rozumieć wpływ cyberbezpieczeństwa na działalność firmy, incydenty, dostawców, ciągłość działania, budżet, dowody zgodności i ryzyko rezydualne.
Lipiec 2026
Przygotowanie zarządu na NIS2 oznacza zbudowanie wspólnego zrozumienia, jakie obowiązki, ryzyka i decyzje wynikają z dyrektywy oraz z krajowych przepisów wdrażających NIS2. Nie chodzi o to, żeby zarząd znał wszystkie artykuły dyrektywy. Chodzi o to, żeby zarząd potrafił podjąć właściwe decyzje.
Zarząd powinien umieć odpowiedzieć na pytania:
Najprościej: zarząd nie musi zarządzać narzędziami security. Zarząd musi zarządzać ryzykiem i decyzjami.
NIS2 wzmacnia rolę organów zarządzających. Zarząd ma rozumieć ryzyko, zatwierdzać środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie i zapewnić, że organizacja traktuje cyberbezpieczeństwo jako element ciągłości działania oraz zarządzania firmą.
Dla zarządu oznacza to trzy poziomy odpowiedzialności:
To nie oznacza, że członek zarządu ma konfigurować MFA albo firewall. Oznacza, że zarząd powinien wiedzieć, czy MFA i inne środki są wdrożone, czy działają i czy ryzyko rezydualne jest akceptowalne.
Nie da się dobrze przygotować zarządu bez odpowiedzi na pytanie, czy firma w ogóle podlega wymaganiom. Analiza podlegania powinna być pierwszym dokumentem dla zarządu.
Analiza powinna uwzględniać:
Dowód do przygotowania: analiza podlegania NIS2 lub KSC z krótką rekomendacją dla zarządu.
Zarząd nie powinien dostać na start długiego wykładu technicznego. Najlepszy briefing powinien mieć 30-60 minut i zakończyć się decyzjami.
Briefing powinien wyjaśniać:
Dobry briefing nie kończy się slajdem „dziękuję”. Kończy się listą decyzji, właścicieli i terminów.
Dowód do przygotowania: agenda i materiały briefingu NIS2 dla zarządu oraz notatka z decyzji.
Zarząd powinien widzieć ryzyka jako scenariusze biznesowe, nie jako surową listę podatności. Scenariusz pokazuje, co może się stać i jak wpłynie to na działalność.
Każde ryzyko powinno mieć:
Dowód do przygotowania: rejestr top 10 ryzyk cyber dla zarządu.
Gap analysis pokazuje różnicę między obecnym stanem firmy a wymaganym lub oczekiwanym poziomem bezpieczeństwa. To dokument, który pomaga zarządowi zrozumieć, co trzeba zrobić i dlaczego.
Analiza luk powinna obejmować:
Dowód do przygotowania: NIS2 gap analysis z priorytetami, kosztami i planem działań.
Jednym z najczęstszych problemów jest rozproszenie odpowiedzialności. IT mówi, że to compliance. Compliance mówi, że to IT. Zarząd zakłada, że ktoś się tym zajmuje. To nie działa.
Program NIS2 powinien mieć właściciela, który koordynuje:
W mniejszych firmach właścicielem może być członek zarządu wspierany przez vCISO lub zewnętrznego doradcę. W większych firmach może to być CISO, risk manager, compliance manager albo osoba wskazana przez zarząd.
Dowód do przygotowania: decyzja zarządu o właścicielu programu NIS2 oraz zakresie odpowiedzialności.
Zarząd potrzebuje planu, który jest realny. Nie wszystko da się zrobić w tydzień. Najlepiej podzielić działania na szybkie zabezpieczenia, działania organizacyjne i projekty długoterminowe.
Dowód do przygotowania: roadmapa NIS2 na 90 dni i 12 miesięcy, zatwierdzona przez zarząd.
Zarząd powinien regularnie widzieć prosty dashboard, a nie długą listę ticketów. Dashboard powinien pokazywać ryzyko, postęp, decyzje i dowody.
Najlepszy rytm dla większości firm to raport kwartalny. Firmy regulowane lub w trakcie intensywnego wdrożenia powinny raportować częściej.
Dowód do przygotowania: kwartalny dashboard NIS2 i cyber risk dla zarządu.
NIS2 sprawia, że incydent to nie tylko problem techniczny. To także komunikacja, terminy, prawo, dowody, klienci, dostawcy i decyzje zarządu.
Zarząd powinien wiedzieć:
Dowód do przygotowania: plan reagowania na incydenty i raport z ćwiczenia tabletop z udziałem zarządu.
Dostawcy są jednym z najważniejszych tematów NIS2. Firma może mieć dobre zabezpieczenia wewnętrzne, ale nadal być narażona przez dostawcę IT, chmury, hostingu, oprogramowania, płatności, usług zarządzanych albo integratora.
Zarząd powinien wymagać listy dostawców krytycznych, która pokazuje:
Najważniejsze pytanie zarządu: czy wiemy, który dostawca może zatrzymać naszą działalność albo narazić nas na incydent?
Dowód do przygotowania: rejestr dostawców krytycznych i wyniki oceny ryzyka dostawców.
NIS2 i wymagania klientów nie kończą się na deklaracjach. Firma powinna mieć dowody, że środki bezpieczeństwa działają.
Dowody powinny być aktualne, uporządkowane i przypisane do właścicieli. W kryzysie nie będzie czasu na szukanie dokumentów po folderach.
Dowód do przygotowania: NIS2 evidence pack przechowywany w kontrolowanym repozytorium.
Szkolenie zarządu powinno być krótkie, konkretne i decyzyjne. Nie powinno być tylko wykładem prawnym ani technicznym. Najlepsze szkolenie łączy regulacje, ryzyko, biznes i praktyczne decyzje.
Dowód do przygotowania: agenda szkolenia, lista uczestników, materiały i notatka z decyzji.
Po pierwszym briefingu NIS2 zarząd powinien podjąć konkretne decyzje. Bez nich temat będzie się przeciągał.
Najważniejsze: zarząd powinien zatwierdzić nie tylko „że coś trzeba zrobić”, ale kto, co i do kiedy zrobi.
Jeżeli spotkanie z zarządem kończy się tylko stwierdzeniem „temat jest ważny”, to nie jest przygotowanie. Po spotkaniu powinny powstać decyzje, właściciele i terminy.
IT odpowiada za wiele działań technicznych, ale NIS2 dotyczy także zarządu, ryzyka, dostawców, incydentów, ciągłości działania, budżetu, dowodów i odpowiedzialności.
Bez analizy podlegania firma nie wie, czy przygotowuje się do obowiązku regulacyjnego, wymagań klienta, dobrej praktyki, czy wszystkiego naraz.
Zarząd potrzebuje informacji o wpływie na firmę, nie tylko o podatnościach, CVE, logach i konfiguracji. Techniczne szczegóły powinny być tłumaczone na ryzyko biznesowe.
Łańcuch dostaw jest jednym z najważniejszych obszarów NIS2. Pominięcie dostawców oznacza, że firma nie rozumie pełnego ryzyka.
Zarząd musi wiedzieć, jak działać w incydencie. Sama procedura nie wystarczy. Potrzebne jest ćwiczenie tabletop z udziałem zarządu i kluczowych osób.
Wdrożenie bez dowodów jest trudne do obrony. Firma powinna gromadzić raporty, decyzje, wyniki testów, listy uczestników szkoleń i potwierdzenia przeglądów.
Firma technologiczna zatrudnia 140 osób i świadczy usługi dla klientów przemysłowych. Klienci zaczynają pytać o NIS2, incident response, MFA, dostawców i testy backupu. Zarząd początkowo uważa, że temat dotyczy tylko IT.
Po krótkim briefingu zarząd widzi, że problem jest szerszy. Firma może być dostawcą dla organizacji objętych NIS2, a jej klienci będą oczekiwać dowodów bezpieczeństwa. Zarząd podejmuje decyzję o analizie podlegania, gap analysis i przygotowaniu rejestru ryzyk.
W pierwszych 30 dniach firma identyfikuje systemy krytyczne, dostawców, top ryzyka i status MFA. W kolejnych 30 dniach powstaje NIS2 gap analysis, plan działań i dashboard. Po 90 dniach zarząd zatwierdza budżet, roadmapę, plan ćwiczenia incydentowego i pakiet dowodów dla klientów.
Największa zmiana nie polega na zakupie jednego narzędzia. Największa zmiana polega na tym, że cyberbezpieczeństwo przechodzi z poziomu „IT się tym zajmuje” na poziom decyzji zarządu, ryzyka biznesowego i mierzalnych dowodów.
ccyber.io pomaga przygotować zarządy do NIS2 w sposób praktyczny, biznesowy i decyzyjny. Nie robimy tylko prezentacji o przepisach. Pomagamy przejść od niepewności do planu: analiza podlegania, ryzyka, luki, roadmapa, budżet, incydenty, dostawcy i dowody.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Board Readiness Workshop. W ciągu jednego warsztatu można ustalić, czy firma ma ryzyko podlegania NIS2, jakie decyzje musi podjąć zarząd i jak zbudować pierwszy plan działań na 90 dni.
Tak, jeśli firma podlega NIS2, krajowym przepisom wdrażającym dyrektywę albo wymaganiom klientów z łańcucha dostaw. Zarząd powinien rozumieć ryzyko, zatwierdzać środki bezpieczeństwa i nadzorować ich wdrożenie.
Nie. Zarząd potrzebuje szkolenia biznesowego i decyzyjnego. Najważniejsze tematy to odpowiedzialność, zakres, ryzyko, incydenty, dostawcy, budżet i dowody.
Najlepiej zacząć od krótkiego briefingu NIS2, analizy podlegania i decyzji o wykonaniu gap analysis. Następnie trzeba przygotować rejestr ryzyk, roadmapę i dashboard dla zarządu.
NIS2 nie sprowadza się do posiadania certyfikatu ISO 27001. ISO 27001 może jednak pomóc uporządkować zarządzanie bezpieczeństwem informacji, ryzykiem, dowodami i ciągłym doskonaleniem.
Zarząd powinien wyznaczyć właściciela programu, zatwierdzić analizę podlegania, zatwierdzić gap analysis, zlecić rejestr ryzyk, sprawdzić plan incydentowy, backup, MFA i dostawców krytycznych.
Tak. Bezpieczeństwo łańcucha dostaw jest jednym z kluczowych obszarów. Zarząd powinien wiedzieć, którzy dostawcy są krytyczni, jaki mają dostęp i jakie wymagania bezpieczeństwa są w umowach.
W większości firm rozsądny jest przegląd kwartalny. W okresie wdrożenia lub po incydencie zarząd powinien otrzymywać status częściej.
Najlepszym dowodem są: szkolenie zarządu, analiza podlegania, gap analysis, rejestr ryzyk, decyzje budżetowe, plan działań, dashboard, plan incydentowy, przegląd dostawców i pakiet dowodów zgodności.
Przygotowanie zarządu na NIS2 nie powinno być jednorazową prezentacją prawną. Powinno być procesem, który prowadzi do decyzji, odpowiedzialności, budżetu, roadmapy i cyklicznego nadzoru.
Zarząd powinien wiedzieć, czy firma podlega NIS2 lub KSC, jakie ryzyka cyber są najważniejsze, jakie środki bezpieczeństwa trzeba wdrożyć, jak raportować incydenty, jak kontrolować dostawców i jakie dowody będą potrzebne.
Najlepszy efekt przygotowania zarządu to nie deklaracja, że „temat jest ważny”. Najlepszy efekt to zarząd, który wie, jakie ryzyko akceptuje, jakie działania finansuje, jakie dowody chce widzieć i jak często będzie nadzorować cyberbezpieczeństwo.
DORA dla dostawców IT i technologicznych: co trzeba wiedzieć
DORA dotyczy przede wszystkim podmiotów finansowych, ale mocno wpływa na dostawców IT, chmury, SaaS, cyberbezpieczeństwa, data center, outsourcingu i technologii. Nawet jeśli dostawca nie jest bezpośrednio nadzorowany, klienci finansowi będą wymagać od niego umów zgodnych z DORA, dowodów bezpieczeństwa, wsparcia przy incydentach, testów, prawa audytu, kontroli podwykonawców i planów wyjścia.
Opracowanie: Zespół redakcyjny CCyber
DORA, czyli Digital Operational Resilience Act, to unijne rozporządzenie dotyczące odporności cyfrowej sektora finansowego. Dla dostawców IT i technologicznych najważniejsze jest to, że DORA w praktyce przenosi wiele wymagań na relacje z klientami finansowymi. Bank, ubezpieczyciel, firma inwestycyjna, fintech lub inny podmiot finansowy będzie wymagał od dostawcy jasnych umów, SLA, wsparcia przy incydentach, testów ciągłości, prawa audytu, informacji o lokalizacji danych, kontroli podwykonawców, planów wyjścia i dowodów bezpieczeństwa.
Lipiec 2026
DORA to unijne rozporządzenie o cyfrowej odporności operacyjnej sektora finansowego. Jego celem jest to, aby podmioty finansowe potrafiły zapobiegać zakłóceniom ICT, wykrywać incydenty, reagować na nie, odtwarzać działanie i kontrolować ryzyko związane z dostawcami technologii.
DORA obejmuje pięć głównych obszarów:
Dla dostawców IT najważniejszy jest czwarty obszar: zarządzanie ryzykiem dostawców ICT. To on powoduje, że klienci finansowi będą wymagać dokładniejszych umów, audytów, dowodów, raportów i kontroli nad podwykonawcami.
Odpowiedź zależy od rodzaju dostawcy i roli usługi. DORA bezpośrednio reguluje podmioty finansowe, ale wprowadza też ramy nadzoru nad krytycznymi zewnętrznymi dostawcami usług ICT. Oprócz tego większość dostawców odczuje DORA przez wymagania klientów finansowych.
To najczęstszy przypadek. Dostawca nie jest bezpośrednio nadzorowany przez europejskie organy nadzoru, ale jego klient finansowy musi spełniać DORA. W praktyce klient przeniesie wymagania do umowy, ankiety, audytu i procesu zarządzania dostawcą.
Dostawca musi być gotowy na pytania o:
Jeżeli usługa dostawcy wspiera funkcję krytyczną lub ważną, wymagania będą mocniejsze. Klient będzie potrzebował pełniejszych SLA, raportowania, testów ciągłości, warunków audytu, planów wyjścia i lepszej kontroli podwykonawców.
Przykłady:
Najwięksi i systemowo istotni dostawcy ICT mogą zostać uznani za krytycznych. Wtedy mogą podlegać unijnemu nadzorowi prowadzonemu przez odpowiednie europejskie organy nadzoru. Dotyczy to przede wszystkim dużych dostawców, których usługi są istotne dla wielu podmiotów finansowych i mogą tworzyć ryzyko koncentracji.
Dla większości mniejszych dostawców praktyczniejszy wniosek jest prosty: nawet bez bezpośredniego nadzoru trzeba być gotowym na wymagania DORA w umowach i audytach klientów.
DORA zmienia sposób, w jaki sektor finansowy kupuje, ocenia i nadzoruje usługi technologiczne. Dostawca IT nie będzie już oceniany tylko pod kątem ceny, funkcji i doświadczenia. Będzie oceniany także pod kątem odporności, bezpieczeństwa, dowodów, procedur i zdolności do współpracy w incydencie.
DORA może wpływać na:
Dostawca, który ma przygotowane dowody, procedury i odpowiedzi, może skrócić sprzedaż i wyglądać bardziej wiarygodnie. Dostawca, który nie ma niczego, będzie spowalniał proces zakupowy i może przegrać z konkurencją.
Dostawcy chmury, data center, hostingu, infrastruktury jako usługi i platform jako usługi będą pytani o dostępność, lokalizację danych, odporność, podwykonawców, testy, bezpieczeństwo fizyczne, szyfrowanie, kopie zapasowe i plan wyjścia.
Firmy SaaS obsługujące banki, ubezpieczycieli, fintechy lub firmy inwestycyjne muszą przygotować dowody bezpieczeństwa aplikacji, ciągłości działania, wsparcia przy incydentach, logowania, kontroli dostępu i zasad aktualizacji.
Dostawcy SOC, EDR, SIEM, IAM, PAM, skanowania podatności, testów bezpieczeństwa i usług reagowania na incydenty często obsługują obszary krytyczne. Ich klienci mogą wymagać szczególnie wysokiej dostępności, jasnego podziału odpowiedzialności, procedur eskalacji i prawa audytu.
Software house’y i zespoły utrzymaniowe będą pytane o bezpieczny cykl wytwarzania, zarządzanie podatnościami, dostęp do środowisk klienta, repozytoria kodu, podwykonawców, testy i reakcję na incydenty.
Dostawcy systemów płatniczych, AML, KYC, core banking, CRM, systemów transakcyjnych, księgowych i raportowych mogą mieć duży wpływ na funkcje krytyczne klienta finansowego. Wymagania będą zwykle bardziej szczegółowe.
DORA kładzie duży nacisk na umowy z dostawcami ICT. Umowy powinny jasno określać prawa i obowiązki stron oraz umożliwiać podmiotowi finansowemu zarządzanie ryzykiem dostawcy.
Umowa powinna jasno opisywać, jakie funkcje i usługi ICT dostarcza dostawca. Dla dostawcy oznacza to potrzebę precyzyjnego katalogu usług, granic odpowiedzialności i zależności technicznych.
Klient może wymagać informacji, w jakich krajach lub regionach usługa jest świadczona i gdzie dane są przetwarzane lub przechowywane. Zmiana lokalizacji może wymagać wcześniejszego powiadomienia.
Umowa powinna obejmować dostępność, autentyczność, integralność i poufność danych, w tym danych osobowych. Dostawca musi umieć pokazać zabezpieczenia techniczne i organizacyjne.
Klient finansowy będzie potrzebował opisów poziomów usług, parametrów dostępności, czasów reakcji, zasad eskalacji, raportowania i działań korygujących, gdy poziomy usług nie są spełnione.
Dostawca powinien wspierać klienta, gdy incydent ICT jest związany z usługą dostarczaną przez dostawcę. W praktyce trzeba przygotować kontakt awaryjny, czasy reakcji, tryb eskalacji i zasady udostępniania informacji technicznych.
Umowa może wymagać współpracy z właściwymi organami i osobami przez nie wyznaczonymi. Dostawca powinien wiedzieć, kto w organizacji obsługuje takie żądania i jak chronić poufność innych klientów.
Klient finansowy może wymagać prawa audytu, inspekcji, dostępu do dokumentacji, raportów i dowodów. Dostawca musi przygotować model audytu, który jest wykonalny operacyjnie i nie narusza bezpieczeństwa innych klientów.
Jeżeli dostawca korzysta z podwykonawców, klient będzie chciał znać zakres, lokalizacje, ryzyka i zasady zmian. Dla usług krytycznych lub ważnych kontrola podwykonawców będzie szczególnie ważna.
Klient finansowy musi umieć zakończyć usługę lub przenieść ją do innego dostawcy bez nadmiernego ryzyka. Dostawca powinien mieć opis zwrotu danych, migracji, wsparcia przejściowego i usunięcia danych po zakończeniu współpracy.
Dostawca powinien mieć jasny opis usług, które oferuje klientom finansowym. Ważne jest odróżnienie, co robi dostawca, co robi klient i za co odpowiadają podwykonawcy.
Dowód do przygotowania: katalog usług, model współodpowiedzialności i opis granic usługi.
Dostawca powinien mieć gotowy pakiet odpowiedzi na pytania klientów. To skraca sprzedaż i ogranicza chaos przy każdej ankiecie security.
Pakiet może zawierać:
Dowód do przygotowania: DORA-ready security pack dla klientów finansowych.
Podmioty finansowe mają obowiązki związane z incydentami ICT. Dostawca musi szybko przekazać informacje, jeśli incydent dotyczy usługi świadczonej klientowi.
Procedura powinna określać:
Dowód do przygotowania: procedura client incident notification i szablon pierwszego powiadomienia.
Klient finansowy będzie chciał wiedzieć, czy dostawca potrafi utrzymać lub odtworzyć usługę po awarii, cyberataku, utracie centrum danych, błędzie wdrożenia albo problemie podwykonawcy.
Przygotuj:
Dowód do przygotowania: BCP, DRP i raport z testu odtwarzania.
Dostawca powinien znać swoich podwykonawców i umieć wyjaśnić, jak wpływają na usługę dla klienta finansowego. Dotyczy to chmury, hostingu, wsparcia technicznego, usług bezpieczeństwa, narzędzi monitoringu, podwykonawców developerskich i dostawców danych.
Rejestr powinien obejmować:
Dowód do przygotowania: rejestr podwykonawców i procedura zatwierdzania zmian.
Dostawca powinien wcześniej ustalić, jak obsługuje audyty klientów finansowych. Bez tego każdy audyt będzie osobnym kryzysem organizacyjnym.
Model audytu powinien określać:
Dowód do przygotowania: procedura audytu klienta i standardowy pakiet dowodów.
Klient może przesłać aneks DORA, który rozszerza umowę o wymagania dotyczące audytu, incydentów, podwykonawców, lokalizacji danych, SLA i planu wyjścia.
Ankieta może obejmować kilkadziesiąt lub kilkaset pytań o bezpieczeństwo informacji, ciągłość działania, dostęp, monitoring, podatności, chmurę, podwykonawców i reakcję na incydenty.
Klient może chcieć prawa audytu, dostępu do raportów, inspekcji lub uzyskania potwierdzenia od niezależnego audytora.
Klient może wymagać szybkiego powiadamiania o incydentach i aktualizacji statusu. Dostawca musi mieć proces, który pozwala udzielić informacji bez chaosu i bez naruszania poufności innych klientów.
Klient może wymagać listy istotnych podwykonawców, informacji o lokalizacji danych i prawa sprzeciwu lub informacji o zmianie podwykonawcy.
Klient może wymagać opisania, jak zakończyć usługę, odzyskać dane, przenieść usługę, usunąć dane i zapewnić wsparcie przejściowe.
W praktyce dla dostawcy najważniejsze jest pytanie, czy jego usługa wspiera funkcję krytyczną lub ważną klienta finansowego. Jeżeli tak, wymagania będą mocniejsze.
Usługa może być krytyczna lub ważna, jeżeli jej awaria, brak dostępności, naruszenie bezpieczeństwa lub nieprawidłowe działanie może istotnie wpłynąć na:
Dostawca powinien poprosić klienta o klasyfikację usługi. Bez tej informacji trudno ocenić właściwy poziom wymagań, dowodów, SLA i audytu.
DORA może być problemem albo przewagą sprzedażową. Dostawca, który odpowiada chaotycznie, nie zna podwykonawców i nie ma dowodów, spowolni proces zakupowy. Dostawca, który ma gotowy pakiet DORA-ready, może wyglądać bardziej dojrzale niż konkurencja.
DORA-ready może pomóc w sprzedaży, ponieważ:
Dla firm technologicznych obsługujących sektor finansowy DORA nie jest tylko obowiązkiem. To także okazja do uporządkowania oferty i lepszego pozycjonowania na rynku.
DORA formalnie dotyczy podmiotów finansowych, ale dostawcy technologii są częścią ich ryzyka operacyjnego. Klient finansowy przeniesie wymagania na dostawcę przez umowy, audyty i ankiety.
Jeżeli przy każdej ankiecie dostawca szuka dokumentów od zera, proces sprzedaży będzie wolny i chaotyczny. Pakiet dowodów powinien być przygotowany wcześniej.
Klient finansowy będzie pytał nie tylko o dostawcę, ale także o jego podwykonawców. Brak rejestru podwykonawców jest jedną z najczęstszych luk.
SLA bez testów ciągłości i odtwarzania może być ryzykowne. Dostawca powinien wiedzieć, czy deklarowane RTO i RPO są realistyczne.
Incydent po stronie dostawcy może uruchomić obowiązki klienta finansowego. Dostawca musi umieć szybko przekazać informacje w sposób uporządkowany.
Klient może wymagać prawa audytu, ale dostawca musi chronić bezpieczeństwo i poufność innych klientów. Trzeba ustalić model udostępniania dowodów, audytu zdalnego i inspekcji.
DORA wymaga, aby podmioty finansowe umiały wyjść z relacji z dostawcą. Dostawca, który nie ma planu zwrotu danych i migracji, będzie postrzegany jako większe ryzyko.
Firma SaaS dostarcza platformę do obsługi procesów sprzedażowych dla banków i fintechów. Przez kilka lat klienci pytali głównie o funkcje, dostępność i ochronę danych osobowych. Po wejściu DORA zaczynają wysyłać aneksy do umów, ankiety o podwykonawców, pytania o plan wyjścia, prawo audytu, RTO, RPO i powiadamianie o incydentach.
Zespół sprzedaży przekazuje pytania do IT, IT do prawników, prawnicy do zarządu, a odpowiedzi powstają ręcznie za każdym razem. Proces sprzedaży zaczyna się wydłużać, a jeden duży klient wstrzymuje podpisanie umowy do czasu uzupełnienia dowodów.
Firma przygotowuje program DORA-ready. Tworzy katalog usług, rejestr podwykonawców, pakiet dowodów bezpieczeństwa, procedurę powiadamiania klientów, plan wyjścia i standardowe odpowiedzi do ankiet. Testuje też odtwarzanie usługi i dokumentuje wynik.
Po 90 dniach rozmowy z klientami są szybsze. Firma nie odpowiada już od zera na każde pytanie. Ma gotowy pakiet dowodów, jasne granice odpowiedzialności i lepszą pozycję w negocjacjach z sektorem finansowym.
ccyber.io pomaga dostawcom IT i technologicznym przygotować się do wymagań DORA w sposób praktyczny, sprzedażowy i zgodny z oczekiwaniami klientów finansowych. Nie chodzi tylko o dokumenty. Chodzi o to, żeby dostawca umiał przejść due diligence, podpisać umowę, obsłużyć audyt i dostarczyć dowody odporności operacyjnej.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki DORA readiness workshop dla dostawcy. Pozwala ustalić, które usługi są najbardziej narażone na wymagania DORA, jakie dowody są już dostępne, czego brakuje i jak przygotować pakiet dla klientów finansowych w pierwszych 30, 60 i 90 dniach.
Tak, ale najczęściej pośrednio. DORA nakłada obowiązki przede wszystkim na podmioty finansowe, które muszą zarządzać ryzykiem dostawców ICT. Dlatego dostawcy IT otrzymują wymagania przez umowy, audyty, ankiety i proces due diligence.
Nie. Bezpośredni nadzór dotyczy krytycznych dostawców ICT wyznaczonych zgodnie z DORA. Większość dostawców nie będzie bezpośrednio nadzorowana, ale będzie musiała spełniać wymagania klientów finansowych.
Najpierw katalog usług, listę klientów finansowych, rejestr podwykonawców, opis lokalizacji danych, status MFA dla administratorów, procedurę incydentową, plan ciągłości działania i pakiet odpowiedzi na ankiety security.
To funkcja, której zakłócenie może istotnie wpłynąć na działalność podmiotu finansowego, jego klientów, zgodność regulacyjną lub ciągłość świadczenia usług. Dostawca powinien ustalić z klientem, czy dana usługa wspiera taką funkcję.
DORA wymaga, aby umowy z dostawcami ICT zawierały odpowiednie prawa dostępu, inspekcji i audytu, szczególnie dla usług wspierających funkcje krytyczne lub ważne. Dostawca powinien przygotować praktyczny model obsługi audytów.
W praktyce tak, szczególnie gdy podwykonawcy wpływają na usługę dla klienta finansowego lub na funkcję krytyczną albo ważną. Klient będzie wymagał informacji o zakresie usług, lokalizacji, ryzyku i zmianach.
Nie zawsze. ISO 27001 pomaga jako dowód systemu zarządzania bezpieczeństwem informacji, ale DORA obejmuje też szczegółowe wymagania umowne, incydenty, ciągłość działania, podwykonawców, testy i plan wyjścia.
Dostawca może przygotować DORA-ready security pack, skrócić czas odpowiedzi na ankiety, lepiej przechodzić due diligence i pokazać klientom finansowym, że rozumie ich regulacyjne obowiązki oraz ryzyko operacyjne.
DORA nie jest tylko regulacją dla banków i ubezpieczycieli. Dla dostawców IT i technologicznych jest zmianą w sposobie sprzedaży, kontraktowania, audytowania i utrzymywania usług dla sektora finansowego.
Najważniejsze jest przygotowanie wcześniej. Dostawca, który zna swoje usługi, podwykonawców, SLA, lokalizacje danych, procedury incydentowe, testy odtwarzania i model audytu, będzie znacznie lepiej przygotowany do rozmów z klientami finansowymi.
DORA-ready nie oznacza tylko posiadania dokumentu. Oznacza zdolność do udowodnienia, że usługa jest bezpieczna, odporna, monitorowana, odtwarzalna, audytowalna i możliwa do zakończenia bez paraliżu klienta. Dla dostawców technologii to nie tylko obowiązek. To przewaga konkurencyjna w sektorze finansowym.
Regulacje cyber UE i zgodność
NIS2, ISO/IEC 27001 i NIST Cybersecurity Framework nie są tym samym. NIS2 to wymóg prawny dla podmiotów objętych regulacją, ISO/IEC 27001 to certyfikowalny system zarządzania bezpieczeństwem informacji, a NIST CSF to elastyczny framework do oceny i komunikowania ryzyka cyber. W praktyce najlepsze firmy łączą te podejścia zamiast wybierać tylko jedno.
Opracowanie: Zespół redakcyjny CCyber
NIS2, ISO/IEC 27001 i NIST CSF służą innym celom. NIS2 odpowiada na pytanie: jakie obowiązki prawne musi spełnić podmiot kluczowy lub ważny. ISO/IEC 27001 odpowiada na pytanie: jak zbudować i certyfikować system zarządzania bezpieczeństwem informacji. NIST CSF odpowiada na pytanie: jak ocenić, uporządkować, priorytetyzować i komunikować ryzyko cyber. Najlepsza decyzja dla większości firm to nie wybór jednego podejścia, ale połączenie ich: NIS2 jako wymóg, ISO/IEC 27001 jako system zarządzania i dowody, NIST CSF jako mapa ryzyka i roadmapa działań.
Lipiec 2026
NIS2 to dyrektywa Unii Europejskiej dotycząca wysokiego wspólnego poziomu cyberbezpieczeństwa w UE. Dotyczy organizacji działających w określonych sektorach i kategoriach, w tym podmiotów kluczowych oraz ważnych. W Polsce wymagania NIS2 są powiązane z ustawą o krajowym systemie cyberbezpieczeństwa, czyli KSC.
NIS2 koncentruje się na tym, aby organizacje objęte regulacją miały odpowiednie i proporcjonalne środki techniczne, operacyjne i organizacyjne do zarządzania ryzykiem cyber oraz ograniczania skutków incydentów.
NIS2 obejmuje między innymi:
NIS2 powinno być punktem startowym, jeżeli firma:
Najważniejsze: NIS2 mówi, co organizacja musi osiągnąć jako obowiązek regulacyjny. Nie zawsze mówi szczegółowo, jak zbudować cały system zarządzania. Do tego przydają się ISO/IEC 27001 i NIST CSF.
ISO/IEC 27001 to międzynarodowy standard dla systemu zarządzania bezpieczeństwem informacji, czyli ISMS. Pomaga organizacji ustanowić, wdrożyć, utrzymywać i doskonalić system zarządzania bezpieczeństwem informacji w sposób oparty na ryzyku.
ISO/IEC 27001 jest szczególnie ważne, gdy firma potrzebuje:
ISO/IEC 27001 pomaga odpowiedzieć na pytanie: czy firma ma system, który regularnie identyfikuje ryzyka, wybiera zabezpieczenia, dokumentuje decyzje, monitoruje skuteczność i stale się doskonali?
ISO/IEC 27001 powinno być punktem startowym, jeżeli firma:
Najważniejsze: ISO/IEC 27001 jest świetnym narzędziem do budowy dowodów i systemu zarządzania. Sam certyfikat nie gwarantuje jednak automatycznie pełnej zgodności z NIS2 ani wysokiej odporności technicznej. Trzeba dobrze określić zakres, ryzyka i realne zabezpieczenia.
NIST Cybersecurity Framework, czyli NIST CSF, to framework do zarządzania ryzykiem cyberbezpieczeństwa. Wersja 2.0 organizuje cyberbezpieczeństwo wokół sześciu funkcji: Govern, Identify, Protect, Detect, Respond i Recover.
W praktyce NIST CSF pomaga firmie:
NIST CSF nie jest certyfikatem. Jego siłą jest prostota, elastyczność i język, który dobrze nadaje się do rozmowy z zarządem.
NIST CSF powinien być punktem startowym, jeżeli firma:
Najważniejsze: NIST CSF bardzo dobrze działa jako narzędzie oceny i priorytetyzacji. Nie zastępuje jednak obowiązków prawnych NIS2 ani certyfikatu ISO/IEC 27001, jeśli klient albo regulator tego wymaga.
Jeżeli firma podlega NIS2 lub KSC, nie ma sensu zaczynać od pytania, czy wybrać ISO czy NIST. Najpierw trzeba ustalić obowiązki prawne.
W praktyce oznacza to:
Najlepsza decyzja: NIS2 jako wymóg docelowy, ISO/IEC 27001 i NIST CSF jako narzędzia wdrożeniowe.
Jeżeli firma dostaje ankiety bezpieczeństwa od klientów, startuje w przetargach, sprzedaje do dużych organizacji albo musi pokazać formalny system zarządzania, ISO/IEC 27001 będzie często najbardziej czytelne biznesowo.
ISO/IEC 27001 pomaga uporządkować:
Najlepsza decyzja: ISO/IEC 27001 jako system zarządzania i certyfikowalny dowód, NIST CSF jako narzędzie do priorytetyzacji, NIS2/KSC jako wymagania prawne do zmapowania.
Jeżeli firma nie wie, od czego zacząć, ma wiele luźnych działań security, brak jasnych priorytetów i chce szybko pokazać zarządowi stan ryzyka, NIST CSF jest bardzo dobrym punktem startowym.
NIST CSF pomaga zbudować:
Najlepsza decyzja: NIST CSF jako pierwsza mapa i roadmapa, potem ISO/IEC 27001, jeśli potrzebny jest system i certyfikat, oraz NIS2/KSC, jeśli firma jest regulowana.
Największy błąd to tworzenie trzech osobnych programów: osobno NIS2, osobno ISO/IEC 27001 i osobno NIST CSF. To prowadzi do duplikacji dokumentów, chaosu, zmęczenia zespołu i braku jasnej odpowiedzialności.
Lepsze podejście:
W praktyce firma może użyć NIST CSF do pierwszego assessmentu, ISO/IEC 27001 do zbudowania systemu zarządzania i NIS2/KSC jako listy wymagań prawnych, które trzeba spełnić i udokumentować.
Najpierw trzeba ustalić, czy organizacja jest podmiotem kluczowym, ważnym, dostawcą dla takiego podmiotu albo organizacją, która może otrzymać wymagania kontraktowe związane z NIS2.
Dowód do przygotowania: analiza kwalifikacji pod NIS2/KSC i decyzja zarządu o statusie organizacji.
NIST CSF dobrze nadaje się do szybkiego sprawdzenia, gdzie firma jest teraz i gdzie powinna być. Ocena powinna objąć governance, identyfikację aktywów, ochronę, wykrywanie, reagowanie i odtwarzanie.
Dowód do przygotowania: NIST CSF current profile, target profile i lista luk.
Jeżeli firma potrzebuje trwałego systemu, dowodów i certyfikacji, ISO/IEC 27001 może stać się szkieletem organizacyjnym. Wtedy wymagania NIS2 i wyniki NIST CSF należy włączyć do rejestru ryzyk, polityk, planów i przeglądów.
Dowód do przygotowania: zakres ISMS, polityka bezpieczeństwa, rejestr ryzyk, plan postępowania z ryzykiem i deklaracja stosowania.
Każde wymaganie NIS2 powinno mieć właściciela, kontrolę, dowód i status. Nie wystarczy powiedzieć, że firma ma „procedury”. Trzeba pokazać, jakie procedury, kto je wykonuje i jakie dowody powstają.
Dowód do przygotowania: matryca wymagań NIS2/KSC, ISO/IEC 27001 i NIST CSF.
Roadmapa powinna być jedna, nawet jeśli źródeł wymagań jest kilka. Działania powinny mieć priorytet biznesowy, właściciela, termin, koszt, ryzyko i dowód zakończenia.
Dowód do przygotowania: roadmapa cyberbezpieczeństwa na 90 dni i 12 miesięcy.
Najlepszy wybór: NIS2/KSC jako obowiązek prawny, ISO/IEC 27001 jako system zarządzania, NIST CSF jako assessment i raport zarządczy.
Priorytet:
Najlepszy wybór: NIST CSF jako szybki start, ISO/IEC 27001 jako kierunek, jeśli klienci wymagają certyfikatu, NIS2/KSC jako wymagania kontraktowe, jeśli firma jest dostawcą dla podmiotów regulowanych.
Priorytet:
Najlepszy wybór: ISO/IEC 27001 jako system i dowód dla klientów, NIST CSF jako roadmapa, NIS2/KSC jako wymagania klienta lub własna kwalifikacja, jeśli firma świadczy usługi objęte regulacją.
Priorytet:
Najlepszy wybór: NIS2/KSC, jeśli firma jest objęta regulacją, NIST CSF jako governance i roadmapa, ISO/IEC 27001 dla systemu zarządzania, a dla OT dodatkowo IEC 62443 jako podejście specjalistyczne.
Priorytet:
Najlepszy wybór: DORA jako regulacja sektorowa, NIS2/KSC, jeśli ma zastosowanie, ISO/IEC 27001 jako ISMS, NIST CSF jako framework ryzyka i raportowania.
Priorytet:
Framework jest narzędziem. Celem jest zmniejszenie ryzyka i spełnienie obowiązków. Firma nie powinna wdrażać standardu dla samego standardu.
ISO/IEC 27001 może bardzo pomóc, ale certyfikat nie oznacza automatycznie, że organizacja spełnia wszystkie obowiązki NIS2 lub KSC. Trzeba wykonać mapowanie wymagań.
NIST CSF nie jest certyfikatem. Jest świetny do oceny, priorytetyzacji i komunikacji, ale nie zastępuje certyfikacji ISO/IEC 27001, jeśli klient jej wymaga.
Osobny projekt NIS2, osobny projekt ISO i osobny projekt NIST tworzą chaos. Lepsza jest jedna mapa, jeden rejestr ryzyka i jedna roadmapa.
Dokumentacja jest ważna, ale sama nie zatrzyma ransomware, nie włączy MFA i nie odtworzy systemu po awarii. Każdy dokument powinien prowadzić do kontroli, dowodu lub decyzji.
NIS2, ISO/IEC 27001 i NIST CSF wymagają udziału zarządu. Cyberbezpieczeństwo nie może być wyłącznie zadaniem administratora IT.
W audycie i rozmowie z klientem nie wystarczy powiedzieć, że firma ma backup, MFA lub szkolenia. Trzeba pokazać raport, log, rejestr, potwierdzenie lub wynik testu.
Firma technologiczna sprzedaje usługi SaaS do klientów z sektora produkcji i infrastruktury. Klienci zaczynają pytać o NIS2, ISO/IEC 27001, backup, MFA, testy bezpieczeństwa i plan reakcji na incydent. Zarząd chce wiedzieć, czy firma powinna „wdrożyć NIS2, ISO czy NIST”.
Po analizie okazuje się, że firma nie jest bezpośrednio podmiotem kluczowym ani ważnym, ale jest dostawcą dla klientów objętych NIS2. Nie ma obowiązku rejestracji jako podmiot regulowany, ale będzie otrzymywać wymagania kontraktowe od klientów. Jednocześnie kilku dużych klientów oczekuje certyfikatu ISO/IEC 27001 w ciągu 12 miesięcy.
Najlepsza decyzja nie polega na wyborze jednego podejścia. Firma używa NIST CSF do szybkiej oceny i roadmapy, ISO/IEC 27001 jako docelowego systemu zarządzania oraz NIS2 jako mapy wymagań, które klienci będą przenosić na dostawców.
W ciągu 90 dni firma przygotowuje current profile i target profile według NIST CSF, wdraża MFA, testuje backup, porządkuje rejestr ryzyk, przygotowuje plan reakcji na incydent i tworzy matrycę wymagań klientów. Po 12 miesiącach przechodzi certyfikację ISO/IEC 27001, mając już dowody zgodne z oczekiwaniami klientów objętych NIS2.
ccyber.io pomaga firmom wybrać właściwe podejście do NIS2, ISO/IEC 27001 i NIST CSF bez tworzenia trzech osobnych projektów. Koncentrujemy się na praktycznym wdrożeniu, dowodach, ryzyku biznesowym i gotowości do audytów oraz wymagań klientów.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest krótki warsztat decyzyjny: NIS2, ISO/IEC 27001 czy NIST CSF. Pozwala ustalić, co jest obowiązkiem prawnym, co jest wymaganiem klientów, co jest narzędziem zarządczym i jaka roadmapa da firmie najlepszy efekt w najkrótszym czasie.
Nie. NIS2 to regulacja prawna, ISO/IEC 27001 to certyfikowalny system zarządzania bezpieczeństwem informacji, a NIST CSF to framework do zarządzania i komunikowania ryzyka cyber.
Nie automatycznie. ISO/IEC 27001 może bardzo pomóc, ale firma musi zmapować konkretne obowiązki NIS2 lub KSC do swoich procesów, kontroli i dowodów.
Nie w typowym sensie. NIST CSF służy do oceny, komunikacji i priorytetyzacji działań. Nie jest standardem certyfikacyjnym tak jak ISO/IEC 27001.
Jeżeli firma podlega NIS2 lub KSC, zacznij od obowiązków regulacyjnych. Jeżeli klient wymaga certyfikatu, zacznij od ISO/IEC 27001 readiness. Jeżeli firma ma chaos i brak priorytetów, zacznij od NIST CSF assessment.
To zależy od klientów, ryzyka i budżetu. Mała firma może zacząć od NIST CSF lub podstaw ISO/IEC 27001, a certyfikację zaplanować dopiero wtedy, gdy wymaga tego sprzedaż lub rynek.
Może dotyczyć pośrednio. Nawet jeśli dostawca nie jest bezpośrednio podmiotem kluczowym lub ważnym, klienci objęci NIS2 mogą wymagać od niego określonych zabezpieczeń i dowodów.
Tak. NIST CSF jest dobry do rozmowy o ryzyku, priorytetach, dojrzałości, lukach i roadmapie. Funkcja Govern w wersji 2.0 szczególnie wzmacnia rolę zarządzania i odpowiedzialności.
Trzeba stworzyć jedną matrycę wymagań i dowodów. Jeden rejestr ryzyk, jedna roadmapa i jeden raport dla zarządu mogą obsługiwać jednocześnie NIS2, ISO/IEC 27001 i NIST CSF.
NIS2, ISO/IEC 27001 i NIST CSF odpowiadają na różne potrzeby. NIS2 tworzy obowiązki prawne i pilność. ISO/IEC 27001 daje system zarządzania i certyfikowalne dowody. NIST CSF pomaga ocenić dojrzałość, ustalić priorytety i rozmawiać o ryzyku cyber z zarządem.
Najlepsza decyzja dla większości firm nie polega na wyborze jednego podejścia i odrzuceniu pozostałych. Najlepsza decyzja polega na mądrym połączeniu tych źródeł w jeden program cyberbezpieczeństwa.
Praktyczna kolejność jest prosta: sprawdź obowiązki NIS2/KSC, oceń dojrzałość według NIST CSF, zbuduj system zarządzania według ISO/IEC 27001, a potem utrzymuj jedną roadmapę, jedną matrycę dowodów i jeden raport cyber risk dla zarządu.
Piszemy o regulacjach takich jak NIS2, DORA, CRA i ISO 27001, o bezpieczeństwie MŚP i infrastruktury krytycznej, a także o cyberhigienie, cyberzagrożeniach i budowaniu świadomości bezpieczeństwa w organizacji.
Każdy artykuł to praktyczna wiedza - bez żargonu i z konkretnymi wskazówkami do wdrożenia, które pomagają firmom skutecznie chronić dane, ludzi i ciągłość działania.