Producent oprogramowania dowiaduje się w piątek wieczorem, że ktoś właśnie wykorzystuje lukę w jego produkcie. Od tej chwili ma dobę na wysłanie wczesnego ostrzeżenia, trzy doby na pełne zgłoszenie i czternaście dni na sprawozdanie końcowe, liczone od udostępnienia poprawki. Tak od 11 września wygląda obowiązek z unijnego rozporządzenia znanego jako Cyber Resilience Act. Obejmie on znacznie szersze grono firm, niż sugeruje słowo cyber w nazwie.
Co trzeba zgłosić i w jakim czasie
Komisja Europejska formułuje to zwięźle: od 11 września 2026 producenci mają obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktów z elementami cyfrowymi.
Terminy są trzystopniowe i liczą się od momentu powzięcia wiadomości o zdarzeniu.
Najpierw 24 godziny na wczesne ostrzeżenie. To nie jest pełny opis sprawy, tylko sygnał, że coś się dzieje. Potem 72 godziny na pełne zgłoszenie. Na końcu sprawozdanie końcowe: 14 dni przy podatnościach, licząc od chwili, gdy dostępny jest środek naprawczy, albo miesiąc przy incydentach.
Warto zobaczyć, gdzie zaczyna się odliczanie. Nie przy publikacji poprawki i nie przy potwierdzeniu skali. Przy powzięciu wiadomości. Firma, która dowiaduje się o problemie w piątek po godzinach, ma pierwszy termin na sobotę wieczór.
Ta konstrukcja ma swoją logikę. Regulator zakłada, że informacja o aktywnie wykorzystywanej luce jest cenna natychmiast, nawet niepełna, bo pozwala ostrzec innych. Dlatego pierwszy krok nazywa się ostrzeżeniem, a nie raportem. Dla firmy oznacza to jednak zmianę nawyku. Dotąd naturalnym odruchem było najpierw zrozumieć problem, potem o nim mówić. Teraz kolejność jest odwrotna i to jest największa różnica w praktyce, większa niż sama liczba godzin.
Kogo obejmuje Cyber Resilience Act, a kogo nie
Adresatem są producenci produktów z elementami cyfrowymi, czyli oprogramowania, sprzętu, urządzeń podłączonych do sieci i automatyki przemysłowej. Krąg jest więc szerszy niż sama branża informatyczna, ale gdzie dokładnie przebiega jego granica, rozstrzyga definicja z rozporządzenia, a nie intuicja.
Dwa wyłączenia warto znać. Pierwsze dotyczy niekomercyjnego oprogramowania open source, które zostaje poza zakresem. Drugie obejmuje branże objęte odrębnymi przepisami: wyroby medyczne, pojazdy, lotnictwo i wyposażenie morskie. Tę drugą listę podaje analiza prawna TPA Poland, a nie sama strona Komisji. Przy wątpliwej klasyfikacji lepiej więc sprawdzić ją w rozporządzeniu, bo katalog może nie kończyć się na tych pozycjach.
Pierwsze wyłączenie bywa źle rozumiane. Nie jest przywilejem każdego, kto korzysta z otwartego kodu. Dotyczy niekomercyjnego wydawania takiego oprogramowania. Firma, która buduje produkt na otwartych komponentach i sprzedaje go klientom, powinna sprawdzić swoją sytuację w rozporządzeniu. Założenie, że wyłączenie ją obejmuje, jest tu najdroższym z możliwych błędów.
Gdzie trafia zgłoszenie
Zgłasza się jednokrotnie, przez wspólną platformę o nazwie Single Reporting Platform. Komisja zapowiada, że będzie ona działać najpóźniej 11 września. Zgłoszenie trafia do zespołu reagowania w państwie głównej siedziby producenta. Informacja idzie równocześnie do agencji ENISA. Dla polskiej firmy oznacza to jedno zgłoszenie zamiast osobnych pism do dwóch instytucji.
Jedną rzecz lepiej ustalić zawczasu niż w dobie liczonej od piątkowego wieczoru. Rozporządzenie mówi o zespole reagowania właściwym dla państwa głównej siedziby. Materiały informacyjne nie wskazują jednak wprost, który polski zespół przyjmie takie zgłoszenia. W Polsce działa ich kilka, o różnych właściwościach. Tę odpowiedź warto mieć w procedurze, a nie szukać jej w trakcie incydentu.
Jest jeszcze obowiązek, o którym mówi się najmniej. Według analizy TPA Poland trzeba poinformować użytkowników produktu dotkniętego poważnym incydentem. W odpowiednich przypadkach także o wykorzystywanej podatności, razem ze środkami zaradczymi. Jeśli tak, zgłoszenie do urzędu nie zamyka sprawy. Warto to sprawdzić, bo powiadomienie klientów wymaga zwykle więcej przygotowania niż wysłanie formularza.
Obowiązek rusza wcześniej niż kara
Tu jest asymetria, którą łatwo przeoczyć przy pobieżnej lekturze kalendarza.
Rozporządzenie (UE) 2024/2847 weszło w życie w listopadzie 2024, a stosuje się je co do zasady od 11 grudnia 2027. Obowiązki sprawozdawcze wyjęto z tego kalendarza i przesunięto o piętnaście miesięcy do przodu, na 11 września 2026. Przepisy o karach zostały tam, gdzie reszta.
Powstaje więc okres, w którym obowiązek już działa, a sankcji za jego złamanie jeszcze nie ma. Kary przewidziane w rozporządzeniu sięgają 15 mln euro albo 2,5% światowego rocznego obrotu, ale zaczną obowiązywać dopiero pod koniec 2027 roku.
Wniosek praktyczny jest odwrotny do intuicyjnego. Piętnaście miesięcy to nie zapas na nicnierobienie. To okres, w którym firma może przećwiczyć procedurę zgłoszeniową bez presji administracyjnej kary z tego rozporządzenia. Inne rodzaje ryzyka, choćby wobec klientów, nie znikają. Pierwsze zgłoszenie robione pod presją i bez wprawy kosztuje znacznie więcej niż to zrobione na sucho.
Ten sam układ widzieliśmy w tym tygodniu przy ustawie o systemach AI. Weszła w życie 11 sierpnia, a uprawnienia karne włącza pod koniec października. Dwa różne akty, dwa różne obszary i ta sama konstrukcja: najpierw obowiązek, dopiero potem sankcja. Prawodawca daje w ten sposób czas na przygotowanie, a firmy zwykle czytają to jako sygnał, że jeszcze nie trzeba się spieszyć.
Czego strona Komisji nie rozstrzyga
Uczciwie: kluczowych definicji na stronie o obowiązkach sprawozdawczych nie ma.
Nie znajdziesz tam, co dokładnie znaczy aktywnie wykorzystywana podatność ani gdzie przebiega granica poważnego incydentu. Nie ma też definicji produktu z elementami cyfrowymi ani samego producenta. Wszystko to siedzi w tekście rozporządzenia, do którego trzeba sięgnąć bezpośrednio, bo od tych definicji zależy, czy dwudziestoczterogodzinny zegar w ogóle ruszy.
To nie jest zarzut wobec Komisji, tylko wskazówka co do kolejności czytania. Strona informacyjna opisuje procedurę, a nie zakres. Kto ustala zakres na podstawie samego streszczenia, ustala go źle.
Pierwsza Misja AI · Kodożercy
Pierwszy raz z AI? Zaczynasz od zera.
Pierwsza Misja AI to kurs dla osób bez technicznego backgroundu. Zero kodu, zero żargonu. Dowiesz się jak działa AI, jak promptować i jak korzystać z niej w pracy.
Wejdź na pokład →
Co zrobić w firmie przed 11 września
Miesiąc wystarczy na cztery rzeczy i żadna nie wymaga budżetu.
Ustalcie, czy w ogóle jesteście producentem w rozumieniu rozporządzenia. Warto zadać to pytanie także wtedy, gdy firma nie uważa się za wytwórcę oprogramowania, bo definicja z rozporządzenia bywa szersza od potocznego rozumienia tego słowa. Odpowiedź znajduje się w akcie prawnym, nie w intuicji zarządu.
Wskażcie osobę i jej zastępcę. Doba to za mało, żeby szukać, kto ma uprawnienia do wysłania zgłoszenia, gdy sprawa wychodzi w środku urlopu. W mniejszej firmie zwykle kończy się to na właścicielu, co jest w porządku pod warunkiem, że ktoś jeszcze zna hasła i wie, gdzie leży procedura.
Napiszcie procedurę na jedną stronę. Ma odpowiadać na trzy pytania: kto ocenia, czy podatność jest wykorzystywana, kto zatwierdza treść wczesnego ostrzeżenia i jak wygląda ścieżka poza godzinami pracy. Jeśli firma ma już jakiekolwiek procesy obsługi incydentów, warto sprawdzić, czy da się je wykorzystać, zamiast budować drugi obieg od zera. O innym obowiązku z obszaru cyberbezpieczeństwa, który dotyka dostawców, pisaliśmy przy procedurze dostawcy wysokiego ryzyka.
Przećwiczcie jedno zgłoszenie na sucho, kiedy nic się nie pali. Wystarczy wymyślony przypadek i godzina czasu zespołu. Ćwiczenie odpowiada na pytania, których nie widać w procedurze: ile naprawdę zajmuje ustalenie, czy lukę ktoś wykorzystuje, i czy osoba wyznaczona do zatwierdzenia treści jest osiągalna po godzinach. To jedyna pozycja z tej listy, której nie da się nadrobić później.
Najczęstsze pytania
Oba poniższe pytania wracają przy każdym nowym obowiązku sprawozdawczym i oba mają odpowiedź inną, niż podpowiada intuicja.
Czy Cyber Resilience Act dotyczy małych firm i jednoosobowych działalności?
Nic nie wskazuje na ogólne wyłączenie ze względu na wielkość podmiotu. Wyłączenie, o którym wiadomo na pewno, wiąże się z charakterem działalności: dotyczy niekomercyjnego oprogramowania open source. Wielkość firmy nie wydaje się więc kryterium samodzielnym, a punktem wyjścia jest to, czy wprowadzasz na rynek Unii produkt z elementami cyfrowymi w celach komercyjnych. Nie znaczy to jednak, że najmniejszy podmiot automatycznie jest objęty albo automatycznie wolny. Szczegóły klasyfikacji trzeba sprawdzić w samym rozporządzeniu, bo strona informacyjna Komisji ich nie podaje.
Co zgłosić, jeśli nie wiadomo jeszcze, czy lukę ktoś wykorzystuje?
Obowiązek dotyczy podatności aktywnie wykorzystywanych i poważnych incydentów, a zegar rusza w chwili powzięcia wiadomości o takim zdarzeniu. Pierwszym krokiem jest wczesne ostrzeżenie, które z założenia nie musi zawierać pełnego obrazu sytuacji. Definicję samego zdarzenia trzeba jednak wziąć z rozporządzenia, a nie ze streszczeń, bo to od niej zależy moment startu terminu. Przy wątpliwej sprawie sensowniej jest ustalić tę definicję zawczasu niż w dwudziestej trzeciej godzinie.
Podsumowanie
Rozporządzenie 2024/2847 kojarzy się z końcem 2027 roku i to skojarzenie jest mylące. Najostrzejsza jego część wchodzi wcześniej. Od 11 września producent, który dowie się o wykorzystywanej luce albo poważnym incydencie, ma dobę na wczesne ostrzeżenie i trzy doby na pełne zgłoszenie. Sprawozdanie końcowe składa w ciągu czternastu dni przy podatnościach, licząc od udostępnienia poprawki, albo w ciągu miesiąca przy incydentach. Do tego dochodzi powiadomienie użytkowników, o którym mówi analiza prawna. Zgłoszenie idzie raz, przez wspólną platformę, do krajowego zespołu reagowania i do ENISA. Kary sięgające 15 mln euro albo 2,5% obrotu poczekają do grudnia 2027. Zostaje więc piętnaście miesięcy na przećwiczenie procedury, zanim wejdzie sankcja z tego rozporządzenia. Kluczowe definicje są w tekście rozporządzenia, nie w materiałach informacyjnych, i od nich zależy, czy termin w danym przypadku w ogóle ruszy.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
