Atakują już procesy, nie tylko dane. Co NIS2 naprawdę zmienia w cyberbezpieczeństwie polskiego OT

Kwietniowa nowelizacja UKSC zamknęła okres, w którym polski przemysł mógł traktować cyberbezpieczeństwo jako sprawę działu IT. Dyrektywa NIS2 przeniosła ciężar odpowiedzialności na zarząd, rozszerzyła zakres regulacji na sektory operujące infrastrukturą fizyczną i nałożyła twarde terminy raportowania incydentów. W tle – 60-proc. wzrost incydentów rok do roku i jakościowa zmiana wektora ataku, od danych do sterowników, pomp i linii produkcyjnych. Maciej Ramotowski i Dawid Bednarczyk z KnowGuard tłumaczą, co to oznacza w praktyce dla polskich firm produkcyjnych.

• Nowelizacja UKSC z kwietnia 2026 r. wciągnęła do systemu sektory, które historycznie nie myślały w kategoriach cyberbezpieczeństwa — od gospodarki odpadami i produkcji żywności po wodociągi i chemię, a sam mechanizm ustawy opiera się na samoidentyfikacji. Żaden urząd nie poinformuje firmy, że właśnie podlega regulacji
• Liczba incydentów naruszenia bezpieczeństwa wzrosła w Polsce o 60% rok do roku, a ciężkie ataki o 57%. Zmienił się też charakter zagrożenia: od manipulacji parametrami ciepłowni w Rucianem-Nidzie, przez przepompownie w Witkowie, po grudniowy atak, jaki CERT zarejestrował na co najmniej 30 farmach wiatrowych i fotowoltaicznych oraz dużej elektrociepłowni
• NIS2 wprowadza osobistą odpowiedzialność finansową członków zarządu — kary do 10 mln euro lub 2% globalnego obrotu dla podmiotów kluczowych, a obowiązek wdrożenia systemu zarządzania bezpieczeństwem spoczywa personalnie na prezesie, nie na dziale IT
• Ścieżka zgodności w warstwie OT to nie zakup technologii, tylko właściwa kolejność działań w sześciomiesięcznym horyzoncie

Rozwijaj swoją markę osobistą. Dołącz do programu BGR Expert Network

Kwiecień 2026 r. był datą graniczną dla polskiego przemysłu. Nowelizacja UKSC, transponująca dyrektywę NIS2, wciągnęła do systemu cyberbezpieczeństwa branże, które dotąd funkcjonowały poza jego logiką: gospodarkę odpadami, produkcję i dystrybucję żywności, chemię, usługi pocztowe i kurierskie, wodociągi. Sektory zarządzające infrastrukturą fizyczną – sterownikami PLC, pompami, zaworami, liniami produkcyjnymi – znalazły się w sytuacji, w której bezpieczeństwo procesowe i cyberbezpieczeństwo muszą zacząć rozmawiać tym samym językiem. Tymczasem dane CERT pokazują, że incydenty wzrosły o 60% rok do roku, a atakujący przesunęli punkt ciężkości z danych na procesy fizyczne – od ciepłowni w Rucianem-Nidzie po 30 farm OZE zaatakowanych pod koniec 2025 r.

O tym, jak zabezpieczać sieci OT bez wymiany sprzętu, jak interpretować zasadę proporcjonalności tam, gdzie jeden patch może oznaczać setki tysięcy złotych przestoju, i co dziś powinno znaleźć się w umowach z integratorami, rozmawiamy z Maciejem Ramotowskim i Dawidem Bednarczykiem z KnowGuard.

Grzegorz Kubera, Business Growth Review: NIS2 dramatycznie rozszerza zakres podmiotów objętych regulacją. Które branże operujące infrastrukturą OT w Polsce najczęściej nie zdają sobie sprawy, że właśnie podpadły pod nowe obowiązki – i z czego to wynika?

Maciej Ramotowski, Co-founder i CEO w KnowGuard: Zacznę od tego, co mówi sama ustawa. Nowelizacja UKSC, która weszła w życie w kwietniu 2026 roku, wciągnęła do systemu sektory, które wcześniej w ogóle nie funkcjonowały w logice regulacji cyberbezpieczeństwa: gospodarkę odpadami, produkcję i dystrybucję żywności, produkcję chemikaliów, usługi pocztowe i kurierskie. Do tego wodociągi i gospodarkę ściekową, które choć formalnie obecne w starym UKSC, w praktyce przez lata funkcjonowały poza głównym nurtem wymagań. To są sektory, w których dziś widzę największą lukę świadomości.

Dlaczego akurat one? Bo mają jedną wspólną cechę: zarządzają infrastrukturą fizyczną. Czyli pompami, zaworami, sterownikami, liniami produkcyjnymi i od zawsze myślały o bezpieczeństwie w kategoriach BHP i ciągłości technicznej, nie cyberbezpieczeństwa. Dział IT, jeśli w ogóle istnieje, zajmuje się komputerami biurowymi. Systemy SCADA i PLC to „działka automatyków”. Ta granica kompetencyjna jest jedną z największych przeszkód we wdrożeniu wymagań UKSC.

Jest też pułapka w samym mechanizmie ustawy, o której mało kto mówi wprost: UKSC oparty jest na samoidentyfikacji. Oznacza to, że żaden urząd nie przyjdzie i nie poinformuje firmy, że podlega pod regulację. Obowiązek analizy i rejestracji spoczywa na Zarządzie. A status podmiotu wynika z samego spełnienia przesłanek ustawowych – nie z faktu złożenia wniosku. Innymi słowy: firma, która się nie zgłosiła, wciąż podlega i może zostać wpisana do wykazu z urzędu oraz skontrolowana. Brak działania nie jest ochroną, jest ryzykiem.

W praktyce widzę, że te firmy nie ignorują NIS2 świadomie. One po prostu jeszcze nie wiedzą, że ona ich dotyczy. Jest to fundamentalna różnica, bo oznacza, że problem jest edukacyjny – nie techniczny.

W warstwie OT wciąż spotykamy urządzenia 15-25-letnie, pracujące na protokołach bez uwierzytelniania (Modbus, Profibus, DNP3). Jak zabezpieczać taką infrastrukturę bez wymiany sprzętu, którego cykl życia produkcyjnego jeszcze się nie skończył?

Maciej Ramotowski: Zanim odpowiem merytorycznie – to jest jedno z tych pytań, gdzie „idealna odpowiedź” i „realna odpowiedź” bardzo się rozjeżdżają. Powiem, jak to wygląda w praktyce. Fundamentalna zasada: nie możesz naprawić protokołu OT, możesz kontrolować dostęp do niego. Co działa?

1. Segmentacja i mikrosegmentacja sieciowa – to fundament

Jeśli sterownik PLC sprzed 20 lat nie może rozmawiać z niczym poza jednym, konkretnym serwerem SCADA – jego brak uwierzytelniania przestaje być krytycznym problemem. Firewalle przemysłowe potrafią działać na poziomie głębokiej analizy ruchu (DPI – deep packet inspection) i odmawiać np. komend zapisu, przepuszczając tylko odczyt. To jest naprawdę użyteczna kontrola bez dotykania urządzenia.

2. Monitoring anomalii ruchu OT – „jeśli nie możesz zabezpieczyć, przynajmniej wiedz”

Narzędzia pasywne nasłuchują ruchu bez ingerencji w urządzenia i budują baseline – „ten sterownik zawsze odpytuje co 500ms, wartości w zakresie X-Y”. Odchylenie = alert. To nie zapobiega atakowi, ale dramatycznie skraca czas wykrycia.

3. Jump serwery i kontrola dostępu do konsoli

Każdy dostęp serwisowy – własny inżynier, integrator, serwisant OT – wyłącznie przez skwantowany jump server z MFA, nagrywaniem sesji i ograniczeniem czasowym. Większość incydentów w OT to nie zaawansowany atak 0-day, tylko przejęte dane dostępowe serwisanta.

4. Wirtualne łatanie (virtual patching)

Jeśli wiesz, że konkretne urządzenie ma podatność CVE-X, a IPS/ IDS lub firewall przemysłowy stoi przed nim – możesz wdrożyć regułę blokującą dokładnie ten wzorzec exploitu, nawet jeśli urządzenie nigdy nie dostanie patcha.

Co nie działa, choć brzmi rozsądnie:

• „Izolujemy air-gapem” – w 2025 roku prawdziwy air-gap prawie nie istnieje; zawsze jest jakiś modem, karta SIM technika, pendrive z updatem. Fałszywe poczucie bezpieczeństwa.
• „Zrobimy inwentaryzację i potem zdecydujemy” – inwentaryzacja OT to projekt na 6-18 miesięcy w średniej fabryce. Tymczasem ryzyko jest teraz.
• Skanery podatności klasy IT w sieci OT – skaner podatności IT odpytujący sterownik PLC może go zresetować lub zawiesić. To nie jest środowisko tolerujące agresywny skan.

Trudna prawda dla rozmówcy

Dawid Bednarczyk, Co-founder i OT/ICS Expert w KnowGuard: Największy problem to nie technologia – to brak widoczności. Większość organizacji przemysłowych nie wie, co dokładnie ma w sieci OT, jakie protokoły i jakie wersje firmware. Zabezpieczanie czegoś, czego nie widać, jest niemożliwe.

Dlatego kolejność kroków to: mapuj — segmentuj — monitoruj — kontroluj dostęp — i dopiero na tym fundamencie buduj kolejne warstwy. Wymiana sprzętu jest ostatecznym rozwiązaniem, ale nie musi być pierwszym.

NIS2 mówi o „odpowiednich i proporcjonalnych” środkach technicznych. Jak interpretować tę zasadę proporcjonalności w środowisku, w którym aktualizacja sterownika PLC może oznaczać przestój linii kosztujący setki tysięcy złotych?

Dawid Bednarczyk: To pytanie dotyka jednego z najbardziej bolesnych napięć w całej dyrektywie i szczerze mówiąc, legislatorzy nie dali nam tu precyzyjnej odpowiedzi. Dali nam zasadę, którą musimy sami zoperacjonalizować.

Dyrektywa celowo używa języka ocennego. „Odpowiednie i proporcjonalne” to nie przypadek redakcyjny — to świadomy wybór, który przenosi ciężar oceny na podmiot i jego specyficzny kontekst. To oznacza, że proporcjonalność jest zawsze relacją trzech zmiennych: prawdopodobieństwo incydentu x potencjalna szkoda z incydentu vs koszt i operacyjny wpływ środka zabezpieczającego.

Jeśli koszt środka przekracza ryzyko, które redukuje — środek jest nieproporcjonalny. I to jest obrona, którą można postawić przed organem nadzorczym.

Jak to udokumentować, żeby ta obrona działała?

Dawid Bednarczyk: Tu jest sedno praktyczne. Proporcjonalność to nie intuicja – to udokumentowany proces decyzyjny. Organ nadzorczy (w Polsce CERT w zależności od sektora) nie będzie oceniał wyniku, będzie oceniał metodologię.

Musimy mieć dokument, który pokazuje: znamy tę podatność w sterowniku X, oceniliśmy prawdopodobieństwo jej exploitacji w naszym środowisku jako niskie/średnie/wysokie z następujących powodów, oceniliśmy potencjalny wpływ jako Y. To nie może być intuicja inżyniera – musi być ustrukturyzowana metodologia, najlepiej zgodna z IEC 62443.

Analiza alternatyw kompensacyjnych to kolejna rzecz. Kluczowy element, często pomijany. Zanim napiszemy „nie możemy zaktualizować PLC”, musimy wykazać, że rozważyliśmy i wdrożyliśmy środki kompensacyjne – segmentację, monitoring, kontrolę dostępu – które redukują ryzyko do akceptowalnego poziomu mimo braku patcha. To jest właśnie proporcjonalność w praktyce: nie „nie robimy nic”, tylko „robimy to co możliwe bez zatrzymania produkcji”.

To jest ten moment, w którym ryzyko operacyjne spotyka się z ryzykiem compliance i ktoś musi podjąć świadomą decyzję.

Gdzie organizacje popełniają błąd?

Dawid Bednarczyk: Najczęstszy błąd to traktowanie proporcjonalności jako wymówki zamiast jako metodologii. „Nie możemy, bo kosztuje” bez dokumentacji to nie jest proporcjonalność — to jest zaniedbanie, które organ nadzorczy zakwalifikuje właśnie jako brak odpowiednich środków.

Drugi błąd to brak przeglądu w czasie. Decyzja o nieaktualizowaniu sterownika podjęta dziś, z udokumentowaną analizą ryzyka i środkami kompensacyjnymi, jest defensible. Ta sama decyzja za trzy lata, bez ponownej oceny, przy zmienionym krajobrazie zagrożeń – już nie jest.

Segmentacja IT/OT. Co trzeba wiedzieć

Segmentacja IT/OT to wciąż otwarty problem w wielu polskich zakładach. Od czego konkretnie powinien zacząć szef bezpieczeństwa, który dziś ma w praktyce „płaską” sieć łączącą biuro z halą produkcyjną?

Dawid Bednarczyk: To jest sytuacja, którą znam z rozmów z praktykami. Większość polskich zakładów produkcyjnych średniej wielkości jest dokładnie w tym miejscu. Płaska sieć, jedno VLAN albo wręcz zero segmentacji, drukarka biurowa w tej samej podsieci co sterownik linii produkcyjnej. To nie jest wyjątek.

Dobra wiadomość jest taka, że droga wyjścia z tego stanu jest powtarzalna. Zła — że wymaga najpierw zrobienia rzeczy, które nie wyglądają jak „bezpieczeństwo”, a wyglądają jak żmudna administracja. 

Inwentaryzacja zasobów to fundament, ale w OT spis nie kończy się na adresach IP. Jakimi narzędziami i metodami zbudować obraz tego, co i jak komunikuje się w warstwie produkcyjnej – bez ryzyka zakłócenia procesów?

Dawid Bednarczyk: Wspomniałem już o tym przy segmentacji, ale warto powiedzieć, że w OT jedyną bezpieczną metodą inwentaryzacji jest metoda pasywna. Cokolwiek aktywnie skanuje sieć – odpytuje urządzenia, wysyła pakiety diagnostyczne – stwarza ryzyko. Sterownik PLC sprzed 15 lat może zareagować na nieoczekiwany pakiet resetem albo zawieszeniem. To nie jest teoretyczne ryzyko, to się zdarza.

Dlatego narzędzia klasy OT-IDS – działają wyłącznie na kopii ruchu sieciowego. Nic nie wysyłają do sieci OT, tylko słuchają. W ciągu kilku dni od podłączenia budują automatycznie: inwentarz urządzeń z wersjami firmware i protokołami, mapę komunikacji pokazującą kto z kim rozmawia i w jakim rytmie, oraz baseline normalnego zachowania sieci, od którego odchylenia generują alerty.

To jest dokładnie ten obraz, którego potrzebujemy jako fundament pod segmentację i zarządzanie ryzykiem – i można go zbudować bez zatrzymania ani jednej maszyny.

Jasne zasady i terminy

Dyrektywa wprowadza twarde terminy zgłaszania incydentów: 24 godziny na wczesne ostrzeżenie, 72 godziny na pełne powiadomienie. Czy zespoły utrzymania ruchu w polskich zakładach są w ogóle zorganizowane tak, żeby odróżnić incydent cyber od klasycznej awarii sprzętowej i to zgłosić w terminie?

Maciej Ramotowski: Krótka odpowiedź: w zdecydowanej większości polskich zakładów — nie. Automatycy i mechanicy często jako pierwsi widzą, że coś jest nie tak. Mają doskonałą intuicję techniczną. Problem nie leży w ich kompetencjach. Problem leży w tym, że organizacja nie dała im narzędzi do zadania właściwego pytania: czy to awaria, czy incydent? To są dwie różne ścieżki postępowania z zupełnie innymi konsekwencjami prawnymi.

W większości zakładów OT, z którymi pracujemy, żadna z tych rzeczy nie istnieje w formalnej postaci. Są procedury awaryjne, są numery telefonów serwisowych, ale nie ma procedury incydentowej w rozumieniu UKSC.

Jak powinno to wyglądać w praktyce? Przede wszystkim organizacja potrzebuje jasno zdefiniowanej ścieżki decyzyjnej — prostej i działającej pod presją czasu. Operator lub automatyk, który widzi anomalię, musi wiedzieć dokładnie trzy rzeczy: komu to zgłasza, w jakim czasie, i co tamta osoba robi dalej. To nie jest skomplikowane — ale musi być zapisane, przećwiczone i znane wszystkim zanim coś się wydarzy.

Drugi element to kryteria klasyfikacji, czyli lista pytań, które pozwalają odróżnić awarię od incydentu. Czy problem dotyczy tylko jednego urządzenia czy wielu jednocześnie? Czy pojawiły się nieoczekiwane zmiany w konfiguracji? Czy dostęp zdalny był aktywny w nieoczekiwanym czasie? To nie są pytania techniczne – to pytania operacyjne, które może zadać każdy przeszkolony pracownik. Odpowiedzi na nie uruchamiają albo ścieżkę serwisową, albo ścieżkę incydentową.

Trzeci element to wyznaczona osoba — nie dział, nie zespół, konkretna osoba — która ma umocowanie do podjęcia decyzji o zgłoszeniu incydentu do CSIRT. W małych i średnich firmach często będzie to ten sam człowiek co COSO lub osoba wyznaczona przez zarząd. Ważne jest żeby ta rola była nazwana, żeby osoba wiedziała że ją pełni i żeby miała gotowy kontakt do właściwego CSIRT sektorowego.

Te trzy elementy, które własnie opisałem — ścieżka decyzyjna, kryteria klasyfikacji, wyznaczona osoba — to nie jest rocket science. To jest kwestia dobrze napisanych polityk i procedur, skrojonych bezpośrednio pod konkretną organizację i jej środowisko OT. Nie generycznych szablonów, nie dokumentów przekopiowanych z sektora IT — tylko procedur które odzwierciedlają realne procesy, realne role i realne systemy w danym zakładzie. I tu jest clou: sama dokumentacja to dopiero połowa drogi. Procedura która leży w szufladzie nie ochroni nikogo. Żeby działała pod presją czasu — a incydent zawsze pojawia się w złym momencie – musi być przećwiczona. Regularnie, cyklicznie, z udziałem wszystkich poziomów organizacji: od operatora przy maszynie, przez osobę decyzyjną, po zarząd który musi wiedzieć że takie ćwiczenia w ogóle się odbywają i jaki jest ich wynik. Ćwiczenia to nie koszt — to jedyny sposób żeby sprawdzić czy procedura działa zanim sprawdzi to atakujący.

I tu jest ważna rzecz, którą często pomija się w dyskusji o gotowości technicznej: obowiązek zapewnienia tych procedur i tej ścieżki eskalacji leży po stronie kierownictwa. UKSC wprost przypisuje odpowiedzialność za wdrożenie systemu zarządzania bezpieczeństwem zarządowi – nie technikom. To zarząd odpowiada za to, czy organizacja jest w stanie zareagować w terminie. Brak procedury to nie jest problem automatyka — to jest problem prezesa.

Standard IEC 62443 bywa wskazywany jako naturalny kompas dla zgodności z NIS2 w OT. Które jego elementy w praktyce najbardziej „domykają” wymogi dyrektywy, a co – mimo wdrożenia 62443 – i tak trzeba zaadresować osobno?

Dawid Bednarczyk: To bardzo dobre pytanie, bo w debacie compliance panuje tendencja do traktowania IEC 62443 jako gotowej odpowiedzi na NIS2 w kontekście OT. Rzeczywistość jest bardziej złożona.

Zdalny dostęp do systemów OT to dziś codzienność: serwisanci, integratorzy, dostawcy maszyn. Jak projektować ten dostęp, żeby nie był jednocześnie najszerszą bramą wjazdową dla atakujących?

Dawid Bednarczyk: To jest obszar, gdzie przepaść między tym jak dostęp zdalny wygląda w dokumentacji a jak wygląda w rzeczywistości jest największa ze wszystkich tematów, o których rozmawiamy.

Rzeczywistość w polskich zakładach jest taka: serwisant przyjeżdża, prosi o hasło do VPN, dostaje to samo hasło co poprzedni serwisant rok temu, łączy się swoim laptopem na którym ma zainstalowane narzędzia do obsługi pięciu innych klientów, robi co ma zrobić i wychodzi. Hasło zostaje. Dostęp zostaje. Nikt nie wie co dokładnie zrobił.

To nie jest hipoteza, tylko opis standardowej procedury w większości zakładów, które nie przeszły świadomego projektowania dostępu zdalnego.

Fundamentalna jest zmiana myślenia: dostęp jako wyjątek, nie jako usługa?

Dawid Bednarczyk: Pierwsza i najważniejsza zmiana jest koncepcyjna. Dostęp zdalny do OT nie powinien być czymś co „jest włączone” i z czego serwisant korzysta kiedy potrzebuje. Powinien być czymś co jest tworzone na żądanie i likwidowane po zakończeniu sesji.

To jest filozofia Just-in-Time access – dostęp istnieje przez konkretne okno czasowe, dla konkretnej osoby, do konkretnego urządzenia, w konkretnym celu. Poza tym oknem — nie ma nic do przejęcia, bo nie ma nic co istnieje.

NIS2 wprowadza osobistą odpowiedzialność członków zarządu za nadzór nad cyberbezpieczeństwem. Jak rozmawiać z prezesem lub dyrektorem operacyjnym o ryzyku OT, żeby decyzje budżetowe zapadały zanim dojdzie do incydentu — a nie po nim?

Maciej Ramotowski: Nie rozmawiać o cyberbezpieczeństwie. Rozmawiać o ciągłości biznesu.

Zacznę od tego, co zarząd rozumie najlepiej: co się stanie z firmą, jeśli produkcja stanie. Kiedy ryzyko ma konkretną kwotę, przestaje być abstrakcją a staje się pozycją w analizie ryzyka biznesowego. Dlatego zamiast mówić „możemy mieć ransomware”, mówię:

• Ile kosztują trzy doby przestoju tej konkretnej linii produkcyjnej,
• Jakie są potencjalne kary administracyjne wynikające z UKSC – do 10 mln euro dla podmiotów kluczowych lub 2% globalnego obrotu,
• Jakie roszczenia kontrahentów mogą wyniknąć z niewykonania umów w terminie.

To zdanie, powiedziane spokojnie przy kawie, otwiera zupełnie inne drzwi niż prezentacja o wektorach ataku.

Więc jak rozmawiać z prezesem czy dyrektorem? Nie przychodź do zarządu z problemem, przychodź z opcjami. „Możemy zrobić A za X złotych, B za Y złotych, albo nie robić nic — wtedy świadomie akceptujemy ryzyko: straty operacyjne z przestoju, utratę reputacji wobec klientów i partnerów, roszczenia kontrahentów z tytułu niewykonania umów oraz osobistą odpowiedzialność finansową prezesa.”

Zarząd jest od podejmowania decyzji — daj im decyzję do podjęcia, nie wykład do wysłuchania. Na koniec dodaję jedno zdanie, które zamyka dyskusję: to nie jest kwestia wyboru. Jeśli firma podlega pod UKSC – wdrożenie wymagań jest obowiązkiem prawnym, nie opcją. Pytanie brzmi tylko: czy robimy to teraz, z głową i budżetem, czy za dwa lata pod presją kontroli i kar.

NIS2 a łańcuchy dostaw

Łańcuch dostaw to obszar, na który dyrektywa kładzie szczególny nacisk. Co realnie powinno znaleźć się w umowach z integratorami systemów sterowania i dostawcami maszyn, żeby firma nie stała się zakładnikiem ich poziomu bezpieczeństwa?

Maciej Ramotowski: Zacznę od samego słowa „zakładnik” bo ono bardzo trafnie opisuje dwa różne, ale równie groźne scenariusze. Zakładnikiem integratora staje się firma, która nie ma dostępu do własnej dokumentacji technicznej systemu, której integrator jest jedyną osobą znającą architekturę i hasła dostępowe, i która nie może zlecić nikomu innemu ani audytu, ani serwisu. Zakładnikiem dostawcy maszyn staje się firma, która kupiła urządzenie bez jakichkolwiek gwarancji dotyczących jego bezpieczeństwa cybernetycznego, bez wiedzy o tym co jest w środku i bez możliwości wymuszenia aktualizacji gdy pojawi się krytyczna podatność. W obu przypadkach warunki wstępne są podobne: pełna dokumentacja techniczna przekazana kupującemu, jasno określone zasady dostępu i prawo do zmiany lub weryfikacji dostawcy bez blokady z jego strony. Bez tego żadna klauzula bezpieczeństwa nie ma sensu.

Kwestie specyficzne dla integratorów – w umowie lub przed jej podpisaniem:

• Prawo do audytu – cykliczne, nie jednorazowe – integrator musi podlegać regularnej weryfikacji poziomu bezpieczeństwa, z określonymi konsekwencjami za niespełnienie wymagań. Audyt bez sankcji jest deklaracją, nie narzędziem.
• Zarządzanie podatnościami przez cały cykl życia – integrator, który wdrożył system i zniknął, zostawia firmę z niezałatanymi lukami przez kolejne 15 lat. Umowa musi określać, kto i w jakim trybie testuje i zatwierdza aktualizacje bezpieczeństwa.
• SBOM (lista wszystkich komponentów oprogramowania) – bez niej firma nie wie nawet, czy nowa krytyczna podatność jej dotyczy.

Kwestie specyficzne dla dostawców maszyn – przed podpisaniem umowy lub przy odbiorze:

• Weryfikacja bezpieczeństwa przed zakupem – UKSC wymaga oceny dostawcy już na etapie procesu zakupowego, zanim maszyna wjedzie na halę. To nie jest formalność po fakcie, to warunek wstępny zakupu.
• Testy odbiorcze bezpieczeństwa – nowy sprzęt powinien przejść weryfikację bezpieczeństwa przed podłączeniem do sieci OT. Maszyna z certyfikatem CE może zawierać podatności w oprogramowaniu sterownika, o których nie wie ani kupujący, ani dostawca – bo dziś CE nie obejmuje cyberbezpieczeństwa. To zmieni się dopiero od stycznia 2027 roku.
• Dostawcy wysokiego ryzyka – UKSC wprowadza możliwość identyfikacji dostawców uznanych za ryzykownych z perspektywy bezpieczeństwa narodowego, co może skutkować obowiązkiem wycofania ich komponentów z infrastruktury. To ryzyko zakupowe, które należy ocenić zanim podpisze się kontrakt.

Kwestie wspólne dla integratorów i dostawców maszyn – w każdej umowie:

• Obowiązek raportowania incydentów z konkretnym terminem – dostawca musi powiadomić firmę wystarczająco wcześnie, żeby ta zdążyła zgłosić incydent do CSIRT w ustawowym terminie 24/72 godzin wymaganym przez UKSC.
• Kontrola dostępu zdalnego – każdy dostęp serwisowy musi być uwierzytelniony wieloskładnikowo i logowany w sposób, którego dostawca sam nie może modyfikować, bez nieudokumentowanych kont – pod rygorem kar umownych.
• Plany odtwarzania z określonym RTO (maksymalny dopuszczalny czas przywrócenia systemu). „Przywrócimy jak będziemy mogli” to w OT nie jest odpowiedź. W IT może tak.

Branżowym punktem odniesienia dla wszystkich tych wymagań jest standard IEC 62443 – nie wymagany wprost przez UKSC, ale de facto minimum, którego należy oczekiwać od dojrzałego partnera w środowisku OT.

Firmy objęte UKSC, które współpracują z ekspertami OT takimi jak KnowGuard, otrzymują kompletną dokumentację polityk i procedur dotyczących dostawców. Dobre polityki i procedury są podstawą do napisania dobrej umowy – bo wiemy o co pytać i czego wymagać, zarówno od integratora, jak i od dostawcy maszyny. Według określonych procedur oceniamy ryzyko dostawcy, następnie przeprowadzamy proces akceptacji, zanim jakakolwiek umowa wejdzie w życie. Minimalizuje to ryzyko uzależnienia już na etapie kontraktowania, a nie dopiero gdy coś pójdzie nie tak.

Jakie wektory ataków na środowiska OT obserwujesz w polskich realiach w ostatnich 12-18 miesiącach? Co się zmieniło i czy widać już efekty kampanii grup APT wymierzonych w infrastrukturę przemysłową w naszym regionie?

Dawid Bednarczyk: Dane są jednoznaczne — i potwierdzają że od połowy 2024 roku mamy w Polsce jakościową zmianę, nie tylko ilościową.

Liczba incydentów naruszenia bezpieczeństwa wzrosła o 60% rok do roku, a ataki o poważnym charakterze – o 57%. Ale sama statystyka nie oddaje tego, co naprawdę się zmieniło.

Wcześniej dominowały ataki DDoS i ransomware celujący w warstwę IT – kosztowne, ale niedotykające fizycznych procesów. Teraz atakujący docierają do systemów sterowania. Cyberprzestępcom udało się manipulować parametrami ciepłowni w Rucianem-Nidzie. W Witkowie odnotowano manipulacje przy przepompowniach wodociągowych. W grudniu 2025 CERT wydał raport o cyberataku wymierzonym w co najmniej 30 farm wiatrowych i fotowoltaicznych, spółkę prywatną z sektora produkcyjnego oraz w dużą elektrociepłownię dostarczającą ciepło dla prawie pół miliona odbiorców w Polsce.

Jesteśmy na froncie — i to dosłownie.

Gdybyś miał wskazać trzy działania, które polska firma produkcyjna powinna wykonać w ciągu najbliższych sześciu miesięcy, żeby faktycznie — a nie tylko papierowo — zbliżyć się do zgodności z NIS2 w warstwie OT, co znalazłoby się na tej liście?

Maciej Ramotowski: Sześć miesięcy to realistyczny horyzont, żeby zrobić trzy rzeczy porządnie. Nie wszystko naraz, nie na papierze – ale trzy konkretne kroki, które budują realną odporność.

Krok pierwszy: audyt zerowy. Zanim firma wyda złotówkę na technologię lub dokumentację, musi wiedzieć co ma. Nie w sensie inwentarza IT – w sensie pełnego obrazu środowiska OT: jakie systemy sterowania są w sieci, jakie protokoły komunikują się z czym, gdzie są połączenia między OT a IT, kto ma zdalny dostęp i na jakich zasadach. W większości firm, z którymi pracujemy, ten obraz nie istnieje w żadnej formalnej postaci. Audyt zerowy odpowiada na pytanie „gdzie jesteśmy” – i bez tej odpowiedzi każde kolejne działanie jest strzelaniem na oślep. To jest też punkt wyjścia do samoidentyfikacji wymaganej przez UKSC – bo żeby ocenić czy i jako jaki podmiot firma podlega pod ustawę, musi najpierw rozumieć swoją własną infrastrukturę.

Krok drugi: wdrożenie polityk i procedur. Gdy wiemy co mamy, wiemy czego chronić i w jaki sposób. Polityki i procedury to nie są dokumenty do szuflady – to operacyjny szkielet systemu zarządzania bezpieczeństwem, którego wymaga UKSC. Obejmują one zarządzanie ryzykiem, obsługę incydentów, zarządzanie dostępem, bezpieczeństwo łańcucha dostaw i ciągłość działania. Kluczowe jest tu słowo „realne” – dokumentacja musi być napisana pod konkretne środowisko OT firmy, nie przekopiowana z szablonu IT. To jest różnica między zgodnością papierową a zgodnością operacyjną. KnowGuard realizuje ten krok kompleksowo – od analizy wyników audytu zerowego, przez opracowanie pełnego zestawu dokumentacji, po jej wdrożenie w organizacji.

Krok trzeci: szkolenie – na każdym poziomie. I tu jest element, który firmy najczęściej pomijają lub traktują jako punkt do odhaczenia: UKSC nakłada obowiązek szkoleń nie tylko na specjalistów technicznych, ale wprost na kierownictwo. Zarząd musi przejść oddzielne szkolenie, które pozwoli mu świadomie nadzorować realizację obowiązków z zakresu cyberbezpieczeństwa – bo odpowiedzialność za nadzór spoczywa personalnie na prezesie, nie na dziale IT. Równolegle – operatorzy, automatycy i pracownicy utrzymania ruchu muszą wiedzieć jak rozpoznać incydent cyber i jak go eskalować. To trzy różne szkolenia, trzy różne grupy odbiorców, jeden cel: organizacja która reaguje spójnie gdy coś się dzieje. KnowGuard prowadzi szkolenia na wszystkich tych poziomach – od świadomości cybernetycznej dla zespołów OT, po dedykowane warsztaty dla zarządu.

Trzy kroki, sześć miesięcy – i firma przechodzi od stanu „nie wiemy co mamy i co nas obowiązuje” do stanu „mamy obraz, mamy dokumentację i mamy ludzi którzy wiedzą co robić.” To nie jest pełna zgodność z UKSC – ale to jest realna, solidna podstawa. A realna podstawa jest warta więcej niż sto stron dokumentów, których nikt nie czyta.

— Rozmawiał Grzegorz Kubera