Bezpieczeństwo Łańcucha Dostaw I Ryzyko Stron Trzecich – Zapomniany Filar NIS2

Znaczenie bezpieczeństwa łańcucha dostaw w NIS2

Dyrektywa NIS2 znacząco podnosi poprzeczkę w zakresie cyberbezpieczeństwa w Unii Europejskiej, rozszerzając wymagania na nowe sektory i obszary. Jednym z kluczowych – choć często niedocenianych – elementów jest bezpieczeństwo łańcucha dostaw oraz zarządzanie ryzykiem stron trzecich (third-party risk). Praktyka pokazuje, iż choćby najlepiej zabezpieczona organizacja może zostać skutecznie zaatakowana poprzez luki u swojego dostawcy lub partnera.

W NIS2 bezpieczeństwo łańcucha dostaw zostało potraktowane jako priorytet ze względu na potencjalny efekt domina: naruszenie u jednego dostawcy może odbić się na dziesiątkach firm korzystających z jego usług.

Głośne ataki z ostatnich lat potwierdzają wagę problemu. Przykładowo, incydent SolarWinds z 2020 roku, w którym doszło do kompromitacji procesu aktualizacji systemu dostarczanego do tysięcy organizacji, dobitnie pokazał, jak atak na dostawcę może zagrozić odbiorcom. Podobnie kampania NotPetya (2017) – rozpowszechniona przez zainfekowane aktualizacje popularnego systemu księgowego – sparaliżowała firmy na całym świecie. Te zdarzenia ujawniły, iż słabości w łańcuchu dostaw potrafią być równie groźne, co bezpośrednie ataki. W efekcie dyrektywa NIS2 kładzie silny nacisk na to, by organizacje proaktywnie zarządzały ryzykiem stron trzecich NIS2 i nie traktowały bezpieczeństwa dostawców jako „cudzej” sprawy. Dla menedżerów IT i bezpieczeństwa odpowiedzialnych za compliance NIS2 oznacza to konieczność uwzględnienia dostawców w strategii cyberochrony na równi z własną infrastrukturą.

Ten artykuł jest częścią serii NIS2 – Jak być zgodnym, w której krok po kroku omawiamy wymagania dyrektywy NIS2, zarządzanie ryzykiem, raportowanie incydentów i wdrożenie zgodności w organizacjach.

Wymogi dyrektywy NIS2 dotyczące stron trzecich i dostawców

NIS2 wprost zobowiązuje organizacje do zajęcia się bezpieczeństwem swoich partnerów i dostawców. Zgodnie z art. 21 ust. 2 lit. d dyrektywy, podmioty objęte regulacją muszą wdrożyć odpowiednie środki techniczne, organizacyjne i operacyjne zapewniające bezpieczeństwo łańcucha dostaw. Innymi słowy – zarządzanie ryzykiem dostawców nie jest opcjonalne, ale obowiązkowe. W praktyce dyrektywa wymaga m.in.:

• Uwzględnienia dostawców w analizach ryzyka – Ocena ryzyka powinna obejmować nie tylko systemy wewnętrzne firmy, ale także kluczowych dostawców i usługodawców. NIS2 podkreśla, iż należy brać pod uwagę podatności każdego istotnego dostawcy oraz jakość jego praktyk bezpieczeństwa (np. czy stosuje on bezpieczne procedury rozwoju oprogramowania).
• Włączenia wymagań bezpieczeństwa do umów – Organizacja musi egzekwować od dostawców odpowiedni poziom ochrony poprzez zapisy kontraktowe. Dyrektywa zaleca konkretne klauzule bezpieczeństwa w umowach: obowiązek przestrzegania standardów (np. ISO 27001), prawo do audytu, wymóg szybkiego zgłaszania incydentów oraz jasno zdefiniowane SLA dotyczące ciągłości działania i reakcji na zdarzenia.
• Szerszego nadzoru i dokumentowania działań – NIS2 nakłada na kierownictwo wyższych szczebli odpowiedzialność za nadzór nad cyberbezpieczeństwem, w tym obszarem third-party risk. Organy regulacyjne mogą zażądać dowodów, iż firma adekwatnie zarządza ryzykiem stron trzecich – np. rejestru dostawców wraz z wynikami ich ocen, wypełnionych ankiet bezpieczeństwa, planów działań naprawczych wobec dostawców niespełniających wymogów. Dlatego organizacje muszą mieć przygotowaną dokumentację świadczącą o ciągłej kontroli bezpieczeństwa w łańcuchu dostaw.

Warto zauważyć, iż w realizacji tych obowiązków pomocne jest korzystanie z uznanych standardów i wytycznych. Zaleca się odnieść do norm takich jak ISO/IEC 27036 (bezpieczeństwo relacji z dostawcami) czy wytycznych ENISA dotyczących cyberbezpieczeństwa łańcucha dostaw, aby ujednolicić kryteria oceny dostawców i wymagania umowne. Spełnienie wymagań NIS2 w tym zakresie oznacza nie tylko zabezpieczenie własnej organizacji, ale także aktywne przyczynianie się do odporności całego ekosystemu dostawców na cyberzagrożenia.

Praktyki oceny ryzyka dostawców i zarządzania relacjami z nimi

Jak zatem skutecznie zarządzać bezpieczeństwem dostawców i partnerów zgodnie z NIS2? Poniżej przedstawiamy najważniejsze praktyki oceny ryzyka dostawców i zarządzania relacjami third-party, które pozwalają ograniczyć ryzyko i wypełnić regulacyjne obowiązki (bazując na wytycznych z rozdziału 6.3 e-booka „NIS2 – How to Be Compliant”):

• Identyfikacja i kategoryzacja dostawców – Podstawą jest pełna ewidencja wszystkich dostawców oraz klasyfikacja ich według ryzyka. Należy określić, którzy dostawcy są krytyczni dla działania biznesu lub przetwarzają wrażliwe dane, i przypisać im odpowiednie poziomy ryzyka (np. niski/średni/wysoki/krytyczny). Dostawcy mający dostęp do kluczowych systemów czy danych powinni podlegać bardziej rygorystycznym wymaganiom niż ci od usług pobocznych. Taka segmentacja (vendor tiering) pozwala skupić wysiłki tam, gdzie potencjalne skutki incydentu są największe.
• Due diligence bezpieczeństwa dostawcy – Przed nawiązaniem lub przedłużeniem współpracy z dostawcą należy przeprowadzić ocenę jego zabezpieczeń (security assessment). Praktyka ta obejmuje wypełnienie przez dostawcę szczegółowych kwestionariuszy bezpieczeństwa, przegląd posiadanych certyfikatów (np. ISO 27001, SOC 2) oraz analizę jego procedur. Warto korzystać ze standaryzowanych ankiet lub frameworków branżowych – przykładowo pytań opartych o normy ISO/IEC 27002 czy rekomendacje CIS – aby ujednolicić oceny. Dodatkowo, można żądać wyników ostatnich audytów bezpieczeństwa dostawcy lub samodzielnie przeprowadzić testy (np. skany podatności usług udostępnianych przez dostawcę). Celem jest zdobycie obiektywnych informacji, czy dostawca spełnia wymagane standardy bezpieczeństwa, zanim zostanie dopuszczony do naszych systemów lub danych.
• Wymagania bezpieczeństwa w umowach (SLA) – Każda umowa z zewnętrznym dostawcą IT powinna zawierać jasne zapisy dotyczące bezpieczeństwa. Do dobrych praktyk należy dodanie klauzul zgodności z NIS2 (wymóg utrzymywania adekwatnych zabezpieczeń i przestrzegania prawa), zapisów dotyczących ochrony danych i poufności, a także uzgodnionych zasad reagowania na incydenty. Ważnym elementem jest określenie Service Level Agreements w kontekście bezpieczeństwa – np. maksymalnego czasu w zastosowanie poprawek bezpieczeństwa (patchowanie), czasu w zgłoszenie incydentu od jego wykrycia, gwarantowanego poziomu dostępności usług itp.. Ponadto umowa powinna przyznawać zamawiającemu prawo do przeprowadzania okresowych audytów bezpieczeństwa u dostawcy lub żądania wyników niezależnych audytów, tak aby weryfikować ciągłość spełniania wymogów. Precyzyjne zdefiniowanie tych kwestii w kontraktach sprawia, iż oczekiwania wobec dostawcy są jasne, a egzekwowanie bezpieczeństwa staje się możliwe również od strony formalno-prawnej.
• Ciągły monitoring i audyty dostawców – Ocena bezpieczeństwa dostawcy nie może być jednorazowa. NIS2 wymaga stałego nadzoru nad podmiotami trzecimi, co oznacza wprowadzenie mechanizmów ciągłego monitorowania ich stanu zabezpieczeń. W praktyce firmy wdrażają narzędzia klasy Vendor Risk Management (VRM) lub Security Ratings, które automatycznie śledzą wybrane wskaźniki bezpieczeństwa dostawców (np. wykryte podatności w ich systemach, wycieki danych, niezałatane serwery widoczne w Internecie itp.). Dobrym rozwiązaniem jest także subskrypcja serwisów z threat intelligence skupionych na dostawcach – dzięki temu organizacja dostaje ostrzeżenia o nowych incydentach lub zagrożeniach związanych z firmami z jej łańcucha dostaw. Niezależnie od automatyzacji, należy planować regularne audyty (na miejscu lub zdalne) u najważniejszych dostawców, np. raz do roku dla dostawców o wysokim ryzyku. Audyty i monitorowanie pozwalają wykryć zaniedbania (np. opóźnienia w łataniu systemów) zanim przerodzą się one w poważny incydent.
• Współpraca w zakresie reagowania na incydenty – Skuteczna reakcja na incydenty wymaga udziału wszystkich zaangażowanych stron, w tym dostawców. Dlatego organizacja powinna zsynchronizować plany reagowania na incydenty (IRP) ze swoimi kluczowymi dostawcami. W umowach warto zobowiązać dostawcę do natychmiastowego powiadamiania o każdym incydencie bezpieczeństwa, który może dotyczyć naszych systemów lub danych, oraz do pełnej współpracy przy jego wyjaśnianiu. Dobrym pomysłem jest opracowanie wspólnych procedur postępowania na wypadek incydentu (np. joint playbooks), które precyzują, kto i jak podejmuje działania po wykryciu ataku. Regularne ćwiczenia typu tabletop z udziałem dostawców pomogą upewnić się, iż w sytuacji kryzysowej komunikacja i podział ról zadziałają sprawnie. Taka zapobiegawcza kooperacja jest zresztą wymagana przez NIS2 – jeżeli incydent spełnia kryteria raportowania do CSIRT/ENISA, obowiązkiem podmiotu jest szybkie zgłoszenie, niezależnie czy źródło problemu leży po stronie własnej, czy u dostawcy.
• Podnoszenie świadomości i wymagania wobec dostawców – Warto traktować dostawców jako przedłużenie własnego zespołu, jeżeli chodzi o kulturę bezpieczeństwa. NIS2 oczekuje, iż kluczowi usługodawcy będą przestrzegać podobnych standardów jak organizacja nadrzędna, dlatego dobrym zwyczajem jest dzielenie się wymaganiami i wiedzą. Przykładowo, jeżeli dostawcy tworzą dla nas oprogramowanie lub świadczą usługi IT, należy wymagać, by ich pracownicy przechodzili szkolenia z bezpieczeństwa (np. z zasad secure coding, ochrony przed phishingiem) podobne do tych, które przechodzą nasi pracownicy. Można dostarczyć dostawcom wytyczne i dobre praktyki (np. dotyczące hardseningu systemów czy polityk haseł) oraz jasno komunikować oczekiwania co do zgodności z nimi. W ten sposób budujemy wspólną linię obrony – dostawca świadomy zagrożeń i obowiązków stanie się raczej sojusznikiem, a nie najsłabszym ogniwem.

Typowe wyzwania i błędy organizacji w obszarze third-party risk

Mimo rosnącej świadomości, wiele organizacji wciąż popełnia podobne błędy przy zarządzaniu bezpieczeństwem dostawców. Poniżej zebrano najczęstsze wyzwania i zaniedbania w obszarze third-party risk, które mogą niweczyć wysiłki zgodności z NIS2:

• Brak formalnej polityki bezpieczeństwa dostawców – Organizacja nie posiada oficjalnej polityki ani standardów określających wymagania bezpieczeństwa dla dostawców. Często brakuje dedykowanych zapisów w umowach regulujących te kwestie. Taki stan rzeczy prowadzi do uznaniowego traktowania ryzyka dostawców i pomijania ważnych aspektów (np. brak klauzul o audytach czy incydentach).
• Brak klasyfikacji dostawców według ryzyka – Wszystkich dostawców traktuje się jednakowo, bez oceny, którzy z nich są krytyczni dla biznesu. Brak segmentacji skutkuje tym, iż zasoby ochrony rozpraszane są równomiernie, zamiast koncentrować się na dostawcach o najwyższym wpływie na organizację.
• Brak monitorowania i audytów dostawców – Organizacja polega wyłącznie na zapewnieniach samych dostawców co do ich bezpieczeństwa. Brak jest systemu okresowych przeglądów, raportowania lub kontroli zgodności dostawców z ustalonymi wymaganiami. W efekcie problemy po stronie partnera (np. nieaktualne łatki, luki w konfiguracji) mogą pozostać długo niewykryte.
• Niejasne lub niewystarczające zapisy w umowach – Umowy z dostawcami nie precyzują konkretnych obowiązków w zakresie cyberbezpieczeństwa. Często pomijane są takie elementy jak wymóg informowania o incydentach bezpieczeństwa, określone RTO/RPO dla usług, czy szczegółowe SLA bezpieczeństwa. Opieranie się na ogólnych zapisach i zaufaniu, bez twardych wymogów, to proszenie się o kłopoty.
• Brak planu reagowania na incydenty z udziałem dostawców – Organizacja nie definiuje, co zrobić, gdy incydent dotknie jednego z jej dostawców. Nie ma ustalonych punktów kontaktu ani procedur komunikacji z dostawcą w sytuacji kryzysowej. Częstym błędem jest założenie, iż „to dostawca się tym zajmie”. Tymczasem brak wspólnego planu skutkuje chaosem – np. atak ransomware u podwykonawcy może sparaliżować nasze usługi, a strony przerzucają się odpowiedzialnością
• Brak kontroli nad poddostawcami (sub-dostawcami) – Organizacja skupia się wyłącznie na bezpośrednim kontrahencie (Tier 1), ignorując fakt, iż on sam korzysta z usług dalszych podmiotów. Brak wymagań ujawniania i akceptacji kluczowych podwykonawców powoduje, iż do ekosystemu bezpieczeństwa przenikają niezweryfikowane firmy trzecie. Przykładowo dostawca hostingu może lokować nasze dane u zewnętrznego operatora chmury, o czym choćby nie wiemy – co stanowi ukryte ryzyko.
• Brak procesu offboardingu dostawców – Po zakończeniu współpracy z dostawcą często zapomina się o bezzwłocznym zamknięciu jego dostępu do systemów i danych firmy. Zdarzają się sytuacje, iż były dostawca przez cały czas posiada aktywne konta lub klucze dostępu do zasobów organizacji. Taki błąd może mieć poważne konsekwencje – od nieautoryzowanego wglądu w dane po sabotowanie systemów, jeżeli relacja z dostawcą zakończyła się konfliktem.

Wyeliminowanie powyższych luk bywa wyzwaniem organizacyjnym, zwłaszcza w dużych firmach z setkami kontrahentów. Jednak zrozumienie tych typowych błędów to pierwszy krok, aby ich unikać i tym samym lepiej zabezpieczyć łańcuch dostaw przed cyberzagrożeniami.

Rekomendacje: jak zbudować skuteczny system oceny bezpieczeństwa łańcucha dostaw

Budowa efektywnego systemu zarządzania bezpieczeństwem dostawców wymaga podejścia systemowego. Poniżej przedstawiamy rekomendowane kroki i dobre praktyki, które pomogą organizacji spełnić wymagania NIS2 i zabezpieczyć łańcuch dostaw:

• Ustal formalną politykę bezpieczeństwa dostawców – Rozpocznij od zdefiniowania i wdrożenia polityki regulującej kwestie bezpieczeństwa w relacjach z dostawcami (można oprzeć ją na normie ISO 27036). Polityka powinna jasno określać role i obowiązki wewnątrz organizacji (np. kto odpowiada za ocenę dostawców), kryteria akceptacji nowych dostawców pod kątem bezpieczeństwa, wymagane minimalne zabezpieczenia, tryb audytów, raportowania incydentów itp.. Taki dokument stanowi fundament zarządzania third-party risk i komunikacji oczekiwań wobec działów biznesowych oraz samych dostawców.
• Inwentaryzuj i klasyfikuj dostawców – Prowadź centralny rejestr wszystkich usługodawców i partnerów, wraz z opisem jakie usługi świadczą oraz jaki dostęp posiadają do zasobów firmy. Każdemu dostawcy przypisz kategorię ryzyka (np. krytyczny, wysoki, średni, niski) zależnie od wpływu, jaki mógłby mieć incydent z jego udziałem na ciągłość działania lub bezpieczeństwo danych. Ta ocena powinna uwzględniać m.in. rodzaj danych powierzonych dostawcy, stopień integracji z infrastrukturą, poziom uprzywilejowania dostępu oraz ewentualne wymagania regulacyjne. Ocena dostawców – bezpieczeństwo IT musi być procesem ciągłym: aktualizuj klasyfikację co najmniej raz do roku lub przy każdej istotnej zmianie w usłudze dostawcy.
• Przeprowadzaj rzetelne due diligence bezpieczeństwa – Zanim włączysz nowego dostawcę do ekosystemu IT, zweryfikuj jego dojrzałość w zakresie cyberbezpieczeństwa. Wykorzystaj ankiety bezpieczeństwa zawierające szczegółowe pytania o polityki, procedury, mechanizmy ochronne dostawcy (np. czy szyfruje dane, jak zarządza dostępami, czy ma SOC/monitoring 24×7). Żądaj potwierdzenia spełniania uznanych standardów – np. certyfikatu ISO 27001, ISO 27701 (ochrona danych osobowych) lub zgodności z wytycznymi branżowymi (OWASP, CIS). Nie poprzestawaj jednak na deklaracjach: proś o dowody (raporty z audytów, testów penetracyjnych) i sprawdzaj zakres ich ważności. W razie krytycznych usług rozważ przeprowadzenie własnej oceny – od zlecenia audytu trzeciej stronie po wizytację on-site u dostawcy. Im większy potencjalny wpływ dostawcy na bezpieczeństwo Twojej organizacji, tym głębsza powinna być weryfikacja.
• Włącz wymagania cyberbezpieczeństwa do umów – Zapisy kontraktowe to pierwszy filar egzekwowania bezpieczeństwa od dostawców. Przygotuj szablony umów uwzględniające najważniejsze wymogi: klauzulę o przestrzeganiu wymagań NIS2, zobowiązanie do implementacji określonych środków bezpieczeństwa (np. szyfrowanie danych, uwierzytelnianie wieloskładnikowe, regularne backupy), obowiązek zgłaszania incydentów bezpieczeństwa w ustalonym krótkim czasie, a także paragraf o prawie do audytu u dostawcy. Dodatkowo zdefiniuj w umowie metryki SLA związane z bezpieczeństwem (czas przywrócenia usług po awarii, maksymalny dopuszczalny czas niedostępności, czas reakcji na krytyczne podatności itd.). Upewnij się, iż umowy zawierają też wymóg zachowania poufności i zgodności z RODO (jeśli przekazywane są dane osobowe). Precyzyjne umowy stanowią podstawę do pociągnięcia dostawcy do odpowiedzialności, gdyby nie spełniał ustaleń – a przede wszystkim mają działanie prewencyjne, motywując go do utrzymania wysokiego poziomu zabezpieczeń.
• Zapewnij mechanizmy ciągłego monitorowania – Po zawarciu umowy relacja z dostawcą wymaga aktywnego nadzoru. Zaimplementuj narzędzia i procesy pozwalające na bieżąco monitorować bezpieczeństwo dostawców. Mogą to być wspomniane platformy ratingowe, automatyczne skanery sprawdzające cyklicznie adresy IP aplikacji dostawcy pod kątem nowych luk, czy systemy notyfikujące o wygaśnięciu certyfikatów SSL itp. Ustal z dostawcą, iż będzie regularnie dostarczał raporty bezpieczeństwa – np. kwartalne raporty z przeglądu podatności lub zgodności z wymaganiami. W przypadku usług chmurowych rozważ wymóg udostępnienia tzw. Security Assertion Markup Language (SOC) report lub innego raportu okresowego o stanie zabezpieczeń. Ciągłe monitorowanie pozwala gwałtownie wychwycić anomalie (np. nagły wzrost incydentów zgłaszanych przez dostawcę) i zareagować zanim przerodzą się w poważne zagrożenie.
• Kontroluj poddostawców (flow-down wymagania) – Zadbaj o to, by obowiązki w zakresie bezpieczeństwa „spływały” w dół łańcucha dostaw. W umowach z dostawcami pierwszego rzędu zawrzyj klauzule wymagające ujawnienia wszystkich krytycznych poddostawców, z których korzystają przy świadczeniu usługi, oraz zobowiązania, iż narzucą oni swoim podwykonawcom te same standardy bezpieczeństwa. Innymi słowy dostawca powinien kontraktowo egzekwować od swojego partnera (Tier 2) wymogi nie mniejsze niż te, które my nakładamy na niego. jeżeli to możliwe, zastrzeż sobie prawo akceptacji (lub veto) co do kluczowych sub-dostawców. W ten sposób unikniesz sytuacji, w której nieświadomie korzystasz z usług firmy trzeciej pozostającej poza jakąkolwiek kontrolą. Świadomość całego ekosystemu dostawców (tzw. fourth-party risk, ryzyko czwartego szczebla) jest istotna – NIS2 podkreśla, iż bezpieczeństwo łańcucha dostaw obejmuje również dalsze ogniwa, nie tylko bezpośrednich kontrahentów.
• Opracuj wspólny plan reagowania na incydenty – Integralną częścią systemu zarządzania dostawcami musi być plan na wypadek incydentu z ich udziałem. Upewnij się, iż Twój plan reagowania na incydenty (IRP) obejmuje scenariusze awarii lub ataków u dostawców (np. przerwa w usługach chmurowych, wyciek danych u podwykonawcy przetwarzającego informacje naszej firmy). Włącz kluczowych dostawców w proces planowania – określ procedury komunikacji (kogo powiadomić po stronie dostawcy i w jakim czasie), ustal kanały wymiany informacji i eskalacji problemu oraz oczekiwaną pomoc techniczną z ich strony. Dobrym pomysłem są cykliczne ćwiczenia z udziałem dostawców, symulujące incydent i sprawdzające, czy obie strony rozumieją swoje role. Taka gotowość zapewni szybkie opanowanie realnego kryzysu. Co więcej, spełni wymóg NIS2, który nakazuje nie tylko zgłaszanie incydentów do adekwatnych organów w krótkim czasie, ale również wykazanie, iż organizacja aktywnie współpracuje z innymi podmiotami (w tym dostawcami) w celu ograniczenia skutków incydentu.
• Zamykaj dostęp po zakończeniu współpracy (offboarding) – Nie mniej istotny od nadzoru bieżącego jest bezpieczny offboarding dostawcy. Przy rozwiązywaniu umowy z dostawcą wdroż procedurę natychmiastowego odebrania mu dostępu do wszystkich systemów, kont i danych firmy. Upewnij się, iż usunięto lub dezaktywowano konta użytkowników dostawcy w Twoich systemach, unieważniono certyfikaty, klucze API, a udostępnione wcześniej dane zostały zwrócone lub zniszczone zgodnie z umową. Warto sporządzić listę kontrolną czynności na moment offboardingu oraz przydzielić odpowiedzialność za ich wykonanie konkretnym osobom. Ten krok często bywa zaniedbywany, a stanowi ostatnią linię obrony – zabezpiecza przed sytuacją, w której były partner przez cały czas ma furtkę do naszej infrastruktury.

Podążając za powyższymi rekomendacjami, organizacja może zbudować kompleksowy system zarządzania bezpieczeństwem łańcucha dostaw. Taki system nie tylko pozwoli spełnić wymagania compliance NIS2, ale przede wszystkim realnie zmniejszy ryzyko związane z atakami poprzez stronę trzecią. W dobie rosnącej zależności od usług zewnętrznych, inwestycja czasu i zasobów w te obszary z pewnością zaprocentuje zwiększoną odpornością na incydenty.

Podsumowanie

Bezpieczeństwo łańcucha dostaw i ryzyko stron trzecich to w kontekście NIS2 filar, którego nie wolno pomijać. Dyrektywa jasno stawia sprawę: ochrona krytycznych usług wymaga patrzenia nie tylko na własne systemy, ale i na otoczenie – dostawców oprogramowania, usług chmurowych, partnerów biznesowych, podwykonawców. Organizacje, które zlekceważą ten aspekt, narażają się podwójnie: z jednej strony na realne incydenty (bo atakujący chętnie uderzą w mniej zabezpieczone ogniwo), z drugiej na kary i sankcje za brak zgodności z NIS2.

Z kolei firmy, które potraktują zarządzanie ryzykiem dostawców jako stały element strategii bezpieczeństwa, zyskają wielowymiarową korzyść. Nie tylko wypełnią obowiązki regulacyjne, ale zbudują bardziej odporną infrastrukturę, w której każdy partner spełnia określone standardy. W efekcie zmniejszy się prawdopodobieństwo kosztownych przestojów czy wycieków danych na skutek zaniedbań strony trzeciej. NIS2 przypomina, iż cyberbezpieczeństwo to gra zespołowa – tylko najsilniejszy łańcuch dostaw gwarantuje pełną ochronę. Dlatego już teraz warto przyjrzeć się swoim dostawcom, ocenić ich bezpieczeństwo i podjąć działania naprawcze tam, gdzie to konieczne. Zapomniany filar NIS2 nie musi dłużej być zapomniany – uczynienie go priorytetem przyniesie wymierne rezultaty dla bezpieczeństwa całej organizacji.

Seria „NIS2 – Jak być zgodnym” powstała na podstawie publikacji open access „NIS2 – How to Be Compliant v1.3” autorstwa Wojciecha Ciemskiego (Zenodo, 2025). Materiał stanowi praktyczny przewodnik po wdrażaniu dyrektywy NIS2 w organizacjach zgodnie z jej artykułami 21 i 23.