# Bezpieczeństwo łańcucha dostaw

Ostatnia aktualizacja: 2026-07-12
Wersja HTML (kanoniczna): https://szbihub.pl/wiedza/bezpieczenstwo-lancucha-dostaw/

---

## 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)](https://isap.sejm.gov.pl/isap.nsf/download.xsp/WDU20180001560/U/D20181560Lj.pdf)
- Ustawa z 23.01.2026 r. (Dz. U. 2026 poz. 252): [ISAP](https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20260000252)
- Dyrektywa (UE) 2022/2555 (NIS2), art. 22 ust. 1 - skoordynowane oceny łańcucha dostaw: [EUR-Lex](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555)
- 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)._