--- title: "Obowiązek raportowania z Cyber Resilience Act wszedł w życie. Procesy większości producentów to wciąż teatr. | Guardian360" description: "Obowiązek raportowania z Cyber Resilience Act wszedł w życie 11 września 2026 roku: producenci muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty w ciągu 24 godzin. Dane z badań pokazują wysoką świadomość, ale słabą gotowość. Co trzeba zgłaszać, kogo to dotyczy i jak naprawdę wygląda bycie przygotowanym." url: https://guardian360.net/pl/blog/cra-reporting-duty-is-live/ locale: en source: guardian360.net --- [← Wszystkie wpisy](https://guardian360.net/pl/blog/) Opinia # Obowiązek raportowania z Cyber Resilience Act wszedł w życie. Procesy większości producentów to wciąż teatr. Autor Jan Martijn Broekhof · 11 września 2026 Dziś, 11 września 2026 roku, obowiązek raportowania z Cyber Resilience Act wchodzi w życie w całej Unii Europejskiej. Nie w grudniu 2027 roku, gdy zaczną obowiązywać zasadnicze wymagania dla produktów i gdy wszystkim zapowiedziano prawdziwą rozprawę. Dziś. Jeśli wytwarzają Państwo produkt z elementami cyfrowymi i sprzedają go na rynku UE, zegar odliczający czas do Państwa pierwszego zgłoszenia rusza od tego momentu, niezależnie od tego, czy Państwa organizacja zaznaczyła sobie tę datę, czy nie. W lipcu pisałem, że Cyber Resilience Act to rozporządzenie, któremu nikt nie przyglądał się wystarczająco uważnie, takie, które potrafi wycofać produkt z rynku, a nie tylko ukarać grzywną stojącą za nim firmę. Tamten tekst skupiał się na szerokim obrazie zgodności: zakresie, kategoryzacji, relacji z NIS2. Ten dotyczy dużo węższego, dużo ostrzejszego obowiązku, który właśnie wszedł w życie, oraz niewygodnej przepaści między tym, ilu producentów mówi, że o nim wie, a iloma faktycznie potrafi działać w ramach godzin, które daje im prawo. ## Data, której nikt nie pilnował Większość doniesień o CRA wciąż krąży wokół grudnia 2027 roku, i to zrozumiałe, bo właśnie wtedy zasadnicze wymagania w zakresie cyberbezpieczeństwa oraz obowiązki oceny zgodności zaczną obowiązywać w pełni. Ale artykuł 14 rozporządzenia wydzielił osobną, wcześniejszą datę przeznaczoną specjalnie na raportowanie: od 11 września 2026 roku producenci muszą zgłaszać aktywnie wykorzystywane podatności i poważne incydenty dotyczące ich produktów, a obowiązek ten obejmuje produkty już obecne na rynku, nie tylko nowe premiery. Komisja Europejska opublikowała swoje praktyczne wytyczne w tej sprawie 27 lipca 2026 roku, zaledwie kilka tygodni przed wejściem tej daty w życie. To wąskie okno dla obowiązku, do którego dołączono pierwszy termin liczony w 24 godzinach. Zasadnicze wymagania w grudniu 2027 roku dają producentom mniej więcej piętnaście miesięcy rozbiegu od tego momentu. Obowiązek raportowania dał znacznie mniej. ## Co dokładnie trzeba zgłaszać? To pytanie, na którym ludzie się potykają, i warto odpowiedzieć na nie precyzyjnie, a nie ogólnikami. Zgłaszają Państwo aktywnie wykorzystywaną podatność, czyli taką, wobec której istnieją wiarygodne dowody, że ktoś właśnie teraz używa jej przeciwko Państwa produktowi. Zgłaszają Państwo poważny incydent, czyli coś, co faktycznie narusza bezpieczeństwo Państwa produktu, a nie jedynie teoretyczną słabość. Czego Państwo nie zgłaszają, to każdego CVE przypisanego do Państwa bazy kodu, każdego wyniku własnego testu penetracyjnego ani każdego zgłoszenia w ramach programu odpowiedzialnego ujawniania podatności lub bug bounty, o ile nie ma dowodu, że rzeczywiście doszło do wykorzystania. Webinar, który holenderskie Ministerstwo Spraw Gospodarczych i Polityki Klimatycznej oraz National Cyber Security Centre (NCSC) przeprowadziły 27 sierpnia, bez ogródek mówił o tym rozróżnieniu, i słusznie: bez niego producenci albo zalaliby swój krajowy CSIRT szumem, albo, co gorsza, założyliby, że każde zgłoszenie podatności wymaga tej samej 24-godzinnej pilności, i wypaliliby zespół, który ma zajmować się tymi, które naprawdę się liczą. Przypadki o niższej istotności nadal można zgłaszać dobrowolnie i istnieją dobre powody, by wyrobić sobie ten nawyk. Ale obowiązek prawny spoczywa konkretnie na aktywnym wykorzystaniu i poważnych incydentach, a wiedza o tym, gdzie przebiega ta granica, to pierwsza rzecz, którą Państwa proces reagowania na incydenty musi mieć poprawnie ustawioną. ## Zegar nie zatrzymuje się na czas Państwa narady o reagowaniu na incydent Gdy już Państwo wiedzą, harmonogram jest etapowy i bezlitosny. Wczesne ostrzeżenie wychodzi w ciągu 24 godzin od powzięcia wiedzy. Pełniejsze zgłoszenie następuje w ciągu 72 godzin i obejmuje to, co wiadomo do tego momentu o charakterze, skutkach i środkach łagodzących. Raport końcowy zamyka sprawę: czternaście dni po udostępnieniu środka naprawczego dla podatności lub miesiąc w przypadku poważnego incydentu, zgodnie z wytycznymi Komisji Europejskiej. Analiza nowego obowiązku autorstwa Freshfields formułuje myśl, przy której warto się zatrzymać: okresy raportowania zaczynają biec w chwili, gdy powezmą Państwo wiedzę, a zegar nie zatrzymuje się w weekendy ani w dni ustawowo wolne. Nie ma taryfy ulgowej za to, że Państwa szef bezpieczeństwa był na konferencji albo że incydent zdarzył się w piątkowy wieczór. Jeśli Państwa organizacja nie ma jeszcze zdefiniowanego procesu określającego, kto ocenia zgłoszenie, kto decyduje, że przekracza ono próg, i kto je składa, budują Państwo ten proces po raz pierwszy pod presją działającego terminu 24 godzin, co jest dokładnie najgorszym momentem na budowanie czegokolwiek. Samo raportowanie odbywa się przez Państwa krajowy CSIRT, w Holandii jest to NCSC, oraz ogólnounijną Single Reporting Platform prowadzoną przez ENISA, więc producent w Belgii, Niemczech czy gdziekolwiek indziej w UE stosuje ten sam etapowy harmonogram za pośrednictwem własnego krajowego punktu kontaktowego. Mechanika różni się nieco w zależności od państwa członkowskiego; obowiązek i terminy już nie. ## Dlaczego liczby dotyczące gotowości są aż tak złe? Tutaj twierdzenie, że „procesy większości producentów to teatr”, musi się obronić, a dane z badań potwierdzają je dobitniej, niż się spodziewałem. SME Cyber Resilience Maturity Assessment Model opracowany przez ENISA, opublikowany 13 lipca 2026 roku i oparty na badaniach terenowych obejmujących 194 organizacje w 31 krajach, wykazał wysoką świadomość CRA, ale konsekwentnie słabą praktyczną gotowość, przy czym reagowanie na incydenty i zarządzanie cyklem życia produktu wypadły jako dwa najsłabsze obszary ogółem. Świadomość, że prawo istnieje, to nie to samo co posiadanie procesu zdolnego działać w oknie 24 godzin. Badanie gotowości do CRA z 2026 roku, przeprowadzone przez Linux Foundation i OpenSSF na 843 respondentach, opowiada podobną historię z innej strony. Sześćdziesiąt sześć procent wciąż nie wiedziało, co właściwie muszą zrobić, by osiągnąć zgodność, i liczba ta ledwie drgnęła z 62 procent rok wcześniej. Tylko 41 procent producentów spodziewało się osiągnąć pełną zgodność do terminu w grudniu 2027 roku, a jedynie 34 procent w ogóle poprawnie wskazało tę datę. Wśród respondentów, którzy w ogóle byli świadomi istnienia CRA, 54 procent wciąż nie potrafiło wyraźnie odróżnić obowiązków producenta od obowiązków opiekuna oprogramowania open source. Nic z tego nie jest przytykiem pod adresem żadnego konkretnego zespołu ds. zgodności. To odzwierciedla rozporządzenie, które przeszło od abstrakcji do praktyki szybciej, niż większość procesów organizacyjnych zdołała za nim nadążyć. Ale oznacza to, że znacząca część producentów czytających te słowa przekroczyła granicę 11 września bez sprawdzonego procesu za sobą, co jest dokładnie tym scenariuszem, który obowiązek raportowania miał zdemaskować. ## Kto właściwie musi raportować? Zgodnie z CRA obowiązek raportowania spoczywa na producencie, czyli podmiocie, który wprowadza produkt z elementami cyfrowymi na rynek UE pod własną nazwą lub marką, a wielkość organizacji Państwa z niego nie zwalnia. Importer lub dystrybutor zasadniczo nie ponosi samodzielnego obowiązku raportowania, chyba że sprzedaje pod własną marką lub istotnie modyfikuje produkt, w którym to przypadku faktycznie staje się producentem tego produktu. Opiekunowie oprogramowania open source podlegają lżejszej wersji tego samego obowiązku, co odzwierciedla odmienną relację, jaką mają z utrzymywanymi przez siebie produktami. Małe i mikroprzedsiębiorstwa również są w pełni objęte zakresem; jedyne ustępstwo, które potwierdziło holenderskie NCSC, to brak kary za niedotrzymanie ścisłego okna 24 godzin w tej kategorii, co jest złagodzeniem, a nie zwolnieniem. Jeden szczegół wart podkreślenia, bo wywołuje realne zamieszanie: sam CRA nie wymaga żadnej wcześniejszej rejestracji, zanim będą Państwo mogli raportować. Nie potrzebują Państwo konta ani loginu, by złożyć zgłoszenie. To celowy wybór projektowy, odrębny od obowiązku rejestracji istniejącego na mocy Cyberbeveiligingswet (holenderskiej transpozycji NIS2) dla organizacji, które podlegają również tej ustawie. Oba obowiązki biegną równolegle, a nie jako jeden połączony proces, i ich mylenie to łatwy błąd do popełnienia. ## Jak właściwie wygląda „bycie przygotowanym”? Przygotowanie do obowiązku raportowania z CRA nie jest z zasady skomplikowane. Jest wymagające w praktyce, a to zupełnie inny problem. Proszę zacząć od uczciwej inwentaryzacji tego, co rzeczywiście znajduje się w Państwa produktach, najlepiej za pomocą Software Bill of Materials, bo nie da się ocenić, czy zgłoszona podatność Państwa dotyczy, jeśli nie wiedzą Państwo, jakie komponenty dostarczają. Proszę z wyprzedzeniem ustalić własne wewnętrzne progi tego, co liczy się jako aktywne wykorzystanie lub poważny incydent, tak aby ta ocena nie była dokonywana po raz pierwszy pod presją. Proszę zbudować ścieżkę eskalacji z przypisanymi rolami: kto sygnalizuje, kto decyduje, kto składa zgłoszenie. Proszę już teraz przygotować szablony wczesnego ostrzeżenia, zgłoszenia po 72 godzinach i raportu końcowego, póki nikt nie działa pod presją terminu. I proszę zgrać to z tym, w ramach czego już Państwo raportują, bo spora część producentów czytających te słowa podlega także pod Cyberbeveiligingswet lub RODO, a prowadzenie trzech nieskoordynowanych procesów raportowania to ryzyko samo w sobie. To, nie przypadkiem, ta sama dyscyplina, za którą opowiadałem się w lipcu, gdy pisałem o szerszych wymaganiach zgodności z CRA: wiedzieć, co się ma, uczciwie to skategoryzować i przygotować dokumentację, zanim poprosi o nią regulator. Obowiązek raportowania po prostu przesunął ten argument z „kiedyś” na „teraz”. Gdyby klient powiedział Państwu dziś rano, że ktoś aktywnie wykorzystuje podatność w Państwa produkcie, czy Państwa organizacja wiedziałaby w ciągu 24 godzin, kto dokładnie zajmie się tym zgłoszeniem? Jeśli uczciwa odpowiedź brzmi „jakoś to ogarniemy”, to obowiązek raportowania nie wszedł dziś w życie na darmo. ## Źródła - European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: [digital-strategy.ec.europa.eu/en/policies/cra-reporting](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026. - Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: [linuxfoundation.org](https://www.linuxfoundation.org/blog/the-cra-readiness-reality-what-changed-and-what-didnt-between-2025-and-2026) - Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: [freshfields.com](https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/cyber-resilience-act-reporting-obligations-take-effect-on-11-september-2026-102nzmk) - Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.