Bezpieczeństwo łańcucha dostaw – jakie wymagania stawiać dostawcom IT?

Zakup systemu informatycznego, hostingu, chmury, usługi utrzymaniowej albo asysty technicznej oznacza nie tylko zakup technologii. Jednostka uzależnia część swojego bezpieczeństwa od zewnętrznego dostawcy, jego personelu, infrastruktury, podwykonawców oraz komponentów wykorzystywanych w dostarczanym rozwiązaniu.

Dostawca może posiadać uprzywilejowany dostęp do systemów, odpowiadać za aktualizacje i kopie zapasowe albo jako pierwszy dowiedzieć się o podatności lub incydencie. Dlatego bezpieczeństwo łańcucha dostaw powinno być uwzględnione już na etapie przygotowania zamówienia, a nie dopiero po podpisaniu umowy.

Nie każda jednostka sektora finansów publicznych (JSFP) jest jednak automatycznie podmiotem kluczowym albo ważnym w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa (KSC). Najpierw należy przeprowadzić kwalifikację zgodnie z art. 5, załącznikami do KSC oraz – jeżeli ma to zastosowanie – decyzją właściwego organu. Poza zakresem KSC część opisanych dalej wymagań może nadal stanowić dobrą praktykę albo wynikać z innych przepisów i analizy ryzyka.

Najważniejsza zasada

Bezpieczeństwa dostawcy nie należy próbować „dopisać do umowy” po wyborze oferty.

ryzyko → wymaganie → OPZ → sposób weryfikacji → umowa → SLA → nadzór → zakończenie współpracy

Zakres wymagań musi być proporcjonalny do ryzyka i przedmiotu zamówienia.

Dwa modele KSC – nie każda jednostka stosuje art. 8 ust. 1

Podmiot stosujący art. 8 ust. 1

Art. 8 ust. 1 KSC wymaga od podmiotu kluczowego lub ważnego objętego tym modelem wdrożenia odpowiednich i proporcjonalnych środków technicznych i organizacyjnych. Jednym z wymienionych wprost obszarów jest bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT oraz procesów ICT, od których zależy świadczenie usługi, z uwzględnieniem relacji z bezpośrednim dostawcą.

Przy wdrażaniu tych środków podmiot bierze pod uwagę między innymi podatności związane z dostawcą, ogólną jakość produktów, usług i procesów ICT, wyniki skoordynowanych ocen bezpieczeństwa na poziomie UE oraz wyniki postępowania dotyczącego dostawcy wysokiego ryzyka. Bezpieczeństwo dostawcy jest więc w tym modelu elementem ustawowego systemu zarządzania bezpieczeństwem informacji (SZBI).

Szczególny model z art. 8 ust. 3 i załącznika nr 4

Szczególny model z art. 8 ust. 3 stosuje podmiot ważny będący podmiotem publicznym oraz wskazane w tym przepisie podmioty systemu szkolnictwa wyższego i nauki, niebędące organizacjami badawczymi – w zakresie, w jakim realizują zadania publiczne z wykorzystaniem systemów informacyjnych.

Podmioty te nie stosują art. 8 ust. 1 w tym zakresie, lecz wdrażają SZBI spełniający wymagania załącznika nr 4. Część II załącznika wskazuje możliwość stosowania środków dodatkowych, w tym odpowiednich wymagań bezpieczeństwa w relacjach ze stronami trzecimi. Nie należy jednak przedstawiać całego tego katalogu jako bezwzględnego zestawu obowiązków dla każdego podmiotu.

Wymagania wobec wykonawcy mogą być niezbędne również do wykonania obowiązkowych elementów części I – przykładowo aktualizacji oprogramowania, zarządzania dostępem, kopii zapasowych czy reagowania na podatności – jeżeli czynności te są wykonywane przez dostawcę.

Uwaga – raportowanie incydentów

Uproszczenie z art. 12c dotyczące braku wczesnego ostrzeżenia odnosi się literalnie do podmiotu ważnego będącego podmiotem publicznym. Samo objęcie podmiotu szkolnictwa wyższego modelem z art. 8 ust. 3 nie oznacza automatycznie zastosowania art. 12c – trzeba dodatkowo ustalić jego status.

Okres przejściowy też trzeba uwzględnić przy zakupach

Podmioty, które spełniały przesłanki uznania za kluczowe albo ważne 3 kwietnia 2026 r., mają zasadniczo 12 miesięcy na realizację obowiązków określonych w rozdziale 3, czyli do 3 kwietnia 2027 r.

Nie oznacza to, że do tego czasu można zawierać wieloletnie umowy bez wymagań bezpieczeństwa. Umowa zawarta w 2026 r. może obowiązywać już po upływie okresu dostosowawczego.

Najpierw oceń ryzyko dostawcy

Nie każdy zakup wymaga prawa audytu w centrum danych, wykazu składników oprogramowania SBOM (Software Bill of Materials) i całodobowego zespołu reagowania.

Przed przygotowaniem opisu przedmiotu zamówienia (OPZ) warto ustalić, czy wykonawca:

• otrzyma dostęp administracyjny do systemów;
• będzie przetwarzał lub przechowywał dane;
• będzie świadczył hosting albo usługę chmurową;
• będzie odpowiadał za aktualizacje lub podatności;
• będzie wykonywał kopie zapasowe;
• może wpływać na ciągłość istotnego procesu;
• posiada zdalny dostęp serwisowy;
• korzysta z podwykonawców mających dostęp do środowiska;
• może jako pierwszy wykryć incydent;
• jest trudny do zastąpienia po zakończeniu umowy.

Im większa zależność od wykonawcy, tym bardziej szczegółowe powinny być wymagania kontraktowe.

OPZ, warunki udziału, kryteria i umowa – cztery różne funkcje

Prawo zamówień publicznych (PZP) wymaga, aby OPZ był jednoznaczny i wyczerpujący. Wymagane cechy mogą odnosić się także do procesu lub cyklu życia przedmiotu zamówienia, jeżeli są związane z przedmiotem i proporcjonalne do jego wartości i celów.

Warunki udziału muszą być proporcjonalne i mogą dotyczyć między innymi zdolności technicznej lub zawodowej wykonawcy. Kryteria oceny ofert muszą natomiast pozostawać związane z przedmiotem zamówienia i co do zasady nie mogą dotyczyć ogólnych właściwości wykonawcy.

Jakie wymagania umieścić w OPZ?

Nie jest to ustawowa lista obowiązkowa dla każdego zamówienia. Zamawiający powinien potrafić wykazać związek konkretnego wymagania z przedmiotem i ryzykiem.

Warunki udziału i certyfikacja

Przy zamówieniu o istotnym ryzyku można badać doświadczenie w utrzymaniu podobnych środowisk, kwalifikacje personelu, zdolność do obsługi incydentów, dostępność wsparcia oraz zdolność do zarządzania podatnościami i aktualizacjami.

Nie należy mechanicznie wymagać od każdego wykonawcy certyfikatu ISO/IEC 27001. Jeżeli certyfikacja jest uzasadniona, trzeba ustalić, czego ma dowodzić, czy jej zakres obejmuje usługę istotną dla zamówienia, czy wymaganie jest proporcjonalne oraz jakie dowody równoważne należy dopuścić.

Kryteria ofertowe – nagradzaj jakość wykonania

PZP pozwala stosować kryteria jakościowe dotyczące m.in. parametrów technicznych, pomocy technicznej, serwisu oraz kwalifikacji personelu, gdy wpływają one istotnie na jakość realizacji.

Można rozważyć premiowanie krótszego czasu usuwania krytycznych podatności, lepszych parametrów RPO/RTO, szerszego monitorowania bezpieczeństwa, krótszego czasu reakcji, lepszych parametrów wsparcia lub dodatkowych zabezpieczeń ponad wymagane minimum.

Ostrożniej należy podchodzić do kryterium „wykonawca ma ISO/IEC 27001 – 10 punktów”, jeżeli punktowana jest w rzeczywistości ogólna cecha przedsiębiorcy, a nie jakość wykonania konkretnego zamówienia.

Umowa – co powinno być egzekwowalne?

Utrzymywanie bezpieczeństwa

Wykonawca powinien utrzymywać wymagany poziom zabezpieczeń przez cały okres świadczenia usługi oraz informować o zmianach mogących wpływać na bezpieczeństwo.

Podatności i aktualizacje

Umowa powinna określać, kto monitoruje podatności, kiedy wykonawca informuje o podatności krytycznej, kto odpowiada za poprawkę, jakie są terminy według krytyczności, jakie środki tymczasowe obowiązują przy braku poprawki oraz kto może odroczyć aktualizację. Terminy te są SLA kontraktowym, a nie ustawowymi terminami KSC.

Dostępy

Warto określić konta imienne, zakres uprawnień, MFA, rejestrowanie działań, zasady dostępu awaryjnego, termin odebrania dostępu oraz obowiązek okresowego przeglądu kont.

Incydent u dostawcy – umowa musi zostawić czas zamawiającemu

Jeżeli podmiot stosuje pełny model raportowania KSC, przekazuje:

• wczesne ostrzeżenie – niezwłocznie, nie później niż w ciągu 24 godzin od wykrycia incydentu poważnego;
• zgłoszenie incydentu poważnego – niezwłocznie, nie później niż w ciągu 72 godzin od wykrycia.

Podmiot ważny będący podmiotem publicznym nie przekazuje wczesnego ostrzeżenia, lecz nadal dokonuje zgłoszenia incydentu poważnego w terminie 72 godzin.

Termin umowny wykonawcy powinien wynikać z modelu KSC właściwego dla zamawiającego i pozostawiać mu realny czas na analizę, klasyfikację i wykonanie własnego obowiązku. Jeżeli zamawiający ma 24 godziny na wczesne ostrzeżenie, termin 24 godzin dla wykonawcy może być bezużyteczny. W zależności od ryzyka można przewidzieć znacznie krótszy czas, liczony w godzinach.

Wykonawca powinien przekazywać dostępne na danym etapie informacje: czas wykrycia, dotknięte systemy, możliwy wpływ, charakter incydentu, podjęte działania, dostępne logi i artefakty, informację o podwykonawcy oraz kolejne aktualizacje. Pierwsza informacja nie powinna zależeć od zakończenia pełnej analizy powłamaniowej.

Podwykonawcy – obowiązki muszą przechodzić w dół łańcucha

JSFP → integrator → dostawca chmury → centrum danych → podwykonawca serwisowy

W zamówieniu wysokiego ryzyka warto ustalić, którzy podwykonawcy mają dostęp do danych lub systemów, jaki jest ich zakres odpowiedzialności, czy posiadają dostęp uprzywilejowany, czy wykonawca zgłasza istotne zmiany, które obowiązki są przenoszone dalej oraz kto odpowiada za naruszenie przez podwykonawcę.

Nie oznacza to konieczności kontrolowania każdego komponentu globalnego łańcucha producenta. Nadzór powinien koncentrować się na zależnościach istotnych dla konkretnej usługi.

Prawo audytu – stopniuj mechanizmy kontroli

KSC nie stanowi, że każda umowa IT musi dawać zamawiającemu nieograniczone prawo audytu dostawcy. Prawo audytu jest mechanizmem kontraktowym potrzebnym do nadzoru nad wykonaniem wymagań.

1. raporty SLA i bezpieczeństwa;
2. niezależne raporty lub certyfikaty;
3. audyt dokumentacyjny;
4. audyt tematyczny w przypadku niezgodności;
5. audyt doraźny po istotnym incydencie.

Umowa powinna określać zakres audytu, ochronę tajemnic, sposób przekazywania dowodów, terminy działań korygujących oraz potwierdzenie ich wykonania. Precyzyjne prawo do konkretnych dowodów może być bardziej użyteczne niż ogólne uprawnienie do „audytu wszystkiego”.

SLA cyberbezpieczeństwa

SLA (Service Level Agreement) nie powinno ograniczać się do dostępności systemu i czasu odpowiedzi helpdesku.

Kary umowne – za naruszenie obowiązku, nie za sam fakt ataku

Sam cyberatak nie oznacza jeszcze nienależytego wykonania umowy. Bardziej precyzyjne są kary za nieterminowe powiadomienie, nieusunięcie podatności, nieuprawnione użycie konta administracyjnego, naruszenie zasad dotyczących podwykonawców, nieprzekazanie logów lub nieusunięcie niezgodności. Kara powinna być powiązana z konkretnym, obiektywnie weryfikowalnym obowiązkiem.

Dwie różne kategorie rekomendacji Pełnomocnika

Rekomendacja z art. 33 ust. 4

Art. 226 ust. 1 pkt 17 PZP nakazuje odrzucić ofertę, jeżeli obejmuje produkt ICT, usługę ICT lub proces ICT wskazany w rekomendacji z art. 33 ust. 4 KSC stwierdzającej ich negatywny wpływ na podstawowy interes bezpieczeństwa państwa. To ten szczególny rodzaj rekomendacji ma bezpośredni skutek zakupowy.

Ogólne rekomendacje z art. 67a

Art. 67a pozwala Pełnomocnikowi wydawać publikowane w BIP rekomendacje określające środki techniczne i organizacyjne służące zwiększaniu bezpieczeństwa. Zgodnie z art. 67a ust. 5 KSC ich stosowanie jest dobrowolne. Sama rekomendacja z art. 67a nie jest podstawą odrzucenia oferty z art. 226 ust. 1 pkt 17 PZP.

Dostawca wysokiego ryzyka

Drugim mechanizmem jest decyzja w sprawie uznania dostawcy za dostawcę wysokiego ryzyka (DWR). Art. 226 ust. 1 pkt 19 PZP przewiduje odrzucenie oferty obejmującej produkty, usługi lub procesy ICT objęte odpowiednią decyzją DWR.

Według informacji Ministerstwa Cyfryzacji z 6 sierpnia 2026 r. na ten dzień nie wydano żadnej decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka. Stan ten może się zmienić, dlatego przed wyborem oferty należy sprawdzać aktualne publikacje.

Ważny przepis przejściowy PZP

Nowe podstawy z art. 226 ust. 1 pkt 17 i 19 weszły w życie 3 kwietnia 2026 r. Art. 30 ustawy nowelizującej wprost stanowi, że nowe brzmienie pkt 17 stosuje się również do postępowań wszczętych i niezakończonych przed tą datą.

Art. 30 nie wymienia pkt 19. UZP wyjaśnia jednak, że wobec braku szczególnego przepisu przejściowego nowa podstawa z pkt 19 również znajduje zastosowanie od 3 kwietnia 2026 r., także w postępowaniach będących wtedy w toku. Nie należy więc uzasadniać obu przypadków identycznym przepisem przejściowym.

Plan wyjścia z umowy

Dla ważnych systemów warto przygotować plan wyjścia (exit plan) obejmujący eksport danych w uzgodnionym formacie, przekazanie dokumentacji i konfiguracji, wsparcie migracji, odebranie dostępów, usunięcie danych, przekazanie informacji o nierozwiązanych podatnościach, zasady kontynuacji licencji i wsparcia oraz usunięcie zależności utrudniających przejęcie systemu.

Wymagania te powinny pojawić się w dokumentacji zakupowej od początku, a nie dopiero podczas sporu z dotychczasowym dostawcą.

KSC i PZP to nie cały katalog wymagań

W zależności od przedmiotu zamówienia trzeba sprawdzić również art. 28 i 32 RODO, przepisy sektorowe, ochronę informacji niejawnych i tajemnic prawnie chronionych, archiwizację, interoperacyjność oraz szczególne zasady korzystania z chmury. Przedstawionych wymagań nie należy traktować jako kompletnej checklisty prawnej dla każdego zamówienia IT.

Checklista przed wszczęciem zamówienia IT

Podsumowanie

Bezpieczeństwo łańcucha dostaw nie polega na dodaniu do projektu umowy zdania: „Wykonawca zapewni zgodność z KSC i NIS2”. Jednostka powinna ustalić, jakie ryzyko wprowadza dostawca, jakie wymagania ograniczają to ryzyko, jak wykonawca ma wykazać ich spełnienie i co stanie się w razie naruszenia.

Dla podmiotów stosujących art. 8 ust. 1 bezpieczeństwo i ciągłość łańcucha dostaw są bezpośrednim elementem ustawowego SZBI. Podmioty objęte art. 8 ust. 3 stosują szczególny model z załącznika nr 4.

ryzyko → OPZ → weryfikacja → umowa → SLA → raportowanie → audyt → plan wyjścia

Najtrudniej kontrolować ryzyko dostawcy, którego jednostka zaczyna weryfikować dopiero po wystąpieniu incydentu. Bezpieczeństwo łańcucha dostaw powinno być projektowane przed zakupem i utrzymywane aż do bezpiecznego zakończenia współpracy.

Zobacz także

• Zarządzanie ryzykiem cyberbezpieczeństwa w JSFP
• Zgłaszanie incydentów w KSC – terminy i obieg informacji
• Pełny SZBI z art. 8 ust. 1 a model z art. 8 ust. 3
• Plan wdrożenia KSC w JSFP do 3 kwietnia 2027 r.

Podstawy prawne i źródła

• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa – tekst jednolity: Dz.U. z 2026 r. poz. 20, z późn. zm.; tekst ujednolicony uwzględniający poz. 252 i 815.
• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw – Dz.U. z 2026 r. poz. 252.
• Prawo zamówień publicznych – tekst jednolity: Dz.U. z 2026 r. poz. 793.
• Urząd Zamówień Publicznych – zmiany w PZP w związku z nowelizacją KSC, 23 marca 2026 r..
• Ministerstwo Cyfryzacji – procedura dotycząca dostawców wysokiego ryzyka, 6 sierpnia 2026 r..
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 – RODO.

Aktualny tekst ujednolicony KSC ma charakter informacyjny. Podstawowymi źródłami prawa pozostają akty ogłoszone w Dzienniku Ustaw oraz ustawy zmieniające. Materiały Ministerstwa Cyfryzacji i UZP mają charakter informacyjny i pomocniczy.

Zastrzeżenie: Artykuł ma charakter informacyjny. Konkretne wymagania zakupowe i kontraktowe należy dostosować do statusu podmiotu, przedmiotu zamówienia, właściwego modelu KSC, analizy ryzyka, dostępu wykonawcy do systemów i danych oraz przepisów PZP i innych regulacji właściwych dla konkretnego zamówienia.