Compliance officer dostaje z rąk audytora świeży certyfikat ISO/IEC 27001:2022 i tego samego tygodnia pytanie od zarządu: „to jesteśmy zgodni z NIS2?”. Pytanie brzmi rozsądnie, bo obie rzeczy dotyczą tego samego obszaru, mówią podobnym językiem i wymagają podobnych dowodów. Kłopot w tym, że certyfikat odpowiada na inne pytanie, niż zadał zarząd — potwierdza zgodność systemu zarządzania bezpieczeństwem informacji z wymaganiami normy, a nie wykonywanie obowiązków, które nakłada prawo.
Ten tekst nie jest instrukcją mapowania. Instrukcję — którą kontrolę przypisać do którego wymagania — znajdziesz w naszym przewodniku po mapowaniu wymagań dyrektywy NIS2 na standardy bezpieczeństwa. Tutaj interesuje nas granica tamtej metody: obowiązki, które nie mają odpowiednika w żadnej kontroli żadnego standardu, bo są parametrem prawnym, a nie praktyką bezpieczeństwa. Progi uznania incydentu za poważny, adresat i zegar zgłoszenia, dokumentowana ścieżka raportowania do właściwego CSIRT, imienna odpowiedzialność kierownika. Tablica odpowiedniości ich nie złapie — i nie dlatego, że ktoś ją źle zrobił, tylko dlatego, że nie ma czego z czym zestawiać.
Czy certyfikat ISO 27001 przesądza o zgodności z NIS2?
Nie przesądza. Certyfikat jest oświadczeniem jednostki certyfikującej o zgodności systemu zarządzania z wymaganiami normy — dokumentem o systemie, nie o wykonaniu przepisu. Organ nadzoru pyta o co innego: czy zgłosiłeś wczesne ostrzeżenie w terminie, czy Twój kierownik przeszedł szkolenie, czy osoba realizująca zadania z zakresu bezpieczeństwa przedstawiła zaświadczenie o niekaralności. Na żadne z tych pytań certyfikat nie odpowiada, bo norma ich nie stawia.
Autor mapowania mówi to samo, i to bez ogródek. W wytycznych technicznych do rozporządzenia wykonawczego 2024/2690 — dokumencie, z którego pochodzi większość krążących po rynku tablic odpowiedniości — ENISA zastrzega:
„Their partial or complete implementation does not assume compliance or conformity with the requirements of the regulation.”
(„Ich częściowe lub całkowite wdrożenie nie oznacza zgodności ani zgodności formalnej z wymogami rozporządzenia”.)
— ENISA, Technical implementation guidance on cybersecurity risk-management measures, wersja 1.0, czerwiec 2025, s. 9.
Zdanie dotyczy wskazówek i przykładów dowodów zawartych w samym dokumencie ENISA. Jeżeli agencja unijna odmawia gwarancji zgodności własnym wytycznym, napisanym wprost pod rozporządzenie, to trudno oczekiwać takiej gwarancji od normy napisanej dziesięć lat wcześniej i w innym celu.
To nie jest argument przeciwko ISO 27001. To argument przeciwko traktowaniu certyfikatu jako dowodu w postępowaniu, w którym dowodzi się czegoś innego. Norma jest dobrym rusztowaniem — wracamy do tego w dalszej części tekstu. Złe jest tylko przekonanie, że rusztowanie zastępuje budynek.
Co dokładnie zastrzega ENISA w wytycznych z czerwca 2025 roku?
Kluczowe zastrzeżenie stoi na stronie 10 dokumentu i brzmi dosłownie tak:
„The mapping should not be interpreted as a measure of equivalency among different standards or frameworks. It simply refers to relevant requirements in these standards or frameworks without assessing whether these fully cover the requirements of the regulation.”
(„Mapowania nie należy interpretować jako miary równoważności między różnymi standardami lub ramami. Wskazuje ono po prostu odpowiadające wymagania w tych standardach lub ramach, bez oceny, czy w pełni pokrywają one wymogi rozporządzenia”.)
— ENISA, Technical implementation guidance on cybersecurity risk-management measures, wersja 1.0, czerwiec 2025, s. 10.
Warto zatrzymać się na drugim zdaniu, bo to ono niesie cały ciężar i bywa gubione w streszczeniach. ENISA nie mówi „mapowanie jest niepełne” ani „mapowanie wymaga uzupełnienia” — obie te formuły sugerowałyby, że ktoś porównał zakresy i znalazł braki. Mówi coś mocniejszego: oceny pokrycia w ogóle nie przeprowadzono. Tablica rejestruje sąsiedztwo tematyczne — tu stoi wymóg rozporządzenia, tam kontrola o pokrewnej treści — i na tym kończy swoją rolę. Ktokolwiek dopisuje do tego wniosek „a zatem kontrola spełnia wymóg”, formułuje ocenę, której autor tablicy świadomie odmówił.
Ma to konkretną konsekwencję dowodową. Jeżeli w dokumentacji przedstawionej organowi nadzoru wskażesz kontrolę z załącznika A jako dowód wykonania wymogu, powołując się na mapowanie ENISA, powołujesz się na dokument, który tego wniosku nie zawiera. Argument nie brzmi „mapowanie jest błędne” — brzmi „mapowanie nie jest o tym”. Różnica jest niewielka w rozmowie i zasadnicza w postępowaniu.
Samą metodę mapowania — co z czym zestawiać i jak z tego zrobić użyteczną macierz — opisaliśmy osobno, w przewodniku po mapowaniu wymagań NIS2 na standardy bezpieczeństwa. Tutaj nie powtarzamy ani tablicy, ani instrukcji jej budowania. Zajmujemy się wyłącznie tym, co zostaje po drugiej stronie granicy wyznaczonej cytowanym zdaniem.
Kluczowy wniosek: zastrzeżenie ze strony 10 nie mówi, że mapowanie jest niedokładne. Mówi, że nie zawiera oceny pokrycia — a więc nie może być dowodem zgodności, nawet gdyby było doskonałe.
Do jakich standardów ENISA naprawdę zmapowała wymagania?
Do pięciu dokumentów i do ram krajowych — a lista bywa w obiegu wtórnym rozszerzana o pozycje, których w niej nie ma. Wytyczne wskazują (s. 9–10), że każde wymaganie zmapowano do ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0, ETSI EN 319 401 V3.1.1 (2024-06) oraz CEN/TS 18026:2024, a ponadto do krajowych ram NIS2 zgłoszonych przez państwa członkowskie i zebranych w Załączniku I dokumentu.
CIS Controls na tej liście nie ma. To nie jest zarzut wobec CIS Controls — to bardzo dobry katalog i wiele organizacji słusznie się nim posługuje. To informacja o tym, czego dokładnie dotyczy zastrzeżenie ENISA: obejmuje ono pięć wymienionych pozycji, a zestawienia wykraczające poza nie są już czyjąś własną pracą, za którą ENISA nie odpowiada i której nie firmuje. Jeżeli Twoja macierz zgodności powstała na podstawie streszczenia, a nie dokumentu, warto sprawdzić, czyje mapowanie faktycznie w niej siedzi — zanim trafi do dokumentacji pokazywanej audytorowi.
Dwa ograniczenia z tej samej strony domykają obraz. Mapowanie objęło wyłącznie standardy horyzontalne i wybrane zagadnienia; standardy szczegółowe i specyfikacje techniczne pojawiają się jedynie w przypisach, tam gdzie były dostępne. Wskazane standardy są przy tym przykładami — wyboru dokonuje sam podmiot, kierując się kontekstem swojej działalności, a dokument, jak deklaruje, nie ustanawia nowego standardu ani nie powiela istniejących.
Jest jeszcze szczegół czysto warsztatowy, który oszczędza pół dnia szukania. Tablic mapowania nie ma w pliku PDF wytycznych — w wersji 1.0 ENISA publikuje je osobno, w arkuszu kalkulacyjnym na własnej stronie (przypis 6 na s. 10). Pracując z samym PDF-em, masz przed sobą wskazówki wdrożeniowe, przykłady dowodów i praktyczne podpowiedzi, ale nie mapowanie. To dwa różne narzędzia do dwóch różnych zadań i warto wiedzieć, które z nich się właśnie otworzyło.
Kogo obowiązują wytyczne ENISA, a kogo nie?
Wytyczne ENISA wspierają rozporządzenie wykonawcze 2024/2690, a to obejmuje wąską grupę podmiotów. Dokument wymienia ją wprost (s. 2): dostawcy usług DNS, rejestry nazw domen najwyższego poziomu (TLD), dostawcy usług chmurowych, dostawcy usług centrum przetwarzania danych, dostawcy sieci dostarczania treści, dostawcy usług zarządzanych oraz usług zarządzanych w zakresie cyberbezpieczeństwa, dostawcy internetowych platform handlowych, wyszukiwarek internetowych i platform usług sieci społecznościowych oraz dostawcy usług zaufania.
Powód takiego zawężenia podaje samo streszczenie dokumentu. Dla większości sektorów krytycznych wymagania ustalają państwa członkowskie na poziomie krajowym; dla kilku podsektorów infrastruktury cyfrowej i zarządzania usługami ICT ustalono je na poziomie unijnym ze względu na transgraniczny charakter tych usług. Poza tą grupą wytyczne — jak deklaruje ENISA na s. 7 — mogą jedynie „dawać wskazówki”, przydatne innym podmiotom publicznym i prywatnym do poprawy własnego bezpieczeństwa.
Polskie prawo powtarza ten podział wprost. Artykuł 8b ust. 1 ustawy o krajowym systemie cyberbezpieczeństwa, w brzmieniu nadanym nowelizacją z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252, obowiązuje od 3 kwietnia 2026 r.), nakazuje dokładnie tej samej liście podmiotów stosować środki zarządzania ryzykiem określone w rozporządzeniu 2024/2690. Ustęp 2 tego samego artykułu odsyła pozostałe podmioty kluczowe i ważne do środków określonych w aktach wykonawczych Komisji wydanych na podstawie art. 21 ust. 5 dyrektywy 2022/2555 — czyli gdzie indziej.
Dla szpitala, zakładu produkcyjnego czy przedsiębiorstwa wodociągowego oznacza to rzecz nieoczywistą: wytyczne ENISA są dla nich dobrą praktyką, a nie miarą zgodności. Można i warto się nimi posiłkować. Nie można natomiast oprzeć na nich argumentacji przed organem nadzoru, bo reżim, któremu podlegają, jest inny. To jedno z najczęstszych nieporozumień, jakie widzimy przy przeglądach dokumentacji — zespół pracowicie odwzorowuje strukturę wytycznych ENISA, nie sprawdziwszy wcześniej, czy w ogóle jest ich adresatem.
Uwaga: zanim zaczniesz porównywać swoją dokumentację z wytycznymi ENISA, ustal, czy Twój podmiot mieści się w katalogu z art. 8b ust. 1 ustawy o KSC. Od tego zależy, czy rozporządzenie 2024/2690 jest dla Ciebie źródłem obowiązku, czy tylko materiałem pomocniczym.
Co zmieniło się w polskim prawie 3 kwietnia 2026 roku?
Zmieniło się to, że NIS2 przestała być dyrektywą do przeczytania, a stała się obowiązkiem do wykonania — z polskimi terminami, polskim organem i polskimi formularzami. Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252) została ogłoszona 2 marca 2026 r. i weszła w życie po upływie miesiąca od ogłoszenia, czyli 3 kwietnia 2026 r. Wdraża ona między innymi dyrektywę 2022/2555 i osadza w polskim porządku prawnym rozporządzenie wykonawcze 2024/2690.
Zmieniło się także słownictwo, i to nie kosmetycznie. Zniknął „operator usługi kluczowej”, a jego miejsce zajęły podmiot kluczowy i podmiot ważny — dotychczasowi operatorzy usług kluczowych stali się z mocy prawa podmiotami kluczowymi. Do słownika weszły definicje dostawcy usług zarządzanych oraz dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa, a także pojęcie kierownika podmiotu kluczowego lub podmiotu ważnego. Jeżeli czytasz materiały napisane przed kwietniem 2026 roku, ich terminologia jest nieaktualna — a wraz z nią część odesłań do konkretnych artykułów ustawy.
Najważniejszą praktyczną nowością jest jednak obowiązek, o którym łatwo zapomnieć, bo nie wygląda na obowiązek z zakresu bezpieczeństwa. Podmiot kluczowy lub ważny składa wniosek o wpis do wykazu w terminie 6 miesięcy od dnia spełnienia przesłanek uznania go za taki podmiot (art. 7c ust. 1), a zmianę danych zgłasza w ciągu 14 dni (ust. 3). Nikt nie przyśle po Ciebie zaproszenia — kwalifikacja następuje z mocy ustawy, a rejestracja jest Twoim ruchem.
Wniosek zawiera przy tym oświadczenie kierownika podmiotu o treści wskazanej w ustawie: „Świadomy odpowiedzialności karnej za złożenie fałszywego oświadczenia wynikającej z art. 233 § 6 ustawy z dnia 6 czerwca 1997 r. – Kodeks karny oświadczam, że dane zawarte we wniosku są zgodne z prawdą” (art. 7c ust. 5). Trudno o wyraźniejszy sygnał, że mówimy o innej kategorii zobowiązania niż wdrożenie kontroli z załącznika do normy. Certyfikat ISO 27001 nie mówi nic o tym, czy wniosek został złożony w terminie — bo takie pytanie w ogóle nie mieści się w zakresie certyfikacji systemu zarządzania.
Dlaczego progi uznania incydentu za poważny nie mieszczą się w żadnym standardzie?
Bo próg jest parametrem prawnym ustalanym poza organizacją, a standard może opisać najwyżej proces jego stosowania. Ustawa o KSC definiuje incydent poważny jako taki, który „powoduje lub może spowodować poważne obniżenie jakości lub przerwanie ciągłości świadczenia usługi przez podmiot kluczowy lub podmiot ważny, straty finansowe dla tego podmiotu lub wpływa na inne osoby fizyczne, osoby prawne, jednostki organizacyjne nieposiadające osobowości prawnej przez wywołanie poważnej szkody materialnej lub niematerialnej” (art. 2 pkt 7 w brzmieniu z Dz.U. 2026 poz. 252). Definicja jest jakościowa — sama z siebie nie mówi, ile godzin przerwy i ilu użytkowników przesądza sprawę.
Liczby dostarczają dwa różne akty, w zależności od tego, kim jesteś. Dla podmiotów z katalogu cyfrowego przypadki uznania incydentu za poważny doprecyzowuje rozporządzenie 2024/2690; słownik wytycznych ENISA sprowadza to do jednego zdania: „Significant incident: an incident that meets the criteria of Article 3 of the regulation” (s. 168). Dla wszystkich pozostałych progi określa Rada Ministrów w drodze rozporządzenia — art. 11 ust. 4 ustawy o KSC nakazuje jej odnieść się do liczby użytkowników dotkniętych zakłóceniem, czasu oddziaływania incydentu, zasięgu geograficznego oraz innych czynników charakterystycznych dla sektora, z wyraźnym wyłączeniem podmiotów, dla których progi ustaliła już Komisja Europejska.
Zestawmy to z tym, co potrafi standard. ISO/IEC 27001:2022 wymaga oceny zdarzeń i decyzji o ich klasyfikacji, ale kryteria klasyfikacji zostawia organizacji — mają wynikać z jej analizy ryzyka. To rozsądne rozwiązanie w normie stosowanej na całym świecie i w każdej branży. Jest jednak dokładnie odwrotne do logiki regulacji, w której kryterium jest narzucone, jednakowe dla całego sektora i niezależne od tego, jak Twoja organizacja ocenia własne ryzyko.
Najciekawsze jest to, że sama ENISA w tym punkcie odsyła poza siebie. Wymieniając kryteria, które warto uwzględnić w systemie kategoryzacji incydentów — wpływ na działalność, wrażliwość danych, skutki prawne i regulacyjne, zasięg, typ ataku, krytyczność systemów — kończy listę pozycją „other criteria on what constitutes a significant incident as per this regulation” (s. 33). Autor wytycznych mówi więc wprost: kategoryzację zbuduj u siebie, ale co jest incydentem poważnym, sprawdź w przepisie.
Warto tu skorygować przekonanie, które w rozmowach o NIS2 powtarza się najczęściej: że organizacja ustala własne progi uznania incydentu za poważny. Do 3 kwietnia 2026 roku taka interpretacja miała jeszcze jakieś oparcie w praktyce. Dziś nie ma: art. 11 ust. 4 ustawy o KSC powierza określenie progów Radzie Ministrów, a dla podmiotów cyfrowych — Komisji Europejskiej. Organizacja ustala własny system kategoryzacji i własne priorytety obsługi, ale próg, od którego biegnie zegar zgłoszenia, jest dla niej danymi wejściowymi, a nie decyzją. To rozróżnienie decyduje o tym, czy procedura incydentowa zadziała pod presją, czy zatrzyma się na pytaniu „a czy to już jest poważny?”.
Praktyczna fiszka: system kategoryzacji incydentów zgodny z ISO 27001 jest warunkiem koniecznym, ale nie wystarczającym. Dopóki nie wpiszesz do niego progów z właściwego dla siebie aktu prawnego, klasyfikujesz incydenty poprawnie metodycznie i bezużytecznie z punktu widzenia obowiązku zgłoszenia.
Jakie terminy zgłoszenia nakłada polska ustawa i skąd się biorą?
Terminy są trzy i wszystkie liczą się od momentu wykrycia albo od zgłoszenia, nie od zakończenia obsługi incydentu. Artykuł 11 ust. 1 ustawy o KSC w brzmieniu obowiązującym od 3 kwietnia 2026 r. nakłada na podmiot kluczowy i podmiot ważny obowiązek:
- zgłoszenia wczesnego ostrzeżenia o incydencie poważnym niezwłocznie, nie później niż w ciągu 24 godzin od momentu jego wykrycia, do właściwego CSIRT sektorowego (pkt 4);
- zgłoszenia samego incydentu poważnego niezwłocznie, nie później niż w ciągu 72 godzin od momentu wykrycia, do właściwego CSIRT sektorowego (pkt 4a);
- przekazania sprawozdania okresowego z obsługi incydentu — na wniosek właściwego CSIRT sektorowego (pkt 4b);
- przekazania sprawozdania końcowego nie później niż w ciągu miesiąca od dnia zgłoszenia z pkt 4a (pkt 4c).
Dostawcy usług zaufania mają reżim ostrzejszy: zgłaszają incydent poważny w ciągu 24 godzin od wykrycia (art. 11 ust. 1a). Jeżeli obsługa incydentu nie zakończy się w terminie składania sprawozdania końcowego, ustawa przewiduje sprawozdanie z postępu obsługi, a sprawozdanie końcowe przesuwa się na miesiąc od zakończenia obsługi (art. 12b).
Zwróć uwagę na trzy rzeczy, których żadna kontrola bezpieczeństwa nie rozstrzygnie. Po pierwsze, adresat: właściwy CSIRT sektorowy, a nie dowolny zespół reagowania — ustalenie, który to, jest zadaniem prawno-organizacyjnym. Po drugie, kanał: wszystkie te dokumenty przekazuje się za pomocą systemu teleinformatycznego, o którym mowa w art. 46 ust. 1 ustawy. Po trzecie, zawartość: art. 12 wylicza sześć elementów wczesnego ostrzeżenia, w tym wskazanie momentu wystąpienia i wykrycia incydentu, czasu jego trwania oraz tego, czy incydent dotyczy innych państw członkowskich.
Do tego dochodzi obowiązek komunikacji na zewnątrz. Przy poważnym cyberzagrożeniu podmiot informuje użytkowników swoich usług o możliwych środkach zapobiegawczych, a o samym zagrożeniu — jeżeli nie zwiększy to poziomu ryzyka (art. 11 ust. 2a). O incydencie poważnym informuje użytkowników wtedy, gdy ma on niekorzystny wpływ na świadczenie usług (art. 11 ust. 2b). To decyzja komunikacyjna z konsekwencjami rynkowymi, podejmowana pod presją czasu, według kryterium zapisanego w ustawie.
Norma opisuje reagowanie na incydent jako proces: wykryj, oceń, zareaguj, wyciągnij wnioski. Ustawa dokłada do tego procesu adresata, zegar, formularz i kanał. Te cztery elementy to nie jest „lepsze wdrożenie ISO 27001” — to osobna warstwa obowiązku, którą trzeba zaprojektować, przypisać komuś imiennie i przetestować, zanim zadzwoni telefon.
Czego jeszcze nie znajdziesz w załączniku A do ISO 27001?
Kilku obowiązków, które ustawa opisuje z precyzją nieosiągalną dla normy międzynarodowej — bo są zakotwiczone w polskich instytucjach. To one najczęściej wypadają z tablic mapowania, i to one najczęściej wychodzą przy kontroli.
Zaświadczenie o niekaralności z Krajowego Rejestru Karnego. Zanim osoba rozpocznie realizację zadań, o których mowa w art. 8 lub art. 11 ustawy, przedstawia podmiotowi informację z KRK stwierdzającą niekaralność za przestępstwa przeciwko ochronie informacji; dopiero po jej otrzymaniu kierownik dopuszcza ją do tych zadań (art. 8f ust. 1). Jeżeli pojawi się uzasadnione podejrzenie skazania, podmiot wzywa do ponownego przedstawienia informacji (ust. 2). ISO 27001 ma kontrolę weryfikacji kandydatów, ale nie wskazuje instrumentu, katalogu przestępstw ani momentu, w którym dopuszczenie do zadań staje się dopuszczalne.
Szkolenie kierownika raz w roku kalendarzowym. Kierownik podmiotu kluczowego lub ważnego oraz osoba, której powierzono jego obowiązki w zakresie cyberbezpieczeństwa, przechodzą szkolenie raz w roku kalendarzowym, o zakresie wyznaczonym przez ustawę, a udział w szkoleniu jest udokumentowany (art. 8e). Norma wymaga świadomości i kompetencji; nie wyznacza częstotliwości, nie wskazuje adresata imiennie i nie żąda dowodu w takiej postaci.
Punkty kontaktu. Ustawa oczekuje wyznaczenia co najmniej dwóch osób do kontaktu z podmiotami krajowego systemu cyberbezpieczeństwa — w przypadku mikro- i małych przedsiębiorców co najmniej jednej. Niewyznaczenie ich jest wprost wymienione wśród podstaw kary pieniężnej dla kierownika (art. 73a ust. 1 pkt 6).
Kanał zgłoszeniowy dla użytkowników. Wśród podstaw kary dla kierownika ustawa wymienia również niezapewnienie użytkownikowi możliwości zgłoszenia cyberzagrożenia, incydentu lub podatności związanych ze świadczoną usługą (art. 73a ust. 1 pkt 7). To wymóg produktowy: dotyczy usługi, którą sprzedajesz, a nie wewnętrznego procesu bezpieczeństwa.
Każdy z tych obowiązków ma w normie jakiegoś dalekiego krewnego. Żaden nie ma odpowiednika, który dałoby się wpisać do tablicy odpowiedniości bez utraty tego, co w nim istotne — a istotny jest zwykle właśnie ten szczegół, który norma świadomie zostawia otwarty.
Kto odpowiada, gdy obowiązek nie zostanie wykonany?
Kierownik podmiotu — imiennie, także wtedy, gdy obowiązki powierzył komu innemu. Artykuł 8c ust. 1 ustawy o KSC przypisuje kierownikowi podmiotu kluczowego lub ważnego odpowiedzialność za wykonywanie wyliczonych w tym przepisie obowiązków, od zgłoszenia do wykazu, przez system zarządzania bezpieczeństwem, po obsługę i raportowanie incydentów. Ustęp 2 dodaje regułę, którą warto przeczytać zarządom dwukrotnie: jeżeli kierownikiem jest organ wieloosobowy i nie wskazano osoby odpowiedzialnej, odpowiedzialność ponoszą wszyscy członkowie tego organu. Ustęp 3 zamyka najczęstszą furtkę — odpowiedzialność trwa również wtedy, gdy część albo całość obowiązków powierzono innej osobie za jej zgodą.
Ustawa idzie dalej i wylicza, co konkretnie należy do kierownika (art. 8d): podejmowanie decyzji w zakresie przygotowania, wdrażania, stosowania, przeglądu i nadzoru systemu zarządzania bezpieczeństwem informacji; planowanie adekwatnych środków finansowych na realizację obowiązków z zakresu cyberbezpieczeństwa; przydzielanie zadań i nadzór nad ich wykonaniem; zapewnienie świadomości personelu; zapewnienie zgodności działania podmiotu z przepisami i regulacjami wewnętrznymi.
Punkt o środkach finansowych jest tym, który najtrudniej odwzorować w standardzie. Norma mówi o zapewnieniu zasobów; ustawa czyni z niedofinansowania bezpieczeństwa osobisty problem konkretnego człowieka. Artykuł 73a przewiduje karę pieniężną dla kierownika za niewykonanie obowiązków z art. 8d, art. 8e, art. 8f, art. 11 i kilkunastu innych przepisów, w kwocie nie większej niż 300 % otrzymywanego wynagrodzenia liczonego według zasad ustalania ekwiwalentu za urlop (ust. 4), a w podmiotach publicznych — do 100 % (ust. 5). Kara ta jest niezależna od kary nakładanej na sam podmiot (ust. 3).
To jest miejsce, w którym rozmowa o zgodności przestaje być rozmową o dokumentacji, a zaczyna być rozmową o ładzie korporacyjnym. Filar, w którym mieści się NIS2, nazywamy u siebie ładem, ryzykiem i zgodnością właśnie dlatego, że pierwsze słowo jest tu pierwsze nie przez przypadek: bez rozstrzygnięcia, kto imiennie odpowiada, pozostałe dwa nie mają się na czym oprzeć.
Ile realnie kosztuje fałszywe poczucie zgodności?
Najwięcej kosztuje w godzinach, nie w złotówkach — ale złotówki też są policzalne i warto je znać. Kara dla podmiotu kluczowego nie może przekroczyć 10 000 000 euro albo 2 % przychodów z działalności gospodarczej w poprzednim roku obrotowym, przy czym stosuje się kwotę wyższą, i nie może być niższa niż 20 000 zł (art. 73 ust. 3). Dla podmiotu ważnego pułap to 7 000 000 euro albo 1,4 % przychodów, przy dolnej granicy 15 000 zł (ust. 4). Jeżeli naruszenie powoduje bezpośrednie i poważne cyberzagrożenie dla obronności, bezpieczeństwa państwa, porządku publicznego albo życia i zdrowia ludzi, organ właściwy nakłada karę do 100 000 000 zł (ust. 5).
Te liczby robią wrażenie na slajdzie i niewiele zmieniają w praktyce, bo żaden zarząd nie planuje naruszenia. Prawdziwy koszt fałszywego poczucia zgodności ujawnia się gdzie indziej — w dwudziestej godzinie incydentu, kiedy okazuje się, że nikt nie wie, który CSIRT sektorowy jest właściwy, że konto w systemie teleinformatycznym z art. 46 ust. 1 nigdy nie zostało założone, a osoba, która miała je założyć, nie przedstawiła informacji z KRK i formalnie nie powinna była realizować tych zadań. Termin 24 godzin biegnie od wykrycia i nie zatrzymuje się na czas ustalania, kto ma co zrobić.
Certyfikat ISO 27001 nie chroni przed tym scenariuszem, bo nie o tym jest. Chroni przed nim jedna rzecz: przećwiczona ścieżka zgłoszenia z przypisanymi nazwiskami, wpisanymi progami i przetestowanym kanałem. Zbudowanie jej zajmuje kilka tygodni. Odkrycie jej braku w trakcie incydentu zajmuje kilka minut i kosztuje znacznie więcej.
Co ISO 27001 rzeczywiście załatwia w drodze do NIS2?
Załatwia rusztowanie — i to jest realna, mierzalna oszczędność, nie pocieszenie. Organizacja z działającym systemem zarządzania bezpieczeństwem informacji ma już to, co przy wdrażaniu obowiązków ustawowych bywa najdroższe: proces szacowania ryzyka, dyscyplinę dokumentacyjną, nawyk zbierania dowodów, rytm przeglądów zarządczych i audytów wewnętrznych, przypisane role. Wchodząc w NIS2, nie zaczyna od zera — dokłada warstwę do istniejącej konstrukcji.
Dlatego dwie tezy, które na pierwszy rzut oka wyglądają na sprzeczne, w rzeczywistości mówią o dwóch różnych rzeczach. Nasz przewodnik po mapowaniu NIS2 na ISO 27001 i NIST pokazuje, że mapowanie na uznane standardy przyspiesza i obniża koszt dojścia do zgodności — i to jest prawda o nakładzie pracy. Ten tekst mówi, że mapowanie nie wyczerpuje zakresu obowiązków — i to jest prawda o katalogu wymagań. Pierwsza odpowiada na pytanie „ile to potrwa”, druga na pytanie „czy to wszystko”. Obie warto mieć na biurku, bo odpowiedź tylko na jedno z tych pytań prowadzi na manowce: bez pierwszej przepłacasz, bez drugiej nie kończysz.
Warto też nazwać rzecz wprost, żeby uniknąć nadinterpretacji. „ISO 27001 nie wystarcza” nie znaczy „ISO 27001 nie pomaga”. Znaczy tyle, że certyfikat jest dowodem w jednej sprawie, a organ nadzoru prowadzi inną. Organizacja bez normy i bez ustawowej ścieżki zgłoszeń jest w sytuacji gorszej niż organizacja z normą i bez ścieżki — po prostu żadna z nich nie jest zgodna.
Jak odróżnić lukę zakresu od luki wdrożenia?
Rozróżnienie jest praktyczne, bo obie luki wymagają zupełnie innej pracy i innych pieniędzy. Luka wdrożenia to sytuacja, w której norma dostarcza mechanizm, a Ty go nie uruchomiłeś albo uruchomiłeś w zbyt wąskim zakresie — naprawiasz ją wewnątrz istniejącego systemu zarządzania. Luka zakresu to sytuacja, w której mechanizmu nie ma w normie w ogóle, bo obowiązek pochodzi z przepisu — naprawiasz ją, dobudowując nowy element i przypisując mu właściciela. Mylenie jednej z drugą kończy się kolejnym cyklem audytu wewnętrznego zamiast decyzji organizacyjnej.
Poniższa tabela porządkuje najczęstsze przypadki, które widzimy przy przeglądach dokumentacji u podmiotów mających certyfikat i zbliżających się do obowiązków ustawowych.
| Obowiązek z ustawy o KSC | Czy ISO 27001 daje mechanizm? | Czego norma nie rozstrzyga | Rodzaj luki | Co trzeba dołożyć |
|---|---|---|---|---|
| Kategoryzacja zdarzeń i decyzja o klasyfikacji | Tak — proces oceny i decyzji | Wartości progowe dla sektora | zakresu | Progi z rozporządzenia właściwego dla podmiotu, wpisane do procedury |
| Zgłoszenie wczesnego ostrzeżenia w 24 h (art. 11 ust. 1 pkt 4) | Częściowo — kontakt z organami | Adresat, zegar, kanał, sześć elementów treści | zakresu | Ustalony CSIRT sektorowy, konto w systemie z art. 46 ust. 1, szablon zgłoszenia |
| Sprawozdanie końcowe w miesiąc (art. 11 ust. 1 pkt 4c) | Tak — analiza poincydentalna | Termin liczony od zgłoszenia, wymagana zawartość | wdrożenia | Rozszerzenie raportu poincydentalnego o elementy z art. 12a i pilnowanie terminu |
| Weryfikacja niekaralności z KRK (art. 8f) | Częściowo — weryfikacja kandydatów | Instrument, katalog przestępstw, moment dopuszczenia | zakresu | Procedura pozyskania informacji z KRK przed dopuszczeniem do zadań |
| Szkolenie kierownika raz w roku (art. 8e) | Częściowo — świadomość i kompetencje | Adresat imienny, częstotliwość, dowód udziału | zakresu | Roczny cykl szkolenia zarządu z udokumentowaną frekwencją |
| Imienna odpowiedzialność kierownika (art. 8c) | Częściowo — role i odpowiedzialności | Skutki dla organu wieloosobowego, trwałość mimo delegacji | zakresu | Uchwała wskazująca osobę odpowiedzialną albo świadome przyjęcie odpowiedzialności zbiorowej |
| Informowanie użytkowników o incydencie (art. 11 ust. 2b) | Częściowo — plan komunikacji | Kryterium ustawowe uruchamiające obowiązek | zakresu | Kryterium decyzyjne i gotowe komunikaty w planie kryzysowym |
| Dowody skuteczności zabezpieczeń | Tak — audyt wewnętrzny i przeglądy | — | wdrożenia | Zwykle nic; wystarczy objąć zakresem systemy w usłudze regulowanej |
Wniosek z tej tabeli jest niewygodny, ale użyteczny: większość różnic między certyfikatem a zgodnością to luki zakresu, nie luki wdrożenia. Nie usuniesz ich lepszym audytem wewnętrznym ani szerszym zakresem certyfikacji, bo dotyczą rzeczy, których norma nie reguluje z założenia. Wymagają decyzji, nazwiska i wpisu do procedury.
Od czego zacząć, jeśli masz ISO 27001, a nie masz pewności co do NIS2?
Zacznij od ustalenia własnego statusu, bo od niego zależy wszystko dalsze. Sprawdź, czy jesteś podmiotem kluczowym, czy ważnym, i czy mieścisz się w katalogu z art. 8b ust. 1 ustawy o KSC — to rozstrzyga, czy Twoim źródłem wymagań technicznych jest rozporządzenie 2024/2690 wraz z wytycznymi ENISA, czy zupełnie inny akt. Ten jeden krok eliminuje najkosztowniejszy błąd, jaki widujemy: pracochłonne odwzorowanie dokumentu, który danego podmiotu nie dotyczy.
Potem, w tej kolejności: ustal właściwy CSIRT sektorowy i załóż konto w systemie teleinformatycznym z art. 46 ust. 1, a następnie przeprowadź przez ten kanał zgłoszenie próbne. Wpisz progi uznania incydentu za poważny do swojego systemu kategoryzacji — jako wartości liczbowe w procedurze, nie jako odesłanie do przepisu. Rozstrzygnij imiennie odpowiedzialność z art. 8c i zaplanuj roczny cykl szkoleń z art. 8e wraz ze sposobem dokumentowania udziału. Na końcu — i dopiero na końcu — zestaw dowody, które już masz w systemie zarządzania, z obowiązkami ustawowymi. Wtedy zobaczysz, ile z nich rzeczywiście da się wykorzystać ponownie, a to zwykle więcej, niż się spodziewasz.
Jeżeli chcesz mieć tę mapę zrobioną szybciej i z zewnętrznym punktem widzenia, oba warianty realizujemy jako usługę. Badanie gotowości do NIS2 odpowiada na pytanie, gdzie stoisz i czego brakuje — z rozbiciem na luki zakresu i luki wdrożenia, dokładnie w logice tabeli powyżej. Wdrożenie zgodności z NIS2 prowadzi od tej diagnozy do działającej ścieżki zgłoszeń, przypisanych odpowiedzialności i dokumentacji, którą da się pokazać organowi nadzoru.
Kluczowy wniosek: ISO 27001 daje Ci rusztowanie i realnie skraca drogę, ale zgodność z NIS2 rozstrzyga się w miejscach, których norma nie opisuje — przy progach, terminach, adresatach i nazwiskach. Zacznij od ustalenia statusu podmiotu, a nie od tablicy odpowiedniości kontroli.
Źródła:
- ENISA, Technical implementation guidance on cybersecurity risk-management measures, wersja 1.0, czerwiec 2025 — s. 2 (zakres podmiotowy), s. 7 (adresaci i charakter dokumentu), s. 9–10 (lista standardów, zastrzeżenia), s. 33 (kryteria kategoryzacji incydentów), s. 168 (słownik).
- Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz.U. 2018 poz. 1560, tekst jednolity Dz.U. 2026 poz. 20), w brzmieniu nadanym ustawą z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252, obowiązuje od 3 kwietnia 2026 r.).
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 z dnia 17 października 2024 r. ustanawiające zasady stosowania dyrektywy (UE) 2022/2555 w odniesieniu do wymogów technicznych i metodycznych dotyczących środków zarządzania ryzykiem w cyberbezpieczeństwie.
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (NIS2) — art. 21 ust. 2 i 5, art. 23 ust. 11.
