Wtorek, w którym państwo oficjalnie zaprosiło hakerów

We wtorek 3 listopada 2026 roku wicepremier i minister cyfryzacji Krzysztof Gawkowski powiedział rzecz, która jeszcze kilka lat temu zabrzmiałaby w polskiej administracji jak herezja: „Chcemy, żeby społecznicy, etyczni hakerzy przeszukiwali nasze systemy państwowe, zwłaszcza w domenie gov.pl". Dodał, że cel jest prosty, czyli szybkie usuwanie błędów, zanim wykorzystają je cyberprzestępcy. Jeszcze w to samo południe, według relacji PAP o 12:32, ruszyła platforma hack.cert.pl, a w serwisach branżowych pojawiło się zdanie, które lepiej niż komunikat prasowy oddaje sedno sprawy: polskie państwo zaprasza hakerów do szukania dziur w swoich systemach i płaci za to prawdziwe pieniądze.

Dla wielu urzędników brzmi to jak zaproszenie złodzieja do przymierzania zamków w drzwiach. Dla ludzi, którzy zawodowo zajmują się bezpieczeństwem, to uznanie faktu, który każdy audytor zna z autopsji: błędy w systemach publicznych istnieją, ktoś je prędzej czy później znajdzie, a jedyne pytanie brzmi, czy pierwszy znajdzie je badacz, który zgłosi sprawę grzecznie, czy grupa, która zgłosi ją żądaniem okupu. Program CERT Polska nie wynajduje tej alternatywy. Porządkuje ją i nadaje jej adres.

Ten tekst jest o tym, co ruszyło 3 listopada, czym różni się od zagranicznych wzorców i dlaczego dotyczy nie tylko administracji centralnej. Skoro w pilotażu od razu znalazła się gmina, a organizatorzy zapowiadają stopniowe włączanie kolejnych jednostek samorządu, to prędzej niż później ktoś zapuka także do Twojego urzędu, wodociągów albo ciepłowni. Zgłoszenie może przyjść od uczciwego badacza, który nie ma nic wspólnego z żadnym konkursem. Warto wiedzieć, co z nim zrobić, zanim przyjdzie.

Co dokładnie ruszyło: pięć konkursów na hack.cert.pl

Platformę zbudował i prowadzi zespół CERT Polska działający w strukturach NASK, czyli jeden z trzech krajowych zespołów CSIRT poziomu krajowego. Pula nagród wynosi 1 mln zł i pochodzi z budżetu samego NASK, co podkreślał dyrektor instytutu Radosław Nielek. Wysokość nagrody za pojedynczą podatność zależy od jej krytyczności i mieści się w przedziale od kilkuset złotych do 20 tys. zł. Opisy programu nie podają sztywnej tabeli stawek dla poszczególnych poziomów ważności, bo kwoty określa regulamin konkretnego konkursu.

Na starcie uruchomiono pięć odrębnych programów. Pierwszy obejmuje portal gov.pl, drugi komunikator mSzyfr, trzeci usługi gminy Władysławowo, a dwa ostatnie systemy samego CERT Polska i systemy NASK. Każdy konkurs ma własny regulamin z listą dozwolonych metod testowania, zakresem systemów i zasadami wypłaty. Uczestnik loguje się przez login.gov.pl, czyli profilem zaufanym, i dopiero po zalogowaniu widzi szczegóły: które instytucje biorą udział, czego wolno dotykać, a czego nie wolno.

Warunki uczestnictwa są wyraźnie zawężone. Zgłaszać mogą osoby pełnoletnie, posiadające numer PESEL i polską rezydencję podatkową, a do wypłaty potrzebny jest rachunek w polskim banku. Organizatorzy zapowiadają, że w przyszłości dołączą osoby w wieku od 16 do 18 lat za zgodą opiekuna prawnego oraz elementy grywalizacji w postaci odznak i rankingów. Program ma formułę konkursu, a to ma praktyczną konsekwencję podatkową: według komunikatu CERT Polska uczestnik nie rozlicza nagrody samodzielnie.

Nagroda nie spada z nieba w chwili wysłania zgłoszenia. Według relacji PAP wypłata następuje dopiero po tym, jak CERT Polska potwierdzi podatność i po wdrożeniu poprawki. Ma to sens, bo odwraca typową patologię wielu programów, w których badacz dostaje potwierdzenie, a administrator wraca do sprawy po kwartale. Dyrektor Nielek ujął to, w parafrazie spidersweb.pl, następująco: znalezienie słabości jest ważne, ale równie ważna jest zdolność instytucji do szybkiego jej usunięcia, bo niezałatana podatność nie poprawia niczyjego bezpieczeństwa.

Proces obsługi wygląda tak: zgłoszenie trafia do wstępnej analizy ekspertów CERT Polska, potwierdzona podatność jest przekazywana właścicielowi systemu, a cała komunikacja odbywa się przez platformę. Seria błędnych zgłoszeń może skutkować czasową blokadą konta, więc badacz ma interes w tym, by przed wysłaniem sprawdzić, czy to, co znalazł, naprawdę jest podatnością. Podmioty publiczne o wysokim poziomie dojrzałości bezpieczeństwa mogą same aplikować o włączenie do programu.

Dlaczego własna platforma, a nie HackerOne

Na świecie dominują dwa modele. W pierwszym państwo lub firma korzysta z komercyjnego pośrednika, takiego jak HackerOne czy Bugcrowd, który zajmuje się rejestracją badaczy, wstępną selekcją zgłoszeń i wypłatami. W drugim organizacja prowadzi program samodzielnie, co wymaga zespołu, procesu i cierpliwości. Polska wybrała wariant trzeci: państwowa platforma, w której cały proces zgłaszania i obsługi podatności odbywa się w wewnętrznej infrastrukturze, bez udziału komercyjnych pośredników.

Szef CERT Polska Marcin Dudek mówił, że podobny program dla instytucji publicznych był dyskutowany od lat, a hack.cert.pl jest pierwszą platformą tego rodzaju zbudowaną przez rząd. Argument bezpieczeństwa nie jest wyłącznie retoryczny. Raport o podatności to w istocie instrukcja włamania do konkretnego systemu, napisana przez kogoś, kto już ją przetestował. Im więcej podmiotów ma dostęp do takiej instrukcji, tym więcej miejsc, z których może wyciec, zanim poprawka zostanie wdrożona. Zamknięty obieg w rękach zespołów, które zgłoszenia weryfikują i naprawiają, ogranicza ten problem.

Własna platforma ma też drugą stronę. Zaufana Trzecia Strona zwróciła uwagę, że wymóg logowania przez login.gov.pl i polskiej rezydencji podatkowej działa jak filtr jakości: odcina anonimowe, masowe i często bezwartościowe zgłoszenia z całego świata, które zalewają komercyjne programy. Za ten filtr płaci się jednak ograniczeniem puli talentów. Wielu najlepszych badaczy pracuje poza Polską albo nie chce ujawniać tożsamości państwu, w którym testuje systemy. Pierwsze miesiące pokażą, czy polska pula wystarczy, czy program będzie musiał się otworzyć.

Ten sam autor trzeźwo zauważył, że usługi objęte startowymi konkursami były już wielokrotnie testowane, więc łatwe błędy mogły zostać wyłapane wcześniej. To dobra wiadomość dla państwa i umiarkowanie zła dla łowców nagród: pierwsze wypłaty mogą przyjść wolniej, niż sugeruje medialny nagłówek o milionie złotych. Nie zmienia to istoty sprawy. Program jest pilotażem, a jego logika zakłada rozszerzanie na kolejne jednostki, jeśli model się sprawdzi.

Liczby, które tłumaczą pośpiech

NASK uzasadnia uruchomienie programu dwoma zestawami liczb. Według danych przytaczanych przy premierze, od stycznia do września 2026 roku na świecie ujawniono ponad 105 tys. nowych podatności, podczas gdy w całym 2025 roku było ich około 71 tys. Liczba podatności obsługiwanych przez CERT Polska wzrosła w ciągu trzech lat o ponad 300 proc. Część tego wzrostu wynika z lepszej wykrywalności i większej liczby badaczy, a nie wyłącznie z gorszej jakości oprogramowania, i organizatorzy sami zwracają na to uwagę. Kierunek jest jednak jednoznaczny.

Według relacji PAP w 2025 roku CERT Polska obsłużył 1732 incydenty związane z podatnościami w usługach wystawionych do internetu. Warto zapamiętać tę liczbę, bo opisuje ona codzienność, a nie spektakularne ataki: ktoś znalazł niezałataną bramę VPN, panel administracyjny bez uwierzytelniania, stary plugin w systemie zarządzania treścią albo bazę danych dostępną z sieci. Takie rzeczy nie trafiają na nagłówki, dopóki nie zakończą się wyciekiem albo szyfrowaniem plików, o czym w ostatnich miesiącach pisaliśmy przy okazji ataków na dostawców oprogramowania medycznego i systemów fakturowania.

Do tego dochodzi sztuczna inteligencja, którą NASK wskazuje jako technologię przyspieszającą zarówno wyszukiwanie, jak i wykorzystywanie podatności. Skracający się czas między ujawnieniem błędu a jego masową eksploatacją ma konkretny skutek organizacyjny: cykl łatania liczony w tygodniach, który jeszcze niedawno uchodził za przyzwoity, staje się ryzykiem sam w sobie. Program bug bounty nie rozwiązuje tego problemu. Przesuwa jednak moment wykrycia na stronę obrońców, a to w tym wyścigu jedyna zmiana, która ma znaczenie.

Władysławowo: gmina na pierwszej linii

Najciekawszym elementem startowego zestawu jest nie gov.pl, tylko trzeci konkurs, czyli usługi gminy Władysławowo. Portal rządowy jest utrzymywany przez centralne zespoły z budżetem i procedurami. Nadmorska gmina w województwie pomorskim to zupełnie inna kategoria organizacji. W typowym polskim urzędzie gminy za informatykę odpowiada jedna osoba, czasem półtora etatu, a systemy utrzymuje kilku dostawców, z których każdy zna tylko swój kawałek.

Fakt, że gmina znalazła się w programie już w pierwszej turze, jest sygnałem politycznym i praktycznym. Politycznym, bo ministerstwo mówi wprost, że jeśli model zadziała, zostanie stopniowo rozszerzony na kolejne jednostki samorządu i administracji centralnej. Praktycznym, bo Władysławowo stanie się poligonem, na którym zobaczymy, jak jednostka o skali typowego polskiego urzędu radzi sobie z napływem zgłoszeń. Czy jest w stanie w rozsądnym czasie zweryfikować zgłoszenie, ustalić właściciela systemu, skontaktować się z dostawcą i wdrożyć poprawkę? Od odpowiedzi na te pytania zależy, czy wypłata nagrody, uzależniona od wdrożenia poprawki, będzie kwestią tygodni, czy miesięcy.

Dla samorządów wniosek jest znajomy z naszych wcześniejszych analiz, w tym z omówienia raportu CSIRT GOV o incydentach w 2025 roku: poważne zdarzenia zaczynają się zwykle od zwykłej luki w systemie, którego nikt nie pilnował, albo od dostawcy, który nie zareagował na czas. Program CERT Polska przenosi ciężar z „czekamy, aż ktoś nas zaatakuje" na „płacimy za to, żeby ktoś nas uprzedził". Jest to tańsze od każdego incydentu, jaki znamy z polskich gmin i szpitali.

Czego komunikaty nie mówią: ochrona prawna badacza

Komunikaty o starcie programu dużo mówią o nagrodach i niewiele o ochronie prawnej uczestników. W dostępnych nam opisach nie znaleźliśmy wzmianki o klauzuli safe harbor, czyli zobowiązaniu systemu do niewszczynania postępowań wobec badacza, który działał w granicach regulaminu. Autorzy relacji odsyłają do regulaminów poszczególnych konkursów i trzeba przyjąć, że to właśnie tam znajdują się zasady, których komunikat prasowy nie powtarza. Nie przesądzamy więc, że ochrony brakuje. Stwierdzamy tylko, że zainteresowany badacz powinien przeczytać regulamin konkursu, zanim cokolwiek przetestuje.

Problem jest realny, bo polskie prawo karne nie zna wyraźnego wyjątku dla badań bezpieczeństwa. Art. 267 Kodeksu karnego penalizuje uzyskanie bez uprawnienia dostępu do informacji dla sprawcy nieprzeznaczonej, między innymi przez włamanie do systemu informatycznego, a art. 269b dotyczy wytwarzania i udostępniania narzędzi przystosowanych do popełniania określonych przestępstw. Badacz, który wychodzi poza zakres zgody administratora, wchodzi w strefę ryzyka, nawet jeśli działa w dobrej wierze. W programie z regulaminem, listą dozwolonych metod i wyraźnym zakresem system sam wyznacza granicę zgody. Poza programem granicy nie wyznacza nikt.

To jedna z najważniejszych lekcji dla samorządów i spółek komunalnych, które nie uczestniczą w hack.cert.pl. Jeśli nie masz polityki przyjmowania zgłoszeń, uczciwy badacz, który znajdzie lukę w Twoim BIP-ie albo systemie obsługi mieszkańców, stoi przed dylematem: zgłosić i ryzykować reakcję prawną, czy milczeć i zostawić dziurę innym. Urząd, który na takie zgłoszenie odpowie pismem od radcy prawnego zamiast podziękowaniem, gwarantuje sobie, że następnym razem nikt do niego nie napisze, a lukę wykorzysta ktoś, kto o zgłaszaniu w ogóle nie myśli.

Podatność w ustawie o KSC: nie ciekawostka, tylko obowiązek

Program CERT Polska działa na tle regulacji, którą samorządy i spółki komunalne znają z procesu samoidentyfikacji. Ustawa o krajowym systemie cyberbezpieczeństwa (UKSC) w art. 2 pkt 11 definiuje podatność jako właściwość produktu lub usługi ICT, którą może wykorzystać cyberzagrożenie. Z tej definicji wynika cały pakiet obowiązków podmiotów kluczowych i ważnych, które analizowaliśmy już przy okazji nowelizacji z 2026 roku i wpisu do wykazu z urzędu.

Według opracowań komentatorskich podmiot objęty ustawą powinien zbierać informacje o zagrożeniach i podatnościach w używanych systemach, stosować procedury pozwalające szybko reagować na ujawnione luki, w tym czasowo ograniczać ruch przychodzący, usuwać podatność, która doprowadziła do incydentu, oraz uwzględniać podatności po stronie dostawców przy wyborze produktów i usług ICT. Wymieniane są także: wymiana informacji o podatnościach z zespołami CSIRT i dostawcami przez system S46 oraz zapewnienie użytkownikom możliwości zgłaszania podatności, zagrożeń i incydentów związanych z usługą.

Ten ostatni punkt jest dla naszego tematu kluczowy. Jeśli ustawa wymaga, by użytkownik mógł zgłosić podatność, to urząd lub spółka muszą mieć miejsce, do którego da się ją zgłosić, osobę, która zgłoszenie odbierze, i procedurę, która nie kończy się na skrzynce ogólnej, czytanej raz na tydzień. Komentatorzy wskazują, że brak takiej możliwości jest zagrożony sankcją liczoną jako wielokrotność wynagrodzenia kierownika podmiotu, a nie wyłącznie karą dla organizacji. Dokładne brzmienie przepisów i wysokość sankcji trzeba w każdym przypadku zweryfikować w aktualnym tekście ustawy, ale kierunek jest jasny: zgłoszenie podatności jest po stronie podmiotu obowiązkiem organizacyjnym, nie grzecznością.

Jest też druga strona zależności. Zespoły CSIRT koordynują ujawnianie podatności, analizują sprzęt i oprogramowanie, a gdy luka mogłaby doprowadzić do poważnego lub krytycznego incydentu, mogą wezwać podmiot kluczowy lub ważny do jej usunięcia. Niewykonanie takiego wezwania zagrożone jest karą sięgającą milionów euro: w ramach NIS2 do 10 mln euro albo 2 proc. obrotu dla podmiotów kluczowych i do 7 mln euro albo 1,4 proc. obrotu dla ważnych. CSIRT NASK przyjmuje przy tym zgłoszenia podatności od każdego przez anonimowy formularz internetowy, więc informacja o dziurze w Twoim systemie może dotrzeć do Ciebie jako wezwanie od państwa, zanim w ogóle usłyszysz o niej od badacza.

Czytelnik, który śledzi nasze analizy, dostrzeże spójność z innym wątkiem: od 11 września 2026 roku producenci produktów z elementami cyfrowymi mają obowiązek zgłaszania aktywnie wykorzystywanych podatności w ramach Cyber Resilience Act. Szczegóły opisaliśmy w tekście o zegarze CRA. Państwo buduje więc równolegle dwa kanały: obowiązkowy dla producentów i wytwórców oprogramowania oraz dobrowolny, nagradzany, dla badaczy. Samorządy i spółki komunalne są w tym układzie po stronie odbiorców obu strumieni informacji, bo kupują produkty, które kogoś będą zgłaszać, i utrzymują usługi, które ktoś będzie badał.

Urząd dostaje pierwsze zgłoszenie: pięć decyzji, które trzeba podjąć wcześniej

Wyobraźmy sobie wtorek, 17 listopada. Do skrzynki kontaktowej gminy trafia wiadomość od osoby, której nikt nie zna. Pisze, że w systemie obsługi mieszkańców znalazła parametr w adresie, który po zmianie wyświetla dane innych użytkowników, i prosi o potwierdzenie odbioru. Skrzynkę czyta sekretariat, który przekazuje wiadomość do informatyka, który jest na urlopie. Po tygodniu nikt nie odpowiedział. Po dwóch tygodniach badacz publikuje opis na swoim blogu. Po trzech do urzędu dzwonią dziennikarze i inspektor ochrony danych.

Żaden z tych kroków nie wymaga złej woli. Każdy wynika z braku decyzji podjętych wcześniej, a decyzji tych jest pięć. Po pierwsze, gdzie można zgłosić podatność: urząd potrzebuje wskazanego adresu, najlepiej dedykowanego aliasu, oraz opublikowanego pliku security.txt zgodnego z RFC 9116 pod adresem /.well-known/security.txt, który mówi badaczowi, do kogo pisać, w jakim języku i jak długo może czekać na odpowiedź. Po drugie, kto odbiera zgłoszenie i kto go zastępuje, bo osoba na urlopie nie jest wystarczającym planem.

Po trzecie, jak szybko urząd odpowiada. Wystarczy automatyczne potwierdzenie w ciągu doby i merytoryczna odpowiedź w ciągu kilku dni roboczych, bo najwięcej szkód wyrządza milczenie, a nie sama luka. Po czwarte, kto naprawia i kto płaci: jeśli system utrzymuje zewnętrzny dostawca, umowa powinna zawierać obowiązek przyjęcia zgłoszenia, ocenę w określonym czasie i wdrożenie poprawki zgodnie z krytycznością, a rejestr zgłoszeń powinien być częścią systemu zarządzania bezpieczeństwem informacji. Po piąte, jak urząd traktuje zgłaszającego: ton pierwszej odpowiedzi, zobowiązanie do niewszczynania postępowań wobec osoby działającej w dobrej wierze i w granicach opublikowanej polityki oraz podziękowanie, nawet jeśli nagrody nie ma.

Do tego dochodzi wątek ochrony danych. Jeżeli zgłoszona podatność dotyczy danych osobowych i okaże się, że ktoś miał do nich nieuprawniony dostęp, uruchamia się reżim art. 33 RODO i 72-godzinne okno na zgłoszenie do Prezesa UODO. Sama luka bez dowodu wykorzystania nie jest jeszcze naruszeniem, ale ocena tego rozróżnienia powinna trafić do rejestru, o czym pisaliśmy w analizie rejestru naruszeń. Zespół, który ma plan na zgłoszenie podatności, ma też gotową ścieżkę dla naruszenia.

Cztery błędy, które zobaczymy w pierwszych miesiącach

Z obserwacji programów bug bounty na świecie i z tego, co widzimy w audytach, wynika kilka powtarzalnych potknięć. Pierwsze to traktowanie programu jako certyfikatu bezpieczeństwa. Zero zgłoszeń nie oznacza zera podatności, a niska liczba wypłat w pierwszych tygodniach, o której wspominała Zaufana Trzecia Strona, mówi więcej o testowanych wcześniej usługach niż o jakości całej administracji. Program uzupełnia testy penetracyjne i skanowanie podatności, a nie je zastępuje. Jednostka, która ma kilkaset niezałatanych krytycznych podatności w sieci wewnętrznej, nie powinna czekać na łowców nagród.

Drugi błąd to brak inwentaryzacji. Nie da się obsłużyć zgłoszenia o systemie, o którego istnieniu nikt w urzędzie nie wie. Tymczasem w polskich samorządach wciąż rutynowo zdarzają się zapomniane subdomeny, stare serwisy konkursowe, testowe instancje BIP i panele administracyjne wystawione dla dostawcy przed laty. Pierwszym wynikiem każdego poważnego skanowania powierzchni ataku jest zwykle lista rzeczy, które ktoś kiedyś uruchomił i o nich zapomniał.

Trzeci błąd to mylenie zgłoszenia podatności z zawiadomieniem o przestępstwie. Dopóki badacz działa w granicach dobrej wiary, nie ma powodu, by urząd przekazywał sprawę organom ścigania, a taki odruch niszczy zaufanie na lata. Czwarty to zaniedbanie dostawców. Zgłoszona podatność dotyczy najczęściej komponentu, którego nie napisał urząd, tylko dostawca systemu dziedzinowego. Jeśli umowa nie przewiduje terminów reakcji, urząd będzie bezradnie czekać na łatkę, mając jednocześnie ustawowy obowiązek usunięcia luki. Do tego wątku wracamy za każdym razem, gdy analizujemy wycieki u dostawców oprogramowania, na przykład po ataku na system fakturowania opisanym w jednym z wcześniejszych materiałów.

Dlaczego z Fib.Code

Fib.Code Sp. z o.o. zajmuje się bezpieczeństwem informacji i zgodnością regulacyjną dla organizacji, które nie mogą sobie pozwolić na luki w odpowiedzialności: samorządów, spółek komunalnych, sądów i przedsiębiorstw z sektora MŚP. Codziennie pracujemy na styku trzech światów, które w programach bug bounty zderzają się ze sobą: technicznego zarządzania podatnościami, prawa (UKSC, RODO, NIS2, CRA) oraz organizacji pracy urzędu czy spółki, w której informatyk bywa jednoosobowym działem. Dlatego nie sprzedajemy gotowych szablonów, tylko projektujemy procedury, które da się wykonać w Twojej organizacji we wtorek rano, bez dodatkowego etatu.

Trzymamy się trzech zasad. Pierwsza: zaczynamy od inwentarza, nie od dokumentu, bo bez listy systemów, dostawców i danych każda polityka jest deklaracją. Druga: procedura ma mieć właściciela z imieniem i nazwiskiem, termin reakcji liczony w godzinach i dni robocze oraz dowód wykonania, bo audytor, kontroler UODO i zespół CSIRT pytają o to samo, tylko innymi słowami. Trzecia: wszystko, co dotyczy dostawców, kończy się zmianą w umowie, a nie wyłącznie pismem z prośbą o współpracę.

Produktem końcowym jest działający system przyjmowania i obsługi zgłoszeń podatności, wpisany w zintegrowany system zarządzania bezpieczeństwem informacji: polityka koordynowanego ujawniania, plik security.txt, rejestr zgłoszeń, zapisy w umowach z dostawcami, scenariusze komunikacji oraz szkolenie osób, które pierwszą wiadomość odbiorą. Realizujemy to jako usługę zewnętrznego pełnomocnika ds. bezpieczeństwa informacji, wirtualnego dyrektora bezpieczeństwa informacji (vCISO) lub jednorazowy projekt wdrożeniowy z audytem na końcu.

Co zrobić w tym tygodniu

Zacznij od jednej godziny w tym tygodniu, najlepiej w czwartek, po przeglądzie bieżących spraw. Zbierz w jednym pokoju kierownika informatyki, inspektora ochrony danych, osobę odpowiedzialną za zamówienia publiczne i, jeśli to możliwe, przedstawiciela głównego dostawcy systemów dziedzinowych. Odpowiedzcie wspólnie na cztery pytania: pod jaki adres dziś można zgłosić Wam lukę, kto ten adres czyta, w jakim czasie ktoś odpowie i kto zdecyduje o poprawce, gdy odpowiedź dotyczy systemu zewnętrznego. Jeśli choć na jedno pytanie nie ma odpowiedzi w ciągu minuty, macie wynik pierwszej diagnozy.

W kolejnych dniach opublikujcie plik security.txt, wskażcie alias do zgłoszeń z zastępstwem i dopiszcie do harmonogramu przeglądu umów z dostawcami klauzulę o obsłudze podatności. Do końca miesiąca zróbcie szybką inwentaryzację zasobów wystawionych do internetu: domen, subdomen, paneli logowania i usług testowych. Do 3 kwietnia 2027 roku, czyli za 144 dni, zostanie Wam jeszcze czas na to, by cały proces wpisać w system zarządzania zgodnie z wymaganiami UKSC. Warto skorzystać z niego wcześniej, bo pierwsze zgłoszenie nie zapyta o harmonogram.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: CRA: masz dobę na przyznanie się do dziury, Wpis do wykazu KSC z urzędu: co dalej, Raport CSIRT GOV 2025: 13 poważnych incydentów w samorządzie oraz Nie każde naruszenie to zgłoszenie do UODO — razem tworzą mapę obowiązków, w której zgłoszenie podatności jest jednym z elementów łączących KSC, RODO i bezpieczeństwo łańcucha dostaw.