NIS2 a bezpieczeństwo łańcucha dostaw, czyli jesteś tak bezpieczny, jak Twój najsłabszy dostawca

Włamywacze rzadko forsują drzwi frontowe, jeśli ktoś zostawił dla nich otwarte okno na zapleczu. W cyberbezpieczeństwie tym oknem coraz częściej okazuje się dostawca – firma obsługująca systemy IT, dostarczająca oprogramowanie albo po prostu mająca dostęp do firmowej sieci. Najgroźniejsze są sytuacje, kiedy ofiarą ataku pada dostawca obsługujący całą branżę. Czy pamiętacie, jak we wrześniu 2025 sparaliżowane zostały lotniska w całej Europie? Przyczyną był prawdopodobnie atak hakerski na dostawcę systemu obsługi biletów MUSE. Podobnie zaczął się atak na SolarWinds z 2020 roku. W tym przypadku skutki były nawet groźniejsze niż awaria MUSE, bo złośliwy kod ukryty w aktualizacji oprogramowania Orion trafił do około 18 tysięcy organizacji, w tym do amerykańskich agencji federalnych. A taki kod może być wykorzystany do kolejnych działań na szkodę firmy, nieraz przez lata, nierzadko pozostając niewykrywalnym.

To widowiskowe przykłady, ale warto też zrozumieć mechanizmy, które sprzyjają tego typu zagrożeniom. Większość cyberataków ma obecnie charakter testowy – hakerzy nie mają konkretnego celu, ale raczej testują zabezpieczenia różnych systemów, szukając słabych punktów. Sprzyja temu rozpowszechnienie (często słabo zabezpieczonych) urządzeń peryferyjnych podłączonych do sieci, które stanowią potencjalny punkt wejścia do systemu. Nie bez znaczenia jest też rozwój sztucznej inteligencji. Anthropic musiał niedawno wstrzymać upublicznienie najnowszego modelu, który okazał się zbyt dobry w znajdowaniu luk bezpieczeństwa. Jednak nawet prostsze modele pozwalają na automatyzację i masowe przeprowadzanie prób ataków. W efekcie każda, nawet najmniejsza, organizacja może stać się ofiarą hakerów (bo koszt próby ataku jest znikomy), a pośrednio punktem wejścia do systemów większych współpracujących z nią instytucji.

Dyrektywa NIS2 wyciąga z tego oczywisty, choć dla wielu organizacji niewygodny wniosek: bezpieczeństwo łańcucha dostaw jest integralną częścią bezpieczeństwa firmy, a zarządzanie ryzykiem stron trzecich przestaje być dobrą praktyką i staje się obowiązkiem prawnym. Statystyki nie pozostawiają złudzeń: według badań z 2025 roku aż 97% organizacji doświadczyło naruszenia bezpieczeństwa za pośrednictwem swojego łańcucha dostaw, mimo że 95% z nich zwiększyło w tym czasie wydatki na zarządzanie ryzykiem. Źródłem problemu okazuje się więc sposób działania organizacji, raczej niż niewystarczające nakłady finansowe i to właśnie ten sposób działania ma zmienić NIS2.

Czym jest NIS2 w kontekście bezpieczeństwa łańcucha dostaw?

Dyrektywa NIS2 (Dyrektywa (UE) 2022/2555) to unijne ramy prawne dot. cyberbezpieczeństwa dla podmiotów kluczowych i ważnych: od energetyki i transportu, przez ochronę zdrowia, po usługi cyfrowe i produkcję. Sercem dyrektywy jest art. 21, który nakłada na te podmioty obowiązek wdrożenia „odpowiednich i proporcjonalnych” środków zarządzania ryzykiem. Wśród dziesięciu minimalnych środków wymienionych w art. 21 znajduje się bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa dotyczące stosunków między podmiotem a jego bezpośrednimi dostawcami lub usługodawcami. Dyrektywa (art. 21 ust. 3) idzie nawet o krok dalej: organizacje muszą uwzględniać podatności specyficzne dla każdego bezpośredniego dostawcy oraz ogólną jakość produktów i praktyk cyberbezpieczeństwa swoich dostawców, łącznie z ich procedurami bezpiecznego rozwoju oprogramowania. Innymi słowy, nie wystarczy mieć polityki na papierze; trzeba faktycznie wiedzieć, jak pracują dostawcy.

Dyrektywa przewiduje też mechanizm na poziomie unijnym: zgodnie z art. 22, Komisja Europejska i ENISA mogą przeprowadzać skoordynowane oceny ryzyka krytycznych łańcuchów dostaw ICT, uwzględniające także czynniki pozatechniczne, w tym kwestie geopolityczne. Wyniki takich ocen organizacje mają obowiązek brać pod uwagę. W praktyce oznacza to, że firma może być wzorowo zorganizowana wewnętrznie, a i tak narazić się na zarzut niezgodności, jeśli zignoruje ostrzeżenia dotyczące konkretnego dostawcy wysokiego ryzyka.

W Polsce NIS2 wdrożono nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa (UKSC), obowiązującą od kwietnia 2026 roku. Polska implementacja zasługuje na uwagę z dwóch powodów. Po pierwsze, kary: do 100 mln zł, z możliwością naliczania kar dziennych. Po drugie, przepisy o dostawcach wysokiego ryzyka, które idą dalej niż sama dyrektywa. Decyzja o uznaniu dostawcy za podmiot wysokiego ryzyka oznacza obowiązek wycofania jego produktów i usług ICT z użytku we wszystkich sektorach objętych ustawą.

Zarządzanie ryzykiem dostawców w praktyce

Punktem wyjścia w przełożeniu tych wymagań na codzienną działalność organizacji jest systematyczne zarządzanie dostawcami oparte na poziomie ryzyka, a nie tylko na wartości kontraktu. Mały podwykonawca z dostępem administracyjnym do serwerów firmy stwarza większe ryzyko niż duży dostawca materiałów biurowych, nawet jeśli faktury tego drugiego są znacznie wyższe. Aczkolwiek automatyzacja zamówień często oznacza, że i ten drugi może mieć jakiś dostęp do systemów.

W praktyce program zarządzania ryzykiem dostawców obejmuje kilka stałych elementów:

• Inwentaryzację dostawców. Kompletny rejestr podmiotów trzecich wraz z informacją o tym, do jakich systemów i danych mają dostęp. Większość organizacji przeprowadzających takie mapowanie po raz pierwszy odkrywa, że ich lista jest znacznie dłuższa, niż przypuszczano. Współcześnie optymalizacja współpracy często osiągana jest poprzez integrację systemów, w efekcie czego nieraz większość klientów i kontrahentów ma jakiś dostęp do jakichś części systemu klienta.
• Klasyfikację według poziomu ryzyka – dostawców dzieli się na kategorie w zależności od krytyczności usług, zakresu dostępu do danych i potencjalnego wpływu na ciągłość działania. Od kategorii zależy głębokość oceny i częstotliwość monitoringu.
• Politykę bezpieczeństwa łańcucha dostaw – formalny dokument określający minimalne wymagania bezpieczeństwa dla dostawców każdej kategorii, komunikowany dostawcom i zintegrowany z procesem zakupowym.
• Cykl życia dostawcy – od oceny przed podpisaniem umowy, przez bezpieczny onboarding i bieżący monitoring, po kontrolowane zakończenie współpracy (odebranie dostępów, zwrot lub zniszczenie danych). Trzeba tu podkreślić zwłaszcza dwa późniejsze etapy, które są częściej zaniedbywane. To, że kontrahent przeszedł pomyślnie weryfikację na początku współpracy nie gwarantuje, że będzie chociażby instalował regularnie aktualizacje oprogramowania i nie stanie się zagrożeniem później.

Due diligence i ocena bezpieczeństwa dostawców

Due diligence dostawców to weryfikacja, której dokonujemy, zanim dostawca uzyska dostęp do naszych systemów – a więc zanim będzie za późno. Szukamy przede wszystkim twardych dowodów, nie samych deklaracji. Certyfikaty takie jak ISO 27001 czy raporty SOC 2 mówią więcej niż najpiękniej wypełniona ankieta. Warto zweryfikować historię incydentów dostawcy, dojrzałość procesów zarządzania podatnościami i aktualizacjami, a w przypadku dostawców oprogramowania, praktyki bezpiecznego rozwoju oprogramowania, o których wprost wspomina art. 21 ust. 3 dyrektywy.

Coraz większe znaczenie ma także SBOM (Software Bill of Materials), czyli „skład” oprogramowania: lista komponentów i bibliotek, z których zbudowany jest produkt. Dobrze pokazała to luka Log4Shell, wykryta w grudniu 2021 roku w bibliotece Log4j, komponencie obecnym w niezliczonych aplikacjach na całym świecie. Organizacja dysponująca SBOM-ami była w stanie w ciągu godzin ustalić, które z jej systemów są zagrożone. Organizacja, która ich nie prowadzi, często dowiaduje się o zagrożeniu dopiero z doniesień medialnych.

Jedna uwaga praktyczna: due diligence powinno być proporcjonalne. Wysyłanie 300-pytaniowej ankiety każdemu dostawcy to prosta droga do tego, by nikt nie czytał odpowiedzi. Dla dostawców niskiego ryzyka wystarczy uznanie certyfikatów; szczegółową ocenę warto zarezerwować dla tych, od których naprawdę zależy nasze bezpieczeństwo.

Monitoring dostawców i ciągła ocena ryzyka

Tu dochodzimy do najważniejszej zmiany koncepcyjnej, jaką wymusza NIS2. Tradycyjny model – ankieta przy onboardingu, powtórka raz w roku, wyniki do segregatora – przestaje wystarczać. Dostawca, który był bezpieczny w styczniu, w czerwcu może już nie być: wystarczy incydent, zmiana właściciela, utrata kluczowego personelu, nowa podatność w wykorzystywanej technologii, albo zwyczajne zaniedbanie aktualizacji bezpieczeństwa.

NIS2 oczekuje monitoringu ciągłego. W praktyce oznacza to korzystanie z narzędzi automatycznej oceny ryzyka, źródeł tzw. threat intelligence i alertów o zdarzeniach dotyczących naszych dostawców. Oznacza to także zdefiniowanie zdarzeń uruchamiających nadzwyczajny przegląd dostawcy: poważny incydent, zmiana struktury własnościowej, sankcje regulacyjne, istotne rozszerzenie zakresu dostępu do naszych systemów. Rzeczywista odporność organizacji wymaga, by wiedza o ryzyku dostawcy była aktualna wtedy, gdy jest potrzebna, a nie dopiero przy okazji kolejnej dorocznej weryfikacji. Takie podejście motywuje też kontrahentów do ciągłego monitorowania cyberbezpieczeństwa.

Umowy, SLA i wymagania bezpieczeństwa

Umowa to jedyne narzędzie, którym realnie dysponujemy wobec dostawcy – dlatego NIS2 i akty wykonawcze kładą tak duży nacisk na zapisy kontraktowe. W umowie z dostawcą krytycznym powinny znaleźć się następujące elementy:

• Minimalne standardy bezpieczeństwa – najlepiej przez odwołanie do uznanego standardu (ISO 27001, CIS Controls), z obowiązkiem utrzymania zgodności przez cały okres umowy.
• Obowiązek zgłaszania incydentów – z konkretnym terminem. Skoro my mamy 24 godziny na wczesne ostrzeżenie do CSIRT (Computer Security Incident Response Team), dostawca musi powiadomić nas znacznie szybciej. Zapis „bez zbędnej zwłoki” to za mało; lepiej wpisać liczbę godzin.
• Prawo do audytu – możliwość weryfikacji praktyk bezpieczeństwa dostawcy, samodzielnie lub przez niezależny podmiot. Bez tego zapisu „ciągły nadzór” pozostaje pobożnym życzeniem.
• Wymogi wobec podwykonawców – obowiązek nałożenia równoważnych wymagań bezpieczeństwa na podwykonawców mających dostęp do naszych danych lub systemów. W ten sposób powstaje „piramida” wzajemnie monitorujących się kontrahentów, z bezpieczeństwem zapewnionym na całym łańcuchu dostaw.
• Prawo wyjścia – możliwość rozwiązania umowy bez kar, jeśli dostawca nie spełnia wymagań bezpieczeństwa lub zostaje uznany za podmiot wysokiego ryzyka.
• SLA dla bezpieczeństwa – czasy reakcji na incydenty i wdrażania krytycznych poprawek, mierzalne i egzekwowalne jak każdy inny parametr usługi.

Incident reporting w łańcuchu dostaw

NIS2 wprowadza trzystopniowy model raportowania poważnych incydentów: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o incydencie, pełne zgłoszenie w ciągu 72 godzin i raport końcowy w ciągu miesiąca. W kontekście łańcucha dostaw kluczowe jest owo „uzyskanie wiedzy”. Jeśli incydent ma źródło u dostawcy, nasz zegar zaczyna tykać w momencie, gdy się o nim dowiadujemy; dlatego tak istotne jest, by umowa gwarantowała szybkie powiadomienie, a wewnętrzne zarządzanie incydentami obejmowało scenariusz „incydent u strony trzeciej”: Kto przyjmuje zgłoszenie od dostawcy? Kto ocenia wpływ na naszą organizację? Kto decyduje o zgłoszeniu do CSIRT?

Warto też pamiętać o ryzyku koncentracji. Jeśli pół branży korzysta z tego samego dostawcy chmury lub operatora usług IT, incydent u niego staje się incydentem systemowym. Pokazał to wspomniany we wstępie incydent z systemem obsługi biletów MUSE czy atak na narzędzie MOVEit Transfer w 2023 roku, gdy wykorzystanie jednej luki w popularnym oprogramowaniu do przesyłania plików dotknęło naraz tysiące organizacji na całym świecie. Identyfikacja pojedynczych punktów awarii w łańcuchu dostaw i przygotowanie planów awaryjnych to element zarządzania ryzykiem, o który coraz częściej pytają instytucje nadzoru cyberbezpieczeństwa.

Zarządzanie podwykonawcami i zależnościami ICT

Łańcuch dostaw rzadko kończy się na pierwszym ogniwie. Nasz dostawca SaaS korzysta z dostawcy chmury, ten z kolei z zewnętrznego wsparcia technicznego… i nagle nasze dane zależą od firmy, o której istnieniu nie mieliśmy pojęcia. To tak zwane ryzyko czwartej strony, a nawet ryzyko „n-tej strony”. Podwykonawcami nie zarządzamy bezpośrednio. Nie łączy nas z nimi umowa i nie mamy wobec nich prawa audytu. Możemy jednak (i powinniśmy) wymagać od naszych bezpośrednich dostawców, by sami prowadzili dojrzałe zarządzanie ryzykiem stron trzecich i ujawniali nam kluczowe zależności. Mapowanie krytycznych zależności ICT, przynajmniej dla najważniejszych usług, nie jest fanaberią, ale staje się warunkiem rzetelnej oceny ryzyka.

W tym kontekście warto wspomnieć o Cyber Resilience Act, który uzupełnia NIS2 od strony produktowej: nakłada wymagania cyberbezpieczeństwa bezpośrednio na producentów produktów cyfrowych. Docelowo oznacza to, że część wysiłków związanych z due diligence wykona za nas regulator, gdyż produkty z oznakowaniem CE w zakresie cyberbezpieczeństwa będą musiały spełniać określone standardy już na etapie projektowania. Jest to szczególnie ważne w kontekście coraz częściej wykorzystywanych usług chmurowych, jak również urządzeń IoT (Internet of Things), które są notorycznie słabo zabezpieczone.

Governance i odpowiedzialność zarządu

NIS2 jednoznacznie przesądza, że cyberbezpieczeństwo – w tym bezpieczeństwo łańcucha dostaw – to odpowiedzialność organów zarządzających, a nie tylko działu IT. Zarząd zatwierdza środki zarządzania ryzykiem, nadzoruje ich wdrażanie i ma obowiązek odbywać szkolenia pozwalające ocenić ryzyko. Polska ustawa stawia sprawę jeszcze ostrzej: członkowie zarządu ponoszą osobistą odpowiedzialność za realizację obowiązków, nawet jeśli zadania delegowano niżej, a kara dla menedżera może sięgnąć 300% miesięcznego wynagrodzenia. Dyrektywa dopuszcza ponadto czasowy zakaz pełnienia funkcji kierowniczych jako konsekwencję.

Z perspektywy ładu korporacyjnego oznacza to konieczność udokumentowanego nadzoru: wyznaczenia osoby odpowiedzialnej za obszar bezpieczeństwa łańcucha dostaw na poziomie kierownictwa, regularnego raportowania ryzyka dostawców do zarządu, formalnego zatwierdzania polityki i decyzji dotyczących dostawców wysokiego ryzyka oraz – co często umyka – udokumentowania, że to wszystko rzeczywiście jest wykonywane.

NIS2 a TPRM i enterprise risk management

Częstym błędem jest traktowanie zgodności z NIS2 jako odrębnego projektu, równoległego do „normalnego” zarządzania ryzykiem. Tymczasem bezpieczeństwo łańcucha dostaw powinno być częścią tzw. enterprise risk management. Dobra wiadomość dla organizacji z wdrożonym ISO 27001 jest taka, że znaczna część wymagań art. 21 jest już spełniona. Typowe luki dotyczą właśnie bezpieczeństwa łańcucha dostaw, odpowiedzialności zarządu i terminów raportowania incydentów. Warto więc zacząć od analizy luk, a nie budować system od zera. Podobnie ISO 22301 (zarządzanie ciągłością działania) dostarcza gotowych ram dla scenariusza „kluczowy dostawca przestaje działać”.

Technologie wspierające bezpieczeństwo łańcucha dostaw

Przy kilku dostawcach wystarczą arkusz kalkulacyjny i determinacja. Przy kilkudziesięciu lub kilkuset – już nie. Stąd rosnąca rola trzech kategorii narzędzi:

• Platformy GRC integrują rejestr dostawców z ocenami ryzyka, wymaganiami umownymi i dowodami zgodności, generując raporty na potrzeby zarządu i regulatora. Jedno źródło prawdy zamiast dwunastu arkuszy w ośmiu wersjach.
• Narzędzia TPRM automatyzują cykl oceny dostawców: ankiety, scoring, monitoring ciągły, alerty o zmianach profilu ryzyka. Coraz częściej wspierane przez AI, która potrafi np. przeanalizować umowę pod kątem brakujących klauzul bezpieczeństwa.
• Systemy SIEM monitorują zdarzenia w infrastrukturze i pozwalają wykryć anomalie mogące świadczyć o lukach bezpieczeństwa w łańcuchu dostaw – czasem zanim dostawca sam zorientuje się, że ma problem.

Najlepsze praktyki i najczęstsze błędy

Z doświadczeń organizacji, które przeszły już tę drogę, wyłania się kilka prawidłowości. Po stronie dobrych praktyk: zaczynanie od dostawców bezpośrednich i krytycznych zamiast prób objęcia wszystkiego naraz; włączenie oceny bezpieczeństwa w proces zakupowy; akceptowanie uznanych certyfikatów zamiast mnożenia ankiet; oraz mierzenie skuteczności programu (czas wykrycia, czas reakcji), a nie samej aktywności (liczba wysłanych ankiet). Po stronie błędów niezmiennie króluje rozdźwięk między zakupami a bezpieczeństwem – dział zakupów podpisuje umowy, o których dział bezpieczeństwa dowiaduje się po fakcie. Drugie miejsce zajmują działania pozorne – programy budowane z myślą o audycie raczej niż o rzeczywistym ograniczeniu ryzyka.

Jak przygotować organizację do wymagań NIS2 – lista kontrolna

1. Ustal, czy organizacja podlega UKSC jako podmiot kluczowy lub ważny, i dopilnuj rejestracji w terminie.
2. Zidentyfikuj dostawców i sklasyfikuj ich według ryzyka (dostęp do danych, krytyczność usług, wpływ na ciągłość działania).
3. Przyjmij formalną politykę bezpieczeństwa łańcucha dostaw i zintegruj ją z procesem zakupowym.
4. Przejrzyj umowy z dostawcami krytycznymi i uzupełnij klauzule: powiadamiania o incydentach z konkretnym terminem, prawa do audytu, wymogów wobec podwykonawców, prawa wyjścia.
5. Wdróż monitoring ciągły dla dostawców najwyższego ryzyka i zdefiniuj zdarzenia uruchamiające przegląd nadzwyczajny.
6. Opisz proces obsługi incydentu u strony trzeciej i przećwicz go – łącznie z dotrzymaniem terminu 24 godzin.
7. Zidentyfikuj ryzyko koncentracji i pojedyncze punkty ryzyka; przygotuj plany awaryjne dla niezastępowalnych dostawców.
8. Udokumentuj nadzór zarządu: zatwierdzenie polityki, cykliczne raportowanie, szkolenia członków zarządu.
9. Rozważ wdrożenie platformy GRC lub TPRM, jeśli liczba dostawców krytycznych przekracza możliwości ręcznego zarządzania.

Podsumowanie

NIS2 przesuwa bezpieczeństwo łańcucha dostaw z kategorii „dobrze mieć” do kategorii „obowiązek prawny z sankcjami”. Najkrócej: musisz wiedzieć, kim są twoi dostawcy i co mogą zepsuć; musisz ich sprawdzić, zanim dasz im dostęp, i sprawdzać dalej, gdy już go mają; twoje umowy muszą dawać ci realne narzędzia – powiadomienia, audyt, wyjście; a Twój zarząd musi to wszystko świadomie nadzorować, bo odpowiada osobiście. Organizacje, które potraktują te wymagania poważnie, nie tylko spełnią wymóg prawny, ale zyskają też zdolność do wykazania dojrzałego zarządzania ryzykiem dostawców, co staje się atutem w przetargach, bo klienci objęci NIS2 szukają partnerów, którzy nie skomplikują im życia.

FAQ – najczęściej zadawane pytania