Przewodnik gotowości do raportowania podatności zgodnie z EU CRA 2026

Jest 08:17 w poniedziałkowy poranek we wrześniu 2026 r. Anna, CISO szybko rosnącej europejskiej spółki SaaS, wciąż wraca myślami do ubiegłotygodniowego posiedzenia zarządu. CEO zadał pytanie, które dziś słyszy każdy lider bezpieczeństwa: „Skoro przygotowaliśmy się już do NIS2, a nasi klienci z sektora fintech stale pytają o DORA, to co zmienia Cyber Resilience Act?”

Odpowiedź pojawia się chwilę później w jej skrzynce odbiorczej.

Niezależny badacz zgłasza podatność możliwą do zdalnego wykorzystania w komponencie aktualizacji firmware używanym przez jeden z połączonych produktów spółki. Wiadomość zawiera proof of concept, nazwę zależności oraz ostrzeżenie, że podobne wykorzystanie zaobserwowano już w środowisku rzeczywistym.

W ciągu kilku minut każdy oczekuje innej odpowiedzi. CTO pyta, czy podatność jest rzeczywista. Dział prawny pyta, czy powstał obowiązek raportowania zgodnie z EU Cyber Resilience Act. Zespół produktowy pyta, których wersji dotyczy problem. CISO pyta, czy zależność występuje w którymkolwiek SBOM. Sprzedaż pyta, czy klienci z sektora finansowego będą potrzebowali dowodów wymaganych przez DORA. Menedżer ds. zgodności otwiera rejestr ryzyk ISO 27001 i znajduje proces zarządzania podatnościami, ale nie znajduje jasnej ścieżki decyzyjnej dla raportowania dotyczącego produktu.

Na tym polega rzeczywisty problem gotowości do CRA. Większość organizacji nie zaczyna od zera. Mają już polityki reagowania na incydenty, procedury zarządzania poprawkami, praktyki bezpiecznego rozwoju oprogramowania, przeglądy dostawców, skanery podatności oraz dowody ISO 27001. CRA nie premiuje jednak odrębnych dokumentów. Wymaga szybkiego, możliwego do obrony procesu, który odpowiada jednocześnie na pięć pytań:

1. Czy jest to aktywnie wykorzystywana podatność albo poważny incydent wpływający na bezpieczeństwo produktu?
2. Których produktów, wersji, klientów, zależności i dostawców dotyczy problem?
3. Który organ, klient albo adresat wynikający z umowy musi zostać powiadomiony i w jakim terminie?
4. Jakie dowody potwierdzają, że triage, mitygacja i ujawnienie były prowadzone w sposób kontrolowany?
5. Jak jest to zgodne z ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF oraz oczekiwaniami audytowymi?

Rozwiązaniem nie jest osobny „folder CRA”. Rozwiązaniem jest włączenie raportowania podatności zgodnie z CRA do SZBI, procesu skoordynowanego ujawniania podatności, dyscypliny SBOM, nadzoru nad dostawcami oraz łańcucha dowodowego reagowania na incydenty, którego i tak wymaga dojrzały ład cyberbezpieczeństwa.

Dlaczego EU Cyber Resilience Act zmienia model raportowania

EU Cyber Resilience Act, Rozporządzenie (UE) 2024/2847, wprowadza bezpieczeństwo produktu do głównego nurtu zgodności. Ma zastosowanie do produktów z elementami cyfrowymi wprowadzanych na rynek UE, w tym do urządzeń połączonych, oprogramowania, firmware, systemów wbudowanych oraz oprogramowania dla przedsiębiorstw.

Najważniejsza dla CISO, liderów bezpieczeństwa produktów i zespołów zgodności zmiana operacyjna zaczyna obowiązywać 11 września 2026 r. CRA Article 14 wymaga etapowego raportowania aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktów z elementami cyfrowymi. W praktyce producenci muszą być gotowi na:

Dokładna ocena prawna zawsze powinna być wykonywana przez wykwalifikowanych doradców prawnych, ale wniosek operacyjny jest jednoznaczny. Pierwsze 24 do 72 godzin są tak dobre, jak przygotowanie wykonane wiele miesięcy wcześniej.

Jeżeli SBOM są niekompletne, kanał CVD jest monitorowany nieformalnie, umowy z dostawcami nie wymagają powiadamiania o podatnościach albo polityka reagowania na incydenty nie odróżnia raportowania podatności produktu od incydentów prywatności lub incydentów operacyjnych, zegar regulacyjny będzie działał szybciej niż proces dowodowy.

Wykorzystaj ISO/IEC 27001:2022 jako konstrukcję nośną gotowości do CRA

ISO/IEC 27001:2022 nie zastępuje zgodności prawnej z CRA, ale jest najlepszą konstrukcją systemu zarządzania do włączenia obowiązków CRA w codzienny ład zarządczy.

Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała kontekst wewnętrzny i zewnętrzny, strony zainteresowane, wymagania, interfejsy z innymi organizacjami oraz zakres SZBI ISO/IEC 27001:2022. Dla gotowości do CRA oznacza to, że zakres SZBI powinien identyfikować produkty z elementami cyfrowymi, odpowiedzialności w cyklu życia produktu, komponenty hostowane, potoki budowania, zależności open source, dostawców, użytkowników, importerów, dystrybutorów, klientów regulowanych oraz właściwe organy.

Klauzule 6.1.1 do 6.1.3 wymagają oceny ryzyka i postępowania z ryzykiem, w tym właścicieli ryzyka, konsekwencji, prawdopodobieństwa, decyzji dotyczących postępowania z ryzykiem, Deklaracji stosowania oraz akceptacji ryzyka szczątkowego. Raportowanie CRA należy traktować jako scenariusz ryzyka bezpieczeństwa produktu w ramach tego procesu, a nie jako doraźne ćwiczenie z interpretacji przepisów.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 zapewnia następnie praktyczną strukturę zabezpieczeń. Najważniejsze zabezpieczenia dla raportowania podatności zgodnie z CRA to:

W Zenith Controls: The Cross-Compliance Guide Clarysec mapuje zabezpieczenie ISO/IEC 27002:2022 8.8, Management of technical vulnerabilities, jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność. Jego atrybuty są zgodne z koncepcjami cyberbezpieczeństwa Identify i Protect, a zdolnością operacyjną jest zarządzanie zagrożeniami i podatnościami.

To ujęcie ma znaczenie. Raportowanie CRA nie dotyczy wyłącznie powiadamiania organów. Dotyczy wykazania, że zdolność zapobiegawczego zarządzania podatnościami istniała zanim zgłoszenie wpłynęło.

Zbuduj model operacyjny wokół CVD, SBOM i zegara raportowania

Wiarygodny proces obsługi podatności CRA zaczyna się zanim badacz po raz pierwszy skontaktuje się z organizacją. Zaczyna się od zdolności przyjmowania zgłoszeń podatności, ich weryfikacji, identyfikacji komponentów, których dotyczy problem, oceny wykorzystania, koordynowania mitygacji, komunikowania się z użytkownikami oraz zachowania dowodów.

Pierwszym elementem jest publiczny kanał zgłaszania podatności. Polityka skoordynowanego ujawniania podatności Clarysec, klauzula wymagań wdrożeniowych 6.1, stanowi:

Publiczne kanały ujawniania: Organizacja musi utrzymywać jasny kanał zgłaszania podatności, taki jak dedykowany adres e-mail kontaktowy ds. bezpieczeństwa (na przykład security@company.com) lub formularz internetowy. Informacja ta musi być opublikowana na stronie bezpieczeństwa w witrynie spółki wraz z publicznym kluczem PGP organizacji, aby umożliwić szyfrowane zgłoszenia.

Rozwiązuje to częstą słabość audytową. Wiele firm deklaruje przyjmowanie zgłoszeń podatności, ale ścieżka raportowania jest ukryta, niezarządzana albo kierowana do ogólnej kolejki wsparcia. W warunkach CRA kanał raportowania staje się punktem uruchomienia świadomości regulacyjnej, oceny wagi i utrwalenia dowodów.

Drugim elementem jest triage. Polityka skoordynowanego ujawniania podatności, klauzula wymagań wdrożeniowych 6.4, stanowi:

Triage i potwierdzenie: Po otrzymaniu zgłoszenia VRT musi je zarejestrować i przesłać zgłaszającemu potwierdzenie w ciągu 2 dni roboczych, nadając numer referencyjny do śledzenia. VRT musi przeprowadzić wstępną ocenę wagi, na przykład z użyciem punktacji CVSS, oraz zweryfikować problem, w tym przy wsparciu zespołów IT i rozwoju, jeżeli jest to konieczne, w docelowym terminie 5 dni roboczych. Podatności krytyczne, takie jak umożliwiające zdalne wykonanie kodu lub poważne naruszenie ochrony danych, muszą być obsługiwane w trybie przyspieszonym.

Dla gotowości do CRA taki zapis triage należy rozszerzyć o pola wspierające regulacyjną decyzję raportową:

Trzecim elementem jest dyscyplina SBOM. Polityka bezpiecznego rozwoju oprogramowania Clarysec, klauzula wymagań ładu zarządczego 5.4, stanowi:

Wykorzystanie kodu open source lub kodu stron trzecich musi być zatwierdzane, śledzone i weryfikowane poprzez: 5.4.1 Analiza składu oprogramowania (SCA) 5.4.2 Przegląd licencji (GPL, MIT, BSD itd.) 5.4.3 Skanowanie znanych podatności (CVE, OSS Index itd.)

Dla mniejszych organizacji Polityka wymagań bezpieczeństwa aplikacji - SME Clarysec, klauzula wymagań wdrożeniowych polityki 6.4.2, wyraża to samo oczekiwanie w praktycznej formie:

Rejestr każdego użytego komponentu zewnętrznego musi być utrzymywany przez programistę lub dostawcę IT i obejmować:

Taki rejestr komponentów staje się minimalnym zestawem dowodowym dla reagowania na podatności opartego na SBOM. Powinien łączyć nazwę komponentu, wersję, źródło, dostawcę lub repozytorium, licencję, wersję produktu, datę budowania oraz status skanowania podatności. Gdy pojawi się CVE, zgłoszenie badacza lub powiadomienie dostawcy, zespół powinien w ciągu godzin odpowiedzieć: „Które wydane produkty zawierają ten komponent?”

Zmapuj CRA, NIS2, DORA i GDPR w jednej macierzy decyzji powiadomień

Cyber Resilience Act nie będzie działał w izolacji. Pojedyncza podatność produktu może uruchomić raportowanie CRA, ocenę incydentu według NIS2, obowiązki dowodowe wobec klientów wynikające z DORA, ocenę naruszenia zgodnie z GDPR oraz umowne obowiązki powiadamiania.

NIS2 Article 21 wymaga, aby podmioty kluczowe i ważne wdrożyły odpowiednie środki techniczne, operacyjne i organizacyjne. Środki te obejmują analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczne nabywanie, rozwój i utrzymanie, obsługę i ujawnianie podatności, ocenę skuteczności, cyberhigienę, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami, MFA oraz zabezpieczoną komunikację.

NIS2 Article 23 ustanawia etapowy model raportowania incydentów: wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy, powiadomienie o incydencie w ciągu 72 godzin, aktualizacje pośrednie na żądanie oraz raport końcowy nie później niż miesiąc od powiadomienia o incydencie. NIS2 Article 20 wprowadza również rozliczalność organu zarządzającego za zatwierdzanie i nadzorowanie środków zarządzania ryzykiem cyberbezpieczeństwa.

DORA obowiązuje od 17 stycznia 2025 r. i tworzy jednolite unijne ramy cyfrowej odporności operacyjnej dla podmiotów finansowych. Dla dostawców SaaS, producentów oprogramowania i dostawców ICT DORA często pojawia się poprzez umowy z klientami. Klient z sektora finansowego może być podmiotem regulowanym DORA, ale obsługa podatności, dowody SBOM, wsparcie incydentowe, prawa do audytu i zobowiązania dotyczące powiadomień po stronie dostawcy mogą być konieczne, aby klient spełnił własne obowiązki.

GDPR dodaje kolejną gałąź. Jeżeli podatność lub incydent powoduje przypadkowe lub niezgodne z prawem zniszczenie, utratę, zmianę, nieuprawnione ujawnienie danych osobowych lub nieuprawniony dostęp do nich, wymagana jest ocena naruszenia ochrony danych osobowych. GDPR Article 5 obejmuje również integralność, poufność i rozliczalność, co oznacza, że organizacja musi być w stanie wykazać sposób podjęcia decyzji.

Polityka reagowania na incydenty Clarysec, klauzula wymagań wdrożeniowych polityki 6.4.1, już wspiera taką ocenę wieloreżimową:

Jeżeli incydent skutkuje potwierdzonym lub prawdopodobnym ujawnieniem danych osobowych albo innych danych regulowanych, dział prawny i DPO muszą ocenić zastosowanie: 6.4.1.1 GDPR Article 33 (72-godzinne powiadomienie organu nadzorczego) 6.4.1.2 GDPR Article 34 (powiadomienie osób, których dane dotyczą, gdy występuje wysokie ryzyko) 6.4.1.3 NIS2 Article 23 (powiadomienie w ciągu 24 godzin od uzyskania wiedzy o incydencie) 6.4.1.4 DORA Article 17 (raportowanie poważnych incydentów związanych z ICT)

Dla gotowości do CRA należy rozszerzyć ten podręcznik postępowania o ocenę raportowania zgodnie z CRA Article 14 dla aktywnie wykorzystywanych podatności oraz poważnych incydentów wpływających na bezpieczeństwo produktu.

Ujednolicona macierz decyzji zapobiega prowadzeniu przez zespoły odrębnych, niespójnych podręczników raportowania:

Dla MŚP Polityka reagowania na incydenty - SME Clarysec, klauzula wymagań ładu zarządczego 5.3.2, ujmuje tę samą zasadę prościej:

Terminy reakcji, w tym odzyskiwanie danych i obowiązki powiadamiania, muszą być udokumentowane i zgodne z wymogami prawnymi, takimi jak 72-godzinny wymóg powiadomienia o naruszeniu ochrony danych osobowych zgodnie z GDPR.

Gotowość do CRA po prostu rozszerza tę zasadę z powiadomienia o naruszeniu ochrony danych osobowych na raportowanie podatności produktu oraz incydentów bezpieczeństwa produktu.

Dowody dostawców są teraz dowodami bezpieczeństwa produktu

Wiele podatności istotnych z perspektywy CRA będzie pochodzić spoza własnej bazy kodu. Mogą wynikać z pakietów open source, modułów firmware, SDK, hostowanych API, narzędzi budowania, usług chmurowych, komponentów podwykonawców lub bibliotek upstream. Dlatego nadzór nad dostawcami ma kluczowe znaczenie dla gotowości do CRA.

ISO 27001:2022 klauzula 8.1 wymaga, aby organizacje kontrolowały zewnętrznie dostarczane procesy, produkty lub usługi istotne dla SZBI. ISO/IEC 27002:2022 zabezpieczenie 5.21, Managing information security in the ICT supply chain, zapewnia punkt odniesienia dla kontroli.

W Zenith Controls Clarysec mapuje zabezpieczenie 5.21 jako kontrolę zapobiegawczą wspierającą poufność, integralność i dostępność. Jego zdolnością operacyjną jest bezpieczeństwo relacji z dostawcami, a domeny obejmują ład zarządczy, ekosystem i ochronę. Wniosek jest prosty: kontrole dostawców nie są dokumentacją zakupową. Są zabezpieczeniami ekosystemu.

Polityka bezpieczeństwa dostawców i stron trzecich - SME Clarysec, klauzula wymagań ładu zarządczego 5.3, ustanawia podstawę umowną:

Umowy muszą zawierać obowiązkowe klauzule obejmujące:

Dla programów enterprise Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controls in Action, Step 23, Organizational controls 5.19 to 5.37, wyjaśnia zabezpieczenie ISO/IEC 27002:2022 5.20, Addressing information security within supplier agreements:

Zaufanie w relacjach z dostawcami nie może opierać się na założeniach. Musi zostać skodyfikowane.

Dla gotowości do CRA umowy z dostawcami powinny zawierać klauzule bezpieczeństwa produktu wspierające szybką reakcję na podatności:

DORA wzmacnia ten sam kierunek. Podmioty finansowe muszą zarządzać ryzykiem stron trzecich ICT, utrzymywać rejestry umów dotyczących usług ICT, oceniać krytyczność, przeprowadzać due diligence, zarządzać ryzykiem koncentracji, definiować zabezpieczenia umowne, zapewniać prawa do audytu i planować wyjście. Jeżeli sprzedajesz oprogramowanie lub usługi ICT podmiotom finansowym, spodziewaj się pytań klientów o to, czy proces raportowania podatności i SBOM wspiera ich potrzeby dowodowe DORA dotyczące incydentów, odporności i stron trzecich.

Proces gotowości CRA według Clarysec

Clarysec pomaga klientom wdrożyć raportowanie CRA w ramach SZBI zgodnego z ISO 27001:2022 poprzez praktyczny proces.

1. Dodaj obowiązki CRA do rejestru wymagań SZBI

Zacznij od klauzul ISO 27001:2022 4.1 do 4.4. Zaktualizuj kontekst organizacji, strony zainteresowane i zakres, aby objąć produkty z elementami cyfrowymi, ekspozycję na rynek UE, użytkowników, importerów, dystrybutorów, regulatorów, CSIRT, dostawców i klientów regulowanych.

Utwórz wpisy w rejestrze wymagań dla raportowania podatności CRA, raportowania poważnych incydentów bezpieczeństwa produktu zgodnie z CRA, powiadamiania o incydentach NIS2, obowiązków wsparcia klientów DORA, oceny naruszenia ochrony danych osobowych GDPR, umownego powiadomienia o incydencie, zobowiązań CVD oraz komunikacji z badaczami.

Daje to audytorom możliwą do prześledzenia ścieżkę od zewnętrznego obowiązku do wewnętrznej kontroli.

2. Utwórz formularz przyjęcia podatności produktu

Oprzyj formularz przyjęcia na Polityce skoordynowanego ujawniania podatności. Powinien rejestrować tożsamość zgłaszającego, bezpieczne dane kontaktowe, wersję produktu, moduł, środowisko, proof of concept, kroki odtworzenia, status wykorzystania, potencjalne ujawnienie danych, wpływ na usługę, dopasowanie komponentu SBOM, wagę CVSS lub równoważną, właściciela, numer referencyjny do śledzenia oraz regulacyjny punkt kontrolny.

Formularz powinien automatycznie tworzyć zgłoszenie w kolejce reagowania na podatności. Powinien również uruchamiać licznik decyzji powiadomieniowej, nawet jeżeli ostateczna odpowiedź brzmi „nie podlega raportowaniu”.

3. Połącz dane SBOM z wydaniami

Dla każdej wydanej wersji produktu utrzymuj SBOM lub równoważny inwentarz komponentów. Minimalny użyteczny zestaw dowodowy obejmuje nazwę komponentu, wersję, źródło, licencję, dostawcę lub repozytorium, wersję produktu, datę budowania oraz status skanowania podatności.

Polityka bezpiecznego rozwoju oprogramowania oraz Polityka wymagań bezpieczeństwa aplikacji - SME zapewniają podstawę polityki dla SCA, przeglądu komponentów i zapisów komponentów zewnętrznych.

4. Zachowuj dowody od pierwszego dnia

Każde zgłoszenie podatności istotnej dla CRA powinno zachowywać:

• Pierwotne zgłoszenie
• Znacznik czasu potwierdzenia
• Notatki z triage
• Uzasadnienie wagi CVSS lub równoważnej
• Wyniki dopasowania SBOM
• Ocenę wykorzystania
• Logi, wskaźniki i migawki kryminalistyczne
• Komunikację z dostawcami
• Akceptację ryzyka, jeżeli mitygacja jest opóźniona
• Plan poprawki, informacje o wydaniu i dowody testowania
• Decyzje dotyczące powiadomienia klientów i organów
• Dane wejściowe do raportu końcowego i wnioski

Jest to zgodne z ISO 27001:2022 klauzula 8.1, która wymaga udokumentowanych informacji wystarczających do wykazania, że procesy działały zgodnie z planem, oraz z klauzulami 8.2 i 8.3, które wymagają udokumentowanych wyników oceny ryzyka i postępowania z ryzykiem.

5. Przetestuj realistyczny scenariusz zależności

Przeprowadź ćwiczenie tabletop z użyciem symulowanej, aktywnie wykorzystywanej podatności zależności. Uwzględnij zespoły inżynierii, bezpieczeństwa, prawny, prywatności, produktu, komunikacji, zarządzania dostawcami oraz zespoły mające kontakt z klientami. Test powinien wykazać, że organizacja potrafi zidentyfikować wersje, których dotyczy problem, ocenić wykorzystanie, podjąć decyzję powiadomieniową, skontaktować się z dostawcami, przygotować wytyczne dla użytkowników i zachować dowody.

Jak audytorzy będą testować gotowość do raportowania podatności CRA

Przegląd gotowości do CRA rzadko ograniczy się do listy kontrolnej CRA. Różni audytorzy będą testować te same dowody przez pryzmat różnych ram.

W Zenith Controls Clarysec mapuje zabezpieczenie ISO/IEC 27002:2022 5.24, Information security incident management planning and preparation, jako kontrolę korygującą wspierającą poufność, integralność i dostępność. Jest ono zgodne z Respond i Recover, a zdolnościami operacyjnymi są ład zarządczy oraz zarządzanie zdarzeniami bezpieczeństwa informacji.

To zabezpieczenie jest pomostem między wykryciem podatności a raportowaniem regulacyjnym.

NIST CSF 2.0 jest szczególnie użyteczny jako warstwa komunikacji z zarządem. Jego funkcje GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER pomagają wyjaśnić, jak raportowanie podatności produktu wpisuje się w korporacyjny ład cyberbezpieczeństwa, zamiast funkcjonować jako wyjątek inżynieryjny.

Typowe luki gotowości do CRA, które należy usunąć przed 2026 r.

Clarysec regularnie obserwuje te same luki.

Pierwsza to CVD bez raportowania. Firma ma adres e-mail ds. bezpieczeństwa lub plik security.txt, ale nie ma wewnętrznej ścieżki od zgłoszenia badacza do oceny powiadomienia regulacyjnego.

Druga to SBOM bez właściciela. Inżynieria może wygenerować SBOM podczas budowania, ale nikt nie odpowiada za jego dokładność dla wydanych produktów ani nie wyjaśnia, jak ustalenia SBOM zasilają reagowanie na podatności.

Trzecia to certyfikat ISO bez zakresu produktu. SZBI obejmuje korporacyjne IT i operacje SaaS, ale nie obejmuje oprogramowania wbudowanego, firmware, infrastruktury aktualizacji produktu, potoków budowania ani ujawniania podatności.

Czwarta to umowy z dostawcami bez klauzul dotyczących podatności. Zakupy wymagają poufności i ochrony danych, ale nie powiadamiania o podatnościach, przejrzystości komponentów, wsparcia incydentowego, skoordynowanego ujawniania ani dowodów audytowych.

Piąta to reagowanie na incydenty bez logiki podatności produktu. Plan incydentowy obejmuje ransomware, phishing i naruszenia ochrony danych osobowych, ale nie obejmuje aktywnie wykorzystywanych podatności produktu, w których systemy klientów mogą być zagrożone zanim dojdzie do naruszenia własnego środowiska producenta.

Szósta to ręczna obsługa dowodów DORA dla klientów. Sprzedaż lub customer success odpowiada na kwestionariusze sektora finansowego przypadek po przypadku, podczas gdy bezpieczeństwo nie ma standardowego pakietu dowodowego pokazującego obsługę podatności, nadzór nad SBOM, wsparcie incydentowe i kontrole dostawców.

Każdą z tych luk można usunąć. Każda staje się kosztowna, jeżeli zostanie wykryta podczas aktywnej podatności.

90-dniowa lista kontrolna gotowości do raportowania podatności CRA

Wykorzystaj następne 90 dni, aby ustanowić możliwą do obrony podstawę:

• Zidentyfikuj produkty z elementami cyfrowymi wprowadzone lub udostępnione na rynku UE.
• Zaktualizuj zakres SZBI i analizę stron zainteresowanych, aby uwzględnić interesariuszy CRA.
• Dodaj ocenę raportowania zgodnie z CRA Article 14 do rejestru wymagań prawnych i regulacyjnych.
• Opublikuj i monitoruj bezpieczny kanał zgłaszania podatności.
• Utwórz zespół reagowania na podatności z rolami prawnymi, produktowymi, inżynieryjnymi, bezpieczeństwa i komunikacji.
• Utrzymuj SBOM lub inwentarze komponentów dla wydanych wersji produktów.
• Połącz wyniki SCA ze zgłoszeniami podatności i wydaniami produktów.
• Dodaj kryteria aktywnego wykorzystania i poważnego incydentu produktu do formularzy triage.
• Utwórz połączoną macierz decyzji powiadomień CRA, NIS2, DORA, GDPR i umownych.
• Zaktualizuj umowy z dostawcami o klauzule powiadamiania o podatnościach, SBOM, wsparcia incydentowego i koordynacji ujawniania.
• Utrzymuj logi poprawek i dowody działań naprawczych.
• Przetestuj proces z użyciem symulowanej aktywnie wykorzystywanej podatności zależności.
• Przedstaw kierownictwu wyniki wraz z lukami, ryzykami szczątkowymi i właścicielami działań naprawczych.
• Dodaj pakiet dowodowy do audytu wewnętrznego i przeglądu zarządzania.

Polityka zarządzania podatnościami i poprawkami - SME Clarysec, klauzula wymagań wdrożeniowych polityki 6.2.1, wspiera podstawy monitorowania:

Funkcja IT musi monitorować podatności z użyciem:

Ta sama polityka, klauzula wymagań ładu zarządczego 5.4.1, dodaje ścieżkę audytową:

Rejestr poprawek musi być utrzymywany i przeglądany podczas audytów oraz działań reagowania na incydenty

Ten rejestr poprawek może stać się jednym z najważniejszych artefaktów w raporcie końcowym CRA. Potwierdza wykrycie, priorytetyzację, działania naprawcze, testowanie i zamknięcie.

Spraw, aby wrzesień 2026 był nudny

Najlepsze zdarzenie raportowe CRA nie jest łatwe dlatego, że podatność jest prosta. Jest łatwe dlatego, że organizacja przećwiczyła już proces.

Przed wrześniem 2026 r. Clarysec może pomóc przekształcić raportowanie podatności w system gotowy do audytu, mapując obecny SZBI ISO 27001:2022, proces CVD, zdolność SBOM, klauzule dostawców i podręczniki reagowania na incydenty względem oczekiwań CRA, NIS2, DORA, GDPR i NIST CSF.

Zacznij od ukierunkowanej oceny gotowości do raportowania podatności CRA. Clarysec przejrzy polityki, dowody SBOM, umowy z dostawcami, zgłoszenia podatności, podręczniki incydentowe i ścieżkę audytową. Następnie wykorzystamy Zenith Blueprint i Zenith Controls, aby zbudować praktyczną mapę działań naprawczych, a nie teoretyczny segregator zgodności.

Jeżeli korzystasz już z polityk Clarysec, dostosujemy je do raportowania CRA. Jeżeli nie, możemy pomóc wdrożyć właściwy zestaw polityk, w tym Politykę skoordynowanego ujawniania podatności, Politykę bezpiecznego rozwoju oprogramowania, Politykę reagowania na incydenty, Politykę zarządzania podatnościami i poprawkami - SME, Politykę wymagań bezpieczeństwa aplikacji - SME oraz Politykę bezpieczeństwa dostawców i stron trzecich - SME, gdy jest to właściwe.

Wrzesień 2026 r. jest wystarczająco blisko, aby planować, i wystarczająco daleko, aby przygotować się w sposób zdyscyplinowany. Organizacje, które działają teraz, nie będą w pierwszych 24 godzinach pytać: „Kto jest właścicielem tej podatności?”. Będą już mieć odpowiedź, dowody i ścieżkę raportowania.

Skontaktuj się z Clarysec, aby zaplanować ocenę gotowości do raportowania podatności CRA i przekształcić złożoność regulacyjną w możliwą do obrony przewagę w obszarze bezpieczeństwa produktu.