Outsourcing bez outsourcingu odpowiedzialności. Jak zabezpieczyć łańcuch dostaw podmiotu krytycznego? [OPINIA]

To założenie stoi za obowiązkami dotyczącymi łańcucha dostaw w znowelizowanej ustawie o krajowym systemie cyberbezpieczeństwa. Nowelizacja (Dz.U. 2026 poz. 252) weszła w życie 3 kwietnia 2026 r. Podmiot kluczowy lub ważny musi zapewnić bezpieczeństwo i ciągłość łańcucha dostaw produktów, usług i procesów ICT, od których zależy świadczona przez niego usługa. Przepis nie rozróżnia, czy dany element infrastruktury utrzymuje własny zespół, czy zewnętrzny dostawca. Obowiązek dotyczy usługi jako całości.

Kiedy dostawca staje się ryzykiem organizacji

Ustawa przewiduje konkretne narzędzia nadzoru nad dostawcami. Organ może wydać decyzję o dostawcy wysokiego ryzyka (art. 67b), co skutkuje obowiązkiem wycofania jego rozwiązań i zakazem ich ponownego wdrożenia czasem na lata.

Dostawcy usług zarządzanych cyberbezpieczeństwa są traktowani jako podmioty kluczowe z mocy samej ustawy (art. 5 ust. 1 pkt 3), więc podlegają tym samym rygorom co ich klienci.

Sankcja za zaniedbanie oceny ryzyka dostawcy jest dotkliwa. Jeśli naruszenie bezpieczeństwa powstanie u dostawcy, a podmiot kluczowy nie przeprowadził wcześniej należytej oceny jego ryzyka, kara administracyjna może sięgnąć 10 mln euro lub 2% rocznego obrotu w zależności od tego, która kwota jest wyższa (art. 73 ust. 3).

Dla podmiotów ważnych pułap jest niższy, ale wciąż liczony w milionach euro. Podobna logika obowiązuje na styku z ustawą o ochronie infrastruktury krytycznej (Dz.U. 2026 poz. 815).

Wprowadza ona pojęcie dostawcy krytycznego podmiotu dostarczającego produkty, usługi lub technologie, których zakłócenie może wywołać incydent istotny u podmiotu krytycznego. Dwa reżimy prawne, jeden mechanizm: odpowiedzialność za bezpieczeństwo łańcucha zostaje po stronie zamawiającego.

Cztery filary bezpiecznego łańcucha dostaw

• Inwentaryzacja i klasyfikacja. Punktem wyjścia jest pełna lista dostawców ICT, z podziałem na krytycznych i niekrytycznych. Większość organizacji nie ma takiej listy w kompletnej formie dostawcy SaaS bywają wdrażani przez pojedyncze zespoły, bez wiedzy działu bezpieczeństwa.
• Ocena ryzyka przed podpisaniem umowy. Due diligence dostawcy powinno obejmować jego certyfikacje, historię incydentów, lokalizację przetwarzania danych i status wobec własnych obowiązków regulacyjnych. Dopiero na tej podstawie można zdecydować, czy ryzyko jest akceptowalne.
• Klauzule umowne proporcjonalne do ryzyka. Umowa z dostawcą istotnym dla bezpieczeństwa systemu kluczowego powinna zawierać prawo do audytu, obowiązek notyfikacji o incydencie w określonym terminie, minimalne wymagania techniczne oraz klauzulę wyjścia (exit clause), która pozwala bezpiecznie zakończyć współpracę bez utraty ciągłości usługi.
• Monitoring, nie jednorazowa kontrola. Ocena ryzyka dostawcy nie kończy się w dniu podpisania umowy. Zmiana właściciela dostawcy, nowy podwykonawca w jego łańcuchu, decyzja regulatora o statusie wysokiego ryzyka każde z tych zdarzeń może zmienić profil ryzyka z dnia na dzień.

Co zrobić z dostawcą, który nie spełnia wymagań

Gdy ocena ryzyka wypada negatywnie, organizacja ma trzy drogi. Może wdrożyć kontrole kompensacyjne dodatkową segmentację sieci, szyfrowanie, wzmocniony monitoring, ograniczenie zakresu dostępu dostawcy.

Może renegocjować umowę, wzmacniając klauzule bezpieczeństwa i prawo do szybkiego wycofania. Może wreszcie zakończyć współpracę i zastąpić dostawcę innym.

Trzecia droga bywa najbezpieczniejsza, ale rzadko najszybsza dlatego plan awaryjny wobec kluczowych dostawców warto mieć przygotowany, zanim stanie się potrzebny.

Dlaczego to szczególnie dotyczy administracji publicznej

Instytucje publiczne rzadko budują infrastrukturę krytyczną samodzielnie. Korzystają z zewnętrznych operatorów telekomunikacyjnych, dostawców chmury, firm utrzymaniowych i podwykonawców budowlanych przy inwestycjach infrastrukturalnych.

Każde z tych ogniw wchodzi w zakres odpowiedzialności instytucji zamawiającej, nawet jeśli formalnie działa pod własną firmą i na własny rachunek.

Rejestr dostawców ICT, ocena ryzyka i odpowiednie klauzule umowne nie są więc formalnością do wypełnienia przed kontrolą.

Są jedynym sposobem, żeby instytucja publiczna wiedziała, gdzie kończy się jej realna kontrola nad bezpieczeństwem usługi i gdzie zaczyna się ryzyko, za które i tak odpowie sama.