CRA PSIRT – Odbiór zgłoszeń o zagrożeniach, raportowanie 24/72h i łańcuch dowodowy | Word/PDF/Excel

Odbierz, oceń i udokumentuj konkretną lukę bezpieczeństwa lub incydent w produkcie cyfrowym – od pierwszego zgłoszenia do faktycznego zgłoszenia w ramach CRA i poinformowania klientów. Ten specjalistyczny pakiet dla producentów produktów z elementami cyfrowymi koncentruje się na artykule 14 CRA i Jednolitej Platformie Zgłoszeniowej (SRP) ENISA. Nie zastępuje on szerokiej oceny ryzyka CRA, SBOM ani faktycznego zgłaszania incydentów organom.

Szybkie fakty: 5 szwedzkich dokumentów roboczych, 1 szwedzki przewodnik użytkownika i 1 angielski przewodnik użytkownika, wszystkie w edytowalnym formacie Word (DOCX) oraz w formacie PDF umożliwiającym wyszukiwanie i drukowanie (nie są to interaktywne formularze), oraz 1 szwedzki arkusz Excel z 9 zakładkami. Łącznie 15 plików dla klienta: siedem niezależnych dokumentów w dwóch formatach oraz jeden plik XLSX. Cyfrowa dostawa w formacie ZIP po aktywacji.

Kto powinien wybrać szablon – i kiedy?

Dla producentów i dostawców oprogramowania, urządzeń połączonych z siecią oraz innych produktów z elementami cyfrowymi sprzedawanych na rynku UE, którzy muszą odnieść się do wskazania aktywnego wykorzystywania luki lub poważnego incydentu bezpieczeństwa. Dwa przypadki: zgłaszający przesyła dowody na ataki wymierzone w konkretną wersję oprogramowania układowego lub producent dowiaduje się o incydencie poważnie wpływającym na bezpieczeństwo produktu. Jeśli jesteś zwykłym dystrybutorem, dostawcą usług utrzymania IT lub zajmujesz się wyłącznie wewnętrznymi incydentami IT, mogą być odpowiedniejsze inne dokumenty i przepisy. Należy najpierw zweryfikować prawny status producenta oraz zastosowanie CRA.

Plik po pliku

Praktyczne zastosowanie arkusza Excel

Arkusz zawiera filtrowalne wpisy, pola statusu, powiązania ID oraz przegląd oparty na formułach. Po wprowadzeniu rzeczywistej wartości czasu UTC, w którym producent dowiedział się o zdarzeniu podlegającym obowiązkowi zgłoszenia, arkusz wskazuje orientacyjne terminy 24 h i 72 h. Są to ostateczne techniczne wartości kontrolne, a nie prawo do zwlekania: należy zgłosić incydent bez zbędnej zwłoki. Datę raportu końcowego należy wprowadzić ręcznie, ponieważ wyzwalacze są różne: dostępność działania naprawczego (AEV) lub rzeczywiste złożenie zgłoszenia po 72 h (SI). Rejestr odróżnia szkic, ocenę, wysłane zgłoszenie i rzeczywiste potwierdzenie.

Krok po kroku

1. Zidentyfikuj prawnego producenta, produkt, wersję oraz uprawnioną rolę PSIRT/SRP.
2. Rejestruj źródła i dowody, nie umieszczając tajemnic ani kodu wykorzystującego lukę w niezabezpieczonych plikach biurowych.
3. Osobno oceń AEV i SI w kontekście artykułu 14 CRA i udokumentuj moment wykrycia.
4. W przypadku obowiązku zgłoszenia: przygotuj dokumentację i zgłoś incydent bez zbędnej zwłoki za pośrednictwem oficjalnej platformy SRP ENISA.
5. Zapisuj rzeczywiste ID i znaczniki czasu złożonych zgłoszeń po 24 h, 72 h oraz odpowiedniego raportu końcowego.
6. Udokumentuj działanie naprawcze, dotkniętych użytkowników, komunikację i kontrolę po naprawie.

Granice prawne i odpowiedzialność

Artykuł 14 CRA (UE) 2024/2847 zaczął obowiązywać dla producentów 11 września 2026 r. Obowiązek zgłaszania aktywnie wykorzystywanych luk wymaga odpowiednich dowodów na rzeczywiste wykorzystanie; numer CVE lub wysoki wynik ryzyka nie wystarcza automatycznie. Poważny incydent należy oceniać zgodnie z artykułem 14.5. Wczesne ostrzeżenie należy przekazać w ciągu 24 h, a zgłoszenie w ciągu 72 h od momentu wykrycia, bez zbędnej zwłoki. W przypadku AEV raport końcowy należy przekazać najpóźniej 14 dni po udostępnieniu działania naprawczego lub ograniczającego. W przypadku SI raport końcowy należy przekazać w ciągu miesiąca od rzeczywistego złożenia zgłoszenia po 72 h. Artykuł 14.8 dotyczy informowania dotkniętych użytkowników.

Należy bezpośrednio przed rzeczywistym zgłoszeniem zweryfikować FAQ dotyczące SRP oraz słowniczek pól ENISA, ponieważ pola i funkcje platformy są aktualizowane. Status w dokumencie Word lub Excel nigdy nie jest traktowany jako złożone zgłoszenie. Pozostałe główne wymagania CRA zaczną w zasadzie obowiązywać 11 grudnia 2027 r., a artykuł 24.3 dotyczący osób odpowiedzialnych za oprogramowanie open-source zacznie obowiązywać w innym terminie. W razie potrzeby wymagana może być osobna ocena zgodnie m.in. z NIS2, RODO i DORA.

Różnica w stosunku do naszych innych dokumentów

Nasz szerszy pakiet zgodności z CRA obejmuje ocenę ryzyka, SBOM, wymagania bezpieczeństwa i ogólne zgłaszanie incydentów w ramach CRA. Ten nowy pakiet jest natomiast specjalistycznym łańcuchem roboczym dla faktycznie otrzymanego zgłoszenia lub incydentu, potwierdzeń SRP, dowodów i informacji dla klientów.

Często zadawane pytania

Czy każdą lukę bezpieczeństwa należy zgłaszać?

Nie. Artykuł 14 określa szczególne progi dla aktywnie wykorzystywanych luk i poważnych incydentów. Inne luki mogą wymagać wewnętrznego zarządzania, ale nie są automatycznie obowiązkowymi zgłoszeniami SRP.

Czy szablon wysyła zgłoszenie do ENISA?

Nie. Dokumentacja przygotowuje i udokumentowuje pracę; uprawniony przedstawiciel musi wysłać zgłoszenie za pośrednictwem rzeczywistej platformy SRP.

Czy pliki PDF można edytować?

Można w nich wyszukiwać i można je drukować, ale nie są to interaktywne formularze do wypełniania. Do edycji należy używać plików Word.

Czy wszystkie materiały zostały przetłumaczone na język angielski?

Nie. Pięć dokumentów roboczych i arkusz Excel są w języku szwedzkim. Angielski przewodnik wyjaśnia, jak należy używać szwedzkich dokumentów.

Wersja, źródła i przejrzystość

Wydanie 1.0, 9 listopada 2026 r. AI-asystowana analiza prawnych źródeł artykułu 14 CRA, informacji Komisji dotyczących zgłaszania incydentów oraz materiałów SRP ENISA z 9 listopada 2026 r. Nie przeprowadzono zewnętrznej niezależnej analizy prawnej, oceny organu ani certyfikacji technicznej produktu. Pakiet stanowi wsparcie administracyjne, a nie gwarancję zgodności.