Producent ma 24 godziny na pierwszy raport. Nowa platforma CRA działa już także dla polskich firm

Pełne stosowanie Aktu o cyberodporności rozpocznie się dopiero 11 grudnia 2027 roku, ale jeden z najważniejszych mechanizmów działa już teraz. Od 11 września 2026 roku producenci produktów z elementami cyfrowymi muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty bezpieczeństwa. Pierwsze ostrzeżenie trzeba przekazać w ciągu 24 godzin od uzyskania wiedzy o zdarzeniu.

Zgłoszenia trafiają przez Single Reporting Platform uruchomioną przez ENISA. W Polsce zadania krajowego punktu kontaktowego wykonuje CSIRT NASK. Dla producenta oprogramowania, aplikacji mobilnej, urządzenia IoT lub innego produktu cyfrowego oznacza to, że procedura „naprawimy i opiszemy później” może nie spełnić obowiązujących wymagań.

Jak działa nowy zegar raportowania

Ministerstwo Cyfryzacji opisuje cztery główne terminy. W ciągu 24 godzin producent przekazuje wczesne ostrzeżenie o aktywnie wykorzystywanej podatności lub poważnym incydencie. W ciągu 72 godzin składa właściwe zgłoszenie z informacjami o produkcie, charakterze wykorzystania oraz podjętych lub możliwych środkach zaradczych.

W przypadku podatności sprawozdanie końcowe należy przekazać w ciągu 14 dni od udostępnienia poprawki lub środka ograniczającego ryzyko. Dla poważnego incydentu termin raportu końcowego wynosi miesiąc od pierwszego zgłoszenia. Koordynujący CSIRT może poprosić o dodatkowe aktualizacje.

Obowiązek nie ogranicza się do przesłania formularza urzędowi. Producent ma również informować użytkowników o wykrytych podatnościach lub incydentach oraz dostępnych działaniach ograniczających ryzyko. Komunikacja dla klientów musi więc powstawać równolegle z analizą techniczną.

Co podlega zgłoszeniu

Raportowaniu podlega aktywnie wykorzystywana podatność, o której producent uzyskał wiedzę, oraz poważny incydent mający wpływ na bezpieczeństwo produktu. Ministerstwo wyjaśnia, że incydent jest poważny, gdy wpływa lub może wpływać na dostępność, autentyczność, integralność albo poufność ważnych lub wrażliwych danych bądź funkcji, albo gdy prowadził lub może prowadzić do uruchomienia złośliwego kodu w produkcie, sieci czy systemie użytkownika.

Nie każde zgłoszenie błędu przez badacza automatycznie uruchamia ten sam scenariusz. Kluczowe są przesłanki aktywnego wykorzystania i powagi incydentu. Firma potrzebuje więc udokumentowanego procesu kwalifikacji, który łączy zespół bezpieczeństwa produktu, reagowanie, prawników, właściciela biznesowego i komunikację.

Pierwsze 24 godziny zaczynają się przed pełną pewnością

Największym ryzykiem organizacyjnym jest oczekiwanie na kompletną analizę przyczyny. Wczesne ostrzeżenie z założenia powstaje wtedy, gdy część faktów pozostaje nieznana. Zespół musi umieć opisać, co wykryto, jakiego produktu dotyczy sygnał, dlaczego może spełniać próg i jakie działania podjęto, bez zgadywania sprawcy oraz skali.

Dlatego firma powinna z góry wskazać osobę, która uruchamia procedurę, zastępstwo poza godzinami pracy, właściciela konta na platformie, prawnika oceniającego przesłanki i osobę zatwierdzającą komunikat dla klientów. Te role muszą działać również w weekend, podczas urlopu i przy awarii głównego systemu współpracy.

W praktyce potrzebny jest dziennik decyzji. Powinien rejestrować moment otrzymania pierwszego wiarygodnego sygnału, osoby poinformowane, dowody, ocenę progu, wysłane raporty oraz uzasadnienie zmian stanowiska. Nie chodzi o tworzenie dokumentacji dla samej dokumentacji, lecz o możliwość odtworzenia, dlaczego organizacja uznała obowiązek za uruchomiony lub nie.

Czego potrzebuje producent przed incydentem

Bez inwentaryzacji produktów i wersji nie da się szybko określić zasięgu. Producent powinien wiedzieć, które wydania są wspierane, jakie komponenty zawierają, gdzie działa wspólny kod i jak dotrzeć do użytkowników. Lista mailingowa prowadzona przez dział sprzedaży nie zastępuje technicznego mapowania produktu.

Proces przyjmowania zgłoszeń podatności musi mieć monitorowany kanał, reguły eskalacji i ochronę osoby zgłaszającej. Zespół powinien umieć odróżnić raport wymagający odtworzenia od sygnału aktywnego wykorzystania w środowisku klientów. Potrzebna jest także zdolność bezpiecznego przygotowania, podpisania i dystrybucji poprawki.

Umowy z dostawcami komponentów i usług powinny gwarantować szybkie przekazanie informacji, ponieważ producent może podlegać terminowi, choć źródło problemu znajduje się w bibliotece, chmurze lub module partnera. Odpowiedzialności nie da się skutecznie przenieść prostym zdaniem „za bezpieczeństwo odpowiada podwykonawca”.

Co zmienia się dla klientów produktów cyfrowych

Klient nie składa raportu za producenta tylko dlatego, że używa produktu, ale powinien być gotowy przyjąć komunikat i działać. Potrzebuje właściciela produktu, kontaktu bezpieczeństwa, informacji o wdrożonej wersji i sposobu szybkiej instalacji poprawki. Bez tych elementów nawet terminowe ostrzeżenie producenta może utknąć w skrzynce osoby, która już nie pracuje.

Zakupy powinny pytać dostawcę o kanał bezpieczeństwa, politykę ujawniania podatności, czas wsparcia, sposób dystrybucji poprawek i format komunikatów. Klauzula „zgodny z CRA” bez dowodów procesu ma ograniczoną wartość. Lepsze są konkretne odpowiedzi, przykład wcześniejszego biuletynu i jasne obowiązki obu stron.

Użytkownik indywidualny również skorzysta z lepszej komunikacji tylko wtedy, gdy aktualizuje urządzenie i nie ignoruje komunikatu producenta. Powiadomienie o podatności nie jest automatycznie phishingiem, ale należy je zweryfikować przez oficjalną stronę lub aplikację, a nie link z niespodziewanej wiadomości.

Przećwicz raportowanie, zanim ruszy zegar

Scenariusz ćwiczenia może zacząć się od zgłoszenia badacza, alarmu klienta lub informacji o złośliwym wykorzystaniu w internecie. Zespół ma ustalić wersje, podjąć decyzję o progu, przygotować wczesne ostrzeżenie, zaplanować poprawkę i napisać komunikat dla użytkowników. Dopiero taki przebieg pokazuje, czy 24 godziny są realne.

Ćwiczenie powinno objąć również konflikt między szybkością a poufnością. Zbyt mało informacji utrudnia klientom ochronę, ale nadmierne szczegóły przed poprawką mogą zwiększyć ryzyko. Decyzja wymaga współpracy, a nie automatycznego opublikowania całego raportu technicznego.

Organizacje mogą uporządkować role, terminy i komunikację podczas ćwiczenia reagowania na incydenty. Dla zespołów budujących produkty uzupełnieniem jest program ujawniania podatności oraz powiązanie obowiązków produktowych z szerszym wdrożeniem NIS2 w Polsce.

Fakty źródłowe i wnioski Breachroad

Komunikat Ministerstwa Cyfryzacji potwierdza datę uruchomienia obowiązków, zakres raportowania, terminy 24 godzin, 72 godzin, 14 dni i miesiąca, rolę platformy ENISA oraz CSIRT NASK, a także datę pełnego stosowania CRA.

Proponowany podział ról, dziennik decyzji, wymagania umowne i scenariusz ćwiczenia są wnioskami Breachroad. Artykuł nie jest poradą prawną; zakres obowiązku konkretnej organizacji i konkretnego zdarzenia powinien zostać oceniony na podstawie CRA oraz okoliczności sprawy.