NIS2 w praktyce: Co to znaczy „zarządzać łańcuchem dostaw”– i gdzie w nim jesteś Ty

Zapytanie ofertowe od klienta z energetyki, ochrony zdrowia czy infrastruktury cyfrowej wygląda dziś inaczej niż jeszcze niedawno. Obok stawek i harmonogramu pojawiają się pytania:

• kto dokładnie z zespołu będzie miał dostęp do systemów,
• jak ta osoba została zweryfikowana,
• jak szybko dostęp zostanie odebrany,
• co zrobi konsultant, jeśli zauważy coś niepokojącego.

Źródłem tych pytań jest znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa (KSC), która wdraża unijną dyrektywę NIS2 i obowiązuje od 3 kwietnia 2026 r. [1] Jednym z jej kluczowych wymagań jest bezpieczeństwo łańcucha dostaw. [2]

Ten tekst nie jest wykładem z prawa. Pokazuje, czym w praktyce jest łańcuch dostaw, gdzie w nim jest osoba z IT pracująca u klienta oraz czego można się spodziewać.

W skrócie: 5 rzeczy do zapamiętania

1. Firmy objęte ustawą (ustawa nazywa je podmiotami kluczowymi i ważnymi) muszą zadbać o bezpieczeństwo produktów, usług i procesów ICT (Information and Communication Technology) dostarczanych z zewnątrz. [3] Konsultant z dostępem do ich systemów jest częścią tego łańcucha.
2. Odpowiedzialność za to ponosi kierownictwo klienta, a od kwietnia 2028 r. za zaniedbania grożą kary finansowe. [4,5]
3. Wymagania trafiają do konsultanta głównie przez umowę i procedury klienta, a nie bezpośrednio z ustawy.
4. Wyjątek wart uwagi: Przy niektórych rolach klient musi poprosić o informację z Krajowego Rejestru Karnego. Miejcie to na uwadze, jeśli musicie szybko dołączyć do projektu. Warto zawczasu mieć takie zaświadczenie (wniosek można złożyć online – na odpowiedź czeka się kilka dni, bądź uzyskać je natychmiast w sądzie obsługującym takie wnioski. I uwaga – nie musicie jechać do sądu, który jest właściwy ze względu na wasze miejsce zamieszkania. Szczególnie nie musicie jechać do sądu w Katowicach, kolejki do KRK są tam już zbyt duże. Polecam sąd w Sosnowcu albo Gliwicach :)) [6]
5. Klient ma 24 godziny na pierwsze zgłoszenie poważnego incydentu. [7] Szybka informacja od konsultanta to jego zapas czasu.

Kalendarz: Gdzie jesteśmy?

Co to znaczy dla IT: Firmy, które były objęte ustawą od dnia jej wejścia w życie, mają czas na wdrożenie obowiązków do 3 kwietnia 2027 r. (Wyjątkiem są dotychczasowi operatorzy usług kluczowych, którzy po nowemu zgłaszają incydenty już po 6 miesiącach). [9] To dlatego wielu klientów właśnie teraz przegląda umowy z dostawcami, wysyła ankiety bezpieczeństwa i dopisuje nowe klauzule.

To nie jednorazowa akcja, tylko budowa stałego procesu, który klient będzie musiał pokazać audytorowi.

Czym właściwie jest „łańcuch dostaw ICT”?

Ustawa mówi o bezpieczeństwie i ciągłości dostaw produktów, usług i procesów ICT, od których zależy usługa klienta. [3] W praktyce chodzi o wszystko i wszystkich spoza organizacji, bez których jej systemy nie działają – albo przez które ktoś mógłby się do nich dostać.

Dyrektywa NIS2 wymienia przykłady: dostawców usług przechowywania i przetwarzania danych, dostawców usług bezpieczeństwa i producentów oprogramowania. Zwraca też uwagę na dostawców „z innych poziomów”, czyli dostawców dla dostawców klienta, np. podwykonawców Twojej firmy. [11]

Trzy pytania, które pomagają rozpoznać „łańcuch”

• Czy system klienta od tego zależy? Jeśli awaria dostawcy chmury zatrzymuje usługę klienta – to jest to element łańcucha.
• Czy ktoś z zewnątrz ma dzięki temu dostęp? Konto konsultanta, VPN serwisanta, klucz API integratora – każdy taki dostęp to potencjalne wejście.
• Czy coś z zewnątrz trafia do środka? Aktualizacja oprogramowania, biblioteka w kodzie, obraz kontenera, firmware.

Co to znaczy „zarządzać” łańcuchem dostaw?

Przepisy nie podają gotowej procedury, ale wskazują, co klient musi brać pod uwagę:

• słabe punkty dostawcy,
• jakość jego produktów i usług,
• jego praktyki bezpiecznego wytwarzania,
• unijne oceny ryzyka i ewentualne uznanie dostawcy za „dostawcę wysokiego ryzyka”. [12]

Dwa pierwsze punkty wydają się wspaniałe, szczególnie dla procesu sprzedaży i negocjacji, prawda? Do oceny technicznej dodano problematyczne elementy do sprawdzenia i udowodnienia, takie jak „słabość” czy „jakość”. W jaki sposób to sprawdzić i udokumentować? Może o tym w innym artykule pt. „Jak żyć z nieprecyzyjnymi wymaganiami”.

Dyrektywa zachęca też do wpisywania wymagań bezpieczeństwa wprost do umów z dostawcami. [11]

W praktyce daje to cykl:

Dlaczego klienci traktują to tak poważnie (albo inaczej – dlaczego poważnie powinni traktować bezpieczeństwo łańcucha dostaw)

We wrześniu 2024 r. przestępcy uzyskali dostęp do infrastruktury Atende, polskiego integratora IT. Z jednego serwera plików pobrali dane dotyczące pracowników firmy i umów z jej klientami. Atende poinformowało klientów o danych, które ich dotyczą, i rozszerzyło uwierzytelnianie dwuskładnikowe na wszystkie konta VPN. [13]

W styczniu 2025 r. ofiarą ataku ransomware padł EuroCert, dostawca usług zaufania (m.in. podpisów kwalifikowanych i pieczęci) dla wielu instytucji publicznych. Pełnomocnik Rządu do spraw Cyberbezpieczeństwa zalecił kontrahentom tej firmy m.in. zablokowanie zdalnego dostępu i powiązań infrastruktury IT z EuroCertem, zmianę poświadczeń do powiązanych kont i wdrożenie uwierzytelniania dwuskładnikowego. [13]

Oba przypadki pokazują to samo: incydent u dostawcy szybko staje się problemem jego klientów. Gdy dostawca ma incydent, klient najpierw odcina mu dostęp, a potem pyta, jakie zabezpieczenia miał.

Trzy scenariusze z projektów

Scenariusze są ilustracyjne; nie opisują konkretnych klientów.

A. Konsultant SAP w spółce energetycznej

B. Zespół developerski u dostawcy chmury

C. Zdalne wsparcie w szpitalu

Droga konsultanta przez wymagania klienta

Większość wymagań można ułożyć na jednej osi – od oferty do zakończenia projektu. U klienta stoją za nimi obowiązki dotyczące bezpieczeństwa personelu, szkoleń i kontroli dostępu. [14]

Zegar incydentu – dlaczego liczą się godziny

Gdy u klienta wydarzy się incydent poważny (czyli taki, który powoduje lub może spowodować poważne zakłócenie jego usług, straty finansowe albo poważną szkodę dla innych), klient ma 24 godziny od wykrycia na wczesne ostrzeżenie do właściwego zespołu reagowania (CSIRT), 72 godziny na zgłoszenie incydentu i miesiąc od tego zgłoszenia na sprawozdanie końcowe. [7]

Zgłasza klient, nie konsultant. Ale często to właśnie osoba z zewnątrz zauważa pierwsza, że coś jest nie tak. Polska ustawa liczy czas od „wykrycia” incydentu, dyrektywa – od „powzięcia wiedzy”. [15] Żaden z przepisów nie przesądza, czy zauważenie problemu przez zewnętrznego konsultanta uruchamia już zegar klienta. Bezpieczniej założyć, że tak.

Ćwiczenie dla zespołu (5 minut)

Sprawdźcie, czy każdy w zespole odpowie tak samo:

• Do kogo po stronie klienta dzwonię/piszę, jeśli zauważę podejrzaną aktywność?
• Do kogo dzwonię/piszę, jeśli zauważę coś podejrzanego wieczorem albo w weekend, gdy mój kontakt u klienta nie odbiera?
• Czy klient ma numer alarmowy albo dyżur bezpieczeństwa poza godzinami pracy i czy go znam?
• Kogo informuję we własnej firmie i czy nie opóźni to przekazania informacji klientowi?

Jeśli odpowiedzi się różnią, to jest to pierwsza rzecz do ustalenia z klientem.

Co to oznacza dla samego konsultanta?

Ustawa kieruje obowiązki do firm objętych przepisami i do ich kierownictwa. To kierownictwo klienta odpowiada za cyberbezpieczeństwo, także wtedy, gdy powierzy część zadań komuś innemu. Kary pieniężne przewidziane w ustawie będzie można nakładać dopiero po 2 latach od jej wejścia w życie, czyli od kwietnia 2028 r. Zewnętrzny konsultant nie jest adresatem tej odpowiedzialności. Jednak jeżeli „przyczyni się” do incydentu, sytuacja jest zgoła inna i wkraczamy na terytorium odpowiedzialności umownej.

Brak odpowiedzialności wobec ustawy nie oznacza, że nic się dla konsultanta nie zmienia.

Zmiany mają głównie charakter umowny i organizacyjny:

• Dłuższy onboarding. Klient musi zadbać o bezpieczeństwo personelu i szkolenia [14] – stąd dodatkowe oświadczenia i szkolenia przed nadaniem dostępu.
• Informacja z KRK – przy niektórych rolach. Jeśli konsultant ma współtworzyć system bezpieczeństwa klienta albo obsługiwać incydenty, przed rozpoczęciem pracy przedstawia informację z KRK o niekaralności za przestępstwa przeciwko ochronie informacji.
• Ścisłe zarządzanie dostępem. Konto aktywne po zakończeniu projektu to ryzyko, które audytor zauważy w pierwszej kolejności.
• Szybka eskalacja. Termin i ścieżkę zgłaszania warto mieć wpisane w umowie.

Do sprawdzenia przez dział prawny: Czy dostawca IT sam może podlegać ustawie?

Wśród sektorów objętych ustawą są też dostawcy usług zarządzanych (o tym, czy firma jest faktycznie objęta, decyduje m.in. jej wielkość), czyli firmy, które instalują, utrzymują lub administrują systemami klienta – na miejscu albo zdalnie. [16] Firma dostarczająca konsultantów, którzy administrują systemami klientów, powinna ocenić, czy część jej działalności nie mieści się w tej definicji. Wtedy obowiązki mogą dotyczyć jej bezpośrednio, a nie tylko przez umowy z klientami.

Klienci z sektora bankowego

Dla banków i infrastruktury rynków finansowych unijnym aktem sektorowym jest rozporządzenie DORA, a polska ustawa wyłącza wobec nich większość wymagań dotyczących SZBI i zgłaszania incydentów. Zasady dotyczące odpowiedzialności kierownictwa, szkoleń i informacji z KRK stosuje się jednak także do nich. [17] Dla konsultanta efekt jest podobny: pytania o weryfikację, dostęp i incydenty i tak padną.

Ściąga: Pytanie klienta – skąd się bierze?

Szybki test gotowości zespołu do poradzenia sobie z NIS2

1. Czy wiesz, jak wygląda proces weryfikacji i onboardingu konsultantów w Twoim obszarze?
2. Czy potrafisz w jednym zdaniu powiedzieć, co robisz, gdy zauważysz coś niepokojącego w systemie klienta (kto, w jakim czasie, jaką drogą)?
3. Czy wiesz, kiedy dostęp jest odbierany po zakończeniu projektu lub zmianie roli?
4. Czy standardowa umowa zawiera klauzule dotyczące incydentów, zmian w zespole i prawa do audytu, czy dopisujecie je za każdym razem?
5. Czy jest jedna osoba lub zespół, który odpowiada na ankiety bezpieczeństwa klientów?
6. Czy wiesz, czy Twoja rola u klienta może wymagać informacji z KRK?

Cybersecurity

Chronimy Twoje dane i środowisko IT dzięki nowoczesnym rozwiązaniom i usługom – audytom, testom penetracyjnym, ciągłemu monitorowaniu i reagowaniu na incydenty.

Oferta Cybersecurity

Podsumowanie

Dla klienta objętego nowymi przepisami nie ma znaczenia, czy dostęp do jego środowiska ma zewnętrzny system, czy zewnętrzny człowiek. W obu przypadkach musi umieć pokazać, że zna to ryzyko, ocenił je i nim zarządza.

Dla osób z IT oznacza to kilka nowych nawyków:

• imienne konta,
• udokumentowane szkolenia,
• znaną ścieżkę eskalacji
• i porządne zamykanie dostępów.

Wiem, wiem – kolejne szkolenia, dodatkowe elementy w procesie to piekło dla IT, ale to niewiele w porównaniu z kosztem utraconego kontraktu albo incydentu, którego nikt nie zgłosił na czas.

Przypisy

„Ustawa o KSC” = ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, tekst ujednolicony (ISAP, stan na 18.08.2026). „Nowelizacja” = ustawa z 23 stycznia 2026 r., Dz.U. 2026 poz. 252. „Dyrektywa NIS2” = dyrektywa (UE) 2022/2555, Dz. Urz. UE L 333 z 27.12.2022.

[1] Nowelizacja, art. 49: „Ustawa wchodzi w życie po upływie miesiąca od dnia ogłoszenia.” Ogłoszona w Dzienniku Ustaw 2 marca 2026 r. [źródło]

[2] Dyrektywa NIS2, art. 21 ust. 2 lit. d: środki obejmują „bezpieczeństwo łańcucha dostaw, w tym aspekty związane z bezpieczeństwem dotyczące stosunków między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami”. [źródło]

[3] Ustawa o KSC, art. 8 ust. 1 pkt 2 lit. e: „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 kluczowym lub podmiotem ważnym”. [źródło]

[4] Ustawa o KSC, art. 8c ust. 1: „Kierownik podmiotu kluczowego lub podmiotu ważnego ponosi odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa (…)”; ust. 3: „(…) także wtedy, gdy niektóre z obowiązków albo wszystkie obowiązki zostały powierzone innej osobie za jej zgodą.” Dyrektywa NIS2, art. 20 ust. 1: organy zarządzające „mogły być pociągnięte do odpowiedzialności”. [źródło]

[5] Nowelizacja, art. 35: „Kary pieniężne, o których mowa w art. 73 ust. 1–4 oraz art. 73a–73c i art. 76b (…) mogą być po raz pierwszy nałożone po upływie 2 lat od dnia wejścia w życie ustawy.” Kara dla kierownika podmiotu: ustawa o KSC, art. 73a. [źródło]

[6] Ustawa o KSC, art. 8f ust. 1: „Przed rozpoczęciem realizacji zadań, o których mowa w art. 8 lub art. 11, osoba, która ma te zadania realizować, przedstawia podmiotowi kluczowemu lub podmiotowi ważnemu informację o osobie z Krajowego Rejestru Karnego stwierdzającą niekaralność za przestępstwa przeciwko ochronie informacji.” Art. 8 dotyczy systemu zarządzania bezpieczeństwem informacji, art. 11 – obsługi incydentów. [źródło]

[7] Ustawa o KSC, art. 11 ust. 1: podmiot „4) zgłasza wczesne ostrzeżenie o incydencie poważnym niezwłocznie, niepóźniej niż w ciągu 24 godzin od momentu jego wykrycia, do właściwego CSIRT sektorowego; 4a) zgłasza incydent poważny niezwłocznie, niepóźniej niż w ciągu 72 godzin od momentu jego wykrycia (…); 4c) przekazuje właściwemu CSIRT sektorowemu sprawozdanie końcowe (…) niepóźniej niż w ciągu miesiąca od dnia zgłoszenia, o którym mowa w pkt 4a”. Definicja incydentu poważnego: art. 2 pkt 7. [źródło]

[8] Nowelizacja, art. 33 ust. 3: wniosek o wpis do wykazu składa się „zgodnie z harmonogramem określonym w art. 34 ust. 3 pkt 1”. Komunikat Ministra Cyfryzacji z 8.04.2026 (Dz. Urz. MC poz. 7): „w terminie od dnia 7 maja 2026 r. do dnia 3 października 2026 r.” [źródło]

[9] Nowelizacja, art. 33 ust. 1: podmioty spełniające przesłanki w dniu wejścia w życie ustawy „realizują obowiązki określone w rozdziale 3 (…) w terminie 12 miesięcy od dnia wejścia w życie niniejszej ustawy”. Rozdział 3 ustawy o KSC obejmuje m.in. art. 8 (SZBI), art. 8c-8f (kierownik, szkolenia, KRK) i art. 11 (incydenty). Art. 33 ust. 4: dotychczasowi operatorzy usług kluczowych „zgłaszają incydenty poważne zgodnie z art. 11–12b (…) w terminie 6 miesięcy od dnia wejścia w życie niniejszej ustawy”. [źródło]

[10] Nowelizacja, art. 33 ust. 2: podmioty kluczowe „przeprowadzają pierwszy audyt (…) w terminie 24 miesięcy od dnia wejścia w życie niniejszej ustawy”. [źródło]

[11] Dyrektywa NIS2, motyw 85: „(…) takimi jak dostawcy usług przechowywania i przetwarzania danych lub dostawcy usług zarządzanych w zakresie bezpieczeństwa oraz edytorzy oprogramowania (…) Podmioty kluczowe i ważne należy w szczególności zachęcać, aby włączały środki zarządzania ryzykiem w cyberbezpieczeństwie do ustaleń umownych z bezpośrednimi dostawcami i usługodawcami. Podmioty te mogłyby rozważyć ryzyko pochodzące od dostawców i usługodawców z innych poziomów.” [źródło]

[12] Ustawa o KSC, art. 8 ust. 2: podmiot uwzględnia „1) podatności związane z dostawcą sprzętu lub oprogramowania; 2) ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy sprzętu lub oprogramowania; 3) wyniki skoordynowanej oceny bezpieczeństwa przeprowadzonej przez Grupę Współpracy (…); 4) wyniki postępowania, o którym mowa w art. 67b” (postępowanie w sprawie uznania za dostawcę wysokiego ryzyka). Dyrektywa NIS2, art. 21 ust. 3: „(…) ogólną jakość produktów i praktyk cyberbezpieczeństwa dostawców i usługodawców, w tym ich procedury bezpiecznego opracowywania”. [źródło]

[13] Komunikat Atende z 22.10.2024 r.  [źródło] ; Komunikat Pełnomocnika Rządu do spraw Cyberbezpieczeństwa ws. wycieku danych w wyniku cyberataku wobec firmy EUROCERT Sp. z o.o. [źródło]

[14] Ustawa o KSC, art. 8 ust. 1 pkt 2: „d) bezpieczeństwo zasobów ludzkich, (…) i) edukację z zakresu cyberbezpieczeństwa dla personelu podmiotu, (…) m) zarządzanie aktywami, n) polityki kontroli dostępu”. [źródło]

[15] Dyrektywa NIS2, art. 23 ust. 4 lit. a: „bez zbędnej zwłoki, a w każdym razie w ciągu 24 godzin od powzięcia wiedzy o poważnym incydencie – wczesne ostrzeżenie (…)”. [źródło]

[16] Ustawa o KSC, art. 2 pkt 4i: „dostawca usług zarządzanych – osobę fizyczną, osobę prawną albo jednostkę organizacyjną nieposiadającą osobowości prawnej, która świadczy usługi związane z instalacją, eksploatacją lub konserwacją produktów ICT, usług ICT, procesów ICT lub systemów informacyjnych przez wsparcie lub aktywną administrację przeprowadzane u usługobiorcy na miejscu lub zdalnie”. Załącznik nr 1 („Sektory kluczowe”): sektor „Zarządzanie usługami ICT” – „Dostawca usług zarządzanych”. [źródło]

[17] Ustawa o KSC, art. 8i ust. 1: do podmiotów „z sektora bankowości i infrastruktury rynków finansowych nie stosuje się przepisów ustawy dotyczących systemu zarządzania bezpieczeństwem informacji lub zgłaszania poważnych incydentów, z wyjątkiem (…)”; ust. 2: „(…) stosuje się odpowiednio przepisy art. 8c–8f, art. 12 ust. 7 oraz art. 31 ust. 1.” Związek z DORA: dyrektywa NIS2, motyw 28: „Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (…) należy uznać za sektorowy akt prawny Unii (…)” oraz art. 4 ust. 1 (pierwszeństwo sektorowych aktów prawnych Unii). [źródło]