Cyber Resilience Act (CRA) — obowiązki i przygotowanie

Cyber Resilience Act (CRA) nie kończy się na liście wymagań. Trzeba wiedzieć, którego produktu dotyczą, kto ma wykonać działanie, do kiedy, na jakiej podstawie podjęto decyzję i gdzie znajduje się dowód.

Od 11 września 2026 r. obowiązują już przepisy CRA dotyczące raportowania określonych podatności i poważnych incydentów. Główne obowiązki rozporządzenia będą stosowane od 11 grudnia 2027 r. To oznacza, że część procesu trzeba mieć działającą teraz, a resztę budować tak, aby nie odtwarzać dokumentacji w ostatniej chwili.

Najważniejsze daty CRA

Data	Co się zmienia
11 września 2026	stosowanie obowiązków raportowych z art. 14 CRA
11 grudnia 2027	pełne stosowanie zasadniczej części CRA

Dla obowiązków raportowych termin liczony jest od momentu uzyskania wiedzy o zdarzeniu. Komisja wskazuje wczesne ostrzeżenie do 24 godzin oraz pełne zgłoszenie do 72 godzin. Raport końcowy ma odrębny termin dla aktywnie wykorzystywanej podatności i dla poważnego incydentu.

Zobacz praktyczny proces raportowania 24/72 h

CRA dotyczy produktu, nie abstrakcyjnej „zgodności firmy”

Pierwszym pytaniem powinno być: jaki konkretny produkt z elementami cyfrowymi oceniamy?

Rozporządzenie obejmuje produkty software i hardware oraz, w określonych warunkach, powiązane rozwiązania zdalnego przetwarzania danych. Osobno znaczenie ma rola organizacji: producenta, importera, dystrybutora albo podmiotu, który dokonuje istotnej modyfikacji.

Dlatego warto zacząć od karty jednego produktu:

nazwa i jednoznaczny identyfikator produktu;
wersja lub linia wydań;
producent i marka, pod którą produkt jest oferowany;
sposób udostępniania na rynku UE;
główne funkcje i przewidywane użycie;
komponenty i zależności;
usługi zdalne niezbędne do działania produktu;
okres wsparcia;
osoby odpowiedzialne za bezpieczeństwo, podatności i wydania.

Dowiedz się, jak sprawdzić zakres CRA dla produktu

Siedem obszarów, które trzeba połączyć

1. Zakres

Najpierw ustal, czy dany produkt i rola firmy mieszczą się w CRA. Sama etykieta „SaaS”, „IoT” albo „oprogramowanie” nie wystarcza.

2. Ryzyko produktu

CRA wiąże wymagania z oceną ryzyka cyberbezpieczeństwa produktu. Ocena powinna być powiązana z wersją produktu i aktualizowana, gdy zmienia się architektura, przeznaczenie albo profil ryzyka.

3. Security by design i security by default

Wymaganie musi zejść do poziomu pracy engineeringu: decyzji projektowej, zadania, testu, akceptacji i dowodu.

Przejdź do security by design w CRA

4. Podatności i SBOM

CRA wymaga identyfikowania oraz dokumentowania podatności i komponentów, w tym sporządzenia Software Bill of Materials (SBOM) w powszechnie używanym, maszynowo czytelnym formacie obejmującym co najmniej zależności najwyższego poziomu.

Zobacz, jak traktować SBOM jako proces, a nie plik

5. Raportowanie

Od 11 września 2026 r. działa CRA Single Reporting Platform (SRP). W praktyce organizacja potrzebuje nie tylko dostępu do portalu, lecz również jasnego momentu T0, kryteriów eskalacji, właściciela, zastępstwa i kompletu informacji potrzebnych do zgłoszenia.

6. Dokumentacja techniczna

Dokumentacja nie powinna być archiwum przypadkowych plików. Musi pozwolić prześledzić produkt, wersję, architekturę, ocenę ryzyka, proces obsługi podatności, testy, decyzje i podstawę okresu wsparcia.

Sprawdź strukturę dokumentacji technicznej CRA

7. Okres wsparcia

Producent określa okres wsparcia na podstawie przewidywanego czasu użycia produktu i innych kryteriów wskazanych w CRA. Co do zasady to co najmniej pięć lat, chyba że oczekiwany czas użycia produktu jest krótszy.

Zobacz, jak udokumentować okres wsparcia

Gdzie firmy mają największy problem

Badanie ENISA z 2026 r. pokazuje różnicę między znajomością nazwy regulacji a zdolnością jej wykonania. W próbie 194 dobrowolnych odpowiedzi 66% respondentów znało CRA, ale 54% deklarowało ograniczoną wiedzę lub jej brak w obszarze oceny zgodności, a 42% w obszarze wymaganej dokumentacji. Wsparcie przy dokumentacji technicznej wskazało 73% respondentów.

Tych danych nie należy traktować jako reprezentatywnego obrazu całego rynku — w próbie było tylko 11 odpowiedzi z Polski. Są jednak dobrym sygnałem, że problemem nie jest wyłącznie „wiedza o CRA”, lecz wykonanie i utrzymanie procesu.

Jak Pulsar GRC pasuje do tej pracy

Pulsar GRC łączy obszary, które zwykle są rozrzucone między dokumentami, arkuszami, ticketami i pocztą:

wymaganie → ryzyko → kontrola lub działanie → właściciel → termin → dokument lub dowód → przegląd → historia decyzji.

W obecnej architekturze produktu dostępne są m.in. audyty, kontrole, ryzyka, dokumenty, dowody, raporty i eksport, CAPA, dostawcy, zadania i powiadomienia oraz historia analiz. To pozwala prowadzić pracę operacyjną i utrzymywać ślad decyzji bez udawania, że narzędzie samo rozstrzyga kwestię prawną.

Pulsar nie certyfikuje zgodności z CRA, nie zastępuje oceny prawnej i nie powinien samodzielnie kwalifikować zdarzenia jako podlegającego obowiązkowi raportowania. Decyzje o zakresie, klasyfikacji zdarzenia i wysłaniu zgłoszenia pozostają po stronie odpowiedzialnych osób.

Zacznij od jednego produktu

Nie próbuj „wdrażać CRA w całej firmie” jako jednego wielkiego projektu. Wybierz jeden produkt, ustal jego zakres, właścicieli, aktualne ryzyka, proces podatności, dokumentację i okres wsparcia. Dopiero wtedy widać realne luki.

Zobacz Pulsar GRC na jednym procesie

Źródła

Stan źródeł: 12 września 2026 r.