Cyber Resilience Act od 11 września 2026 r. — kto i co musi raportować w 24 i 72 godziny?

Kiedy zaczynają działać obowiązki raportowe CRA?

Cyber Resilience Act wszedł w życie 10 grudnia 2024 r. Większość jego obowiązków, w tym zasadnicze wymagania dotyczące projektowania produktów, oceny zgodności, dokumentacji i oznakowania CE, będzie stosowana od 11 grudnia 2027 r. Ustawodawca unijny przewidział jednak wcześniejszy termin dla zgłaszania podatności i incydentów: art. 14 stosuje się od 11 września 2026 r.

To rozdzielenie terminów ma praktyczną konsekwencję. Firma nie może uznać, że każdy produkt sprzedawany przed grudniem 2027 r. pozostaje poza CRA. Komisja Europejska wyjaśnia, że obowiązki raportowe obejmują produkty z elementami cyfrowymi udostępnione na rynku Unii, w tym produkty wprowadzone wcześniej.

Proces raportowania powinien więc działać dla aktualnego portfolio, a nie tylko dla nowych wersji projektowanych zgodnie z pełnym reżimem CRA.

Jakie produkty mogą podlegać CRA?

Rozporządzenie obejmuje sprzęt i oprogramowanie, których zamierzony cel lub racjonalnie przewidywalne użycie wiąże się z bezpośrednim albo pośrednim logicznym lub fizycznym połączeniem z urządzeniem lub siecią. Produktem z elementami cyfrowymi może być zarówno gotowe urządzenie, jak i aplikacja, program komputerowy albo komponent udostępniany oddzielnie. Zakres może objąć również rozwiązanie zdalnego przetwarzania danych, jeżeli zostało zaprojektowane przez producenta lub na jego odpowiedzialność i jest niezbędne do realizacji jednej z funkcji produktu.

Nie każda usługa cyfrowa jest automatycznie produktem CRA. Trzeba przeanalizować, co firma faktycznie udostępnia na rynku, jak produkt jest dostarczany i czy element zdalny stanowi integralną część jego funkcji. Osobnej oceny wymagają rozwiązania open source oraz produkty podlegające sektorowym regulacjom unijnym wyłączającym albo modyfikującym zastosowanie CRA.

Pierwszym etapem przygotowań powinna być mapa produktów, wersji, komponentów i odpowiedzialnych podmiotów. Sama lista systemów używanych wewnątrz organizacji nie odpowiada na pytanie o zakres rozporządzenia.

Kto jest producentem i odpowiada za zgłoszenie?

Producentem jest nie tylko podmiot, który samodzielnie pisze kod lub montuje urządzenie. Jest nim również firma, która zleca zaprojektowanie, opracowanie lub wytworzenie produktu i wprowadza go na rynek pod własną nazwą albo znakiem towarowym. Marka handlowa i sposób oferowania produktu mogą być zatem równie ważne jak techniczny podział prac.

W praktyce trzeba odróżnić co najmniej cztery role:

Podstawowy obowiązek raportowy ciąży na producencie. Nie oznacza to jednak, że pozostali uczestnicy łańcucha mogą pominąć podatność. Ich umowy i procedury powinny zapewniać szybkie przekazanie informacji podmiotowi, który ma dokonać kwalifikacji i zgłoszenia. Outsourcing utrzymania produktu lub bezpieczeństwa nie przenosi automatycznie ustawowej roli producenta.

• producenta sprzedającego produkt pod własną marką;
• zewnętrzny software house lub zakład produkcyjny wykonujący prace dla producenta;
• importera wprowadzającego do Unii produkt producenta spoza UE;
• dystrybutora udostępniającego produkt bez zmiany jego właściwości.

Jakie zdarzenia trzeba raportować?

CRA nie nakazuje zgłaszania każdej wady lub każdego incydentu IT. Art. 14 koncentruje się na dwóch kategoriach.

Pierwsza to aktywnie wykorzystywana podatność produktu z elementami cyfrowymi. Chodzi o podatność, w odniesieniu do której istnieją wiarygodne dowody, że złośliwy podmiot wykorzystał ją w systemie bez zgody właściciela. Sama możliwość stworzenia exploita albo zgłoszenie teoretycznego błędu nie musi jeszcze oznaczać aktywnego wykorzystania. Nie zwalnia to producenta z obsługi podatności, lecz wpływa na uruchomienie konkretnej ścieżki raportowej.

Druga kategoria to poważny incydent mający wpływ na bezpieczeństwo produktu. Ocena wymaga ustalenia wpływu na zdolność produktu do ochrony dostępności, autentyczności, integralności lub poufności danych albo funkcji. Zdarzenie operacyjne w infrastrukturze producenta nie zawsze będzie takim incydentem, ale może równolegle podlegać KSC, RODO albo obowiązkom kontraktowym.

Firma potrzebuje krótkiej matrycy kwalifikacyjnej, która łączy ustalenia techniczne z definicjami CRA. Bez niej zespół bezpieczeństwa może traktować wymóg jako ogólne „zgłoszenie każdego incydentu”, a dział prawny dowie się o zdarzeniu dopiero po upływie 24 godzin.

Jak liczyć terminy 24 i 72 godzin?

Terminy biegną od chwili, w której producent uzyska wiedzę o aktywnie wykorzystywanej podatności albo poważnym incydencie. Pierwszy etap to wczesne ostrzeżenie w ciągu 24 godzin. Jego zadaniem nie jest zastąpienie pełnego raportu. Powinno sygnalizować zdarzenie i przekazać dostępne podstawowe informacje.

W ciągu 72 godzin producent przekazuje zgłoszenie uzupełniające z dostępnymi informacjami o produkcie, charakterze podatności lub incydentu, jego skutkach i podjętych działaniach. Ustawowy model zakłada, że pełna analiza może nadal trwać. Brak pewności co do każdego szczegółu nie uzasadnia automatycznie wstrzymania pierwszego zgłoszenia.

Końcowy raport dotyczący aktywnie wykorzystywanej podatności składa się co do zasady nie później niż 14 dni od udostępnienia środka naprawczego lub ograniczającego ryzyko. Przy poważnym incydencie termin raportu końcowego wynosi zasadniczo miesiąc od zgłoszenia uzupełniającego. Dokładna treść powinna odpowiadać rodzajowi zdarzenia i rozwojowi analizy.

Zgłoszenia będą przekazywane przez jednolitą platformę raportowania CRA tworzoną przez ENISA. Komisja wskazuje, że ma ona być operacyjna na dzień rozpoczęcia stosowania obowiązków.

Jak CRA łączy się z NIS2/KSC i RODO?

Jedno zdarzenie może uruchamiać kilka procesów. Producent software’u może równocześnie być podmiotem kluczowym lub ważnym w rozumieniu KSC, a incydent może prowadzić do naruszenia danych osobowych. Zakresy nie są jednak identyczne.

CRA koncentruje się na bezpieczeństwie produktu z elementami cyfrowymi i obowiązkach producenta. KSC/NIS2 dotyczy bezpieczeństwa sieci i systemów informacyjnych określonych podmiotów oraz ciągłości świadczonych przez nie usług. RODO chroni dane osobowe i wymaga od administratora oceny ryzyka dla praw lub wolności osób.

Dlatego procedura powinna zawierać trzy odrębne testy, wspólny zespół faktów i skoordynowane terminy. Artykuł o NIS2 i wpisie do Wykazu KSC pomaga ustalić status organizacji, a materiał o naruszeniu danych w pierwszych 72 godzinach opisuje osobną ścieżkę RODO.

Co zmienić w umowach z dostawcami i klientami?

Producent potrzebuje informacji od podmiotów, które rozwijają, hostują, monitorują lub serwisują produkt. Umowa z software house’em, operatorem chmury albo dostawcą komponentu powinna określać co najmniej:

Nie wystarczy ogólna klauzula, że dostawca „przestrzega prawa”. Procedura musi działać poza godzinami pracy i w weekendy. Warto ją połączyć z mechanizmem obsługi błędów oraz SLA opisanym w umowie SaaS z klientem biznesowym.

• szybki obowiązek zgłoszenia podejrzenia podatności lub incydentu, krótszy niż ustawowe 24 godziny;
• dostęp do logów, dowodów, repozytoriów i osób technicznych;
• zasady kwalifikacji zdarzenia i wskazanie podmiotu podejmującego decyzję o zgłoszeniu;
• współpracę przy przygotowaniu raportów, aktualizacji i komunikacji z użytkownikami;
• kontrolę podwykonawców i komponentów osób trzecich;
• zachowanie poufności bez blokowania obowiązkowego zgłoszenia;
• podział kosztów działań naprawczych i odpowiedzialności.