Cyber Resilience Act: raportowanie już obowiązuje - terminy 24 i 72 godzin

Które obowiązki CRA już działają?

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.

Punktem wyjścia do oceny zakresu 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:

• 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.

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.

Odrębnie należy ocenić status administratora oprogramowania open source (open-source software steward). Komisja Europejska wskazuje, że jego szczególne obowiązki raportowe z art. 24 ust. 3 mają być stosowane od 11 grudnia 2027 r. Nie należy automatycznie przypisywać mu daty właściwej dla producentów z art. 14.

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. O kwalifikacji jako poważnego incydentu decydują przesłanki art. 14 ust. 5 CRA; sama etykieta „incydent bezpieczeństwa” nie wystarcza.

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. Oba terminy liczy się od uzyskania wiedzy o zdarzeniu, a nie kolejno: 72 godziny nie zaczynają biec dopiero po pierwszym ostrzeżeniu.

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.

Jednolita platforma raportowania CRA (Single Reporting Platform, SRP) działa od 11 września 2026 r. ENISA wskazuje ją jako kanał obowiązkowych zgłoszeń. Producent powinien zapewnić odpowiednie konto, uprawnienia i zastępstwo, aby brak dostępu nie zatrzymał zgłoszenia.

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:

• 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.