Czym jest NIS2 w kontek\u015bcie bezpiecze\u0144stwa \u0142a\u0144cucha dostaw?<\/h2>\n\n\n\n
Dyrektywa NIS2<\/a> (Dyrektywa (UE) 2022\/2555) to unijne ramy prawne dot. cyberbezpiecze\u0144stwa dla podmiot\u00f3w kluczowych i wa\u017cnych: od energetyki i transportu, przez ochron\u0119 zdrowia, po us\u0142ugi cyfrowe i produkcj\u0119. Sercem dyrektywy jest art. 21, kt\u00f3ry nak\u0142ada na te podmioty obowi\u0105zek wdro\u017cenia \u201eodpowiednich i proporcjonalnych” \u015brodk\u00f3w zarz\u0105dzania ryzykiem. W\u015br\u00f3d dziesi\u0119ciu minimalnych \u015brodk\u00f3w wymienionych w art. 21 znajduje si\u0119 bezpiecze\u0144stwo \u0142a\u0144cucha dostaw, w tym aspekty bezpiecze\u0144stwa dotycz\u0105ce stosunk\u00f3w mi\u0119dzy podmiotem a jego bezpo\u015brednimi dostawcami lub us\u0142ugodawcami. Dyrektywa (art. 21 ust. 3) idzie nawet o krok dalej: organizacje musz\u0105 uwzgl\u0119dnia\u0107 podatno\u015bci specyficzne dla ka\u017cdego bezpo\u015bredniego dostawcy oraz og\u00f3ln\u0105 jako\u015b\u0107 produkt\u00f3w i praktyk cyberbezpiecze\u0144stwa swoich dostawc\u00f3w, \u0142\u0105cznie z ich procedurami bezpiecznego rozwoju oprogramowania. Innymi s\u0142owy, nie wystarczy mie\u0107 polityki na papierze; trzeba faktycznie wiedzie\u0107, jak pracuj\u0105 dostawcy.<\/p>\n\n\n\n Dyrektywa przewiduje te\u017c mechanizm na poziomie unijnym: zgodnie z art. 22, Komisja Europejska i ENISA mog\u0105 przeprowadza\u0107 skoordynowane oceny ryzyka krytycznych \u0142a\u0144cuch\u00f3w dostaw ICT, uwzgl\u0119dniaj\u0105ce tak\u017ce czynniki pozatechniczne, w tym kwestie geopolityczne. Wyniki takich ocen organizacje maj\u0105 obowi\u0105zek bra\u0107 pod uwag\u0119. W praktyce oznacza to, \u017ce firma mo\u017ce by\u0107 wzorowo zorganizowana wewn\u0119trznie, a i tak narazi\u0107 si\u0119 na zarzut niezgodno\u015bci, je\u015bli zignoruje ostrze\u017cenia dotycz\u0105ce konkretnego dostawcy wysokiego ryzyka.<\/p>\n\n\n\n W Polsce NIS2 wdro\u017cono nowelizacj\u0105 ustawy o krajowym systemie cyberbezpiecze\u0144stwa (UKSC), obowi\u0105zuj\u0105c\u0105 od kwietnia 2026 roku. Polska implementacja zas\u0142uguje na uwag\u0119 z dw\u00f3ch powod\u00f3w. Po pierwsze, kary: do 100 mln z\u0142, z mo\u017cliwo\u015bci\u0105 naliczania kar dziennych. Po drugie, przepisy o dostawcach wysokiego ryzyka, kt\u00f3re id\u0105 dalej ni\u017c sama dyrektywa. Decyzja o uznaniu dostawcy za podmiot wysokiego ryzyka oznacza obowi\u0105zek wycofania jego produkt\u00f3w i us\u0142ug ICT z u\u017cytku we wszystkich sektorach obj\u0119tych ustaw\u0105.<\/p>\n\n\n\n Punktem wyj\u015bcia w prze\u0142o\u017ceniu tych wymaga\u0144 na codzienn\u0105 dzia\u0142alno\u015b\u0107 organizacji jest systematyczne zarz\u0105dzanie dostawcami<\/a> oparte na poziomie ryzyka, a nie tylko na warto\u015bci kontraktu. Ma\u0142y podwykonawca z dost\u0119pem administracyjnym do serwer\u00f3w firmy stwarza wi\u0119ksze ryzyko ni\u017c du\u017cy dostawca materia\u0142\u00f3w biurowych, nawet je\u015bli faktury tego drugiego s\u0105 znacznie wy\u017csze. Aczkolwiek automatyzacja zam\u00f3wie\u0144 cz\u0119sto oznacza, \u017ce i ten drugi mo\u017ce mie\u0107 jaki\u015b dost\u0119p do system\u00f3w.<\/p>\n\n\n\n W praktyce program zarz\u0105dzania ryzykiem dostawc\u00f3w obejmuje kilka sta\u0142ych element\u00f3w:<\/p>\n\n\n\n Due diligence dostawc\u00f3w to weryfikacja, kt\u00f3rej dokonujemy, zanim dostawca uzyska dost\u0119p do naszych system\u00f3w \u2013 a wi\u0119c zanim b\u0119dzie za p\u00f3\u017ano. Szukamy przede wszystkim twardych dowod\u00f3w, nie samych deklaracji. Certyfikaty takie jak ISO 27001 czy raporty SOC 2 m\u00f3wi\u0105 wi\u0119cej ni\u017c najpi\u0119kniej wype\u0142niona ankieta. Warto zweryfikowa\u0107 histori\u0119 incydent\u00f3w dostawcy, dojrza\u0142o\u015b\u0107 proces\u00f3w zarz\u0105dzania podatno\u015bciami i aktualizacjami, a w przypadku dostawc\u00f3w oprogramowania, praktyki bezpiecznego rozwoju oprogramowania, o kt\u00f3rych wprost wspomina art. 21 ust. 3 dyrektywy.<\/p>\n\n\n\n Coraz wi\u0119ksze znaczenie ma tak\u017ce SBOM (Software Bill of Materials<\/em>), czyli \u201esk\u0142ad” oprogramowania: lista komponent\u00f3w i bibliotek, z kt\u00f3rych zbudowany jest produkt. Dobrze pokaza\u0142a to luka Log4Shell, wykryta w grudniu 2021 roku w bibliotece Log4j, komponencie obecnym w niezliczonych aplikacjach na ca\u0142ym \u015bwiecie. Organizacja dysponuj\u0105ca SBOM-ami by\u0142a w stanie w ci\u0105gu godzin ustali\u0107, kt\u00f3re z jej system\u00f3w s\u0105 zagro\u017cone. Organizacja, kt\u00f3ra ich nie prowadzi, cz\u0119sto dowiaduje si\u0119 o zagro\u017ceniu dopiero z doniesie\u0144 medialnych.<\/p>\n\n\n\n Jedna uwaga praktyczna: due diligence<\/em> powinno by\u0107 proporcjonalne. Wysy\u0142anie 300-pytaniowej ankiety ka\u017cdemu dostawcy to prosta droga do tego, by nikt nie czyta\u0142 odpowiedzi. Dla dostawc\u00f3w niskiego ryzyka wystarczy uznanie certyfikat\u00f3w; szczeg\u00f3\u0142ow\u0105 ocen\u0119 warto zarezerwowa\u0107 dla tych, od kt\u00f3rych naprawd\u0119 zale\u017cy nasze bezpiecze\u0144stwo.<\/p>\n\n\n\n Tu dochodzimy do najwa\u017cniejszej zmiany koncepcyjnej, jak\u0105 wymusza NIS2. Tradycyjny model \u2013 ankieta przy onboardingu, powt\u00f3rka raz w roku, wyniki do segregatora \u2013 przestaje wystarcza\u0107. Dostawca, kt\u00f3ry by\u0142 bezpieczny w styczniu, w czerwcu mo\u017ce ju\u017c nie by\u0107: wystarczy incydent, zmiana w\u0142a\u015bciciela, utrata kluczowego personelu, nowa podatno\u015b\u0107 w wykorzystywanej technologii, albo zwyczajne zaniedbanie aktualizacji bezpiecze\u0144stwa.<\/p>\n\n\n\n NIS2 oczekuje monitoringu ci\u0105g\u0142ego. W praktyce oznacza to korzystanie z narz\u0119dzi automatycznej oceny ryzyka, \u017ar\u00f3de\u0142 tzw. threat intelligence<\/em> i alert\u00f3w o zdarzeniach dotycz\u0105cych naszych dostawc\u00f3w. Oznacza to tak\u017ce zdefiniowanie zdarze\u0144 uruchamiaj\u0105cych nadzwyczajny przegl\u0105d dostawcy: powa\u017cny incydent, zmiana struktury w\u0142asno\u015bciowej, sankcje regulacyjne, istotne rozszerzenie zakresu dost\u0119pu do naszych system\u00f3w. Rzeczywista odporno\u015b\u0107 organizacji wymaga, by wiedza o ryzyku dostawcy by\u0142a aktualna wtedy, gdy jest potrzebna, a nie dopiero przy okazji kolejnej dorocznej weryfikacji. Takie podej\u015bcie motywuje te\u017c kontrahent\u00f3w do ci\u0105g\u0142ego monitorowania cyberbezpiecze\u0144stwa.<\/p>\n\n\n\n Umowa to jedyne narz\u0119dzie, kt\u00f3rym realnie dysponujemy wobec dostawcy \u2013 dlatego NIS2 i akty wykonawcze k\u0142ad\u0105 tak du\u017cy nacisk na zapisy kontraktowe. W umowie z dostawc\u0105 krytycznym powinny znale\u017a\u0107 si\u0119 nast\u0119puj\u0105ce elementy:<\/p>\n\n\n\n NIS2 wprowadza trzystopniowy model raportowania powa\u017cnych incydent\u00f3w: wczesne ostrze\u017cenie w ci\u0105gu 24 godzin od uzyskania wiedzy o incydencie, pe\u0142ne zg\u0142oszenie w ci\u0105gu 72 godzin i raport ko\u0144cowy w ci\u0105gu miesi\u0105ca. W kontek\u015bcie \u0142a\u0144cucha dostaw kluczowe jest owo \u201euzyskanie wiedzy”. Je\u015bli incydent ma \u017ar\u00f3d\u0142o u dostawcy, nasz zegar zaczyna tyka\u0107 w momencie, gdy si\u0119 o nim dowiadujemy; dlatego tak istotne jest, by umowa gwarantowa\u0142a szybkie powiadomienie, a wewn\u0119trzne zarz\u0105dzanie incydentami<\/a> obejmowa\u0142o scenariusz \u201eincydent u strony trzeciej”: Kto przyjmuje zg\u0142oszenie od dostawcy? Kto ocenia wp\u0142yw na nasz\u0105 organizacj\u0119? Kto decyduje o zg\u0142oszeniu do CSIRT?<\/p>\n\n\n\n Warto te\u017c pami\u0119ta\u0107 o ryzyku koncentracji. Je\u015bli p\u00f3\u0142 bran\u017cy korzysta z tego samego dostawcy chmury lub operatora us\u0142ug IT, incydent u niego staje si\u0119 incydentem systemowym. Pokaza\u0142 to wspomniany we wst\u0119pie incydent z systemem obs\u0142ugi bilet\u00f3w MUSE czy atak na narz\u0119dzie MOVEit Transfer w 2023 roku, gdy wykorzystanie jednej luki w popularnym oprogramowaniu do przesy\u0142ania plik\u00f3w dotkn\u0119\u0142o naraz tysi\u0105ce organizacji na ca\u0142ym \u015bwiecie. Identyfikacja pojedynczych punkt\u00f3w awarii w \u0142a\u0144cuchu dostaw i przygotowanie plan\u00f3w awaryjnych to element zarz\u0105dzania ryzykiem, o kt\u00f3ry coraz cz\u0119\u015bciej pytaj\u0105 instytucje nadzoru cyberbezpiecze\u0144stwa.<\/p>\n\n\n\n \u0141a\u0144cuch dostaw rzadko ko\u0144czy si\u0119 na pierwszym ogniwie. Nasz dostawca SaaS korzysta z dostawcy chmury, ten z kolei z zewn\u0119trznego wsparcia technicznego\u2026 i nagle nasze dane zale\u017c\u0105 od firmy, o kt\u00f3rej istnieniu nie mieli\u015bmy poj\u0119cia. To tak zwane ryzyko czwartej strony, a nawet ryzyko \u201en-tej strony\u201d. Podwykonawcami nie zarz\u0105dzamy bezpo\u015brednio. Nie \u0142\u0105czy nas z nimi umowa i nie mamy wobec nich prawa audytu. Mo\u017cemy jednak (i powinni\u015bmy) wymaga\u0107 od naszych bezpo\u015brednich dostawc\u00f3w, by sami prowadzili dojrza\u0142e zarz\u0105dzanie ryzykiem stron trzecich i ujawniali nam kluczowe zale\u017cno\u015bci. Mapowanie krytycznych zale\u017cno\u015bci ICT, przynajmniej dla najwa\u017cniejszych us\u0142ug, nie jest fanaberi\u0105, ale staje si\u0119 warunkiem rzetelnej oceny ryzyka.<\/p>\n\n\n\nZarz\u0105dzanie ryzykiem dostawc\u00f3w w praktyce<\/h2>\n\n\n\n
\n
![\"\"](\"https:\/\/adaptivegrc.com\/wp-content\/uploads\/2026\/08\/Elementy-programu-zarzadzania-ryzykiem-dostawcow-1024x727.png\")
<\/figure>\n\n\n\nDue diligence i ocena bezpiecze\u0144stwa dostawc\u00f3w<\/h2>\n\n\n\n
Monitoring dostawc\u00f3w i ci\u0105g\u0142a ocena ryzyka<\/h2>\n\n\n\n
Umowy, SLA i wymagania bezpiecze\u0144stwa<\/h2>\n\n\n\n
\n
![\"\"](\"https:\/\/adaptivegrc.com\/wp-content\/uploads\/2026\/08\/Elementy-umowy-z-dostawca-krytycznym-1024x727.png\")
<\/figure>\n\n\n\nIncident reporting w \u0142a\u0144cuchu dostaw<\/h2>\n\n\n\n
Zarz\u0105dzanie podwykonawcami i zale\u017cno\u015bciami ICT<\/h2>\n\n\n\n