Nowelizacja UKSC ,za dyrektywą NIS2, nakłada także obowiązki bieżące: audyty użytkowanych systemów pod kątem bezpieczeństwa, bieżące szkolenia pracowników z zakresu AI (sztucznej inteligencji) i cyberbezpieczeństwa, obowiązki raportowe, również prowadzone na bieżąco. Wśród nich raportowanie incydentów naruszenia przepisów i rejestr cyberzdarzeń. O praktyczną stronę realizacji spytaliśmy eksperta od cyberbezpieczeństwa.
Na pytania Forsal.pl odpowiada Kamil Pszczółkowski, dyrektor w Zespole Cybersecurity EY Polska (d. Ernst&Young)
1. W jakim zakresie moja firma odpowiada za zaniedbania dostawcy, np. wyciek danych lub informacji przekazanych w celu realizacji usługi?
Przekazanie realizacji usługi podmiotowi zewnętrznemu nie oznacza przeniesienia odpowiedzialności za cyberbezpieczeństwo. To jedna z najważniejszych zmian, jakie w praktyce wprowadza dyrektywa NIS2 oraz nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa (UKSC). Organizacja może zlecić wykonanie określonych czynności, ale nie może przenieść na dostawcę odpowiedzialności za zarządzanie ryzykiem związanym z korzystaniem z jego usług.
Dobrym przykładem jest współpraca z agencją marketingową. Jeżeli przedsiębiorstwo przekazuje jej bazę klientów, informacje handlowe lub inne poufne dane niezbędne do realizacji kampanii, a następnie dochodzi do ich ujawnienia, źródłem incydentu może być dostawca. Nie oznacza to jednak, że organ właściwy będzie oceniał wyłącznie jego działania. W pierwszej kolejności sprawdzi, czy przedsiębiorstwo prawidłowo zarządzało ryzykiem związanym z powierzeniem realizacji usługi podmiotowi zewnętrznemu.
Dyrektywa NIS2 zalicza bezpieczeństwo łańcucha dostaw do podstawowych środków zarządzania ryzykiem w cyberbezpieczeństwie. Obejmuje ono nie tylko relacje z bezpośrednimi dostawcami usług ICT, ale również ocenę bezpieczeństwa produktów i usług wykorzystywanych przez organizację. Proces zarządzania ryzykiem dostawców powinien uwzględniać m.in. krytyczność dostawcy, ocenę ryzyka, wymagania bezpieczeństwa zawarte w umowach, monitorowanie świadczonych usług oraz okresową weryfikację skuteczności zastosowanych zabezpieczeń.
Z punktu widzenia przedsiębiorstwa oznacza to, że samo zawarcie umowy z renomowanym dostawcą nie będzie wystarczające. Organizacja powinna być w stanie wykazać, że świadomie oceniła ryzyko współpracy i przez cały okres obowiązywania umowy nadzorowała sposób realizacji usługi.
W praktyce podczas kontroli organu nadzorczego mogą pojawić się pytania dotyczące między innymi:
- a) sposobu identyfikacji dostawców krytycznych,
- b) kryteriów oceny ryzyka dostawcy,
- c) wymagań bezpieczeństwa określonych w umowie,
- d) prawa do audytu lub pozyskiwania informacji o poziomie bezpieczeństwa,
- e) monitorowania realizacji usługi oraz okresowych przeglądów ryzyka.
Warto jednocześnie rozróżnić odpowiedzialność wynikającą z umowy od odpowiedzialności wynikającej z przepisów. Jeżeli umowa przewiduje kary umowne lub obowiązek naprawienia szkody, przedsiębiorstwo może dochodzić roszczeń od dostawcy. Nie zmienia to jednak faktu, że z perspektywy UKSC organ nadzorczy będzie oceniał przede wszystkim działania samej organizacji. Przedmiotem oceny będzie to, czy wdrożono odpowiedni proces zarządzania ryzykiem oraz czy był on rzeczywiście stosowany.
Relatywnie, jeżeli incydent dotyczy danych osobowych, równolegle zastosowanie znajdą przepisy RODO. Administrator danych pozostaje odpowiedzialny za wybór podmiotu przetwarzającego zapewniającego odpowiednie gwarancje wdrożenia środków technicznych i organizacyjnych. W zależności od okoliczności może również powstać obowiązek zgłoszenia naruszenia Prezesowi UODO oraz poinformowania osób, których dane dotyczą.
Podsumowując, NIS2 / UKSC nie nakłada odpowiedzialności za działania dostawcy, lecz za sposób zarządzania ryzykiem związanym z jego wykorzystaniem. W praktyce oznacza to konieczność udokumentowania całego procesu – od kwalifikacji dostawcy, przez ocenę ryzyka i wymagania kontraktowe, po bieżący nadzór nad świadczoną usługą. To właśnie te elementy będą weryfikowane podczas kontroli, a nie wyłącznie sam fakt wystąpienia incydentu czy zakresu podpisanej umowy z dostawcą.
2. Jeżeli u jednego z uczestników łańcucha dostaw dojdzie do incydentu cyberbezpieczeństwa, czy pozostali uczestnicy powinni zostać o tym poinformowani? Co w sytuacji, gdy pracownik wykorzystał publiczny model AI i przekazał poufne informacje?
Nie każdy incydent występujący u dostawcy lub partnera biznesowego uruchamia obowiązek informowania wszystkich uczestników łańcucha dostaw czy organy nadzorczego. NIS2 oraz nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa (UKSC) nie przewidują automatycznego mechanizmu przekazywania informacji o każdym zdarzeniu. Kryterium decydującym jest wpływ incydentu na bezpieczeństwo lub ciągłość świadczenia usług oraz możliwość oddziaływania na inne organizacje.
Jeżeli organizacja ocenia, że skutki incydentu mogą dotknąć również jej klientów, odbiorców usług albo partnerów biznesowych, powinna rozważyć przekazanie im informacji umożliwiających ograniczenie ryzyka. W wielu przypadkach szybka komunikacja pozwala uniknąć kolejnych naruszeń, zwłaszcza gdy incydent wynika z wykorzystania tej samej podatności, wspólnej platformy lub współdzielonej usługi.
Niezależnie od komunikacji prowadzonej z partnerami czy klientami biznesowymi organizacja powinna wypełnić obowiązki wynikające z przepisów UKSC. W przypadku incydentu poważnego konieczne będzie jego zgłoszenie właściwemu CSIRT, a jeżeli zdarzenie wpływa na odbiorców usług, również przekazanie im stosownych informacji. W praktyce należy uwzględnić także zobowiązania wynikające z umów, ponieważ coraz częściej zawierają one szczegółowe wymagania dotyczące notyfikacji incydentów oraz współpracy przy ich obsłudze.
Szczególnej uwagi wymagają zdarzenia związane z wykorzystaniem publicznych modeli generatywnej sztucznej inteligencji. Samo korzystanie z takich narzędzi nie stanowi incydentu. Problem pojawia się w chwili, gdy do zewnętrznej usługi trafiają informacje, które zgodnie z polityką bezpieczeństwa nie powinny opuszczać organizacji. Mogą to być dane klientów (w tym dane osobowe), dokumentacja techniczna, kod źródłowy, informacje finansowe czy dane objęte tajemnicą przedsiębiorstwa.
Ocena takiego zdarzenia powinna koncentrować się na skutkach, a nie na technologii wykorzystanej przez pracownika. Należy ustalić, jakie informacje zostały ujawnione, czy możliwe jest ich dalsze przetwarzanie przez dostawcę usługi, jaki wpływ zdarzenie wywiera na poufność informacji oraz czy może oddziaływać na świadczone usługi lub bezpieczeństwo innych podmiotów. Dopiero na tej podstawie można ocenić, czy zdarzenie spełnia przesłanki incydentu wymagającego zgłoszenia zgodnie z UKSC lub naruszenia ochrony danych osobowych w rozumieniu RODO.
Jeżeli ujawnione informacje obejmują dane osobowe, administrator powinien przeprowadzić ocenę ryzyka naruszenia praw i wolności osób fizycznych oraz podjąć działania wymagane przez RODO. W zależności od wyniku tej analizy może powstać obowiązek zgłoszenia naruszenia Prezesowi UODO oraz zawiadomienia osób, których dane dotyczą.
Coraz więcej organizacji wdraża rozwiązania pozwalające monitorować przepływ informacji do usług zewnętrznych, wykorzystywanie narzędzi opartych na sztucznej inteligencji czy przesyłanie danych poza organizację. Należy jednak pamiętać, że takie mechanizmy mogą wiązać się z dodatkowymi obowiązkami ustanowienia zasad wykorzystania w organizacji oraz zastosowanie adekwatnych środków bezpieczeństwa.
Należy pamiętać, że największym błędem jest przyjęcie założenia, że obowiązek poinformowania partnerów czy klientów biznesowych istnieje wyłącznie wtedy, gdy wynika z umowy. W rzeczywistości decyzja powinna opierać się na analizie wpływu incydentu na bezpieczeństwo i ciągłość świadczonych usług. Jeżeli organizacja dysponuje informacjami, które mogą pomóc innym uczestnikom łańcucha dostaw ograniczyć skutki zdarzenia, przekazanie ich należy traktować jako element skutecznego zarządzania ryzykiem, a nie wyłącznie realizację obowiązku formalnego. W przypadku incydentów związanych z wykorzystaniem publicznych narzędzi AI, kluczowe znaczenie ma nie sama technologia, lecz zakres ujawnionych informacji oraz ich wpływ na działalność organizacji, jego partnerów i klientów.
3. Jakie są praktyczne różnice pomiędzy podmiotem kluczowym a podmiotem ważnym?
Podział wprowadzony przez dyrektywę NIS2 budzi wiele pytań, ponieważ intuicyjnie sugeruje dwa różne poziomy obowiązków. W rzeczywistości dla większości przedsiębiorstw różnica nie polega na tym, co należy wdrożyć, lecz jak będzie wyglądał nadzór ze strony organu nadzorczego.
Zarówno podmioty kluczowe, jak i ważne mają obowiązek wdrożyć środki zarządzania ryzykiem w cyberbezpieczeństwie. Obejmują one między innymi zarządzanie incydentami, zapewnienie ciągłości działania, bezpieczeństwo łańcucha dostaw ICT, zarządzanie podatnościami, ochronę systemów informacyjnych wykorzystywanych do świadczenia usług, testowanie skuteczności zabezpieczeń oraz stosowanie odpowiednich mechanizmów uwierzytelniania i bezpiecznej komunikacji. Zakres tych wymagań wynika z dyrektywy NIS2 i został odzwierciedlony w nowelizacji Ustawy o Krajowym Systemie Cyberbezpieczeństwa (UKSC).
W praktyce oznacza to, że przedsiębiorstwo zakwalifikowane jako podmiot ważny nie może budować uproszczonego systemu zarządzania bezpieczeństwem informacji tylko dlatego, że nie zostało uznane za podmiot kluczowy. W obu przypadkach organizacja powinna być przygotowana do wykazania, że środki bezpieczeństwa zostały dobrane na podstawie oceny ryzyka i są rzeczywiście stosowane.
Jak wspomniałem wcześniej, największa różnica pomiędzy podmiotem kluczowym a podmiotem ważnym dotyczy sposobu wykonywania nadzoru. W odniesieniu do podmiotów kluczowych dyrektywa przewiduje zarówno działania ex ante, jak i ex post. Organ nadzorczy może prowadzić planowe kontrole, żądać dokumentacji, przeprowadzać inspekcje oraz weryfikować skuteczność wdrożonych środków niezależnie od tego, czy doszło do incydentu. Natomiast w przypadku podmiotów ważnych zasadą jest nadzór następczy. Najczęściej zostaje wszczęty po wystąpieniu poważnego incydentu lub gdy organ dysponuje informacjami wskazującymi na możliwe naruszenie przepisów lub wynika to z przeprowadzonych tzw. kontroli krzyżowych. Nie oznacza to jednak, że organizacje te są kontrolowane w mniejszym zakresie. Jeżeli postępowanie zostanie wszczęte, organ może oczekiwać tego samego poziomu przygotowania i tej samej jakości dokumentacji, jakiej wymaga od podmiotów kluczowych.
Należy zaznaczyć, że to rozróżnienie ma istotne znaczenie dla zarządu organizacji. Część organizacji błędnie zakłada, że status podmiotu ważnego pozwala odłożyć wdrożenie części wymagań do czasu pierwszej kontroli. Takie podejście trudno pogodzić z wymaganiami NIS2. Obowiązek wdrożenia środków bezpieczeństwa powstaje z chwilą objęcia organizacji przepisami, a nie dopiero po zainteresowaniu się nią przez organ nadzorczy.
Również odpowiedzialność kierownictwa została ukształtowana w podobny sposób dla obu kategorii podmiotów. Zarząd odpowiada za zatwierdzenie środków zarządzania ryzykiem, nadzór nad ich wdrożeniem oraz zapewnienie odpowiedniego poziomu wiedzy osób zarządzających. W praktyce oznacza to, że członkowie zarządu powinni rozumieć najważniejsze ryzyka cyberbezpieczeństwa i być w stanie ocenić, czy organizacja dysponuje adekwatnymi mechanizmami ich ograniczania.
Z perspektywy przeprowadzanej kontroli nadzorczej największe znaczenie ma możliwość wykazania, że system zarządzania bezpieczeństwa informacji funkcjonuje w organizacji w praktyce, a nie tylko na „papierze”. Same procedury nie będą wystarczające. Organ może oczekiwać zapisów potwierdzających przeprowadzanie oceny ryzyka, ocen dostawców ICT, testów zabezpieczeń, przeglądów podatności, ćwiczeń reagowania na incydenty, działań naprawczych oraz szkoleń osób odpowiedzialnych za cyberbezpieczeństwo. To właśnie ta dokumentacja będzie podstawą oceny zgodności z wymaganiami UKSC.
Dziennikarz z zawodu i zamiłowania. Zajmuje się tematyką gospodarczą, prawną i finansową, szczególnie nowymi technologiami, i komunikacją oraz mediami. Poza dziennikarstwem zajmuje się fotografią, jeździ na nartach i uwielbia Hiszpanię. Z marką INFOR związany wcześniej, zaczynał przygodę z dziennikarstwem w Gazecie Prawnej. Od kwietnia 2026 r. już jako dziennikarz internetowy przygotowuje i publikuje artykuły na portalu Forsal.pl.