CRA to problem 2026, a nie 2027
Obowiązek raportowania wynikający z rozporządzenia CRA (Cyber Resilience Act) wchodzi w życie 11 września 2026 r. – ponad rok przed wymogami zasadniczymi. Zespoły planujące prace wstecz od terminu oznakowania CE w 2027 r. układają je w niewłaściwej kolejności.

Zapytaj zespół produktowy, kiedy rozporządzenie CRA (Cyber Resilience Act) będzie miało na niego wpływ, a większość odpowie: grudzień 2027 r. To data, od której będą obowiązywać wymogi zasadnicze, ocena zgodności oraz oznakowanie CE, i to ją najczęściej uwzględnia się w planach. Jest to jednak zła data, od której należy rozpocząć planowanie.
Rozporządzenie CRA weszło w życie 10 grudnia 2024 r., a artykuł 71 określa rozłożony w czasie harmonogram, a nie jeden termin. Przepisy dotyczące powiadamiania jednostek oceniających zgodność (rozdział IV, artykuły 35–51) będą obowiązywać od 11 czerwca 2026 r. Natomiast obowiązki raportowania określone w artykule 14 zaczną obowiązywać 11 września 2026 r. Dopiero główna część rozporządzenia, wymogi zasadnicze z załącznika I oraz ścieżka zgodności prowadząca do oznakowania CE, wejdą w życie 11 grudnia 2027 r. (rozporządzenie (UE) 2024/2847, artykuł 71; Komisja Europejska, "Cyber Resilience Act: Podsumowanie tekstu ustawodawczego", digital-strategy.ec.europa.eu). Oznacza to, że pierwsze bezwzględne zobowiązanie dla producenta objętego zakresem regulacji wchodzi w życie około piętnaście miesięcy wcześniej niż termin, który wszyscy biorą pod uwagę w swoich planach.
To nie jest apel o rozpoczęcie prac wcześnie. To stwierdzenie dotyczące kolejności działań. Zespół, który planuje prace związane z CRA wstecz od terminu oznakowania CE w 2027 r., umieszcza obowiązek raportowania na końcu, podczas gdy zarówno kalendarz, jak i zależności operacyjne nakazują, aby był on priorytetem.
Co naprawdę wchodzi w życie w 2026 r.
Artykuł 14 nie jest obowiązkiem biurokratycznym, który można dołączyć na końcu. Od 11 września 2026 r. producent wyrobu zawierającego elementy cyfrowe musi zgłaszać każdą aktywnie wykorzystywaną podatność w tym wyrobie oraz każde poważne incydent wpływający na jego bezpieczeństwo do wyznaczonego przez dane państwo członkowskie CSIRT (zespołu reagowania na incydenty komputerowe) oraz do ENISA, za pośrednictwem jednolitej platformy raportowania. Odliczanie jest bezwzględne: wstępne ostrzeżenie należy przekazać w ciągu 24 godzin od momentu uzyskania świadomości, szczegółowe powiadomienie w ciągu 72 godzin, a ostateczny raport należy sporządzić w ciągu 14 dni od udostępnienia środka naprawczego dla podatności lub w ciągu miesiąca w przypadku poważnego incydentu (rozporządzenie (UE) 2024/2847, artykuł 14).
Przeanalizuj uważnie sformułowanie wyzwalające. „Aktywnie wykorzystywana podatność” to taka, wobec której istnieją wiarygodne dowody na to, że złośliwy kod został wykonany przez podmiot na systemie bez zgody właściciela systemu (rozporządzenie (UE) 2024/2847, artykuł 3). To nie jest hipotetyczna sytuacja, którą można obsłużyć w wolnym czasie. Jest to zdarzenie w czasie rzeczywistym, które uruchamia 24-godzinny zegar w momencie, gdy dowiesz się o nim, a obowiązek ten wchodzi w życie ponad rok przed wymogami zasadniczymi, które miałyby umożliwić jego wykrycie.
Obowiązek wiedzy pojawia się przed obowiązkiem postępowania
Oto odwrócenie, którego nie dostrzega planowanie oparte na terminie 2027 r. Obowiązek zgłoszenia w ciągu 24 godzin od momentu uzyskania świadomości to, w praktyce, obowiązek bycia w stanie uzyskać świadomość. Nie możesz złożyć wstępnego ostrzeżenia dotyczącego aktywnie wykorzystywanej podatności w Twoim wyrobie, jeśli:
- nie masz kanału, przez który informacje o wykorzystaniu dotarłyby do Ciebie,
- nie posiadasz spisu inwentaryzacyjnego, który wskazuje, które wersje dostarczonego produktu zawierają podatny komponent,
- nie masz reguły klasyfikacji incydentów określającej, czy dany incydent jest „poważny”, zanim 72-godzinne okno się zamknie.
Każda z tych zdolności jest opisana w załączniku I, części II tego samego rozporządzenia: utrzymywanie wyceny oprogramowania (SBOM) obejmującej co najmniej zależności najwyższego poziomu w formacie maszynowo czytelnym, prowadzenie polityki ujawniania podatności w sposób skoordynowany z punktem kontaktowym do zgłaszania, oraz naprawianie podatności bez zbędnej zwłoki za pomocą aktualizacji zabezpieczeń (rozporządzenie (UE) 2024/2847, załącznik I, część II). Wymogi te są prawnie obowiązujące od 11 grudnia 2027 r. Jednak obowiązek raportowania, który prawnie Cię obowiązuje od 11 września 2026 r., trudno jest spełnić w sposób niezawodny bez nich. Prawo pozwala Ci odroczyć proces postępowania do 2027 r.; nie pozwala jednak odroczyć konsekwencji w momencie, gdy uzyskasz świadomość.
Zatem praktyczny efekt artykułu 14 dla każdego, kto rzeczywiście znajduje się w zakresie regulacji, polega na przyśpieszeniu o piętnaście miesięcy konieczności wdrożenia części modelu operacyjnego z załącznika I, część II. Nie dlatego, że wymogi zasadnicze wchodzą w życie wcześniej, ale dlatego, że obowiązek raportowania trudno jest spełnić w sposób niezawodny bez operacyjnego kręgosłupa, który te wymogi opisują.
Zastrzeżenie i dlaczego nie jest ono trafne
Doświadczony praktyk może podnieść zastrzeżenie, które warto poważnie rozważyć. Artykuł 14 jest wąski. Obowiązuje wyłącznie w przypadku aktywnie wykorzystywanych podatności oraz poważnych incydentów, a nie rutynowego backlogu niskiego ryzyka. Dobrze prowadzony produkt może przez długi czas nie doświadczyć zdarzenia wymagającego raportowania. Dlaczego więc nie uruchomić procesu raportowania od września 2026 r., a budowę rzeczywistego systemu postępowania z podatnościami pozostawić na 2027 r., akceptując niewielkie ryzyko wystąpienia wczesnego zdarzenia?
Istnieją trzy powody, dla których „cienki” proces jest pułapką.
Po pierwsze, ramy „rzadkich zdarzeń” błędnie oceniają ryzyko. Obowiązek nie jest uciążliwy dlatego, że występuje często. Jest niebezpieczny, ponieważ występuje nieprzewidywalnie i uruchamia 24-godzinny zegar, którego nie można zatrzymać, aby zbudować niezbędne zdolności. Tydzień, w którym dojdzie do aktywnie wykorzystywanej podatności, to właśnie ten tydzień, w którym nie możesz pozwolić sobie na tworzenie SBOM, aby ustalić, którzy klienci są dotknięci problemem.
Po drugie, kształt odpowiedzialności prawnej różni się od luki w zgodności i jest gorszy. Niekompletna postawa zgodna z załącznikiem I ujawnia się podczas oceny, w sali, z szansą na naprawienie. Pominięte powiadomienie w ciągu 24 godzin to odrębna, datowana, zewnętrznie udokumentowana porażka. Tworzy ono zapis, który później może mieć znaczenie w dyskusjach nad nadzorem lub egzekwowaniem prawa, a ścieżka raportowania, którą budujesz od września 2026 r., jest częścią tego zapisu. „Cienki” proces nie jest mniejszą wersją zgodności; jest udokumentowaną ścieżką momentów, w których nie byłeś gotowy.
Po trzecie, proces raportowania bez procesu postępowania za nim to teatr. Możliwość przesłania formularza do ENISA w ciągu 24 godzin jest bezwartościowa, jeśli nie jesteś w stanie odpowiedzieć na rzeczywiste pytania zawarte w formularzu: które wersje są dotknięte, jaki jest środek naprawczy, kiedy zostanie wydany. Obowiązek raportowania i wymogi postępowania to jeden system obserwowany w dwóch momentach. Nie możesz kupić obserwowalnej połowy i pominąć mechanizmu.
Planuj wstecz od września 2026 r.
Praktyczna korekta nie polega na „robieniu wszystkiego teraz”. Polega na zidentyfikowaniu minimalnego podzbioru wymogów zasadniczych z 2027 r., które artykuł 14 sprawia, że są kluczowe w 2026 r., oraz na zaplanowaniu tego podzbioru względem wrześniowego terminu, a nie grudniowego 2027 r.
Minimalny zakres gotowości raportowej jest mniejszy niż pełen program załącznika I i na tyle konkretny, aby można go było zaplanować:
- Aktualna wycena oprogramowania (SBOM) dla każdego dostarczonego produktu, obejmująca co najmniej zależności najwyższego poziomu, aby w dniu wystąpienia podatności możliwe było określenie zakresu wpływu w godzinach, a nie tygodniach.
- Monitorowany kanał przyjmowania zgłoszeń oraz polityka ujawniania podatności w sposób skoordynowany, aby wykorzystanie podatności i zgłoszenia od stron trzecich rzeczywiście do Ciebie docierały i uruchamiały zegar, za który jesteś odpowiedzialny.
- Pisemna reguła klasyfikacji ciężkości incydentów, która może sklasyfikować zdarzenie jako wymagające raportowania w ciągu 72 godzin, bez konieczności zwoływania komitetu.
- Wyznaczony właściciel oraz przetestowana ścieżka przesyłania do koordynującego CSIRT i ENISA, sprawdzona na platformie raportowania przed koniecznością jej użycia w sytuacji krytycznej.
Żadne z powyższych nie wymaga zharmonizowanych standardów ani ścieżki zgodności, które są nadal finalizowane na 2027 r. Wszystko to można zbudować teraz, a wszystkie te elementy stanowią zaliczkę na poczet obowiązków z 2027 r., a nie pracę wyrzucaną do kosza. Producenci ważnych produktów wymienionych w załączniku III, klasa II mają drugi powód, aby nie czekać: ich ścieżka zgodności zazwyczaj wymaga organu notyfikowanego, a organy te mogą być wyznaczane dopiero po uruchomieniu mechanizmów rozdziału IV od 11 czerwca 2026 r.. Pojemność oceny jest ograniczona, a kolejki tworzą się w terminach, a nie przed nimi.
Zasada, którą warto zachować
Gdy regulacja wchodzi w życie etapowo, główny termin jest zazwyczaj tym ostatnim, a data końcowa jest najmniej przydatną rzeczą w niej dla planowania. Zamiast tego przeczytaj harmonogram rozłożony w czasie i zapytaj, który obowiązek zależy od innych. W przypadku CRA obowiązek raportowania z artykułu 14 jest pierwszy w kalendarzu i pierwszy w grafie zależności: nie możesz zgłosić tego, czego nie jesteś w stanie wykryć, a nie jesteś w stanie wykryć bez operacyjnego kręgosłupa, który opisują wymogi z 2027 r. Planuj prace wstecz od 11 września 2026 r., a nie do przodu do 11 grudnia 2027 r., a kolejność działań sama się ułoży.
Jeśli Twoim najbliższym zadaniem jest określenie, które z Twoich produktów obejmuje CRA i czego dokładnie wymaga obowiązek raportowania od września 2026 r., to określanie zakresu i powiązania to rodzaj pracy, do którego ISMS Copilot został stworzony, aby ją przyspieszyć. Dla wielu zespołów praca nad oznakowaniem CE to furtka na 2027 r.; gotowość zgodna z artykułem 14 to furtka na 2026 r. Planuj wcześniejszą furtkę w pierwszej kolejności.
To praktyczna analiza zgodności, a nie porada prawna. Potwierdź zakres i obowiązki swojego produktu na podstawie samego rozporządzenia oraz, w razie potrzeby, z właściwym organem lub radcą prawnym.
Powiązane artykuły

Macierz ryzyka 5x5 przechodzi audyty, ale nie krytyczną analizę
ISO 27001 nigdy nie wymaga mapy cieplnej. To, czego standard rzeczywiście wymaga (spójne, trafne i porównywalne wyniki), jest testem, któremu większość macierzy ryzyka nie jest w stanie sprostać.

Opóźnienie dotyczące systemów wysokiego ryzyka w AI Act nie jest odroczeniem
UE przesunęła terminy dotyczące systemów wysokiego ryzyka na grudzień 2027 i sierpień 2028. Powód, dla którego to zrobiono, powinien zmienić sposób, w jaki to interpretujesz: to ostrzeżenie dotyczące zakresu, a nie luz dla Twojego harmonogramu.

AI a RODO: Automatyzacja transferów danych poza EOG
Automatyzuj mapowanie, monitorowanie i dokumentowanie transferów danych poza EOG z wykorzystaniem AI – ostateczne decyzje pozostają w gestii zespołów prawnych.
