CRA: raportowanie podatności i incydentów w 24 i 72 godziny

Od 11 września 2026 r. producenci objęci CRA mają obowiązek raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu z elementami cyfrowymi. Wczesne ostrzeżenie trzeba złożyć do 24 godzin od uzyskania wiedzy, a pełne zgłoszenie do 72 godzin.

Największym ryzykiem operacyjnym nie jest brak formularza. Jest nim brak uzgodnionego momentu T0, osoby decyzyjnej, zastępstwa, źródeł danych i śladu tego, dlaczego zdarzenie zakwalifikowano w określony sposób.

Jakie terminy obowiązują

Etap	Termin	Co trzeba kontrolować
Uzyskanie wiedzy	T0	zapisz czas, źródło informacji i osobę, która ją przyjęła
Wczesne ostrzeżenie	do 24 h	minimalny pakiet informacji wymagany przez CRA/SRP
Pełne zgłoszenie	do 72 h	uzupełnione informacje o zdarzeniu i jego wpływie
Raport końcowy — aktywnie wykorzystywana podatność	do 14 dni po udostępnieniu środka naprawczego	działania naprawcze i stan obsługi
Raport końcowy — poważny incydent	do 1 miesiąca od zgłoszenia 72 h	przebieg, skutki, działania i wynik

Zawsze sprawdzaj aktualne instrukcje CRA Single Reporting Platform. Interfejs i materiały operacyjne mogą się zmieniać szybciej niż samo rozporządzenie.

Nie każda podatność oznacza zgłoszenie z art. 14

CRA mówi o aktywnie wykorzystywanej podatności, a nie o każdej pozycji znalezionej przez skaner. Tak samo pojęcie poważnego incydentu ma określone znaczenie prawne.

Dlatego proces powinien rozdzielać:

wykrycie lub otrzymanie informacji;
triage techniczny;
ocenę przesłanek regulacyjnych;
decyzję osoby uprawnionej;
przygotowanie zgłoszenia;
wysłanie przez właściwy kanał;
dalsze działania i raport końcowy.

Automatyczne przypisanie etykiety „podlega CRA” bez zatwierdzenia człowieka tworzy ryzyko zarówno pominięcia zgłoszenia, jak i niepotrzebnego raportowania.

Minimalny model odpowiedzialności

Nie wystarczy wpisać „Security Team”. Dla każdego produktu potrzebujesz wskazać:

osobę przyjmującą sygnał o podatności lub incydencie;
osobę prowadzącą triage techniczny;
właściciela produktu;
osobę zatwierdzającą kwalifikację regulacyjną;
osobę wysyłającą zgłoszenie do SRP;
zastępstwo dla każdej roli krytycznej czasowo;
kanał eskalacji poza godzinami pracy, jeżeli produkt tego wymaga.

Jeżeli jedna osoba pełni kilka ról, zapisz to wprost. Problemem nie jest mały zespół, tylko niejasność odpowiedzialności.

Co zapisać przy T0

Pierwszy rekord powinien powstać zanim zespół zacznie dyskutować, czy „to na pewno poważne”. Minimum:

dokładny czas uzyskania wiedzy;
źródło informacji;
produkt i wersja;
zgłaszający lub system, który wykrył zdarzenie;
krótki opis obserwacji;
osoba, która przyjęła informację;
link do materiału źródłowego lub artefaktu dowodowego.

Bez tego po kilku godzinach może nie być jasne, od kiedy rzeczywiście liczony jest termin.

Praktyczny przebieg obsługi

1. Rejestracja

Utwórz sprawę i nie nadpisuj pierwotnego zgłoszenia. Zachowaj oryginał oraz historię zmian.

2. Triage

Potwierdź produkt, wersję, zakres techniczny, znane skutki i dostępne dowody. Oddziel fakty od hipotez.

3. Kwalifikacja

Zapisz przesłanki za i przeciw obowiązkowi raportowania. Decyzja powinna wskazywać osobę zatwierdzającą i czas zatwierdzenia.

4. Zgłoszenie 24 h

Przygotuj wczesne ostrzeżenie na podstawie informacji dostępnych w danym momencie. Nie czekaj na pełne RCA, jeżeli termin biegnie.

5. Zgłoszenie 72 h

Uzupełnij dane zgodnie z aktualnym zakresem wymaganym przez SRP.

6. Naprawa i komunikacja

Powiąż działania techniczne, wydania, aktualizacje bezpieczeństwa i komunikację z klientami z tą samą sprawą.

7. Raport końcowy

Zamknij proces dopiero wtedy, gdy masz zapisany wynik, działania, dowody weryfikacji i wymagany raport końcowy.

Ćwiczenie przed realnym zdarzeniem

Najprostszy test procesu trwa krócej niż naprawianie go podczas rzeczywistego incydentu. Weź hipotetyczny scenariusz dla jednego produktu i sprawdź:

czy zespół wie, gdzie utworzyć rekord;
czy potrafi wskazać T0;
czy zna osobę zatwierdzającą;
czy istnieje zastępstwo;
czy wiadomo, jakie dane pobrać z produktu i logów;
czy osoba wysyłająca ma dostęp do SRP;
czy po ćwiczeniu zostaje ślad decyzji i lista poprawek.

Rola Pulsar GRC

Pulsar może spiąć incydent lub podatność z ryzykiem, działaniami, właścicielami, dokumentami, dowodami, raportem i historią decyzji. Obecne repo produktu potwierdza obszary ryzyk, zadań, dokumentów, dowodów, raportów i historii analiz.

Nie publikujemy claimu, że Pulsar automatycznie wysyła zgłoszenie do SRP albo sam decyduje, czy zdarzenie podlega art. 14. Taka funkcja wymaga osobnego, potwierdzonego wdrożenia i kontroli autoryzacji.

Zobacz Pulsar GRC na przykładzie procesu

Powiązane materiały

Źródła

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