Dziesięć prób logowania do panelu, który zarządza wodą dla całego miasta

Środa, 16 września 2026 roku, godzina 16:30. Portal CyberDefence24 publikuje krótką notatkę Oskara Klimczuka o Rejowcu Fabrycznym, miasteczku w powiecie chełmskim. Ktoś próbował dostać się do panelu administracyjnego systemu wodociągowego, z którego kierownik systemu może zdalnie sterować dystrybucją wody. Prób było dziesięć. Burmistrz Gabriel Adamiec, cytowany przez lokalny tygodnik „Super Tydzień Chełmski", mówił o serii nieautoryzowanych prób uzyskania dostępu do systemu sterowania miejskim ujęciem wody. Dostawy nie zostały zakłócone. Miasto zawiadomiło CERT Polska i zwiększyło fizyczny nadzór nad obiektami, między innymi przez nocne patrole.

Z perspektywy statystyki to zdarzenie jest niczym. Nie zakończyło się włamaniem, nie wyłączyło żadnej pompy, nie trafi do kategorii incydentu poważnego. Jest jednym z kilkudziesięciu tysięcy punktów, z których składa się wykres w rocznym raporcie. A jednak właśnie takie punkty warto oglądać pod lupą, bo opowiadają o rzeczywistości dokładniej niż sumy. Jeżeli ktoś z zewnątrz może w ogóle spróbować zalogować się do panelu wodociągów, to znaczy, że panel jest widoczny z internetu. A jeżeli jest widoczny, to jedynym, co dzieli miasto od przerwy w dostawie wody, jest jakość hasła i szczęście.

Tę historię trzeba mieć w głowie, kiedy otwiera się „Raport o stanie bezpieczeństwa cyberprzestrzeni RP w 2025 roku", który CSIRT GOV, zespół prowadzony przez szefa Agencji Bezpieczeństwa Wewnętrznego, upublicznił na początku jesieni. Spider's Web opisał go 3 września 2026 roku, a strona publikacji w serwisie CSIRT GOV nosi datę 13 października 2026 roku. Liczby są efektowne i media chętnie je cytują. Mało kto zadaje pytanie, co one mierzą i czego nie mierzą. Tymczasem od odpowiedzi na to pytanie zależy, czy burmistrz, wójt albo prezes spółki wodociągowej wyciągnie z raportu właściwe wnioski, czy tylko poczuje przelotny niepokój.

Co naprawdę mówi raport CSIRT GOV

Zacznijmy od suchych liczb, bo warto je znać dokładnie. W 2025 roku do CSIRT GOV wpłynęło 23 136 zgłoszeń potencjalnych incydentów. Rok wcześniej było ich 17 439, a w 2023 roku 19 888. Po weryfikacji 5033 z nich zakwalifikowano jako faktyczne incydenty bezpieczeństwa, wobec 3991 w 2024 roku i 4676 w 2023. To wzrost o około jedną czwartą rok do roku. Rozkład kwartalny pokazuje wyraźne przyspieszenie na końcu roku: w pierwszym kwartale było 4694 zgłoszeń, w drugim 5519, w trzecim 5464, a w czwartym aż 7459.

Największy skok odnotowała kategoria podatności. W 2025 roku zidentyfikowano ich 1879, rok wcześniej 1105, czyli o około siedemdziesiąt procent więcej. Raport sam tłumaczy ten wzrost: to głównie zasługa lepszej detekcji luk w usługach wystawionych do internetu, a nie nagłego pogorszenia jakości oprogramowania. W dalszej części dokumentu znajdziemy dane o atakach DDoS: 374 ataki wobec 348 w 2024 roku, przy czym wyraźny szczyt, 279 ataków, przypadł na drugi kwartał i miał związek z rozliczeniami podatkowymi. Średni czas trwania ataku wyniósł 84,5 minuty, czyli o ponad jedną piątą dłużej niż rok wcześniej.

CSIRT GOV wysłał w ciągu roku 772 ostrzeżenia, najczęściej z wskaźnikami kompromitacji generowanymi przez system ARAKIS GOV. Raport opisuje też bieżące kampanie rosyjskich i białoruskich grup, w tym APT28, Laundry Bear i UNC1151, oraz aktywność prorosyjskich haktywistów, takich jak NoName057(16). To obraz państwa, które jest stale sondowane, skanowane i testowane, a zarazem coraz lepiej to widzi. Drugi człon tego zdania jest równie ważny jak pierwszy.

Trzynaście incydentów poważnych i żaden atak: dlaczego ta liczba jest ważniejsza od 23 136

W całej tej lawinie liczb jedna zasługuje na szczególną uwagę. Spośród tysięcy zdarzeń trzynaście zostało zgłoszonych jako incydenty poważne w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa (KSC). I według raportu żaden z nich nie miał charakteru intencjonalnego ani nie był cyberatakiem. Były to awarie, błędy konfiguracji, zdarzenia techniczne i organizacyjne, które przekroczyły próg poważnego wpływu na świadczenie usługi.

Ten szczegół obala dwie popularne opowieści jednocześnie. Pierwsza głosi, że polska cyberprzestrzeń płonie, a każdy urząd jest o krok od katastrofy. Druga, odwrotna, że skoro poważnych incydentów jest tylko kilkanaście, to problem jest rozdmuchany. Prawda leży gdzie indziej. Próg poważnego incydentu w KSC jest zdefiniowany przez skutek dla usługi, a nie przez intencję napastnika. Kiedy zespół zarządzający systemem sam zepsuje konfigurację, a usługa przestanie działać na kilka godzin, to jest dokładnie ten rodzaj zdarzenia, który regulacja ma na myśli. Awaria własna kosztuje obywatela tyle samo, co atak z zewnątrz.

Dla samorządu i spółek komunalnych płynie z tego wniosek praktyczny. Obowiązek zgłaszania incydentów poważnych w reżimie KSC, w zgodzie z NIS2, to trzy kroki w czasie: wczesne ostrzeżenie w ciągu 24 godzin od wykrycia, zgłoszenie incydentu w ciągu 72 godzin i raport końcowy po miesiącu. Procedura ma zadziałać także wtedy, gdy nikt nie włamał się do sieci, a „tylko" wysypał się serwer, na którym stoi system rozliczeń wodnych albo elektroniczny obieg dokumentów. Organizacje, które mają w procedurach wyłącznie scenariusz „hakerzy zaszyfrowali dane", w dniu zwykłej, nudnej awarii nie będą wiedziały, kogo zawiadomić i w jakim terminie. O praktyce reagowania pisaliśmy szerzej w artykule o zarządzaniu incydentami bezpieczeństwa.

Siedemdziesiąt procent więcej podatności: skanery lepiej widzą, a Wy?

Wzrost liczby podatności z 1105 do 1879 łatwo przeczytać jako dowód, że oprogramowanie jest gorsze niż rok temu. To czytanie błędne. CSIRT GOV od kilku lat rozwija aktywne wyszukiwanie luk w zasobach wystawionych do internetu i w 2025 roku robił to skuteczniej. Ta sama poprawa detekcji, którą po stronie państwa nazywamy sukcesem, ma po stronie napastników swój odpowiednik: skanery, które odnajdują podatny serwer poczty, bramę VPN albo panel zarządzania, są dziś tanie, szybkie i dostępne dla każdego, kto potrafi zapłacić kilkaset złotych.

Raport w przeglądzie miesięcznym wymienia trzydzieści pięć identyfikatorów CVE z 2025 roku. Są wśród nich produkty, które w polskich urzędach i spółkach stoją na brzegu sieci od lat: Ivanti, Palo Alto, Fortinet, Cisco, NetScaler, Zimbra, Roundcube, Microsoft. Część luk była wykorzystywana jako zero-day, czyli zanim producent wydał łatkę. Osobny akapit raportu dotyczy oprogramowania, którego producent zakończył wsparcie, oraz łatek, które istnieją, ale nie zostały wdrożone. To jest ta część problemu, którą organizacja kontroluje w stu procentach.

Warto zadać sobie jedno pytanie, które w większości jednostek pozostaje bez odpowiedzi. Ile usług z naszej organizacji jest widocznych z internetu i kto je ostatnio sprawdzał? Nie chodzi o inwentarz z arkusza kalkulacyjnego, który prowadzi dział informatyki, tylko o rzeczywisty widok z zewnątrz. Zewnętrzny skan zajmuje kilka godzin, a wynik bywa nieprzyjemnym zaskoczeniem: zapomniany serwer testowy, brama VPN sprzed trzech lat, panel kamery z hasłem producenta. To są dokładnie te zasoby, które liczba 1879 próbuje opisać.

Gdzie w tych statystykach jest samorząd

Raport rozbija incydenty na typy podmiotów, które je zgłosiły. Na pierwszym miejscu znalazła się kategoria „instytucja" z 1032 incydentami, następnie ministerstwa z 889, operatorzy infrastruktury krytycznej z 830, organy państwowe z 825 i urzędy z 593. Pozostałe podmioty zgłosiły 523 incydenty, a służby 341. Raport nie wyodrębnia osobno jednostek samorządu terytorialnego, energetyki, wodociągów ani ochrony zdrowia, więc nie wolno z niego wyciągać liczb, których tam nie ma. To uczciwa granica tego dokumentu: CSIRT GOV obsługuje administrację publiczną i podmioty istotne dla funkcjonowania państwa, a nie cały rynek.

Granica ma jednak swoje konsekwencje. Jeżeli ktoś czyta, że „urzędy" zgłosiły 593 incydenty, i myśli, że to obraz polskiego samorządu, to myli się dwukrotnie. Po pierwsze, w Polsce jest blisko dwa i pół tysiąca gmin, a statystyka obejmuje tylko te zdarzenia, które do zespołu dotarły. Po drugie, zgłasza się tylko to, co się zauważyło. Mała gmina, w której informatyk jest jedną osobą na pół etatu i jednocześnie administratorem sieci, kopii zapasowych oraz drukarek, nie widzi większości tego, co dzieje się na jej brzegu sieci. Statystyka dobrze opisuje podmioty z działającym monitoringiem, a słabo te, które go nie mają. Prawdziwy obraz zagrożenia dla małych jednostek jest więc prawdopodobnie gorszy niż tabela, a nie lepszy.

Z drugiej strony ostatnie miesiące pokazały, co się dzieje, gdy zdarzenie jednak nie pozostaje niezauważone. W marcu 2026 roku ransomware sparaliżował urząd miasta w Myszkowie, a w kolejnych tygodniach kilka placówek medycznych, o czym pisaliśmy w analizie fali ransomware wiosną 2026 roku. To nie były trzy odosobnione wypadki, tylko zdarzenia o wspólnym mianowniku: zewnętrzny dostawca, brak segmentacji i kopie zapasowe, które nie zostały przetestowane w warunkach rzeczywistego odtwarzania.

Woda, panele HMI i domyślne hasła

Raport CSIRT GOV zawiera jeden fragment, który każdy prezes spółki wodociągowej powinien przeczytać dwa razy. W 2025 roku odnotowano próby ingerencji w panele HMI oczyszczalni ścieków i stacji uzdatniania wody. Przyczyny wskazane w raporcie są prozaiczne: błędy konfiguracji, brak segmentacji sieci i domyślne hasła. Liczba takich prób nie jest podana, ale kierunek wniosków jest jednoznaczny.

Ten obraz zgadza się z tym, co dzieje się w terenie. Burmistrz Rejowca Fabrycznego przywołał własny przypadek, a artykuł CyberDefence24 sięga po szerszy kontekst: prezes Wodociągów Białostockich mówił o nawet kilku tysiącach prób dziennie w szczycie, a w Grudziądzu o kilku tysiącach prób włamania miesięcznie. Zdecydowana większość jest nieskuteczna. Jednak raport CERT Polska za 2025 rok opisuje zdarzenie, w którym zmiana ustawień pomp doprowadziła do przerwy w dostawie wody trwającej około sześciu godzin dla około dwóch i pół tysiąca mieszkańców jednej gminy. Pozostaje jeszcze styczniowa seria z Warmii i Mazur, opisana przez WP Finanse: manipulacje parametrami urządzeń w Wydminach, Tolkmicku i Małdytach, w tym nocne wyłączenie pompy głębinowej w Tolkmicku. Dziesięć nieudanych logowań w Rejowcu to odmiana tego samego zjawiska, tyle że bez skutku.

Rekomendacje CERT Polska dla takich instalacji są od lat te same i niezmiennie niedopełniane. Panele ICS i OT nie powinny być dostępne z internetu. Zdalny dostęp powinien odbywać się przez VPN z uwierzytelnianiem wieloskładnikowym, także w małych instalacjach, które często są celem właśnie dlatego, że uchodzą za bezbronne. Domyślne dane logowania trzeba zmienić jeszcze przed uruchomieniem urządzenia, a sieć sterowania odseparować od biurowej. Omówiliśmy to w opracowaniu o specyfice sektora wodno-kanalizacyjnego wobec NIS2. Niestety, rządowy program „Cyberbezpieczne Wodociągi", który miał te zmiany sfinansować, nie wszędzie przeszedł z etapu naboru do etapu wdrożeń. Część zakwalifikowanych jednostek nie podpisała umów o dofinansowanie, a ministerstwo nie planuje kolejnych edycji naboru. Kto liczył na zewnętrzne pieniądze, a ich nie otrzymał, ma dziś dwie opcje: znaleźć własne środki albo zaakceptować ryzyko, które da się wycenić, choć mało kto to robi.

Telefon w kieszeni pracownika: phishing przez kod QR i kradzież tokenów

Najbardziej pouczająca część raportu dla organizacji o dowolnej wielkości dotyczy phishingu. CSIRT GOV opisuje go jako kluczowy wektor ataku, w którym fałszywe panele logowania podszywają się pod Microsoft, Adobe, Roundcube i Zimbrę, a także pod urzędy skarbowe oraz serwisy rządowe, na przykład biznes.gov.pl. Nowością, która rośnie, jest phishing z kodem QR, a także z kodem Aztec. Ofiara dostaje maila z kodem, skanuje go telefonem i trafia na fałszywą stronę logowania. Adres nie jest widoczny przed przekierowaniem.

Konsekwencja architektoniczna jest tu ważniejsza od samej sztuczki. Telefon prywatny albo służbowy, ale nieobjęty zarządzaniem, leży poza zasięgiem bramy pocztowej, filtrów webowych i systemu EDR. Organizacja, która wydała pieniądze na ochronę stacji roboczych, może w ogóle nie zobaczyć zdarzenia, w którym pracownik wpisuje hasło do poczty służbowej na smartfonie. Raport zwraca również uwagę na phishing oparty na tokenach, czyli kradzież tokenów OAuth, na przykład w Microsoft 365, oraz na przejmowanie kont w komunikatorach Signal i WhatsApp. W obu przypadkach dodatkowy czynnik uwierzytelnienia nie ratuje sytuacji, jeżeli napastnik przechwyci już wydany token sesji.

Zalecenia z raportu są klarowne: wymieniać informacje służbowe wyłącznie kanałami monitorowanymi przez organizację, bez prywatnych urządzeń i alternatywnych komunikatorów, wdrażać zarządzanie urządzeniami mobilnymi (MDM) i szkolić użytkowników. W praktyce wiele urzędów ma dziś zasadę „nie używamy WhatsAppa do spraw służbowych", która istnieje tylko na papierze, bo wójt i sekretarz gminy rozmawiają tak, jak wygodnie. Zmiana polega na tym, że to nie jest już kwestia dyscypliny, tylko ryzyka, które da się wpisać w analizę.

Sztuczna inteligencja po stronie napastnika: pierwszy malware z modelem w środku

Raport odnotowuje wydarzenie, które jeszcze dwa lata temu było tematem konferencyjnych prelekcji. Grupa APT28 użyła złośliwego oprogramowania o nazwie LAMEHUG, które wykorzystywało model językowy działający na platformie Hugging Face jako serwer dowodzenia i kontroli. Polecenia nie były wpisane na stałe w kod, tylko generowane na bieżąco przez model. Według raportu to pierwszy przypadek zarejestrowany przez CSIRT GOV, w którym sztuczna inteligencja stanowiła integralną część szkodliwego programu.

Mniej spektakularne, ale statystycznie ważniejsze zastosowania AI są bardziej codzienne. Modele piszą poprawne językowo, spersonalizowane wiadomości phishingowe w polszczyźnie, której kilka lat temu brakowało większości kampanii. Tłumaczą kampanie na polski, przygotowują deepfake'i wizerunku osób publicznych i wspomagają rozpoznanie podatności. Ostatni element ma znaczenie dla wniosku z poprzedniej sekcji: skoro napastnik z pomocą modelu szybciej przegląda wyniki skanowania, to okno czasowe między ujawnieniem luki a jej masowym wykorzystaniem się kurczy. Procedura aktualizacji, która zakłada comiesięczne okna serwisowe, przestaje być wystarczająca dla systemów brzegowych.

Dla zarządu to oznacza konieczność rozróżnienia dwóch tempów łatania. Systemy wewnętrzne mogą być łatane według harmonogramu. Systemy dostępne z internetu, czyli VPN, poczta, bramy, panele i portale, powinny mieć ścieżkę awaryjną, która pozwala wdrożyć krytyczną łatkę w ciągu dni, a nie tygodni. Taką ścieżkę trzeba mieć opisaną przed incydentem, bo w dniu ogłoszenia luki nikt nie ma czasu na ustalanie, kto ma uprawnienia do zatrzymania usługi w środku dnia pracy.

Czego raport nie mówi i dlaczego to też ma znaczenie

Dokument ma swoje granice, które uczciwie trzeba nazwać. Słowo ransomware nie pada w nim ani razu, mimo że w tym samym czasie to właśnie zaszyfrowane systemy sparaliżowały szpitale i urzędy. Powód jest prosty: raport CSIRT GOV opisuje działalność zespołu wobec administracji rządowej i podmiotów w jego zakresie, a nie rynek szpitali, spółek czy samorządów. O ransomware w ochronie zdrowia mówią inne źródła, na przykład roczny raport CSIRT CeZ, w którym zespół policzył 1441 incydentów w sektorze zdrowia w 2025 roku, o ponad sześćdziesiąt procent więcej niż rok wcześniej.

Ważna jest też relacja między tym raportem a tym, co opisała CERT Polska w sprawie grudniowego ataku na energetykę z końca 2025 roku. CSIRT GOV nazywa go pierwszym w polskiej cyberprzestrzeni atakiem o potencjale destrukcyjnym wymierzonym w sektor energii i podkreśla, że nie przerwał dostaw energii ani ciepła. Szczegóły techniczne, w tym wektor w postaci prywatnego APN w jednej z elektrociepłowni, opisaliśmy w analizie ataku na elektrociepłownię. Dla naszej analizy istotne jest co innego: skoro żaden z trzynastu incydentów poważnych nie był cyberatakiem, to grudniowy atak na energetykę nie należy do tego zestawu, a obie publikacje mierzą inne populacje. Kto porównuje wskaźniki z różnych raportów, powinien wiedzieć, że każdy mierzy inną populację.

Z tego wynika praktyczna zasada interpretacji. Raportów nie czyta się po to, by sprawdzić, czy „jest gorzej, czy lepiej". Czyta się je po to, by znaleźć powtarzalne mechanizmy: panel dostępny z internetu, domyślne hasło, brak segmentacji, telefon poza nadzorem, łatka, która czeka na okno serwisowe. Mechanizmy są niemal niezmienne od lat, a liczby wokół nich się przesuwają.

Pięć pytań, które zarząd, wójt albo prezes spółki może zadać w poniedziałek

Raport ma wartość tylko wtedy, gdy zamienia się w decyzje. Poniżej pięć pytań, na które w każdej jednostce da się odpowiedzieć w ciągu jednego spotkania, a których brak odpowiedzi jest sam w sobie ustaleniem.

Pierwsze. Które z naszych systemów są dostępne z internetu i kiedy ostatnio ktoś z zewnątrz je przeskanował? Odpowiedź „zna to informatyk" nie jest odpowiedzią, bo zarząd odpowiada za ryzyko, a nie za wiedzę o konfiguracji.

Drugie. Czy panele sterowania wodą, ciepłem, ściekami lub odpadami, czyli wszystko, co jest systemem OT, są odcięte od internetu, a jeśli mają zdalny dostęp, to czy przez VPN z drugim składnikiem uwierzytelnienia? Czy ktoś zmienił hasła producenta?

Trzecie. Czy mamy opisaną procedurę zgłaszania incydentów poważnych w trzech krokach, 24 godziny, 72 godziny, miesiąc, i czy obejmuje ona także awarie bez udziału napastnika? Kto w sobotę o 22:00 podejmuje decyzję o zgłoszeniu i jaki ma numer telefonu do właściwego CSIRT? Przy okazji warto sprawdzić zgodność z obowiązkami z nowelizacji KSC po 3 kwietnia.

Czwarte. Jak wygląda u nas poczta służbowa na telefonach i czy ktoś zarządza tymi urządzeniami? Co się dzieje, gdy pracownik zeskanuje kod QR z maila i wpisze hasło na stronie, która wygląda jak logowanie do Microsoft 365?

Piąte. W jakim czasie jesteśmy w stanie wdrożyć krytyczną łatkę na bramie VPN albo serwerze poczty, jeżeli producent ogłosi lukę w piątek po południu? Jeżeli odpowiedź brzmi „w najbliższym oknie serwisowym", to ta odpowiedź jest dokładnie tym, co skanery napastnika są zaprojektowane wykorzystać.

Dlaczego z Fib.Code

Pracujemy z jednostkami samorządu terytorialnego, spółkami komunalnymi, wodociągami, ciepłowniami i sądami od lat, więc raporty typu CSIRT GOV czytamy z perspektywy tego, co znajdziemy podczas audytu w konkretnej gminie, a nie tego, co wygląda dobrze na slajdzie. Znamy typowe konfiguracje, w których panel wodociągów stoi obok systemu rozliczeń, a w serwerowni nikt nie pamięta, kto ustawił regułę na firewallu trzy lata temu. Znamy też typowe kompromisy: jedna osoba w dziale IT, budżet na licencje bez budżetu na ludzi, wymóg NIS2 bez planu jego wdrożenia.

Nasze podejście opiera się na trzech zasadach. Po pierwsze, zaczynamy od widoku z zewnątrz, czyli od tego, co faktycznie widzi napastnik, a nie od tego, co mówi dokumentacja. Po drugie, priorytetyzujemy według skutku dla usługi: to, co może zatrzymać wodę, ogrzewanie albo obsługę mieszkańców, trafia na początek kolejki, niezależnie od tego, jak wysoko plasuje się w rankingu podatności. Po trzecie, każdy wniosek z audytu zamieniamy na zadanie z właścicielem i terminem, bo raport bez właściciela zadań ląduje w szufladzie.

Efektem współpracy jest dokument, który zarząd może podpisać i który wytrzyma kontrolę: aktualna analiza ryzyka, plan postępowania z ryzykiem, procedura zgłaszania incydentów poważnych ze scenariuszami także dla awarii własnych, wykaz systemów dostępnych z internetu z ocenionymi zagrożeniami i harmonogram prac naprawczych. W razie potrzeby przejmujemy rolę pełnomocnika ds. bezpieczeństwa informacji albo wirtualnego CISO, tak by jednostka bez własnego specjalisty miała kogoś, kto odpowiada na telefon, gdy coś się dzieje.

Co zrobić w ten tydzień

Do piątku zaplanujcie jedno dwugodzinne spotkanie, w którym wezmą udział osoba zarządzająca jednostką, kierownik informatyki oraz kierownik odpowiedzialny za system OT, jeśli taki jest. Na spotkaniu przejdźcie przez pięć pytań z poprzedniej sekcji i zapiszcie odpowiedzi tak, jak są, bez ich upiększania. Tam, gdzie zabraknie odpowiedzi, wpiszcie osobę odpowiedzialną i termin: najpóźniej do końca października.

Równolegle zlećcie zewnętrzny skan zasobów dostępnych z internetu. Jeżeli macie system sterowania wodą, ciepłem lub ściekami, poproście dostawcę o potwierdzenie na piśmie, czy panel jest dostępny z sieci publicznej i jakie ma uwierzytelnianie. Sprawdźcie też, czy wasza lista podmiotów w ramach KSC jest aktualna, bo termin wpisu do wykazu minął 3 października 2026 roku, o czym pisaliśmy w opracowaniu o wykazie podmiotów KSC. Do końca tygodnia powinniście mieć w rękach trzy rzeczy: listę usług widocznych z internetu, odpowiedź dostawcy OT i nazwisko osoby, która w razie incydentu poważnego podejmuje decyzję o zgłoszeniu.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: fala ransomware wiosną 2026 w szpitalach, samorządach i MŚP, wodociągi wobec NIS2 i specyfika sektora wodno-kanalizacyjnego, stopnie alarmowe CRP i obowiązki samorządu — razem składają się na praktyczny obraz tego, co raport mówi o ryzyku, a co zostawia czytelnikowi do dopowiedzenia.