NIS2 dla zespołu IT: które wymagania wpiąć w CI

Art. 21 ust. 2 dyrektywy NIS2 wylicza dziesięć grup środków zarządzania ryzykiem, a w zespole, który buduje i wydaje oprogramowanie, znaczną część z nich da się zamienić w kontrolę w CI albo w dowód, który powstaje sam. Państwa członkowskie miały przyjąć przepisy wdrażające dyrektywę (UE) 2022/2555 w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii do 17 października 2024 roku i stosować je od 18 października 2024 roku (art. 41). Polskie przepisy, w tym SZBI z art. 8 ustawy o KSC, opisuje artykuł o SZBI w ustawie o KSC. Tu chodzi o samą dyrektywę i o to, co z jej listy może przejąć pipeline.

Co NIS2 każe zrobić w art. 21 i art. 23

Art. 21 ust. 1 wymaga od podmiotów kluczowych i ważnych środków technicznych, operacyjnych i organizacyjnych, które są odpowiednie i proporcjonalne do ryzyka dla sieci i systemów informatycznych. Przy ich doborze uwzględnia się stan wiedzy technicznej, w stosownych przypadkach normy europejskie i międzynarodowe oraz koszt wdrożenia. Przy proporcjonalności uwzględnia się narażenie na ryzyko, wielkość podmiotu oraz prawdopodobieństwo i dotkliwość incydentów, w tym ich skutki społeczne i gospodarcze. Dyrektywa nie narzuca więc narzędzi. Wylicza cele, a sposób ich osiągnięcia zostawia podmiotowi. Wyjątkiem są niektórzy dostawcy usług cyfrowych, między innymi chmury, centrów danych i usług zarządzanych, dla których dyrektywa przewiduje wymogi techniczne w aktach wykonawczych Komisji (ust. 5).

Środki mają obejmować wszystkie zagrożenia, a ust. 2 podaje listę minimum od lit. a do j. Podmiot, który stwierdzi niezgodność z tą listą, podejmuje środki naprawcze bez zbędnej zwłoki (ust. 4). Państwa członkowskie ustalają kary same, ale dyrektywa wyznacza dolną granicę ich maksimum: dla podmiotów kluczowych co najmniej 10 mln euro albo 2% łącznego rocznego światowego obrotu przedsiębiorstwa z poprzedniego roku obrotowego, dla ważnych co najmniej 7 mln euro albo 1,4%, w obu przypadkach według kwoty wyższej (art. 34 ust. 4 i 5). Kwoty z polskiej ustawy i datę, od której można je nakładać, podaje artykuł o SZBI.

Które punkty art. 21 ust. 2 da się zamienić w kontrolę

Większość wymogów z listy można rozpisać na trzy rzeczy: kontrolę uruchamianą automatycznie, dowód, który ta kontrola zostawia, i decyzję, która zostaje człowiekowi. Ten sam sposób myślenia opisuje artykuł o WCAG i europejskim akcie o dostępności jako bramce w buildzie. Dyrektywa nie mówi, jak zautomatyzować środek, więc kolumny z kontrolą i dowodem to przełożenie na praktykę zespołu, a lista punktów pochodzi z ust. 2.

Kontrola uruchamiana przy każdej zmianie wykrywa niezgodność wcześniej niż przegląd wykonywany raz na jakiś czas, a podmiot, który ją stwierdzi, podejmuje środki naprawcze bez zbędnej zwłoki (art. 21 ust. 4). Wynik kontroli jest materiałem do polityk i procedur, których wymaga ust. 2, a nie ich zastępstwem.

Art. 23: wczesne ostrzeżenie, zgłoszenie i sprawozdania z logów

Incydent jest znaczący, gdy spowodował lub może spowodować poważne zakłócenia operacyjne albo straty finansowe podmiotu, albo dotknął lub może dotknąć inne osoby, powodując znaczne szkody majątkowe lub niemajątkowe (art. 23 ust. 3). Zgłoszenia składa się do CSIRT-u lub organu właściwego w kilku krokach (ust. 4):

• wczesne ostrzeżenie niezwłocznie, najpóźniej w ciągu 24 godzin od chwili, w której podmiot dowiedział się o znaczącym incydencie;
• zgłoszenie incydentu w ciągu 72 godzin, ze wstępną oceną dotkliwości i skutków oraz wskaźnikami naruszenia, jeśli są dostępne;
• sprawozdanie okresowe na żądanie;
• sprawozdanie końcowe nie później niż miesiąc po zgłoszeniu z 72. godziny, z opisem, rodzajem zagrożenia lub przyczyną źródłową, zastosowanymi środkami zaradczymi i skutkami transgranicznymi;
• przy incydencie, który trwa, sprawozdanie z postępu, a sprawozdanie końcowe w ciągu miesiąca od jego obsłużenia.

Zegar na wczesne ostrzeżenie rusza w chwili, w której podmiot się dowiedział, więc ta chwila musi zostać zapisana. W systemach oznacza to centralne logi, alert, którego potwierdzenie przez dyżurnego zostawia znacznik czasu, i logi wystarczające do wstępnej oceny z 72. godziny oraz do przyczyny źródłowej w sprawozdaniu końcowym. Najtańszy sprawdzian to ćwiczenie: zespół wypełnia szablon zgłoszenia z logów symulowanego incydentu i widzi luki, zanim zobaczy je prawdziwy incydent. Wynik ćwiczenia jest przy okazji materiałem do lit. f. Jak zgłoszenia wyglądają w polskiej ustawie, w tym przez S46, opisuje artykuł o SZBI.

Kopie, zależności i wydania: punkty c i e

Lit. c wymienia kopie zapasowe i przywracanie po sytuacji nadzwyczajnej. Kopia, której nikt nie odtworzył, pozostaje przypuszczeniem. Cykliczne zadanie odtwarza ją w izolowanym środowisku, uruchamia test dymny i zapisuje czas. Wynik jest materiałem do procedur z lit. c, a czas odtworzenia metryką dla lit. f.

Lit. e obejmuje bezpieczeństwo w nabywaniu, rozwoju i utrzymaniu systemów, w tym postępowanie w przypadku podatności i ich ujawnianie. W zespole przekłada się to na alerty o podatnościach w zależnościach (w GitHubie Dependabot), bramkę w GitHub Actions na krytycznych podatnościach, przegląd kodu przed scaleniem i kontrolę sekretów w repozytorium. Przy higienie zależności i bramkach w CI pracujemy na kodzie, architekturze i CI/CD, a ocena, czy dany podmiot spełnia NIS2 albo ustawę o KSC, to zadanie dla prawnika lub doradcy ds. zarządzania ryzykiem i zgodnością (GRC). Czy podmiot w ogóle podlega przepisom, pomaga ustalić przegląd ustawy o KSC w CyberKatalogu.

Z ujawnianiem podatności jest podobnie. Plik /.well-known/security.txt z kontaktem do zgłoszeń da się sprawdzić testem, czy istnieje i nie wygasł. Osoba, która odpowiada na zgłoszenie, to już sprawa organizacji.

Kryptografia, dostęp, MFA i miary skuteczności

Lit. h wymaga polityk i procedur stosowania kryptografii i, w stosownych przypadkach, szyfrowania. W systemach to konfiguracja, którą da się testować: wersje TLS, nagłówki ochronne, wygasanie certyfikatów. Test nie zastąpi dokumentu mówiącego, co jest szyfrowane i dlaczego.

Lit. i łączy kontrolę dostępu z zarządzaniem aktywami. Uprawnienia opisane jako kod i inwentarz wynikający z repozytorium oraz konfiguracji infrastruktury są wiarygodniejsze od arkusza prowadzonego ręcznie, bo zmieniają się razem z systemem. Przy MFA z lit. j dyrektywa dodaje zastrzeżenie "w stosownych przypadkach", a sprawdzenie, czy konta, które mają mieć MFA, je mają, to raport z ustawień organizacji.

Lit. f żąda polityk i procedur oceny skuteczności środków. Pipeline daje do tego surowiec: czas od alertu o podatności do poprawki, odsetek udanych odtworzeń kopii, liczbę wyjątków od bramek. W lit. g, podstawowych praktykach cyberhigieny i szkoleniach, część techniczna to regularne aktualizacje zależności i kontrola sekretów.

Czego nie da się wpiąć w CI

Lit. a, polityka analizy ryzyka i bezpieczeństwa systemów informatycznych, jest dokumentem i decyzją, a nie testem. Podobny charakter mają szkolenia z lit. g, zarządzanie kryzysowe z lit. c i bezpieczeństwo zasobów ludzkich z lit. i. Lit. d, bezpieczeństwo łańcucha dostaw, zaczyna się od oceny dostawców, a tę wykonuje człowiek.

Art. 20 ust. 1 przypisuje zatwierdzanie środków z art. 21 organom zarządzającym, które nadzorują ich wdrożenie i mogą odpowiadać za naruszenia. Ust. 2 wymaga regularnych szkoleń członków tych organów, a podmioty mają być zachęcane do podobnych szkoleń dla pracowników. Zatwierdzenie należy więc do organów zarządzających, a zespół IT dostarcza im to, co zatwierdza i nadzoruje: stan kontroli i listę odstępstw od nich.

Jak to się ma do ustawy o KSC

Dyrektywa wyznacza listę, a ustawa o KSC wdraża ją w Polsce z własnymi terminami, SZBI z art. 8 i systemem S46 do zgłoszeń. Daty, zakres obowiązków i krajowe kary zebrał artykuł o SZBI w ustawie o KSC. Kontrole opisane wyżej służą przy każdym z tych porządków, bo opierają się na logach, kopiach, zależnościach i dostępie.

Najczęściej zadawane pytania

Czy NIS2 wymaga konkretnych narzędzi?

NIS2 nie narzuca konkretnych narzędzi. Art. 21 ust. 1 mówi o środkach odpowiednich i proporcjonalnych, dobranych według stanu wiedzy technicznej, kosztu wdrożenia i ryzyka, a ust. 2 wylicza cele. Wybór narzędzia należy do podmiotu.

Czy 24 godziny na zgłoszenie oznaczają pełny raport?

Zgłoszenie w 24 godziny to wczesne ostrzeżenie, a nie pełny raport. Termin liczy się od chwili, w której podmiot dowiedział się o znaczącym incydencie. Zgłoszenie ze wstępną oceną następuje w ciągu 72 godzin, a sprawozdanie końcowe z przyczyną źródłową nie później niż miesiąc po tym zgłoszeniu (art. 23 ust. 4).

Kto odpowiada za środki z art. 21?

Za środki z art. 21 odpowiada podmiot, a zatwierdzają je i nadzorują organy zarządzające, które mogą odpowiadać za naruszenia (art. 20 ust. 1). Członkowie tych organów przechodzą regularne szkolenia (ust. 2).

Od kiedy obowiązuje NIS2?

Art. 41 nakazywał państwom członkowskim przyjąć i opublikować przepisy wdrażające do 17 października 2024 roku i stosować je od 18 października 2024 roku. W Polsce dyrektywę wdraża nowelizacja ustawy o KSC (Dz.U. 2026 poz. 252), która obowiązuje od 3 kwietnia 2026 roku, a SZBI trzeba wdrożyć do 3 kwietnia 2027 roku. Pozostałe terminy zebrał artykuł o SZBI.

Źródła

1. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii (dyrektywa NIS 2), art. 20, art. 21 ust. 1-4, art. 23 ust. 3-4, art. 34 ust. 4-5 i art. 41 (odczyt 28.10.2026)