NIS2: zarządzanie ryzykiem dostawców – łańcuch dostaw, który zaczyna się w Twoim dziale zakupów

Kiedy w zeszłym roku przygotowywałem się do wdrożenia NIS2 w jednej z firm, zadałem działowi zakupów proste pytanie: „Kto z Waszych dostawców IT ma dostęp do naszych danych?”. Zapadła cisza, a potem usłyszałem: „No… chyba wszyscy, bo to chmura”. To zdanie uświadomiło mi, że zarządzanie ryzykiem dostawców w NIS2 to nie kolejny załącznik do polityki bezpieczeństwa, ale fundamentalna zmiana w sposobie myślenia o relacjach biznesowych. Dyrektywa wymaga oceny i monitorowania poziomu cyberbezpieczeństwa zewnętrznych dostawców usług cyfrowych i oprogramowania – a to oznacza, że za bezpieczeństwo płacisz także wtedy, gdy nie masz na nie bezpośredniego wpływu.

Nie tylko umowa, ale realna ocena ryzyka

Art. 21 ust. 2 lit. d dyrektywy NIS2 nakłada obowiązek wdrożenia środków technicznych, organizacyjnych i operacyjnych zapewniających bezpieczeństwo łańcucha dostaw. W praktyce oznacza to, że musisz wiedzieć, jakiego rodzaju dane i systemy powierzasz dostawcy, jaki ma on dostęp do Twojej infrastruktury oraz jakie są jego własne zabezpieczenia. To nie jest jednorazowy kwestionariusz – chodzi o proces due diligence, który uwzględnia m.in. ocenę ryzyka dla każdego dostawcy, weryfikację certyfikatów i polityk bezpieczeństwa, a także analizę podatności na incydenty. W materiałach źródłowych, które przeglądałem, podkreśla się, że 97% organizacji doświadczyło naruszenia bezpieczeństwa za pośrednictwem swojego łańcucha dostaw – to liczba, która powinna znieść złudzenia, że „jakoś to będzie”.

Drugi konkret: NIS2 nie wymaga od Ciebie, byś samodzielnie audytował każdego dostawcę, ale musisz umieć udokumentować, że podejmujesz działania proporcjonalne do ryzyka. Oznacza to na przykład, że dla dostawcy krytycznego (np. operatora chmury, który przetwarza dane klientów) warto zażądać raportu z niezależnego audytu (np. ISO 27001) lub wypełnionego kwestionariusza bezpieczeństwa z załącznikami. Dla mniejszego dostawcy narzędzia SaaS wystarczy oświadczenie o stosowanych środkach i klauzula umowna o prawie do audytu. Ważne, by ocena była powtarzalna i aktualizowana – nie tylko przy podpisywaniu umowy.

Umowa jako narzędzie monitoringu, a nie archiwum

W NIS2 zarządzanie ryzykiem stron trzecich jest integralną częścią bezpieczeństwa organizacji, a umowy z dostawcami muszą zawierać postanowienia dotyczące bezpieczeństwa. W praktyce widzę, że wiele firm poprzestaje na standardowym załączniku o poufności i karach umownych, które nigdy nie są egzekwowane. Tymczasem dyrektywa kładzie nacisk na monitorowanie – czyli regularne sprawdzanie, czy dostawca nadal spełnia wymagania. Proponuję wprowadzić do umów zapisy o obowiązku zgłaszania incydentów w określonym czasie (np. 24 godzin), prawie do przeprowadzenia audytu lub żądania raportu z testów penetracyjnych oraz o aktualizacji dokumentacji bezpieczeństwa. Bez takich klauzul trudno mówić o realnym zarządzaniu ryzykiem.

Kolejny konkret: SBOM (Software Bill of Materials) staje się coraz częściej wymaganym elementem dla dostawców oprogramowania. Choć NIS2 nie wymaga go wprost, to w połączeniu z obowiązkiem oceny ryzyka związanego z podatnościami w komponentach, SBOM daje Ci obraz, jakie biblioteki są używane i czy nie są przestarzałe. W mojej ocenie to jeden z najprostszych sposobów na podniesienie świadomości ryzyka w łańcuchu dostaw – i argument, który łatwo sprzedać działowi zakupów jako „checklistę” do rozmowy z dostawcą.

Przykład z praktyki

W pewnej firmie logistycznej, która wdrażała NIS2, dział IT i dział zakupów postanowiły wspólnie stworzyć rejestr dostawców krytycznych. Zaczęli od prostego pytania: które systemy i usługi mają dostęp do danych osobowych lub wpływają na ciągłość operacji? Okazało się, że lista jest dłuższa niż sądzili – od operatora chmury, przez dostawcę systemu TMS, po zewnętrzną firmę serwisującą serwery. Dla każdego dostawcy przypisali poziom ryzyka (wysoki, średni, niski) i zdefiniowali minimalne wymagania: dla wysokiego – audyt ISO 27001 lub równoważny, dla średniego – wypełniony kwestionariusz i oświadczenie, dla niskiego – standardowa klauzula umowna. Kluczowe było to, że rejestr nie trafił do szuflady, ale stał się częścią przeglądu zarządzania i był aktualizowany raz na kwartał.

Po kilku miesiącach zdarzył się incydent: jeden z dostawców usług chmurowych zgłosił naruszenie bezpieczeństwa, które mogło dotknąć dane klientów. Dzięki wcześniejszym ustaleniom firma miała jasną ścieżkę eskalacji i mogła szybko zweryfikować, czy incydent dotyczy ich danych. Co więcej, umowa zawierała zapis o obowiązku dostarczenia raportu powłamaniowego w ciągu 48 godzin – dostawca wywiązał się z tego, a firma mogła ocenić skutki i podjąć decyzję o dalszej współpracy. To doświadczenie utwierdziło mnie w przekonaniu, że NIS2 nie wymaga nadzwyczajnych narzędzi, ale konsekwencji w egzekwowaniu ustaleń.

Co z tego wynika

Zarządzanie ryzykiem dostawców w NIS2 to nie projekt do odhaczenia, ale ciągły proces, który powinien być wpięty w codzienną pracę działu zakupów i IT. Zamiast tworzyć kolejną politykę, warto zacząć od inwentaryzacji dostawców i przypisania im poziomów ryzyka, a następnie dostosować do nich wymagania umowne i monitoring. Bez tego nawet najlepszy audyt wewnętrzny nie pomoże, bo ryzyko w łańcuchu dostaw pozostanie poza kontrolą.