Bezpieczeństwo łańcucha dostaw w NIS2 i ustawie o KSC – jak sprawdzić dostawcę IT i co wpisać do umowy

Bezpieczeństwo łańcucha dostaw w ustawie o krajowym systemie cyberbezpieczeństwa (KSC) wymaga, by podmiot sprawdzał bezpośrednich dostawców IT proporcjonalnie do ryzyka i zapisywał wymagania bezpieczeństwa w umowach. W praktyce oznacza to rejestr dostawców, ocenę krytyczności, dowody dopasowane do ryzyka, osiem elementów umowy i stały monitoring. Poniżej sześć kroków dla podmiotów kluczowych i ważnych.

Stan prawny na dzień 9 października 2026 r.

Co oznacza bezpieczeństwo łańcucha dostaw w ustawie o KSC i NIS2?

Bezpieczeństwo łańcucha dostaw to obowiązek zarządzania ryzykiem, które wnoszą dostawcy sprzętu, oprogramowania i usług IT. Art. 8 ust. 1 pkt 2 lit. e ustawy o KSC (po nowelizacji Dz.U. 2026 poz. 252) wymaga, by SZBI obejmował „bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT, od których zależy świadczenie usługi”.

Art. 8 ust. 1 pkt 2 lit. e KSC wdraża art. 21 ust. 2 lit. d dyrektywy (UE) 2022/2555 (NIS2) i dotyczy relacji z bezpośrednimi dostawcami. Art. 8 ust. 2 KSC, odpowiednik art. 21 ust. 3 NIS2, każe przy wdrażaniu tych środków uwzględnić:

• podatności związane z dostawcą sprzętu lub oprogramowania,
• ogólną jakość jego produktów, usług i procesów ICT,
• wyniki skoordynowanej oceny bezpieczeństwa Grupy Współpracy NIS (art. 22 ust. 1 NIS2),
• wyniki postępowania w sprawie dostawcy wysokiego ryzyka (art. 67b KSC).

Według art. 8b ust. 1 KSC rozporządzenie wykonawcze Komisji (UE) 2024/2690 stosują wprost m.in. dostawcy chmury, centrów przetwarzania danych, usług DNS i sieci CDN, dostawcy usług zarządzanych (MSP) oraz usług zarządzanych w zakresie cyberbezpieczeństwa (MSSP). Pozostałe podmioty stosują akty wykonawcze wydane dla ich rodzaju podmiotu (art. 8b ust. 2 KSC). W naszej ocenie mogą traktować rozporządzenie 2024/2690 jako punkt odniesienia i dobrą praktykę.

Podmiot ważny będący podmiotem publicznym buduje SZBI według załącznika nr 4 do ustawy (art. 8 ust. 3 KSC w brzmieniu z Dz.U. 2026 poz. 252). Jeśli nie wiesz jeszcze, do której grupy należysz, sprawdź, kogo obejmuje ustawa o KSC i jakie nakłada obowiązki.

Jak sprawdzić dostawcę IT – sześć kroków

Dostawcę IT sprawdza się w sześciu krokach, od rejestru po monitoring, zgodnie z pkt 5.1–5.2 załącznika do rozporządzenia 2024/2690.

1. Załóż rejestr bezpośrednich dostawców

Pkt 5.2 załącznika do rozporządzenia 2024/2690 wymaga rejestru bezpośrednich dostawców z punktami kontaktowymi i wykazem dostarczanych produktów, usług i procesów ICT. Dopisz właściciela relacji i rodzaj dostępu.

W projektach, które prowadzimy, najczęściej w rejestrze brakuje dostawcy z dostępem zdalnym: firmy z kontem VPN, kontem serwisowym lub narzędziem zdalnego wsparcia. Kupuje się od niej usługę, nie licencję, więc umyka ewidencji oprogramowania.

2. Oceń, od których dostawców zależy świadczenie usługi

Dla każdego dostawcy ustal, czy ma dostęp do systemów lub danych, co się stanie, gdy przestanie działać, i jak szybko można go zastąpić. Wynik przełóż na poziom krytyczności: wysoki przy dostępie administracyjnym lub zdalnym, danych usługi u dostawcy albo trudnej zastępowalności, średni, gdy produkt przetwarza dane usługi po Twojej stronie bez dostępu dostawcy, niski bez dostępu do systemów i danych. Użyj tej samej metody szacowania ryzyka w bezpieczeństwie informacji, co w całym SZBI.

3. Ustal kryteria wyboru i kwestionariusz

Pkt 5.1.2 załącznika do rozporządzenia 2024/2690 wskazuje cztery kryteria wyboru: praktyki cyberbezpieczeństwa dostawcy (w tym procedury bezpiecznego opracowywania), zdolność spełnienia Twoich specyfikacji, jakość i odporność produktów oraz możliwość ograniczenia uzależnienia od jednego dostawcy. Zapisz je w polityce bezpieczeństwa łańcucha dostaw (pkt 5.1.1).

W kwestionariuszu, zgodnie z pkt 6.1.2 załącznika, pytaj o aktualizacje zabezpieczeń w całym cyklu życia lub wymianę po końcu wsparcia, o elementy sprzętu i oprogramowania oraz o metody walidacji zgodności.

4. Dobierz dowód do krytyczności dostawcy

Siła dowodu powinna rosnąć razem z krytycznością dostawcy. Poniższy podział to nasza robocza propozycja: przykłady dowodów do wymogów rozporządzenia 2024/2690 podaje ENISA w NIS2 Technical Implementation Guidance z 26 czerwca 2025 r., ale poziomów krytyczności przepisy nie narzucają.

Krytyczność dostawcy	Przykład	Minimalny dowód	Kiedy żądać więcej
Niska	Dostawca oprogramowania bez dostępu do systemów i danych usługi	Oświadczenie lub wypełniony kwestionariusz bezpieczeństwa	Gdy dostawca uzyskuje dostęp do danych albo rozszerza się zakres usługi
Średnia	Aplikacja przetwarzająca dane usługi, utrzymywana po stronie podmiotu	Certyfikat ISO/IEC 27001 z zakresem obejmującym dostarczaną usługę i kwestionariusz	Gdy zakres certyfikatu nie obejmuje usługi albo u dostawcy wystąpił poważny incydent
Wysoka	Dostawca z dostępem administracyjnym lub zdalnym, MSP/MSSP, chmura z danymi usługi	Raport z testu penetracyjnego, prawo do audytu lub raporty z audytu	Gdy raport jest nieaktualny, nie obejmuje używanych komponentów albo brakuje retestu

Certyfikat ISO/IEC 27001 potwierdza działający system zarządzania w określonym zakresie, a nie brak podatności w konkretnym produkcie.

Nabywca ma ograniczony wgląd w powstawanie produktów, które mogą być podrobione lub zawierać złośliwą funkcjonalność (NIST SP 800-161 Rev. 1), więc przy wysokiej krytyczności sam certyfikat nie wystarcza. Test penetracyjny, który motyw 15 rozporządzenia 2024/2690 wymienia wśród testów bezpieczeństwa, sprawdza produkt w Twoim środowisku. Przy niższej krytyczności zwykle wystarczy przegląd dokumentacji.

5. Wpisz wymagania do umowy

Pkt 5.1.4 załącznika do rozporządzenia 2024/2690 wymienia osiem elementów, które w stosownych przypadkach określa się w umowach z dostawcami, także w umowach o gwarantowanym poziomie usług (SLA).

Element umowy	Co wpisać w praktyce
a) Wymogi cyberbezpieczeństwa	Załącznik z wymaganiami: MFA przy dostępie zdalnym, szyfrowanie, logowanie, aktualizacje.
b) Szkolenia i certyfikaty personelu	Obowiązek szkoleń z bezpieczeństwa dla osób obsługujących usługę i wymagane kwalifikacje administratorów.
c) Sprawdzanie przeszłości pracowników	Weryfikacja osób z dostępem uprzywilejowanym w granicach prawa pracy i ochrony danych.
d) Zgłaszanie incydentów bez zbędnej zwłoki	Konkretny termin zawiadomienia, krótszy niż Twoje wczesne ostrzeżenie do CSIRT (24 h wg art. 11 KSC), kanał kontaktu i zakres informacji. Zobacz też, jak wyglądają terminy zgłaszania incydentów poważnych.
e) Prawo do audytu lub raportów z audytu	Prawo do audytu albo do raportów, w tym z testów penetracyjnych i retestów, z ustaleniem kosztów i zasad udostępniania.
f) Postępowanie z podatnościami	Terminy usuwania zależne od wagi podatności, informowanie o nich i dostarczanie poprawek.
g) Podwykonawstwo	Zgoda na podwykonawców z dostępem do usługi i przeniesienie na nich tych samych wymagań.
h) Obowiązki przy rozwiązaniu umowy	Zwrot lub usunięcie danych z potwierdzeniem, odebranie dostępów, przekazanie dokumentacji i informacji potrzebnych do przejęcia usługi.

W przeglądanych przez nas umowach często widzimy zapisy, które dają prawo do audytu, ale nie mówią, kto ponosi jego koszt. Nie rozstrzygają też, czy raport z testu penetracyjnego dostawcy można udostępnić audytorowi lub organowi.

6. Monitoruj, przeglądaj i zaplanuj wyjście

Pkt 5.1.6–5.1.7 załącznika do rozporządzenia 2024/2690 wymaga przeglądu polityki w zaplanowanych odstępach oraz po istotnych zmianach i poważnych incydentach. Monitoruj raporty SLA, incydenty u dostawców i zmiany w ich produktach.

Plan wyjścia wskazuje alternatywę, sposób odzyskania danych i czas migracji. Relację z dostawcą z perspektywy obu stron porządkuje norma ISO/IEC 27036-1:2021.

Dostawca wysokiego ryzyka – co oznacza decyzja ministra dla Twoich umów?

Dostawca wysokiego ryzyka to dostawca sprzętu lub oprogramowania uznany decyzją ministra właściwego do spraw informatyzacji za zagrożenie dla podstawowego interesu bezpieczeństwa państwa (art. 67b ust. 15 KSC). Decyzja oznacza zakaz wprowadzania do użytkowania objętych nią produktów, usług i procesów ICT. Już używane trzeba wycofać najpóźniej w 7 lat od ogłoszenia decyzji (art. 67c KSC, Dz.U. 2026 poz. 252). Przedsiębiorcy komunikacji elektronicznej z art. 67b ust. 1 pkt 2 mają na wycofanie 4 lata w zakresie funkcji krytycznych z załącznika nr 3 do ustawy (art. 67c ust. 2).

Postępowanie minister prowadzi z urzędu lub na wniosek przewodniczącego Kolegium do Spraw Cyberbezpieczeństwa, po opinii Kolegium (art. 67b KSC). Ministerstwo Cyfryzacji w komunikacie z 29 października 2024 r. podkreślało, że ocena obejmuje aspekty techniczne i nietechniczne, a nie samo państwo pochodzenia.

Decyzja wskazuje typy produktów i usług, jest ogłaszana w Monitorze Polskim i podlega natychmiastowemu wykonaniu (art. 67b ust. 15–18 KSC w tekście nowelizacji). Do czasu wycofania dopuszczalne są naprawy, modernizacja, wymiana elementu i aktualizacja, jeśli są niezbędne dla ciągłości usług (art. 67c KSC).

Wyniki tego postępowania uwzględniasz w środkach łańcucha dostaw (art. 8 ust. 2 pkt 4 KSC). Potrzebne są dwie rzeczy:

• inwentarz produktów i usług od każdego dostawcy, z którego ustalisz, czego dotyczy decyzja;
• klauzula umowna o wymianie objętego komponentu albo prawie wypowiedzenia umowy.

Inwentarz przyda się też przy kontroli: art. 67d KSC (Dz.U. 2026 poz. 252) pozwala organom właściwym żądać informacji o wycofywanych produktach w terminie nie krótszym niż 7 dni.

Najczęstsze pytania o bezpieczeństwo łańcucha dostaw

Czy obowiązek bezpieczeństwa łańcucha dostaw w KSC dotyczy wszystkich dostawców, czy tylko bezpośrednich?

Przepisy dotyczą przede wszystkim bezpośrednich dostawców. Art. 8 ust. 1 pkt 2 lit. e ustawy o KSC i art. 21 ust. 2 lit. d NIS2 odnoszą się do relacji z bezpośrednim dostawcą lub usługodawcą. Dalsze ogniwa kontroluje się pośrednio: klauzulą o podwykonawstwie, która przenosi wymagania na podwykonawców, i pytaniami o komponenty produktu.

Czy certyfikat ISO 27001 dostawcy wystarczy?

Dla dostawców o średniej krytyczności zwykle tak, razem z kwestionariuszem i pod warunkiem, że zakres certyfikatu obejmuje dostarczaną usługę. Certyfikat ISO/IEC 27001 potwierdza jednak działający system zarządzania, a nie brak podatności w konkretnym produkcie. Od dostawców z dostępem administracyjnym lub z danymi usługi warto dodatkowo żądać raportu z testu penetracyjnego albo prawa do audytu.

Czy można wymagać od dostawcy testów penetracyjnych?

Tak, jeśli uzasadnia to ocena ryzyka i zapisano to w umowie. Pkt 5.1.4 załącznika do rozporządzenia 2024/2690 przewiduje prawo do audytu lub raportów z audytu, a motyw 15 wymienia testy penetracyjne wśród testów bezpieczeństwa. Umowa powinna określać zakres testu, częstotliwość, retest po poprawkach i zasady udostępniania raportu.

Co zrobić, gdy duży dostawca chmury nie zgadza się na nasze klauzule?

Porównaj standardową umowę i dokumentację dostawcy z listą z pkt 5.1.4 rozporządzenia 2024/2690 i zapisz, które elementy są pokryte. Luki uzupełnij raportami z niezależnych audytów, certyfikatami o właściwym zakresie i własnymi zabezpieczeniami, np. szyfrowaniem i kopiami zapasowymi poza dostawcą. Ryzyko rezydualne udokumentuj i przekaż do akceptacji właścicielowi ryzyka wskazanemu w metodyce, a przy wysokim ryzyku kierownictwu.

Od kiedy grożą kary za brak środków łańcucha dostaw?

Kary można nałożyć po raz pierwszy po 3 kwietnia 2028 r., czyli 2 lata od wejścia w życie nowelizacji (Dz.U. 2026 poz. 252, art. 35 ustawy zmieniającej). Podstawą jest art. 73 ust. 1 pkt 3 KSC: kara grozi, gdy SZBI nie spełnia wymogów art. 8 ust. 1, także w zakresie łańcucha dostaw. Podmioty objęte ustawą od 3 kwietnia 2026 r. wdrażają SZBI do 3 kwietnia 2027 r. (art. 33 ust. 1 ustawy zmieniającej).

Jak Pentestica może pomóc

Mamy ponad 10 lat doświadczenia i setki zrealizowanych projektów. W ramach wdrożenia wymagań NIS2 i ustawy o KSC oceniamy dostawców, przygotowujemy rejestr i kwestionariusze oraz przeglądamy umowy. Wykonujemy testy penetracyjne systemów dostarczanych przez dostawców wraz z retestami po poprawkach. Prowadzimy też audyt bezpieczeństwa IT obejmujący dostęp dostawców. Wstępny zakres prac określisz w konfiguratorze zakresu usług NIS2.

Źródła

• 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) – nowelizacja KSC, m.in. art. 8, 8b, 67b–67d i 73
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) – art. 21 ust. 2 lit. d i ust. 3 o bezpieczeństwie łańcucha dostaw
• Rozporządzenie wykonawcze Komisji (UE) 2024/2690 – załącznik, pkt 5.1–5.2 i 6.1.2: polityka łańcucha dostaw, kryteria wyboru, elementy umów, rejestr dostawców
• ENISA, NIS2 Technical Implementation Guidance (czerwiec 2025) – praktyczne wskazówki i przykłady dowodów do wymogów rozporządzenia 2024/2690
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations – zarządzanie ryzykiem łańcucha dostaw w systemach i organizacjach
• ISO/IEC 27036-1:2021 Cybersecurity – Supplier relationships – Part 1 – relacja z dostawcą z perspektywy nabywcy i dostawcy
• Ministerstwo Cyfryzacji, komunikat z 29.10.2024 o procedurze dostawcy wysokiego ryzyka – kryteria oceny w projekcie przepisów