Průvodce připraveností na hlášení zranitelností podle EU CRA pro rok 2026

Je pondělí ráno v září 2026, 08:17. Anna, ředitelka informační bezpečnosti (CISO) rychle rostoucí evropské SaaS společnosti, stále přemýšlí o zasedání správní rady z minulého týdne. Generální ředitel položil otázku, kterou nyní slyší každý bezpečnostní lídr: „Pokud jsme se už připravili na NIS2 a naši fintech klienti se stále ptají na DORA, co mění akt o kybernetické odolnosti?“

Odpověď jí vzápětí přichází do e-mailové schránky.

Nezávislý výzkumník hlásí vzdáleně zneužitelnou zranitelnost v komponentě pro aktualizace firmwaru, kterou používá jeden z připojených produktů společnosti. Zpráva obsahuje proof of concept, název závislosti a upozornění, že obdobné zneužití již bylo pozorováno v praxi.

Během několika minut chce každý jinou odpověď. Technický ředitel se ptá, zda je zranitelnost skutečná. Právní oddělení se ptá, zda vznikla povinnost hlášení podle aktu EU o kybernetické odolnosti. Produktový tým se ptá, kterých verzí se problém týká. CISO se ptá, zda se daná závislost objevuje v některém SBOM. Obchod se ptá, zda zákazníci z finančního sektoru potřebují důkazy pro DORA. Manažer compliance otevírá registr rizik ISO 27001 a nachází proces řízení zranitelností, ale nikoli jasnou rozhodovací cestu pro hlášení související s produktem.

To je skutečný problém připravenosti na CRA. Většina organizací nezačíná od nuly. Už má politiky reakce na incidenty, rutiny řízení záplat, postupy bezpečného vývoje, přezkumy dodavatelů, skenery zranitelností a důkazy podle ISO 27001. CRA však neodměňuje izolované dokumenty. Vyžaduje rychlý, obhajitelný pracovní postup, který dokáže současně zodpovědět pět otázek:

1. Jde o aktivně zneužívanou zranitelnost nebo závažný incident ovlivňující bezpečnost produktu?
2. Které produkty, verze, zákazníci, závislosti a dodavatelé jsou dotčeni?
3. Který orgán, zákazník nebo smluvní příjemce musí být informován a kdy?
4. Jaké důkazy dokládají, že triáž, zmírnění a oznámení byly řízené?
5. Jak je tento postup sladěn s ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF a očekáváními auditu?

Řešením není samostatná „složka CRA“. Řešením je napojit hlášení zranitelností podle CRA na ISMS, proces koordinovaného oznamování zranitelností, disciplínu SBOM, řízení dodavatelů a důkazní řetězec reakce na incidenty, které už potřebujete pro vyspělou správu a řízení kybernetické bezpečnosti.

Proč akt EU o kybernetické odolnosti mění model hlášení

Akt EU o kybernetické odolnosti, nařízení (EU) 2024/2847, přesouvá bezpečnost produktů do hlavního proudu compliance. Vztahuje se na produkty s digitálními prvky uváděné na trh EU, mezi které mohou patřit připojená zařízení, software, firmware, vestavěné systémy i podnikové softwarové produkty.

Provozní změna, která je pro CISO, vedoucí produktové bezpečnosti a týmy compliance nejdůležitější, začíná 11. září 2026. Článek 14 CRA vyžaduje odstupňované hlášení aktivně zneužívaných zranitelností a závažných incidentů ovlivňujících bezpečnost produktů s digitálními prvky. Prakticky to znamená, že výrobci musí být připraveni na následující:

Přesné právní posouzení má vždy provádět kvalifikovaný právník, ale provozní ponaučení je jasné. Prvních 24 až 72 hodin bude pouze tak dobrých, jak dobrá byla příprava dokončená v předchozích měsících.

Pokud jsou vaše SBOM neúplné, pokud je schránka CVD monitorována neformálně, pokud smlouvy s dodavateli nevyžadují oznamování zranitelností nebo pokud politika reakce na incidenty nerozlišuje hlášení zranitelností produktu od incidentů v oblasti soukromí či provozních incidentů, právní lhůta poběží rychleji než váš důkazní proces.

Použijte ISO/IEC 27001:2022 jako nosnou strukturu připravenosti na CRA

ISO/IEC 27001:2022 není náhradou za právní soulad s CRA, ale je nejvhodnější nosnou strukturou systému řízení pro začlenění povinností CRA do každodenní správy a řízení.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla internímu a externímu kontextu, zainteresovaným stranám, požadavkům, rozhraním s jinými organizacemi a rozsahu ISMS ISO/IEC 27001:2022. Pro připravenost na CRA to znamená, že rozsah ISMS má identifikovat produkty s digitálními prvky, odpovědnosti v rámci životního cyklu produktu, hostované komponenty, pipeline sestavení, open-source závislosti, dodavatele, uživatele, dovozce, distributory, regulované zákazníky a příslušné orgány.

Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik a ošetření rizik, včetně vlastníků rizik, následků, pravděpodobnosti, rozhodnutí o ošetření, Prohlášení o použitelnosti a přijetí zbytkového rizika. Hlášení podle CRA má být v tomto procesu vedeno jako scénář rizika bezpečnosti produktu, nikoli jako nouzové právní interpretační cvičení.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 následně poskytuje praktickou strukturu opatření. Nejdůležitější opatření pro hlášení zranitelností podle CRA jsou:

V Zenith Controls: průvodci napříč požadavky compliance Clarysec mapuje opatření ISO/IEC 27002:2022 8.8, Řízení technických zranitelností, jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Jeho atributy odpovídají konceptům kybernetické bezpečnosti Identifikovat a Chránit, přičemž provozní schopností je řízení hrozeb a zranitelností.

Tento rámec je důležitý. Hlášení podle CRA není pouze o oznamování orgánům. Jde o doložení, že preventivní schopnost řízení zranitelností existovala ještě před přijetím hlášení.

Postavte provozní model na CVD, SBOM a lhůtách hlášení

Důvěryhodný pracovní postup pro zranitelnosti podle CRA začíná dříve, než vás výzkumník vůbec kontaktuje. Začíná schopností přijímat hlášení zranitelností, ověřovat je, identifikovat dotčené komponenty, posoudit zneužití, koordinovat zmírnění, komunikovat s uživateli a uchovávat důkazy.

Prvním stavebním prvkem je veřejný kanál pro hlášení zranitelností. Clarysec Politika koordinovaného oznamování zranitelností, požadavky na implementaci, kapitola 6.1, uvádí:

Veřejné kanály pro oznámení: Organizace musí udržovat jasný kanál pro hlášení zranitelností, například vyhrazenou e-mailovou adresu bezpečnostního kontaktu (například security@company.com) nebo webový formulář. Tyto informace musí být zveřejněny na bezpečnostní stránce webu společnosti společně s veřejným klíčem PGP organizace, aby bylo možné šifrované podání.

Tím se řeší běžné selhání při auditu. Mnoho společností tvrdí, že přijímá hlášení zranitelností, ale cesta hlášení je skrytá, neřízená nebo směrovaná přes obecnou frontu podpory. V podmínkách CRA se kanál pro hlášení stává spouštěcím bodem pro právní povědomí, posouzení závažnosti a zachycení důkazů.

Druhým stavebním prvkem je triáž. Politika koordinovaného oznamování zranitelností, požadavky na implementaci, kapitola 6.4, uvádí:

Triáž a potvrzení přijetí: Po obdržení hlášení jej VRT zaznamená a do 2 pracovních dnů zašle oznamovateli potvrzení přijetí s přiděleným referenčním číslem. VRT provede předběžné posouzení závažnosti, například pomocí skórování CVSS, a ověří problém, včetně podpory týmů IT a vývoje, je-li to nezbytné, v cílové lhůtě 5 pracovních dnů. Kritické zranitelnosti, například ty, které umožňují vzdálené spuštění kódu nebo závažné porušení zabezpečení dat, musí být vyřízeny zrychleně.

Pro připravenost na CRA má být tento záznam triáže rozšířen o pole podporující právní rozhodnutí o hlášení:

Třetím stavebním prvkem je disciplína SBOM. Clarysec Politika bezpečného vývoje, požadavky na správu a řízení, kapitola 5.4, uvádí:

Použití open-source kódu nebo kódu třetích stran musí být schváleno, sledováno a ověřeno prostřednictvím: 5.4.1 Analýza složení softwaru (SCA) 5.4.2 Přezkum licencí (GPL, MIT, BSD atd.) 5.4.3 Skenování známých zranitelností (CVE, OSS Index atd.)

Pro menší organizace stanoví Clarysec Politika požadavků na zabezpečení aplikací pro malé a střední podniky (SME), požadavky na implementaci politiky, kapitola 6.4.2, stejné očekávání v praktické podobě:

Vývojář nebo poskytovatel IT služeb musí vést záznam o každé použité externí komponentě, včetně:

Tento záznam komponent se stává minimálním důkazním souborem pro reakci na zranitelnosti řízenou SBOM. Má propojovat název komponenty, verzi, zdroj, dodavatele nebo repozitář, licenci, verzi produktu, datum sestavení a stav skenu zranitelností. Když dorazí CVE, hlášení výzkumníka nebo oznámení dodavatele, váš tým má být schopen během hodin odpovědět: „Které vydané produkty tuto komponentu obsahují?“

Namapujte CRA, NIS2, DORA a GDPR do jedné rozhodovací matice oznámení

Akt o kybernetické odolnosti nebude fungovat izolovaně. Jedna zranitelnost produktu může vyvolat hlášení podle CRA, posouzení incidentu podle NIS2, povinnosti poskytovat zákaznické důkazy podle DORA, posouzení porušení zabezpečení podle GDPR a smluvní oznamovací povinnosti.

Článek 21 NIS2 vyžaduje, aby základní a důležité subjekty zavedly vhodná technická, provozní a organizační opatření. Tato opatření zahrnují analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování, vývoj a údržbu, zvládání a oznamování zranitelností, posuzování účinnosti, kybernetickou hygienu, kryptografii, bezpečnost v oblasti lidských zdrojů, řízení přístupu, správu aktiv, MFA a zabezpečenou komunikaci.

Článek 23 NIS2 stanoví odstupňovaný model hlášení incidentů: včasné varování do 24 hodin od zjištění, oznámení incidentu do 72 hodin, průběžné aktualizace na vyžádání a závěrečnou zprávu nejpozději do jednoho měsíce od oznámení incidentu. Článek 20 NIS2 zároveň vytváří odpovědnost řídicích orgánů za schvalování opatření řízení rizik kybernetické bezpečnosti a dohled nad nimi.

DORA se použije od 17. ledna 2025 a vytváří jednotný rámec digitální provozní odolnosti EU pro finanční subjekty. Pro poskytovatele SaaS, dodavatele softwaru a dodavatele ICT se DORA často projevuje prostřednictvím zákaznických smluv. Vaším regulovaným subjektem podle DORA může být zákazník z finančního sektoru, ale vaše zvládání zranitelností, důkazy SBOM, podpora incidentů, práva na audit a závazky oznamování mohou být nezbytné, aby tento zákazník splnil své vlastní povinnosti.

GDPR přidává další větev. Pokud zranitelnost nebo incident způsobí náhodné nebo protiprávní zničení, ztrátu, změnu, neoprávněné zpřístupnění osobních údajů nebo neoprávněný přístup k nim, je vyžadováno posouzení porušení zabezpečení osobních údajů. Článek 5 GDPR zahrnuje také integritu, důvěrnost a odpovědnost, což znamená, že organizace musí být schopna doložit své rozhodování.

Clarysec Politika reakce na incidenty, požadavky na implementaci politiky, kapitola 6.4.1, již podporuje toto posouzení napříč režimy:

Pokud incident vede k potvrzené nebo pravděpodobné expozici osobních údajů nebo jiných regulovaných dat, právní oddělení a DPO musí posoudit použitelnost: 6.4.1.1 článek 33 GDPR (oznámení dozorovému úřadu do 72 hodin) 6.4.1.2 článek 34 GDPR (oznámení subjektům údajů, pokud existuje vysoké riziko) 6.4.1.3 článek 23 NIS2 (oznámení do 24 hodin od zjištění incidentu) 6.4.1.4 článek 17 DORA (hlášení závažných incidentů souvisejících s ICT)

Pro připravenost na CRA rozšiřte tento playbook o posouzení hlášení podle článku 14 CRA pro aktivně zneužívané zranitelnosti a závažné incidenty ovlivňující bezpečnost produktu.

Jednotná rozhodovací matice brání týmům v používání samostatných a vzájemně nekonzistentních playbooků hlášení:

Pro malé a střední podniky uvádí Clarysec Politika reakce na incidenty pro malé a střední podniky (SME), požadavky na správu a řízení, kapitola 5.3.2, stejný princip jednodušší formou:

Reakční lhůty, včetně obnovy dat a oznamovacích povinností, musí být dokumentovány a sladěny s právními požadavky, například s požadavkem GDPR na oznámení porušení zabezpečení osobních údajů do 72 hodin.

Připravenost na CRA tento princip jednoduše rozšiřuje z oznámení porušení zabezpečení osobních údajů na hlášení zranitelností produktu a bezpečnostních incidentů produktu.

Důkazy od dodavatelů jsou nyní důkazy bezpečnosti produktu

Mnoho zranitelností relevantních pro CRA vznikne mimo vaši vlastní kódovou základnu. Mohou pocházet z open-source balíčků, modulů firmwaru, SDK, hostovaných rozhraní API, nástrojů pro sestavení, cloudových služeb, subdodavatelských komponent nebo upstream knihoven. Proto je řízení dodavatelů pro připravenost na CRA zásadní.

ISO 27001:2022 kapitola 8.1 vyžaduje, aby organizace řídily externě poskytované procesy, produkty nebo služby relevantní pro ISMS. ISO/IEC 27002:2022 opatření 5.21, Řízení bezpečnosti informací v dodavatelském řetězci ICT, poskytuje oporu v opatřeních.

V Zenith Controls Clarysec mapuje opatření 5.21 jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Jeho provozní schopností je bezpečnost vztahů s dodavateli a jeho domény zahrnují správu a řízení, ekosystém a ochranu. Pointa je jednoduchá: dodavatelská opatření nejsou pořizovací administrativa. Jsou to opatření na ochranu ekosystému.

Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran pro malé a střední podniky (SME), požadavky na správu a řízení, kapitola 5.3, stanoví smluvní základ:

Smlouvy musí obsahovat povinné doložky pokrývající:

Pro podnikové programy vysvětluje Zenith Blueprint: 30krokový plán auditora, fáze Opatření v praxi, krok 23, organizační opatření 5.19 až 5.37, opatření ISO/IEC 27002:2022 5.20, Řešení bezpečnosti informací ve smlouvách s dodavateli:

Důvěra v dodavatele nemůže stát na předpokladech. Musí být zakotvena ve smluvních pravidlech.

Pro připravenost na CRA mají smlouvy s dodavateli zahrnovat doložky bezpečnosti produktu, které podporují rychlou reakci na zranitelnosti:

DORA posiluje stejný směr. Finanční subjekty musí řídit riziko třetích stran v oblasti ICT, vést registry smluv o službách ICT, posuzovat kritičnost, provádět náležitou péči, řídit riziko koncentrace, definovat smluvní ochranné mechanismy, zajistit práva na audit a plánovat ukončení. Pokud prodáváte software nebo ICT služby finančním subjektům, očekávejte, že se zákazníci budou ptát, zda váš proces hlášení zranitelností a SBOM dokáže podpořit jejich důkazní potřeby podle DORA v oblasti incidentů, odolnosti a třetích stran.

Pracovní postup připravenosti na CRA podle Clarysec

Clarysec pomáhá klientům provozně začlenit hlášení podle CRA do ISMS sladěného s ISO 27001:2022 prostřednictvím praktického pracovního postupu.

1. Přidejte povinnosti CRA do registru požadavků ISMS

Začněte kapitolami ISO 27001:2022 4.1 až 4.4. Aktualizujte kontext organizace, zainteresované strany a rozsah tak, aby zahrnovaly produkty s digitálními prvky, expozici na trhu EU, uživatele, dovozce, distributory, regulační orgány, CSIRT, dodavatele a regulované zákazníky.

Vytvořte položky registru požadavků pro hlášení zranitelností podle CRA, hlášení závažných bezpečnostních incidentů produktu podle CRA, oznámení incidentů podle NIS2, povinnosti podpory zákazníků podle DORA, posouzení porušení zabezpečení osobních údajů podle GDPR, smluvní oznámení incidentů, závazky CVD a komunikaci s výzkumníky.

Tím auditorům poskytnete dohledatelnou cestu od externí povinnosti k internímu opatření.

2. Vytvořte formulář pro příjem produktových zranitelností

Formulář pro příjem založte na Politice koordinovaného oznamování zranitelností. Má zachycovat identitu oznamovatele, bezpečné kontaktní údaje, verzi produktu, modul, prostředí, proof of concept, kroky k reprodukci, stav zneužití, možné vystavení dat, dopad na službu, shodu komponenty v SBOM, závažnost podle CVSS nebo rovnocenného schématu, vlastníka, referenční číslo a regulační kontrolní bod.

Formulář má automaticky vytvořit tiket ve frontě reakce na zranitelnosti. Současně má spustit časovač pro rozhodnutí o oznámení, i když je konečná odpověď „nepodléhá hlášení“.

3. Propojte data SBOM s vydáními

Pro každou vydanou verzi produktu udržujte SBOM nebo rovnocennou evidenci komponent. Minimální užitečné důkazy zahrnují název komponenty, verzi, zdroj, licenci, dodavatele nebo repozitář, verzi produktu, datum sestavení a stav skenu zranitelností.

Politika bezpečného vývoje a Politika požadavků na zabezpečení aplikací pro malé a střední podniky (SME) poskytují politický základ pro SCA, přezkum komponent a záznamy externích komponent.

4. Uchovávejte důkazy od prvního dne

Každý tiket zranitelnosti relevantní pro CRA má uchovávat:

• Původní hlášení
• Časové razítko potvrzení přijetí
• Poznámky z triáže
• Odůvodnění závažnosti podle CVSS nebo rovnocenného schématu
• Výsledky shody SBOM
• Posouzení zneužití
• Logy, indikátory a forenzní snímky
• Komunikaci s dodavateli
• Přijetí rizika, pokud je zmírnění odloženo
• Plán záplatování, poznámky k vydání a důkazy o testování
• Rozhodnutí o oznámení zákazníkům a orgánům
• Vstupy do závěrečné zprávy a získané poznatky

To odpovídá ISO 27001:2022 kapitole 8.1, která vyžaduje dokumentované informace dostatečné k doložení, že procesy probíhaly podle plánu, a kapitolám 8.2 a 8.3, které vyžadují dokumentované výsledky posouzení rizik a ošetření rizik.

5. Otestujte postup na realistickém scénáři závislosti

Proveďte simulační cvičení se simulovanou aktivně zneužívanou zranitelností závislosti. Zapojte vývoj, bezpečnost, právní oddělení, ochranu soukromí, produkt, komunikaci, řízení dodavatelů a týmy pracující se zákazníky. Test má prokázat, že organizace dokáže identifikovat dotčené verze, posoudit zneužití, přijmout rozhodnutí o oznámení, kontaktovat dodavatele, připravit pokyny pro uživatele a uchovat důkazy.

Jak auditoři otestují připravenost na hlášení zranitelností podle CRA

Přezkum připravenosti na CRA se zřídkakdy omezí na kontrolní seznam CRA. Různí auditoři budou stejné důkazy testovat prostřednictvím různých rámců.

V Zenith Controls Clarysec mapuje opatření ISO/IEC 27002:2022 5.24, Plánování a příprava řízení incidentů bezpečnosti informací, jako nápravné opatření podporující důvěrnost, integritu a dostupnost. Je sladěno s funkcemi Reagovat a Obnovit, přičemž provozními schopnostmi jsou správa a řízení a řízení událostí bezpečnosti informací.

Toto opatření je mostem mezi zjištěním zranitelnosti a regulačním hlášením.

NIST CSF 2.0 je obzvlášť užitečný jako komunikační vrstva pro správní orgány. Jeho funkce GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER pomáhají vysvětlit, jak hlášení zranitelností produktu zapadá do správy a řízení kybernetické bezpečnosti podniku, a nikoli jako výjimka pro vývoj.

Běžná selhání připravenosti na CRA, která je třeba odstranit před rokem 2026

Clarysec opakovaně vidí stejné mezery.

První je CVD bez hlášení. Společnost má bezpečnostní e-mailovou adresu nebo soubor security.txt, ale nemá interní cestu od hlášení výzkumníka k právnímu posouzení oznamovací povinnosti.

Druhé je SBOM bez vlastnictví. Vývoj dokáže během sestavení vygenerovat SBOM, ale nikdo neodpovídá za přesnost u vydaných produktů ani nevysvětluje, jak zjištění ze SBOM vstupují do reakce na zranitelnosti.

Třetí je certifikát ISO bez produktového rozsahu. ISMS pokrývá firemní IT a provoz SaaS, ale nikoli vestavěný software, firmware, infrastrukturu aktualizací produktu, pipeline sestavení ani oznamování zranitelností.

Čtvrté jsou smlouvy s dodavateli bez doložek o zranitelnostech. Nákup vyžaduje důvěrnost a ochranu údajů, ale nikoli oznámení zranitelností, transparentnost komponent, podporu při incidentech, koordinované oznámení nebo auditní důkazy.

Páté je reakce na incidenty bez logiky produktových zranitelností. Plán incidentů pokrývá ransomware, phishing a porušení zabezpečení osobních údajů, ale nikoli aktivně zneužívané zranitelnosti produktu, kdy mohou být systémy zákazníků ohroženy dříve, než je kompromitováno vlastní prostředí výrobce.

Šesté jsou důkazy pro zákazníky podle DORA zpracovávané ručně. Obchod nebo tým péče o zákazníky odpovídají na dotazníky finančního sektoru případ od případu, zatímco bezpečnost nemá standardní důkazní balíček dokládající zvládání zranitelností, správu SBOM, podporu incidentů a opatření u dodavatelů.

Každou mezeru lze odstranit. Každá se prodraží, pokud je objevena během živé zranitelnosti.

90denní kontrolní seznam připravenosti na hlášení zranitelností podle CRA

Využijte příštích 90 dnů k vytvoření obhajitelného základu:

• Identifikujte produkty s digitálními prvky uváděné na trh EU nebo na něm zpřístupňované.
• Aktualizujte rozsah ISMS a analýzu zainteresovaných stran tak, aby zahrnovaly zainteresované strany CRA.
• Přidejte posouzení hlášení podle článku 14 CRA do registru právních a regulačních požadavků.
• Zveřejněte a monitorujte bezpečný kanál pro hlášení zranitelností.
• Vytvořte tým pro reakci na zranitelnosti s rolemi právního oddělení, produktu, vývoje, bezpečnosti a komunikace.
• Udržujte SBOM nebo evidence komponent pro vydané verze produktů.
• Propojte výsledky SCA s tikety zranitelností a vydáními produktů.
• Přidejte kritéria aktivního zneužití a závažného produktového incidentu do formulářů triáže.
• Vytvořte kombinovanou rozhodovací matici oznámení pro CRA, NIS2, DORA, GDPR a smlouvy.
• Aktualizujte smlouvy s dodavateli o doložky pro oznámení zranitelností, SBOM, podporu při incidentech a koordinaci oznámení.
• Udržujte logy záplat a důkazy o nápravě.
• Otestujte pracovní postup pomocí simulované aktivně zneužívané zranitelnosti závislosti.
• Prezentujte výsledky vedení spolu s mezerami, zbytkovými riziky a vlastníky nápravy.
• Přidejte důkazní balíček do interního auditu a přezkoumání vedením.

Clarysec Politika řízení zranitelností a záplat pro malé a střední podniky (SME), požadavky na implementaci politiky, kapitola 6.2.1, podporuje základ monitorování:

Funkce IT musí monitorovat zranitelnosti pomocí:

Stejná politika, požadavky na správu a řízení, kapitola 5.4.1, doplňuje auditní stopu:

Log záplat musí být veden a přezkoumáván během auditů a činností reakce na incidenty

Tento log záplat se může stát jedním z nejdůležitějších artefaktů v závěrečné zprávě podle CRA. Dokládá zjištění, prioritizaci, nápravu, testování a uzavření.

Zajistěte, aby září 2026 bylo rutinní

Nejlepší událost hlášení podle CRA není snadná proto, že je zranitelnost jednoduchá. Je snadná proto, že organizace si pracovní postup už nacvičila.

Před zářím 2026 vám Clarysec může pomoci proměnit hlášení zranitelností v systém připravený na audit tím, že namapuje váš stávající ISMS podle ISO 27001:2022, proces CVD, schopnost SBOM, dodavatelské doložky a playbooky reakce na incidenty vůči očekáváním CRA, NIS2, DORA, GDPR a NIST CSF.

Začněte cíleným posouzením připravenosti na hlášení zranitelností podle CRA. Clarysec přezkoumá vaše politiky, důkazy SBOM, dodavatelské smlouvy, tikety zranitelností, incidentní playbooky a auditní stopu. Poté použijeme Zenith Blueprint a Zenith Controls k vytvoření praktického plánu nápravy, nikoli teoretického šanonu pro compliance.

Pokud už používáte politiky Clarysec, upravíme je pro hlášení podle CRA. Pokud je nepoužíváte, pomůžeme implementovat správnou sadu politik, včetně Politiky koordinovaného oznamování zranitelností, Politiky bezpečného vývoje, Politiky reakce na incidenty, Politiky řízení zranitelností a záplat pro malé a střední podniky (SME), Politiky požadavků na zabezpečení aplikací pro malé a střední podniky (SME) a Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran pro malé a střední podniky (SME), kde je to vhodné.

Září 2026 je dostatečně blízko pro plánování a zároveň dostatečně daleko pro disciplinovanou přípravu. Organizace, které začnou jednat nyní, se během prvních 24 hodin nebudou ptát: „Kdo vlastní tuto zranitelnost?“ Už budou mít odpověď, důkazy i cestu hlášení.

Kontaktujte Clarysec a naplánujte posouzení připravenosti na hlášení zranitelností podle CRA. Proměňte regulační složitost v obhajitelnou výhodu bezpečnosti produktu.