Baza wiedzy - obowiązek KSC

Bezpieczeństwo łańcucha dostaw

Bezpieczeństwo łańcucha dostaw w ustawie o KSC (art. 8 ust. 1 pkt 2 lit. e i ust. 2): rejestr dostawców ICT, ocena krytyczności, dostawca wysokiego ryzyka (art. 67b) i presja kontrahentów w praktyce.

Opublikowano: 11 lipca 2026Ostatnia aktualizacja: 12 lipca 2026

Status tej treści

Poniżej znajduje się pełna treść artykułu w wersji roboczej 0.9-draft - przed przeglądem radcy prawnego (OP-6.2, blueprint-nis2-gtm-operations.md). Mimo formy artykułu poradnikowego nie jest to jeszcze zatwierdzona treść prawna: dopiero po przeglądzie kancelarii treść uzyska status zatwierdzonej. Miejsca oznaczoneTODO-CONTENT/TODO-LEGAL-REVIEW to otwarte pytania i decyzje, których nie wypełniamy domysłem.

TL;DR

  • Podmiot kluczowy lub ważny zapewnia “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, z uwzględnieniem związków pomiędzy bezpośrednim dostawcą sprzętu lub oprogramowania a podmiotem” (art. 8 ust. 1 pkt 2 lit. e ustawy o KSC).
  • Przy wdrażaniu tych środków uwzględnia się podatności i ogólną jakość produktów poszczególnych dostawców, wyniki skoordynowanych ocen bezpieczeństwa łańcucha dostaw Grupy Współpracy NIS2 oraz wyniki krajowego postępowania w sprawie dostawcy wysokiego ryzyka (art. 8 ust. 2, w zw. z art. 67b).
  • Efekt domina: skoro KAŻDY podmiot objęty ustawą musi oceniać swoich dostawców ICT, to dostawcy ICT (w tym firmy IT) będą dostawać kwestionariusze bezpieczeństwa od klientów - niezależnie od tego, czy sami są objęci ustawą.
  • Praktyczny nośnik obowiązku: rejestr dostawców z oceną krytyczności i zapisami nadzoru (interpretacja praktyczna, nie cytat przepisu).

Co dokładnie nakazuje ustawa

Art. 8 ust. 1 pkt 2 lit. e wskazuje przedmiot ochrony: 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 - z uwzględnieniem związków między podmiotem a jego bezpośrednim dostawcą sprzętu lub oprogramowania.

Art. 8 ust. 2 precyzuje, co bierze się pod uwagę przy doborze środków:

  1. podatności charakterystyczne dla poszczególnych dostawców,
  2. ogólną jakość produktów ICT, usług ICT i procesów ICT poszczególnych dostawców,
  3. wyniki skoordynowanych ocen bezpieczeństwa łańcucha dostaw prowadzonych przez Grupę Współpracy NIS2 (mechanizm z art. 22 ust. 1 dyrektywy (UE) 2022/2555),
  4. wyniki krajowego postępowania w sprawie dostawcy wysokiego ryzyka (art. 67b ustawy o KSC).

Ostatni punkt ma zęby: jeżeli w postępowaniu krajowym dostawca zostanie uznany za dostawcę wysokiego ryzyka, podmioty objęte ustawą muszą się z tym wynikiem liczyć przy własnych decyzjach zakupowych. TODO-CONTENT: szczegółowe skutki decyzji z art. 67b dla już posiadanego sprzętu/oprogramowania (harmonogramy wycofania) wymagają odrębnej analizy prawnej - nie opisujemy ich tu z pamięci.

Efekt domina: dlaczego to Ciebie dotyczy, nawet jeśli ustawa Cię nie obejmuje

Ten obowiązek jako jedyny w ustawie działa “na zewnątrz”. Podmiot objęty ustawą, wykonując art. 8 ust. 1 pkt 2 lit. e, musi zapytać swojego dostawcę usług IT o bezpieczeństwo - bo od tego dostawcy zależy jego usługa. W praktyce oznacza to kwestionariusze due diligence, załączniki bezpieczeństwa do umów i pytania o certyfikaty, wysyłane do firm, których ustawa formalnie nie obejmuje.

Dla firmy IT obsługującej podmioty objęte ustawą są dwa wnioski:

  1. Pytania przyjdą od klientów, zanim cokolwiek zrobi urząd. Kontrole organu właściwego (art. 53) obowiązują od 3.04.2026 r., ale kwestionariusz od największego klienta może przyjść w dowolny wtorek - i brak odpowiedzi kosztuje kontrakt, nie karę.
  2. Sam możesz być objęty ustawą bezpośrednio. Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa jest podmiotem kluczowym już od statusu małego przedsiębiorstwa (art. 5 ust. 1 pkt 3); granica między “zwykłą” obsługą IT a usługami zarządzanymi bywa nieostra (definicje: art. 2 pkt 4i oraz 4j) - w razie wątpliwości sprawdź kwalifikację i skonsultuj status z prawnikiem.

Jak to wygląda w praktyce małej firmy

  1. Wyprowadź listę dostawców z rejestru aktywów. Usługi zewnętrzne (hosting, poczta, SaaS księgowy, serwis IT, dostawca oprogramowania branżowego) to gotowa pierwsza kolumna rejestru dostawców.
  2. Oceń krytyczność względem usługi. Pytanie testowe: co się dzieje z naszą usługą, gdy ten dostawca znika na 24 h / 30 dni? Dostawcy krytyczni dostają wyższy reżim nadzoru.
  3. Zbierz to, co dostawca już publikuje. Lokalizacja danych, certyfikaty, lista podprocesorów, status zgodności - dla większości dostawców SaaS te dane są publiczne. Zapis w rejestrze z datą i źródłem to już zapis nadzoru (art. 10 ust. 4).
  4. Dla dostawców krytycznych: wymagania do umowy. Powiadamianie o incydentach, prawo do informacji o podatnościach, warunki wyjścia (eksport danych). Nowe umowy negocjujesz od razu; istniejące - przy odnowieniu.
  5. Przegląd na zdarzenia i cyklicznie. Incydent u dostawcy, zmiana podprocesorów, wynik postępowania z art. 67b - to wyzwalacze. Do tego przegląd całości raz do roku (nasza praktyka, spójna z przeglądem SZBI).

Jakie artefakty trzeba mieć

Artefakt Podstawa Uwagi
Rejestr dostawców ICT z oceną krytyczności art. 8 ust. 1 pkt 2 lit. e forma rejestru = interpretacja praktyczna
Zapisy nadzoru nad dostawcami (daty, źródła, ustalenia) art. 8 ust. 2; art. 10 ust. 4 dowód, że ocena faktycznie się dzieje
Wymagania bezpieczeństwa w umowach z dostawcami krytycznymi art. 8 ust. 1 pkt 2 lit. e dobra praktyka: PN-EN ISO/IEC 27001 zał. A 5.19-5.23
Plan na scenariusz “dostawca wysokiego ryzyka” art. 8 ust. 2 w zw. z art. 67b TODO-CONTENT: szczegóły skutków decyzji do analizy prawnej

Najczęstsze błędy

  1. Rejestr dostawców = lista kontrahentów z księgowości. Liczy się zależność usługi od dostawcy ICT, nie wolumen faktur. Mały dostawca krytycznego oprogramowania branżowego jest ważniejszy niż duży dostawca materiałów biurowych.
  2. Ankieta wysłana, temat zamknięty. Kwestionariusz bez oceny odpowiedzi i bez zapisu w rejestrze to korespondencja, nie nadzór (art. 8 ust. 2 każe uwzględniać podatności i jakość - czyli wyciągać wnioski).
  3. Brak warunków wyjścia. Bezpieczeństwo ŁAŃCUCHA obejmuje też ciągłość (art. 8 ust. 1 pkt 2 lit. e mówi o “bezpieczeństwie i ciągłości”): umowa bez eksportu danych i planu przejścia zostawia Cię z ryzykiem, którego nie widać do dnia wypowiedzenia.
  4. Ignorowanie własnej roli dostawcy. Firma IT, która doradza klientom w KSC, a sama nie odpowiada na ich kwestionariusze, traci wiarygodność dokładnie tam, gdzie zarabia.

Checklista do odhaczenia

  • Mam rejestr dostawców ICT wyprowadzony z rejestru aktywów (art. 8 ust. 1 pkt 2 lit. e)
  • Każdy dostawca ma ocenę krytyczności względem świadczonej usługi
  • Dla dostawców krytycznych zebrałem publiczne dane bezpieczeństwa (lokalizacja danych, podprocesorzy, certyfikaty) z datą i źródłem
  • Nowe umowy z dostawcami krytycznymi zawierają wymagania bezpieczeństwa i warunki wyjścia
  • Mam wyzwalacze przeglądu (incydent u dostawcy, zmiana podprocesorów, decyzja art. 67b) + przegląd roczny
  • Zapisy nadzoru trafiają do dokumentacji operacyjnej (art. 10 ust. 4)
  • (Firma IT) sprawdziłem własny status: czy nie jestem dostawcą usług zarządzanych / usług zarządzanych w zakresie cyberbezpieczeństwa (art. 2 pkt 4i-4j, art. 5 ust. 1 pkt 3)

Pytania i odpowiedzi

Czy muszę audytować każdego dostawcę? Nie. Art. 8 ust. 2 każe uwzględniać podatności i jakość produktów dostawców - intensywność nadzoru dobierasz do krytyczności (proporcjonalność z art. 8 ust. 1 pkt 2). Dla dostawcy niekrytycznego wystarczy wpis w rejestrze; dla krytycznego - zapisy nadzoru i wymagania umowne.

Mój klient (podmiot objęty ustawą) przysłał mi kwestionariusz bezpieczeństwa. Czy mam obowiązek odpowiedzieć? Ustawowego obowiązku nie masz (o ile sam nie jesteś podmiotem objętym) - ale Twój klient wykonuje swój obowiązek z art. 8 ust. 1 pkt 2 lit. e i brak odpowiedzi zwykle oznacza dla niego ryzyko, którego musi się pozbyć. W praktyce: odpowiedź to warunek utrzymania kontraktu.

Co to jest “dostawca wysokiego ryzyka”? Instytucja krajowego postępowania z art. 67b ustawy o KSC: wynik takiego postępowania podmioty objęte ustawą muszą uwzględniać przy zapewnianiu bezpieczeństwa łańcucha dostaw (art. 8 ust. 2). Szczegółowe skutki decyzji (w tym dla już eksploatowanego sprzętu) - TODO-CONTENT, wymagają analizy prawnej.

Czy chmura (M365, AWS) też wchodzi do rejestru dostawców? Tak, jeżeli od niej zależy świadczenie usługi - art. 8 ust. 1 pkt 2 lit. e obejmuje usługi ICT i procesy ICT, nie tylko dostawców sprzętu.

Źródła

  • Ustawa o KSC - tekst ujednolicony Kancelarii Sejmu z 2026-07-07: isap.sejm.gov.pl (PDF)
  • Ustawa z 23.01.2026 r. (Dz. U. 2026 poz. 252): ISAP
  • Dyrektywa (UE) 2022/2555 (NIS2), art. 22 ust. 1 - skoordynowane oceny łańcucha dostaw: EUR-Lex
  • PN-EN ISO/IEC 27001, zał. A 5.19-5.23 (relacje z dostawcami) - norma, dobra praktyka, nie przepis

Ten artykuł jest narzędziem informacyjnym, nie poradą prawną. Status treści: 0.9-draft, przed przeglądem kancelarii (TODO-LEGAL-REVIEW).

Podstawa prawna

Numer artykułu ustawy o KSC dla tego obowiązku:art. 8 ust. 1 pkt 2 lit. e i ust. 2

  • Kontrahenci już proszą podmioty o wykazanie statusu zgodności z NIS2 - potwierdza to badanie CyberSmart "NIS2 Survey 2026" (n=670 liderów biznesu, 9 rynków UE w tym Polska).
    ref

    CyberSmart, "NIS2 Survey 2026" (badanie OnePoll, n=670, 9 rynków UE w tym Polska)

    brak (obserwacja rynkowa, nie przepis prawny) - badanie rynkowe, nie ustawa

    Zobacz źródło →TODO-LEGAL-REVIEW

Powiązane artefakty w platformie

Klucze artefaktów produktu powiązanych z tym obowiązkiem (mechanika, nie treść prawna):

  • register:suppliers:non_empty

Powiązane narzędzia

Pełny rejestr zmian prawnych i "stan prawny treści" czyta ten sam źródło co sekcja "Prawo" dokumentacji.