4 dni temu
Od 11 września 2026 r. zegar zgłoszeń z aktu o cyberodporności liczy godziny zegarowe, także w weekend. Ilustracja wygenerowana przez AI.
Co to jest CRA i po co to komu
CRA (Cyber Resilience Act) to unijne rozporządzenie z października 2024 roku. Pierwsze, które każe producentom odpowiadać za bezpieczeństwo softu tak, jak od lat odpowiadają za bezpieczeństwo producenci tostera czy zabawki – od grudnia 2027 roku nowe programy i urządzenia dostaną wymagania techniczne i znak CE także za cyberbezpieczeństwo. Powód? Ataki idą przez dziurawe kamery, routery i aplikacje, a ich producent często o luce nie wie albo woli milczeć.
Od 11 września 2026 r. obowiązuje pierwsza część CRA: masz zgłaszać luki, które ktoś wykorzystuje, i poważne incydenty, żeby o ataku gwałtownie dowiedziały się urzędy i użytkownicy, a nie tylko włamywacz. Dla twojej firmy to nowy obowiązek i ryzyko kary. Dla twoich klientów argument, żeby wybrać ciebie, a nie konkurenta, który luki ukrywa.
Czy CRA dotyczy twojej firmy
Tak, jeżeli tworzysz produkt z elementami cyfrowymi (albo zlecasz jego stworzenie) i udostępniasz go w Unii pod własną marką w ramach działalności gospodarczej. Cena nie ma znaczenia: darmowa aplikacja z reklamami, wersja próbna albo program dodawany gratis do sprzętu też się liczą. Produkt z elementami cyfrowymi to każdy program i każde urządzenie, które łączy się z siecią: aplikacja mobilna, program księgowy instalowany u klienta, kamera, router, wtyczka do sklepu internetowego. Rozmiar firmy nie ma znaczenia.
Poza CRA zostają usługi działające wyłącznie w chmurze (chyba iż są częścią sprzedawanego produktu). Wyroby medyczne, samochody, lotnictwo i sprzęt morski mają własne przepisy. Z open source są trzy sytuacje i każda kończy się inaczej:
SytuacjaCo na to CRARozwijasz open source i nie zarabiasz na nim: ani ceną, ani płatnym wsparciem, ani danymi użytkownikówPoza CRAZarabiasz na open source: wersja komercyjna, płatne wsparcie, platforma, danePełne obowiązki producenta, ze zgłoszeniami włącznieJesteś fundacją albo inną organizacją, która utrzymuje projekt używany komercyjnie przez innych, sama bez zyskuLżejsze obowiązki: zgłaszasz tylko luki w tym, co sam współtworzysz; kar pieniężnych nie ma
Rzecz, o której możesz nie wiedzieć: zgłaszać trzeba luki także w produktach sprzedanych przed 11 grudnia 2027 roku, a według wytycznych Komisji Europejskiej choćby w takich, których już nie wspierasz. Przykład: kamerę sprzedajesz od 2022 roku i dawno przestałeś ją aktualizować. jeżeli jutro ktoś wykorzysta w niej lukę i ty się o tym dowiesz, masz 24 godziny na wczesne ostrzeżenie, choć łatać jej już nie musisz.
Masz wątpliwość? Na dedykowanej CRA stronie biznes.gov.pl możesz sprawdzić, czy akt o cyberodporności dotyczy twojego produktu. Znajdziesz tam również listę obowiązków.
Co zgłaszasz i od kiedy tyka zegar
Zgłaszasz dwa rodzaje zdarzeń:
Aktywnie wykorzystywaną podatność, czyli lukę, co do której masz wiarygodne dowody, iż ktoś wykorzystał ją w cudzym systemie bez zgody właściciela.
Poważny incydent, czyli coś, co psuje dostępność, integralność albo poufność wrażliwych danych lub funkcji, albo wprowadza do produktu złośliwy kod.
Raport badacza o luce, której nikt jeszcze nie użył, zegara nie uruchamia. Mail od klienta z logami, iż przez tę lukę ktoś wyniósł bazę, uruchamia.
Zegar startuje w chwili, gdy „dowiadujesz się” o zdarzeniu, a według wytycznych Komisji Europejskiej z 27 lipca 2026 roku dowiadujesz się wtedy, gdy po wstępnej ocenie masz rozsądny stopień pewności, iż luka jest wykorzystywana albo iż incydent się zdarzył. Niepotwierdzone podejrzenie zegara jeszcze nie uruchamia, czekanie na prezesa już go nie zatrzyma. Najlepiej zapisz godzinę tej oceny.
Trzy terminy, nie dwa
W obiegu krążą dwie liczby, 24 i 72 godziny, a etapy są trzy.
EtapTerminCo musi zawieraćWczesne ostrzeżenie24 godziny od chwili, gdy się dowiadujeszPrzy luce: kraje Unii, w których produkt jest dostępny. Przy incydencie: czy podejrzewasz działanie bezprawne albo złośliweZgłoszenie72 godziny od tej samej chwiliOgólny opis produktu i luki albo incydentu, wstępna ocena, co już zrobiliście, co może zrobić użytkownikSprawozdanie końcoweLuka: 14 dni od udostępnienia poprawki. Incydent: miesiąc od zgłoszeniaOpis z oceną wagi i skutków, kto wykorzystał lukę albo co wywołało incydent (jeśli wiadomo), szczegóły poprawki
Przy 24 i 72 godzinach liczą się godziny zegarowe i weekend niczego nie zatrzymuje, bo przepis mówi o godzinach, nie o dniach roboczych (w przeciwieństwie do większości działów IT). Tak by to wyglądało, gdyby zaczęło się dziś po południu:
KiedyCo się dziejepiątek 11 września, 15:00helpdesk dostaje od klienta dowód włamania przez lukę w panelu; zegar startujesobota 12 września, 15:00mija termin wczesnego ostrzeżenia (24 godziny)poniedziałek 14 września, 15:00mija termin zgłoszenia (72 godziny)piątek 25 wrześniawydajesz poprawkępiątek 9 październikamija termin sprawozdania końcowego o luce (14 dni od poprawki)środa 14 październikagdyby to był incydent, a nie luka: termin sprawozdania końcowego (miesiąc od zgłoszenia złożonego 14 września)
Gdzie zgłosić i co zrobić w tym tygodniu
Zgłoszenia idą przez platformę SRP unijnej agencji ENISA, uruchomioną 11 września. Rejestrujesz się na portalu (https://portal.cra-srp.enisa.europa.eu/) przez konto EU Login z uwierzytelnianiem dwuskładnikowym i wybierasz CSIRT, czyli zespół reagowania na incydenty, w kraju, w którym zapadają decyzje o bezpieczeństwie twojego produktu. W Polsce to CERT Polska z NASK. Jedno zgłoszenie trafia od razu i tam, i do ENISA.
W dniu incydentu nie ma czasu w zakładanie kont, więc warto rozważyć pięć rzeczy na ten tydzień:
Wyznacz osobę, która decyduje o zgłoszeniu, i jej zastępcę. Z numerem telefonu działającym w sobotę.
Załóż konto EU Login i zarejestruj na portalu SRP przedstawiciela firmy z wyborem CERT Polska jako koordynatora. Lepiej dziś, niż w dniu incydentu.
Opracuj listę produktów z wersjami i krajami Unii, w których są dostępne: bez niej nie wypełnisz choćby wczesnego ostrzeżenia.
Przygotuj szablon zgłoszenia z polami z tabeli wyżej i kanał do klientów (mailing albo strona statusowa), bo po zdarzeniu masz też poinformować użytkowników, których ono dotyczy; jeżeli będziesz zwlekasz, CERT zrobi to za ciebie.
Próba na sucho: fikcyjny mail o 15:00 i stoper. jeżeli zespół nie mieści się w dwóch godzinach na ćwiczeniu, w prawdziwym incydencie nie zmieści się w 24.
Pytania kieruj najpierw tam, gdzie odpowiedź jest za darmo: wpis CERT Polska z 25 maja o dobrych praktykach CRA (https://cert.pl/posts/2026/05/cra-dobre-praktyki/), FAQ ENISA o platformie, ankieta na Biznes.gov.pl.
Do prawnika idź wtedy, gdy z ankiety wychodzi produkt „ważny” albo „krytyczny”, bo tam od grudnia 2027 dochodzą osobne procedury.
Co grozi za milczenie
Brak zgłoszenia jest w najwyższej kategorii kar: do 15 milionów euro albo 2,5 procent rocznego obrotu firmy, liczonego ze wszystkich rynków, nie tylko z Unii, zależnie od tego, która kwota jest wyższa. Mikro i małe firmy nie dostaną kary za samo spóźnienie z 24-godzinnym ostrzeżeniem, choć zgłosić muszą. Osobno traktowane są fundacje utrzymujące projekty open source, z których inni korzystają komercyjnie: mają lżejsze obowiązki i kar nie płacą wcale.
Z treści rozporządzenia wynika, iż przepisy o karach i nadzorze rynku zaczną działać dopiero 11 grudnia 2027 roku. Natomiast co z producentem, który do tego czasu nie zgłosi niczego, tego ani Komisja, ani ENISA nie powiedziały. Ale lekceważyć terminów nie warto – zgłoszenia zostają w systemie, a klient objęty ustawą o krajowym systemie cyberbezpieczeństwa (jak pisaliśmy przy okazji Wykazu KSC, to dziś kilkadziesiąt tysięcy firm i urzędów) sam musi zgłosić incydent, który mu zrobiła twoja luka. Być może zapamięta, kto go zawiódł.
CRA a RODO: jedno zgłoszenie nie załatwia drugiego
Urząd Ochrony Danych Osobowych przypomniał 11 września, iż zgłoszenie do ENISA nie zastępuje obowiązków z RODO. jeżeli w incydencie ucierpiały dane osobowe, a ty przetwarzasz je dla klienta, osobno powiadamiasz tego klienta (administratora), a on w 72 godziny zgłasza naruszenie do UODO. Dwa zegary, dwa adresy.
Uważam, iż to dobre rozwiązanie, które wymusza na producentach systemu branie pod uwagę kwestii związanych z bezpieczeństwem i ochroną danych, w tym osobowych, już na etapie projektowania rozwiązań. skomentował w komunikacie urzędu z 11 września Mirosław Wróblewski, prezes Urzędu Ochrony Danych Osobowych.
Firma, która oprogramowanie tylko kupuje, dostaje dzięki CRA coś, czego RODO jej nie dawało: wiadomość o luce od producenta, choćby bez żadnej umowy o dane; co ma z nią zrobić, to temat na osobny tekst.
CRA · obowiązki producenta
Zegar CRA: od dowodu włamania do sprawozdania końcowego
Przykład redakcji: producent widzi w logach, iż luka w jego produkcie jest wykorzystywana w piątek o 15:00. Od tej minuty liczą się cztery terminy z art. 14 aktu o cyberodporności.
DZNNKINTRNTWżycie, internet i AIdi.com.pl
Zgłoszeniatrzy pierwsze doby
pt 11.09 · 15:00
Dowód, iż luka jest aktywnie wykorzystywana. Start zegara.
godzina zero
sb 12.09 · 15:00
Wczesne ostrzeżenie do CSIRT i ENISA. Wystarczy sam fakt i kraje, w których produkt działa.
24 godziny
pn 14.09 · 15:00
Zgłoszenie adekwatne: opis luki, dotknięte wersje, środki zaradcze dla użytkowników.
72 godziny
Sprawozdaniapo wydaniu poprawki
pt 25.09
Producent wydaje poprawkę. To ona uruchamia termin sprawozdania o luce.
zdarzenie, nie termin
pt 9.10
Sprawozdanie końcowe o luce: opis luki, skutki, wydana poprawka.
14 dni od poprawki
śr 14.10
Sprawozdanie końcowe o poważnym incydencie: przebieg, przyczyny, środki naprawcze.
miesiąc od zgłoszenia
Źródło: art. 14 ust. 2 i 4 rozporządzenia o cyberodporności (CRA). Daty to przykład własny redakcji; terminy liczone od godziny zero.
Podstawa prawna
Definicje producenta, produktu z elementami cyfrowymi i aktywnie wykorzystywanej podatności (pkt 42): art. 3 rozporządzenia (UE) 2024/2847 z 23 października 2024 r. (akt o cyberodporności, CRA), Dz.Urz. UE L z 20 listopada 2024 r. (https://eur-lex.europa.eu/eli/reg/2024/2847/oj/pol). Wyłączenia sektorowe: art. 2.
Terminy 24 godzin, 72 godzin, 14 dni i miesiąca, zawartość zgłoszeń, CSIRT-koordynator, informowanie użytkowników: art. 14 ust. 1-8 CRA, stosowany od 11 września 2026 r. Platforma SRP: art. 16. Zgłoszenia także dla produktów sprzed 11 grudnia 2027 r.: art. 69 ust. 3. Daty stosowania: art. 71 ust. 2.
Wytyczne Komisji Europejskiej, załącznik do komunikatu C(2026) 5252 z 27 lipca 2026 r.: pkt 213 (moment „dowiedzenia się”), pkt 210 (zgłoszenia także po zakończeniu wsparcia), pkt 217 (bez zgłaszania wstecz) (https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation).
Kary do 15 mln euro lub 2,5 proc. obrotu, ulga dla mikro i małych firm przy 24-godzinnym terminie, wyłączenie opiekunów open source: art. 64 ust. 2 i 10 CRA. Zakres (działalność gospodarcza, open source): motywy 15 i 18 CRA oraz wytyczne KE, pkt 40-43; obowiązki opiekunów open source: art. 24 CRA i wytyczne KE, pkt 81-83.
Naruszenie ochrony danych osobowych, 72 godziny na zgłoszenie do UODO: art. 33 i 34 RODO. Relacja CRA do RODO: motyw 32 CRA. Rola CERT Polska (CSIRT NASK) jako koordynatora: art. 26a ust. 1 ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252); lista koordynatorów ENISA, stan 10 września 2026 r.
Najczęstsze pytania
Od kiedy trzeba zgłaszać luki według CRA?
Od 11 września 2026 roku. Reszta obowiązków, w tym wymagania techniczne i znak CE, od 11 grudnia 2027 roku.
Czy stary produkt, którego już nie wspieram, też podlega zgłoszeniom?
Tak. Rozporządzenie rozciąga obowiązek na produkty sprzedane przed 11 grudnia 2027 roku, a wytyczne Komisji dodają, iż koniec wsparcia go nie zdejmuje. Zdejmuje tylko obowiązek łatania.
Czy trzeba zgłaszać luki, o których wykorzystaniu wiedziałem przed 11 września?
Nie, wytyczne Komisji wykluczają zgłaszanie wstecz. jeżeli jednak o samej luce wiedziałeś wcześniej, a o tym, iż ktoś ją wykorzystuje, dowiadujesz się dopiero teraz, zgłoszenie obowiązuje.
Czy zgłoszenie do ENISA zwalnia ze zgłoszenia naruszenia do UODO?
Nie. Zgłoszenie z CRA dotyczy bezpieczeństwa produktu, zgłoszenie z RODO dotyczy danych osobowych i idzie do administratora, a od niego do UODO. jeżeli przetwarzasz dane dla klienta, robisz jedno i drugie. Potwierdził to UODO w komunikacie z 11 września 2026 roku.
Źródła
Komunikat Urzędu Ochrony Danych Osobowych „Akt o cyberodporności (CRA), wzmocnienie cyberochrony danych”, 11 września 2026 r.
Rozporządzenie (UE) 2024/2847 (akt o cyberodporności), tekst w EUR-Lex.
Komisja Europejska: strona „Cyber Resilience Act, reporting obligations” oraz wytyczne w sprawie stosowania CRA, załącznik do komunikatu C(2026) 5252 z 27 lipca 2026 r., pkt 210, 213 i 217.
ENISA: komunikat o uruchomieniu platformy SRP z 11 września 2026 r., FAQ o platformie oraz lista CSIRT-ów wyznaczonych na koordynatorów (stan 10 września 2026 r.).
CERT Polska, „CRA: nowe obowiązki dla producentów systemu i korzyści dla użytkowników”, 25 maja 2026 r.
Biznes.gov.pl, usługa „Pre-kwalifikacja dotycząca wymagań dla producenta IT (CRA)”, Ministerstwo Rozwoju i Technologii.
Materiał ma charakter informacyjny i redakcyjny, nie powstał na zlecenie żadnej instytucji i nie jest poradą prawną. Stan prawny i informacje o platformie ENISA według stanu na 11 września 2026 roku. Przed wdrożeniem własnej procedury sprawdź sytuację swojego produktu w ankiecie na Biznes.gov.pl albo z prawnikiem.
