Dwudziestego dziewiątego grudnia 2025 roku, około wpół do szóstej rano, w elektrociepłowni dostarczającej ciepło pięćdziesięciu tysiącom mieszkańców zatrzymała się turbina parowa. Kilka chwil później stanęła stacja uzdatniania wody do celów technicznych. Kogeneracja, czyli skojarzone wytwarzanie energii elektrycznej i cieplnej, została przerwana. Na terenie zakładu akurat pracował podwykonawca — trwały prace utrzymaniowe. Wyjaśnienie nasunęło się samo i było całkowicie rozsądne: ktoś z ekipy serwisowej musiał coś przestawić.

Obsługa zareagowała szybko i sprawnie. Sterowniki, które sprawiały problemy, przywrócono do ustawień fabrycznych, wgrano w nie oprogramowanie z kopii bezpieczeństwa i procesy technologiczne ruszyły ponownie. Odbiorcy nie odczuli niczego — nie było przerwy w dostawie ciepła. Zdarzenie zostało jednak zgłoszone do CERT Polska, i to jest w całej tej historii moment przełomowy. Bez tego zgłoszenia sprawa zamknęłaby się w wewnętrznej notatce o pomyłce podwykonawcy.

Ósmego sierpnia 2026 roku CERT Polska opublikował raport uzupełniający do styczniowej analizy grudniowych ataków na polską energetykę. Śledztwo trwało ponad trzy miesiące. Wynik: to nie była pomyłka serwisanta. To był atak, a wektor wejścia do sieci przemysłowej elektrociepłowni nie został wcześniej udokumentowany nigdzie na świecie. Szczegóły przedstawił Marcin Dudek, kierownik CERT Polska, podczas konferencji DEF CON w Las Vegas.

Sterowniki w trybie STOP, zabezpieczone hasłem

Grudniowa fala była skoordynowana. W pierwotnym raporcie ze stycznia 2026 roku CERT Polska opisał ataki na co najmniej trzydzieści farm wiatrowych i fotowoltaicznych, na prywatną spółkę z sektora produkcyjnego oraz na dużą elektrociepłownię obsługującą blisko pół miliona odbiorców. Ta duża elektrociepłownia obroniła się. Farmy, mimo uszkodzonych urządzeń kontrolnych, nadal generowały prąd. Cel napastników był wyłącznie destrukcyjny — CERT Polska porównał te działania do celowych podpaleń — ale skutek pozostał uciążliwy, nie katastrofalny.

Raport sierpniowy dokłada do tej układanki element, którego wcześniej publicznie nie opisywano: drugą, mniejszą elektrociepłownię, w której napastnikom rzeczywiście udało się zatrzymać proces technologiczny. Przebieg ostatniej fazy ataku był brutalnie prosty. Około 5:30 sprawcy połączyli się przez wcześniej przygotowane tunele SSH z siecią zakładu i dostali się do sterowników Siemens S7-300, S7-1200 oraz S7-1500. Przełączyli je w tryb STOP i zabezpieczyli hasłem. To wszystko. Żadnego szyfrowania, żadnego okupu, żadnego złośliwego oprogramowania w klasycznym rozumieniu — po prostu wykorzystanie funkcji, które sterownik przemysłowy udostępnia projektantowi instalacji.

W kolejnym kroku, dokładnie tak jak wcześniej na farmach, napastnicy zmienili konfigurację siedmiu serwerów portów szeregowych i trzech przełączników sieciowych Moxa. Urządzenia zresetowano do ustawień fabrycznych, zmieniono ich adresy IP i hasła — po to, by utrudnić obsłudze odzyskanie kontroli. Łączyli się także do przemienników częstotliwości ABB serii ACS, choć nie wiadomo, co zamierzali z nimi zrobić. Do przemienników Schneider Electric ATV6xx dostać im się nie udało, ponieważ szukali panelu sterującego na porcie 80, a ten był wystawiony gdzie indziej. Ten drobiazg wart jest zapamiętania: część infrastruktury ocalała nie dzięki zabezpieczeniu, lecz dzięki niestandardowej konfiguracji, o której napastnicy nie wiedzieli.

Prywatny APN, czyli sieć, która tylko nazywa się prywatna

Najważniejsze pytanie brzmiało, jak w ogóle znaleźli się w środku. Odpowiedź okazała się nowa — i to nie tylko w skali Polski.

Sprawcy byli już w sieci farm wiatrowych i szukali możliwości poszerzenia dostępu. Znaleźli tam routery komórkowe z kartami SIM, podłączone do prywatnego APN — wydzielonej bramy sieciowej operatora telekomunikacyjnego, zarządzanej przez operatora systemu dystrybucyjnego. Prywatny APN to rozwiązanie stosowane w energetyce od lat i traktowane jako oczywiście bezpieczne. Karta SIM nie łączy się z internetem, tylko z zamkniętą siecią wirtualną, w której rozmawiają ze sobą system SCADA i sterowniki RTU rozsiane po obiektach. Zgodnie z wymaganiami operatora dystrybucyjnego komunikacja miała się odbywać wyłącznie protokołem szeregowym DNP3.0.

Problem polegał na tym, że wewnątrz tego APN można było nawiązywać połączenia pomiędzy dowolnymi urządzeniami. Sieć była prywatna względem internetu, ale całkowicie płaska od środka. Każdy, kto zdobył dostęp do jednego urządzenia w APN, uzyskiwał widoczność wszystkich pozostałych — w tym urządzeń należących do zupełnie innego podmiotu, w zupełnie innym mieście.

To właśnie ten fragment raportu powinien zapalić czerwoną lampkę w każdej spółce ciepłowniczej i wodociągowej w Polsce. CERT Polska nie poprzestał bowiem na analizie jednego przypadku: przeprowadził ankiety w podmiotach korzystających z tego typu rozwiązań. Wniosek jest jednoznaczny — taka konfiguracja była w Polsce często spotykana, a według wiedzy zespołu jest też powszechnie stosowana w innych krajach. Innymi słowy, opisany scenariusz nie jest ciekawostką z jednego zakładu, tylko modelem, który da się powtórzyć w dziesiątkach miejsc. Dlatego raport kończy się rekomendacjami adresowanymi wprost do wszystkich użytkowników prywatnych APN.

Router, którego nie objęły wymagania operatora

Wejściem do APN był router Teltonika RUTX50 zainstalowany w jednej z farm wiatrowych. Miał dwa interfejsy: łącze szeregowe, do którego podpięto sterownik RTU, oraz łącze Ethernet podłączone do VLAN-u. Hasło do jego panelu administracyjnego — dostępnego przez WWW i SSH — zostało zmienione z domyślnego. To ważne, bo pokazuje, że ktoś w tym zakładzie odrobił podstawową lekcję higieny. A mimo to napastnicy się do niego dostali. Sposobu, w jaki pokonali hasło, nie udało się ustalić. Udało się natomiast wydobyć z urządzenia logi wskazujące na połączenia włamywaczy i na wykorzystanie routera do tunelowania ruchu SSH w głąb sieci APN.

Tu dochodzimy do sedna, które ma wymiar znacznie bardziej kontraktowy niż techniczny. Wymagania operatora systemu dystrybucyjnego opisywały precyzyjnie, jak ma wyglądać komunikacja użytkowa: tylko DNP3.0, tylko przez łącze szeregowe. Nie obejmowały natomiast interfejsu administracyjnego routera komórkowego. Nikt nie napisał, że panel zarządzania nie ma prawa być osiągalny z sieci APN, że dostęp administracyjny wymaga drugiego składnika uwierzytelnienia, że logowania mają być zbierane centralnie. Reguła opisywała ruch produkcyjny i milczała o kanale, którym się tym ruchem zarządza.

To jest najczęstsza luka, jaką widzimy w dokumentacji bezpieczeństwa w sektorze utilities: wymaganie dotyczy protokołu, a nie urządzenia. Norma ISO/IEC 27001:2022 adresuje ten problem wprost w zabezpieczeniu A.8.20, dotyczącym bezpieczeństwa sieci, oraz A.8.22, które nakazuje separację sieci — nie tylko na styku ze światem zewnętrznym, ale również wewnątrz. Rodzina IEC 62443 nazywa to jeszcze precyzyjniej: strefy i kanały. Jeżeli farma wiatrowa i elektrociepłownia znajdują się w tej samej strefie tylko dlatego, że korzystają z tego samego APN, to nie mamy segmentacji, mamy jedną wielką sieć zakładową rozciągniętą na kilkaset kilometrów.

Domyślne hasło w miejscu, do którego „nikt nie ma dostępu"

Od osiemnastego grudnia sprawcy systematycznie skanowali sieć APN, szukając usług VNC, HTTP, S7 i Modbus. Znaleźli sterownik WAGO PFC200 z interfejsem WWW wystawionym do APN i — to nie jest literówka — z domyślnym hasłem konta „admin". Sterownik nie był dostępny z internetu. Żeby go zobaczyć, trzeba było najpierw dostać się do prywatnej sieci operatora. I dokładnie na tym założeniu opierał się cały model zaufania: skoro z zewnątrz nikt tu nie wejdzie, hasło nie ma znaczenia.

Domyślnie urządzenie nie udostępniało SSH. Napastnicy zalogowali się przez przeglądarkę i sami włączyli sobie tę usługę. Sterownik miał dostęp do systemów sterowania przemysłowego elektrociepłowni, więc od tego momentu wystarczyło zestawić tunel. Przez ten tunel przeszukali sieć zakładu w poszukiwaniu usług S7 na porcie 102, Modbus na 502, CODESYS na 11740, a także monitoringu RTSP na 554, zdalnego pulpitu i interfejsów webowych. Zlokalizowali urządzenia, które trzy dni później próbowali wyłączyć i uszkodzić.

Warto zatrzymać się nad tym, jak wygląda ta ścieżka z perspektywy audytora. Punktem wejścia było urządzenie brzegowe innego podmiotu. Punktem przesiadkowym — sterownik z hasłem, którego nie zmieniono, bo stał w miejscu uznanym za niedostępne. Punktem docelowym — sterowniki odpowiadające za turbinę. Żaden z tych trzech kroków nie wymagał podatności typu zero-day, złośliwego kodu ani wyrafinowanej socjotechniki. Wymagał cierpliwości i jedenastu dni skanowania sieci, w której nikt nie monitorował ruchu, bo teoretycznie nie miało w niej być niczego poza DNP3.0.

Awaria, którą zapisano na konto podwykonawcy

Najbardziej pouczający fragment tej historii nie dotyczy techniki. Dotyczy tego, jak organizacja interpretuje własne zdarzenia.

Turbina stanęła w momencie, w którym na terenie zakładu pracował zewnętrzny wykonawca. Zbieg okoliczności był na tyle wygodny, że hipoteza o ludzkim błędzie serwisanta wydała się oczywista. To zachowanie całkowicie naturalne — w utrzymaniu ruchu pierwsza hipoteza prawie zawsze brzmi „ktoś czegoś dotknął", bo w dziewięciu przypadkach na dziesięć jest prawdziwa. Kłopot polega na tym, że dziesiąty przypadek wygląda dokładnie tak samo.

Z punktu widzenia systemu zarządzania bezpieczeństwem informacji to jest klasyczna porażka etapu klasyfikacji zdarzenia. Norma ISO/IEC 27001:2022 w zabezpieczeniach A.5.24 i A.5.25 wymaga zaplanowania reakcji na incydenty oraz oceny i podjęcia decyzji o zdarzeniach związanych z bezpieczeństwem informacji. Kluczowe słowo brzmi „ocena". Jeżeli w procedurze nie ma progu, który każe potraktować nieoczekiwane zatrzymanie procesu technologicznego jako potencjalny incydent bezpieczeństwa — a nie wyłącznie jako awarię — to organizacja nigdy nie dojdzie do właściwych wniosków, bo nigdy nie zada właściwego pytania.

Konsekwencja praktyczna jest prosta i da się ją wdrożyć w każdym zakładzie w dwa tygodnie. Nieplanowane przejście sterownika w tryb STOP, nieoczekiwana zmiana adresacji urządzenia sieciowego, reset konfiguracji przełącznika czy przemiennika częstotliwości — każde z tych zdarzeń powinno automatycznie uruchamiać ścieżkę dwutorową: utrzymanie ruchu przywraca produkcję, a równolegle ktoś zabezpiecza logi i weryfikuje hipotezę o działaniu zewnętrznym. Nie odwrotnie, nie po kolei.

Reset do ustawień fabrycznych i cena szybkiego powrotu

Obsługa elektrociepłowni zachowała się racjonalnie i skutecznie. Przywróciła sterowniki do ustawień fabrycznych, wgrała oprogramowanie z kopii bezpieczeństwa i uruchomiła procesy. Ciepło popłynęło dalej, mieszkańcy nie odczuli niczego. Z perspektywy ciągłości działania to jest podręcznikowy sukces: kopie były aktualne, personel wiedział, co robić, czas przestoju liczono w minutach, nie w dniach.

Ta sama operacja usunęła jednak ślady włamania.

Mamy tu autentyczny konflikt dwóch dobrze uzasadnionych celów. Norma ISO 22301 i logika zarządzania ciągłością działania każą przywrócić usługę w założonym czasie odtworzenia. Zabezpieczenie A.5.28 w ISO/IEC 27001:2022, dotyczące zbierania materiału dowodowego, każe zachować stan urządzenia do czasu analizy. W ogniu zdarzenia, o piątej trzydzieści rano, przy temperaturze zewnętrznej typowej dla końca grudnia, wygrywa ciągłość — i słusznie. Ale to nie znaczy, że dowody trzeba stracić.

Rozstrzygnięciem nie jest wybór między jednym a drugim, tylko procedura, która pozwala zrobić obie rzeczy naraz. Zrzut konfiguracji przed resetem, eksport logów z urządzenia i z przełącznika, fotografia ekranu z komunikatem błędu, zapisanie dokładnego czasu zdarzenia z zegara systemowego, a jeżeli sprzęt jest wymienialny — odłożenie oryginalnego urządzenia i uruchomienie zapasowego zamiast czyszczenia tego, które padło ofiarą. Każda z tych czynności zajmuje minuty i nie opóźnia odtworzenia produkcji w sposób odczuwalny. Warunkiem jest to, żeby były opisane w instrukcji wiszącej w dyspozytorni, a nie odkrywane pod presją.

Napastnicy dobrze rozumieli wartość tego materiału. W sterowniku WAGO PFC200, przez który wchodzili do sieci ofiary, uszkodzili tablicę partycji tak skutecznie, że nie powiodły się nawet profesjonalne, laboratoryjne próby odzyskania danych. Router komórkowy również przywrócili do ustawień fabrycznych — z niego jednak logi udało się odzyskać, i to one pozwoliły odtworzyć całą ścieżkę. Cały ten raport istnieje dlatego, że jedno urządzenie nie zostało wyczyszczone dość dokładnie.

Kto to zrobił i dlaczego atrybucja zmienia kalkulację

Analiza infrastruktury użytej w ataku wskazuje, że w znacznym stopniu pokrywa się ona z zapleczem klastra aktywności znanego publicznie pod nazwami Static Tundra w nomenklaturze Cisco, Berserk Bear u CrowdStrike, Ghost Blizzard u Microsoftu oraz Dragonfly w klasyfikacji Symanteca. To nie jest grupa przypadkowa i nie jest to grupa nastawiona na zysk. To aktor od lat kojarzony z długoterminowym rozpoznaniem i przygotowywaniem dostępu w infrastrukturze energetycznej państw zachodnich.

Ta atrybucja zmienia sposób, w jaki należy czytać skutek. Gdyby motywem był okup, prezes spółki ciepłowniczej mógłby uczciwie policzyć ryzyko: ile kosztuje odtworzenie, ile kosztuje przestój, jakie jest prawdopodobieństwo. Przy przeciwniku, którego celem jest zniszczenie i którego nie interesuje monetyzacja, ten rachunek się nie domyka, bo po drugiej stronie nie ma nikogo, z kim można negocjować, i nie ma progu opłacalności, poniżej którego cel przestaje być atrakcyjny. Mała elektrociepłownia na pięćdziesiąt tysięcy mieszkańców nie została wybrana dlatego, że jest bogata. Została wybrana dlatego, że była osiągalna i że w środku grudnia dostarcza ciepło.

Ten sam wniosek płynął z prokuratorskiego wątku dotyczącego siedemnastu ataków na polskie obiekty wodociągowe, o którym pisaliśmy w sierpniu. Tam sprawcy również nie szukali pieniędzy, a zabezpieczenia, które by ich zatrzymały, były banalne. Powtarzalność tego wzorca to nie zbieg okoliczności, tylko opis obecnego krajobrazu zagrożeń dla polskiej infrastruktury komunalnej.

Ciepłownictwo w ustawie o KSC i zegar do 3 października

Warstwa regulacyjna tej sprawy jest równie konkretna jak techniczna. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS-2, weszła w życie 3 kwietnia 2026 roku. Energia jest sektorem z załącznika nr 1 — sektorem o wysokiej krytyczności — a systemy ciepłownicze i chłodnicze są w nim wymienione osobno. Operator systemu ciepłowniczego spełniający progi wielkości jest zatem podmiotem kluczowym, z pełnym katalogiem obowiązków.

Zegar tyka wyraźnie. Podmioty, które spełniały kryteria w dniu wejścia nowelizacji w życie, mają czas na złożenie wniosku o wpis do wykazu podmiotów kluczowych i ważnych do 3 października 2026 roku. To niecałe sześć tygodni od dziś. Samoidentyfikacja jest tu zasadą ustrojową: nikt nie przyśle spółce ciepłowniczej zawiadomienia, że podlega ustawie. Wniosek składa się w systemie S46, a uwierzytelnienie następuje przez Węzeł Krajowy. Kto nie złoży, nie przestaje podlegać obowiązkom — po prostu wchodzi w nie z formalnym zaniedbaniem na starcie.

Trzy elementy tego reżimu mają w kontekście grudniowego incydentu szczególną wagę. Po pierwsze, terminy zgłoszeniowe: wczesne ostrzeżenie w ciągu dwudziestu czterech godzin, zgłoszenie incydentu w ciągu siedemdziesięciu dwóch godzin i raport końcowy w ciągu miesiąca. Zdarzenie zakwalifikowane jako pomyłka podwykonawcy nie uruchamia żadnego z tych zegarów, a ustawa nie przewiduje okoliczności łagodzącej w postaci szczerego przekonania, że to była awaria. Po drugie, bezpieczeństwo łańcucha dostaw produktów, usług i procesów ICT — czyli dokładnie ta warstwa, w której zabrakło wymagania dotyczącego interfejsu administracyjnego routera i konfiguracji APN po stronie operatora. Po trzecie, osobista odpowiedzialność kierownika podmiotu, sięgająca trzystu procent jego wynagrodzenia. To ostatnie przenosi rozmowę o segmentacji sieci z pokoju informatyków do gabinetu prezesa i na posiedzenie rady nadzorczej, gdzie zresztą powinna się toczyć od dawna.

Czego ten raport uczy spółkę komunalną bez własnego SOC

Typowa polska spółka ciepłownicza obsługująca kilkadziesiąt tysięcy odbiorców nie ma centrum operacji bezpieczeństwa, nie ma analityka OT i nie będzie ich miała, bo nie ma z czego. To nie jest wymówka, tylko warunek brzegowy, w którym trzeba zaprojektować sensowną obronę. Dobra wiadomość jest taka, że ta konkretna ścieżka ataku dałaby się przerwać w kilku miejscach środkami, które nie wymagają ani nowego etatu, ani wielomilionowego projektu.

Pierwsze pytanie brzmi: czy w naszej sieci APN urządzenia mogą się widzieć nawzajem. Odpowiedź nie należy do nas, tylko do operatora, który tym APN zarządza — i właśnie dlatego trzeba je zadać na piśmie, a odpowiedź wpiąć do dokumentacji. Domyślnym stanem docelowym jest odrzucanie wszystkiego, co nie zostało jawnie dozwolone, oraz komunikacja wyłącznie w relacji SCADA–RTU, bez możliwości nawiązywania połączeń między urządzeniami końcowymi.

Drugie pytanie dotyczy inwentaryzacji. Ile mamy routerów komórkowych, sterowników, konwerterów i przełączników w sieci przemysłowej, kto je instalował, kiedy ostatnio zmieniano na nich hasła i czy któryś nadal chodzi na haśle z pudełka. Zabezpieczenie A.8.9 w ISO/IEC 27001:2022, dotyczące zarządzania konfiguracją, brzmi w tym kontekście mniej abstrakcyjnie: chodzi o listę, która istnieje i jest aktualna, a nie o wiedzę zamkniętą w głowie jednego automatyka.

Trzecia rzecz to interfejsy administracyjne. Panel WWW i SSH na urządzeniu brzegowym nie powinien być osiągalny z sieci technologicznej — powinien być dostępny wyłącznie z wydzielonego segmentu zarządzania, najlepiej przez host pośredniczący, z uwierzytelnieniem dwuskładnikowym i z logowaniem prób dostępu wysyłanym poza urządzenie. To jest jedna zmiana konfiguracyjna, która w opisywanym scenariuszu zatrzymałaby napastnika na pierwszym kroku.

Czwarta to monitoring, ale rozumiany oszczędnie. Nie chodzi o wdrożenie systemu klasy SIEM z korelacją w czasie rzeczywistym. Chodzi o to, żeby ktoś raz w tygodniu zobaczył, że w sieci, w której miał chodzić wyłącznie DNP3.0, ktoś od jedenastu dni skanuje porty 102, 502 i 11740. Zabezpieczenia A.8.15 i A.8.16, dotyczące rejestrowania zdarzeń i monitorowania działań, wymagają zbierania logów i ich przeglądania — samo zbieranie bez przeglądania nie jest zgodnością, tylko archiwum.

Piąta to ćwiczenie. Raz w roku, dwie godziny, przy stole: turbina staje o piątej trzydzieści, na terenie jest podwykonawca, panel sterownika prosi o hasło, którego nikt nie zna. Kto dzwoni do CERT Polska, kto zabezpiecza logi, kto podejmuje decyzję o resecie, kto liczy dwadzieścia cztery godziny do wczesnego ostrzeżenia i kto informuje zarząd. Organizacje, które przeprowadziły takie ćwiczenie, reagują inaczej niż te, które mają wyłącznie procedurę w segregatorze.

Dlaczego z Fib.Code

Pracujemy na styku trzech światów, które w polskiej infrastrukturze komunalnej rzadko się spotykają: prawa (ustawa o KSC, RODO, wymagania sektorowe), systemów zarządzania (ISO/IEC 27001, ISO 22301, KRI) oraz realiów technicznych sieci przemysłowych. Znamy specyfikę spółek ciepłowniczych, wodociągowych i gospodarki odpadami — wiemy, że dyspozytornia pracuje w ruchu ciągłym, że automatyk jest jeden, że budżet inwestycyjny na kolejny rok jest już podzielony i że rada nadzorcza pyta o taryfę, a nie o segmentację VLAN-ów.

Nasze podejście opiera się na trzech zasadach. Zaczynamy od tego, co da się zrobić bez wydawania pieniędzy — od inwentaryzacji, konfiguracji i pytań zadanych dostawcom na piśmie, bo w większości audytów to właśnie tam leży największa część ryzyka. Nie oddzielamy warstwy technicznej od dokumentacyjnej: analiza ryzyka, która nie kończy się zmianą w konfiguracji urządzenia, jest tylko papierem, a zmiana w konfiguracji bez zapisu w dokumentacji jest niemożliwa do udowodnienia przed kontrolą. I trzymamy się dowodu — wszystko, co uznajemy za wdrożone, musi mieć postać, którą da się położyć na stole przed organem nadzoru.

Produktem końcowym nie jest opasły raport. Jest nim lista wykonanych zmian, komplet dokumentacji systemu zarządzania bezpieczeństwem informacji odpowiadający wymaganiom ustawy o KSC, plan ciągłości działania przetestowany na scenariuszu z waszego zakładu oraz przeszkolony zespół, który wie, co robi o piątej trzydzieści rano.

Co zrobić w ten poniedziałek

Zwołajcie w poniedziałek jedno spotkanie na godzinę. Przy stole: prezes, osoba odpowiedzialna za utrzymanie ruchu, automatyk i informatyk. Zadajcie cztery pytania i zapiszcie odpowiedzi wraz z nazwiskiem osoby odpowiedzialnej i datą.

Czy złożyliśmy wniosek o wpis do wykazu podmiotów kluczowych i ważnych, a jeśli nie, to kto to zrobi przed 3 października 2026 roku. Czy w naszej sieci APN urządzenia mogą się widzieć nawzajem i czy mamy na to odpowiedź od operatora na piśmie. Czy istnieje aktualna lista urządzeń brzegowych w sieci technologicznej wraz z informacją, kiedy ostatnio zmieniano na nich hasła. Co dokładnie robi obsługa, gdy sterownik nieoczekiwanie przechodzi w tryb STOP — i czy w tej procedurze jest cokolwiek o zabezpieczeniu logów przed resetem.

Jeżeli na którekolwiek z tych pytań padnie odpowiedź „trzeba sprawdzić", macie właśnie gotowy plan pracy na wrzesień. Sześć tygodni to wystarczająco dużo, żeby domknąć wszystkie cztery.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: Bezpieczeństwo informacji w ciepłowni, Zarzuty dla Rosjan za ataki na polskie wodociągi, Samoidentyfikacja NIS-2 i wpis do wykazu, Nowelizacja KSC 2026 po 3 kwietnia oraz Zarządzanie incydentami bezpieczeństwa — jeden incydent, cztery warstwy obowiązków i jedno spotkanie, od którego wszystko się zaczyna.