Ustawa o KSC, NIS2 i dostawcy oprogramowania: co musi zrobić każda ze stron

01NIS2 i ustawa o KSC jesienią 2026 r.

Dyrektywa NIS2 (otwiera stronę zewnętrzną), czyli dyrektywa (UE) 2022/2555, została opublikowana w Dzienniku Urzędowym 27 grudnia 2022 r. i weszła w życie 16 stycznia 2023 r. Państwa członkowskie miały przyjąć i opublikować przepisy krajowe do 17 października 2024 r. i stosować je od 18 października 2024 r., czyli od dnia uchylenia pierwszej dyrektywy NIS.

Dyrektywa wiąże przez prawo krajowe, a wdrażanie przebiegało nierówno: część państw zdążyła w terminie, inne przyjęły przepisy dopiero w 2025 lub 2026 r., a Komisja Europejska wszczęła postępowania w sprawie naruszenia przeciwko państwom, które terminu nie dotrzymały. Dlatego rejestracja, kanały zgłoszeń i organy nadzoru różnią się w zależności od kraju.

W Polsce NIS2 wdraża ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (otwiera stronę zewnętrzną) (Dz.U. 2026 poz. 252). Obowiązuje od 3 kwietnia 2026 r. Wykaz podmiotów kluczowych i ważnych ruszył 13 kwietnia 2026 r., samorejestracja trwała od 7 maja do 3 października 2026 r., a część podmiotów Minister Cyfryzacji wpisał do wykazu z urzędu. Komunikaty o wykazie publikuje Ministerstwo Cyfryzacji (otwiera stronę zewnętrzną).

02Podmioty kluczowe i ważne

NIS2 obejmuje podmioty publiczne i prywatne z sektorów wymienionych w załączniku I (sektory kluczowe: energetyka, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT, administracja publiczna i przestrzeń kosmiczna) oraz w załączniku II (sektory ważne: usługi pocztowe i kurierskie, gospodarowanie odpadami, chemikalia, żywność, produkcja, dostawcy usług cyfrowych i badania naukowe). Co do zasady dotyczy średnich i dużych organizacji. Niektóre podmioty są objęte niezależnie od wielkości, na przykład dostawcy usług zaufania, dostawcy usług DNS i podmioty administracji rządowej.

Art. 3 dyrektywy dzieli te organizacje na dwie kategorie:

• Podmioty kluczowe: głównie duże organizacje z sektorów z załącznika I oraz podmioty kluczowe niezależnie od wielkości, takie jak kwalifikowani dostawcy usług zaufania, rejestry nazw domen najwyższego poziomu, dostawcy usług DNS i podmioty administracji rządowej. Nadzór nad nimi jest uprzedni i może obejmować audyty oraz kontrole na miejscu.
• Podmioty ważne: pozostałe organizacje objęte załącznikami I i II. Nadzór jest następczy: organ działa, gdy pojawią się sygnały, że podmiot nie spełnia wymagań.

Obie kategorie mają te same podstawowe obowiązki: środki zarządzania ryzykiem (art. 21), zgłaszanie incydentów (art. 23) i odpowiedzialność kierownictwa (art. 20). Różnią się nadzorem i wysokością kar. Za naruszenie art. 21 lub 23 prawo krajowe musi przewidywać kary maksymalne co najmniej 10 mln euro albo 2% całkowitego światowego rocznego obrotu dla podmiotów kluczowych oraz co najmniej 7 mln euro albo 1,4% dla podmiotów ważnych, w zależności od tego, która kwota jest wyższa. O tym, czy i w jakim zakresie kary dotyczą podmiotów administracji publicznej, decydują państwa członkowskie. Konkretne kary w Polsce określa ustawa o KSC.

Czy dostawca oprogramowania sam podlega przepisom?

Tworzenie oprogramowania samo w sobie nie jest sektorem NIS2. Dostawca może jednak podlegać przepisom bezpośrednio. Załącznik I obejmuje dostawców usług zarządzanych, a dyrektywa definiuje ich szeroko: to podmioty, które instalują, zarządzają, obsługują lub utrzymują produkty, sieci, infrastrukturę lub aplikacje ICT dla klientów, na miejscu albo zdalnie. Średni lub duży dostawca, który prowadzi lub utrzymuje aplikacje swoich klientów, może więc podlegać NIS2 samodzielnie, podobnie jak dostawcy usług chmurowych i centrów danych. Dla tych dostawców szczegółowe wymagania techniczne określa rozporządzenie wykonawcze (UE) 2024/2690 (otwiera stronę zewnętrzną).

Większość dostawców oprogramowania styka się jednak z NIS2 przez klientów, którzy przekładają własny obowiązek dotyczący łańcucha dostaw na klauzule umowne, kwestionariusze i audyty. Produkty programowe obejmuje też akt o cyberodporności (otwiera stronę zewnętrzną), rozporządzenie (UE) 2024/2847: obowiązki zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów stosuje się od 11 września 2026 r., a pozostałe obowiązki od 11 grudnia 2027 r.

03Dziesięć minimalnych środków z art. 21

Art. 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, opartych na podejściu uwzględniającym wszystkie zagrożenia. Mają odpowiadać aktualnemu stanowi wiedzy oraz właściwym normom europejskim i międzynarodowym, a także narażeniu podmiotu na ryzyko, jego wielkości i prawdopodobnej dotkliwości incydentów. Obejmują co najmniej:

1. 01politykę analizy ryzyka i bezpieczeństwa systemów informatycznych;
2. 02obsługę incydentów;
3. 03ciągłość działania, na przykład zarządzanie kopiami zapasowymi i odtwarzanie po awarii, oraz zarządzanie kryzysowe;
4. 04bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa relacji z bezpośrednimi dostawcami i usługodawcami;
5. 05bezpieczeństwo w procesie nabywania, rozwoju i utrzymania sieci i systemów informatycznych, w tym obsługę i ujawnianie podatności;
6. 06polityki i procedury oceny skuteczności tych środków;
7. 07podstawowe praktyki cyberhigieny i szkolenia z cyberbezpieczeństwa;
8. 08polityki i procedury stosowania kryptografii oraz, w stosownych przypadkach, szyfrowania;
9. 09bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie aktywami;
10. 10w stosownych przypadkach uwierzytelnianie wieloskładnikowe lub ciągłe oraz zabezpieczoną komunikację głosową, wideo, tekstową i awaryjną.

Punkty 4 i 5 dotyczą dostawców bezpośrednio. Art. 21 ust. 3 każe podmiotom uwzględniać podatności specyficzne dla każdego bezpośredniego dostawcy, ogólną jakość jego produktów i praktyk cyberbezpieczeństwa oraz jego procedury bezpiecznego rozwoju. Klient ma więc patrzeć na to, jak dostawca buduje oprogramowanie, a nie tylko na to, co dostarcza.

04Kierownictwo zatwierdza, nadzoruje i odpowiada

Zgodnie z art. 20 organy zarządzające podmiotów kluczowych i ważnych zatwierdzają środki zarządzania ryzykiem w cyberbezpieczeństwie, nadzorują ich wdrażanie i mogą ponosić odpowiedzialność za naruszenia. Ich członkowie muszą przechodzić szkolenia, a podmioty powinny regularnie szkolić także pracowników. W przypadku podmiotów publicznych nadal obowiązują krajowe przepisy o odpowiedzialności instytucji publicznych i urzędników.

To zmienia rozmowę z dostawcami. Zarząd, który ma zatwierdzić środki, potrzebuje dowodów, które da się prześledzić: którzy dostawcy obsługują które usługi, jakie ryzyka pozostają i co rzeczywiście przetestowano.

05Zgłaszanie incydentów: 24 godziny, 72 godziny, miesiąc

Art. 23 zobowiązuje podmioty do zgłaszania poważnych incydentów właściwemu zespołowi CSIRT lub organowi. Incydent jest poważny, jeśli spowodował lub może spowodować poważne zakłócenia działania usług albo straty finansowe podmiotu, lub znaczne szkody majątkowe albo niemajątkowe u innych. Zgłoszenie przebiega etapami:

W stosownych przypadkach podmioty muszą też bez zbędnej zwłoki informować odbiorców swoich usług o poważnych incydentach, które mogą na te usługi wpłynąć. Ustawa o KSC określa, do kogo i w jakiej formie zgłasza się incydenty w Polsce.

Termin biegnie od chwili, w której podmiot dowiedział się o incydencie. Jeśli incydent zaczyna się w systemie dostawcy, klient dotrzyma terminu 24 godzin tylko wtedy, gdy dostawca wykryje go, rozpozna i przekaże dalej w ciągu kilku godzin. Wykrywanie, rejestrowanie zdarzeń i uzgodniony kanał powiadomień są więc warunkami umowy, a nie tylko szczegółem technicznym.

06Czego klient objęty NIS2 oczekuje od dostawcy oprogramowania

W praktyce art. 21 przekłada się na środki techniczne i dowody, które dostawca powinien móc pokazać bez uruchamiania osobnego projektu. Najczęściej spotykamy:

• Bezpieczny cykl wytwarzania oprogramowania. Modelowanie zagrożeń przy istotnych zmianach, przegląd kodu, automatyczne testy bezpieczeństwa i skanowanie zależności w potoku, podpisane kompilacje oraz zestawienie podstawowych materiałów do produkcji oprogramowania (SBOM) dla każdego wydania.
• Obsługa i ujawnianie podatności. Opublikowany sposób zgłaszania podatności, czasy reakcji uzgodnione według wagi i powiadomienie klienta, gdy podatność dotyczy jego środowiska.
• Kontrola dostępu personelu dostawcy. Imienne konta, uwierzytelnianie wieloskładnikowe, minimalne uprawnienia, ograniczony w czasie dostęp uprzywilejowany i rejestr każdej czynności administracyjnej w środowisku klienta.
• Rejestrowanie zdarzeń i dowody incydentów. Zdarzenia istotne dla bezpieczeństwa zapisywane z wiarygodnymi znacznikami czasu, przechowywane przez uzgodniony okres i możliwe do wyeksportowania, aby klient mógł odpowiedzieć na pytania wczesnego ostrzeżenia i sprawozdania końcowego.
• Współpraca przy incydentach. Wskazana osoba kontaktowa i kanał, czas powiadomienia wyraźnie krótszy niż 24 godziny klienta oraz wsparcie w analizie przyczyn.
• Ciągłość działania i odtwarzanie. Kopie zapasowe sprawdzone przez faktyczne odtworzenie, cele odtwarzania zgodne z celami klienta i przećwiczona procedura.
• Dokumentacja łańcucha dostaw. Aktualna lista podwykonawców i lokalizacji hostingu oraz głównych komponentów i usług zewnętrznych, od których zależy rozwiązanie.
• Plan wyjścia. Eksport danych w użytecznych formatach, dokumentacja i wsparcie przy przekazaniu, aby klient mógł zmienić dostawcę bez utraty kontroli nad usługą.

Dla dojrzałych zespołów inżynierskich nic z tego nie jest nowe. NIS2 zmienia to, że klient musi umieć to wykazać. Na stronie Zaufanie i zgodność opisujemy, jak pracujemy jako dostawca, w tym system zarządzania bezpieczeństwem informacji z certyfikatem ISO/IEC 27001.

07Lista kontrolna dla umów i zamówień

1. 01Przypisanie dostawców do usług. Ustalić, którzy dostawcy obsługują które usługi objęte przepisami i którzy mają dostęp do systemów lub danych.
2. 02Klasyfikacja według krytyczności. Najwyższe wymagania stawiać dostawcom, którzy prowadzą krytyczne systemy lub mogą je zmieniać.
3. 03Środki zapisane w umowie. Wymagania bezpieczeństwa, czas i kanał powiadamiania o incydentach, obsługa podatności, rejestrowanie i retencja zdarzeń, prawo do audytu lub dowodów, zasady podwykonawstwa i lokalizacje.
4. 04Dowody zamiast deklaracji. Certyfikaty wraz z zakresem, wyniki testów, SBOM, data ostatniego testu odtworzenia.
5. 05Wyjście uzgodnione z góry. Zwrot danych, wsparcie w okresie przejściowym i czas, przez który dostawca utrzymuje usługę.
6. 06Wspólne ćwiczenia. Ćwiczenie incydentu z krytycznymi dostawcami, łącznie z wczesnym ostrzeżeniem w ciągu 24 godzin.
7. 07Regularny przegląd. Dostawcy, usługi i zagrożenia się zmieniają; rejestr dostawców aktualizowany raz w roku przez większość roku jest nieaktualny.

W zamówieniach publicznych te wymagania trafiają do specyfikacji warunków zamówienia (SWZ) i projektu umowy. Wykonawca odpowiada na nie punkt po punkcie i dostarcza dokumentację wymaganą w postępowaniu.

08Szczegóły określa prawo krajowe

Rejestracja, kanały zgłoszeń, formularze, właściwy organ i ewentualne dodatkowe wymagania wynikają z prawa krajowego, w Polsce z ustawy o KSC i jej aktów wykonawczych. Niektóre państwa członkowskie wiążą środki z art. 21 z krajowymi ramami lub certyfikacją. Co do zasady podmiot podlega państwu, w którym ma siedzibę. Art. 26 przewiduje wyjątki: dostawcy publicznych sieci i usług łączności elektronicznej podlegają każdemu państwu, w którym świadczą usługi, dostawcy chmury, centrów danych, usług zarządzanych i kilku innych usług cyfrowych państwu swojej głównej jednostki organizacyjnej, a podmioty administracji publicznej państwu, które je utworzyło. Dla polskiego podmiotu z dostawcą z innego państwa UE oznacza to, że obie strony mogą podlegać różnym przepisom krajowym.

09Na co zwracać uwagę w najbliższych miesiącach

• Akty wykonawcze do ustawy o KSC, aktualizacje wykazu podmiotów kluczowych i ważnych oraz komunikaty właściwych organów.
• Zaproponowany przez Komisję 19 listopada 2025 r. Digital Omnibus (otwiera stronę zewnętrzną), COM(2025) 837, który kierowałby zgłoszenia incydentów na podstawie NIS2, RODO, DORA i innych przepisów przez jeden punkt kontaktowy prowadzony przez ENISA. W październiku 2026 r. projekt wciąż był rozpatrywany przez Parlament Europejski (otwiera stronę zewnętrzną)); dopóki nie zostanie przyjęty i nie zacznie być stosowany, obowiązują obecne kanały i terminy.
• Skoordynowane unijne oceny ryzyka krytycznych łańcuchów dostaw ICT na podstawie art. 22, które podmioty muszą uwzględniać przy doborze środków wobec dostawców.
• Harmonogram aktu o cyberodporności dla produktów programowych, z pełnym stosowaniem od 11 grudnia 2027 r.

W przypadku podmiotów sektora finansowego rozporządzenie DORA zastępuje przepisy NIS2 o zarządzaniu ryzykiem ICT, zgłaszaniu incydentów i nadzorze; więcej w artykule DORA i zewnętrzni dostawcy usług ICT. Komisja prowadzi przegląd NIS2 i aktów wykonawczych na swojej stronie poświęconej dyrektywie NIS2 (otwiera stronę zewnętrzną).