Sprievodca pripravenosťou na hlásenie zraniteľností podľa CRA EÚ v roku 2026

Je 08:17 v pondelok ráno v septembri 2026. Anna, CISO rýchlo rastúcej európskej SaaS spoločnosti, stále premýšľa nad zasadnutím predstavenstva z minulého týždňa. Generálny riaditeľ položil otázku, ktorú dnes počuje každý bezpečnostný líder: „Ak sme sa už pripravili na NIS2 a naši fintech klienti sa neustále pýtajú na DORA, čo mení Cyber Resilience Act?“

Odpoveď jej následne príde do doručenej pošty.

Nezávislý výskumník nahlási vzdialene zneužiteľnú zraniteľnosť v komponente aktualizácie firmvéru, ktorý používa jeden z pripojených produktov spoločnosti. Správa obsahuje proof of concept, názov závislosti a upozornenie, že podobné zneužitie už bolo pozorované v reálnom prostredí.

V priebehu niekoľkých minút potrebuje každý inú odpoveď. CTO sa pýta, či je zraniteľnosť skutočná. Právne oddelenie sa pýta, či vznikla povinnosť hlásenia podľa EU Cyber Resilience Act. Produktový tím sa pýta, ktoré verzie sú dotknuté. CISO sa pýta, či sa závislosť nachádza v niektorom SBOM. Obchod sa pýta, či zákazníci z finančného sektora potrebujú dôkazy podľa DORA. Manažér súladu otvorí register rizík ISO 27001 a nájde proces riadenia zraniteľností, ale nie jasnú rozhodovaciu cestu pre hlásenie týkajúce sa produktu.

Toto je skutočný problém pripravenosti na CRA. Väčšina organizácií nezačína od nuly. Už majú politiky reakcie na incidenty, postupy riadenia záplat, praktiky bezpečného vývoja, preverovanie dodávateľov, skenery zraniteľností a dôkazy ISO 27001. CRA však neodmeňuje izolované dokumenty. Vyžaduje rýchly a obhájiteľný pracovný tok, ktorý dokáže súčasne zodpovedať päť otázok:

1. Ide o aktívne zneužívanú zraniteľnosť alebo závažný incident ovplyvňujúci bezpečnosť produktu?
2. Ktoré produkty, verzie, zákazníci, závislosti a dodávatelia sú dotknutí?
3. Ktorý orgán, zákazník alebo zmluvný príjemca musí byť informovaný a kedy?
4. Aké dôkazy preukazujú, že triáž, zmiernenie a zverejnenie boli riadené?
5. Ako je to zosúladené s ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF a očakávaniami auditu?

Riešením nie je samostatný „priečinok CRA“. Riešením je integrovať hlásenie zraniteľností podľa CRA do ISMS, procesu koordinovaného zverejňovania zraniteľností, disciplíny SBOM, riadenia dodávateľov a dôkazového reťazca reakcie na incidenty, ktoré už potrebujete na vyspelé riadenie kybernetickej bezpečnosti.

Prečo EU Cyber Resilience Act mení model hlásenia

EU Cyber Resilience Act, nariadenie (EÚ) 2024/2847, presúva bezpečnosť produktov do hlavného prúdu súladu. Vzťahuje sa na produkty s digitálnymi prvkami uvádzané na trh EÚ, čo môže zahŕňať pripojené zariadenia, softvér, firmvér, vstavané systémy a podnikové softvérové produkty.

Prevádzková zmena, ktorá je pre CISO, lídrov produktovej bezpečnosti a tímy súladu najdôležitejšia, začína 11. septembra 2026. CRA Article 14 vyžaduje stupňované hlásenie aktívne zneužívaných zraniteľností a závažných incidentov ovplyvňujúcich bezpečnosť produktov s digitálnymi prvkami. V praxi musia byť výrobcovia pripravení na:

Presné právne posúdenie má vždy vykonávať kvalifikovaný právny zástupca, prevádzkové poučenie je však jasné. Prvých 24 až 72 hodín bude len takých dobrých, ako príprava dokončená mesiace vopred.

Ak sú vaše SBOM neúplné, ak sa doručená pošta CVD monitoruje neformálne, ak zmluvy s dodávateľmi nevyžadujú oznámenie zraniteľnosti alebo ak vaša politika reakcie na incidenty nerozlišuje hlásenie zraniteľnosti produktu od incidentov ochrany súkromia alebo prevádzkových incidentov, právne lehoty budú plynúť rýchlejšie než váš dôkazový proces.

Použite ISO/IEC 27001:2022 ako nosnú konštrukciu pripravenosti na CRA

ISO/IEC 27001:2022 nie je náhradou právneho súladu s CRA, ale je najlepšou nosnou konštrukciou systému manažérstva na integráciu povinností CRA do každodenného riadenia.

Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia porozumela internému a externému kontextu, zainteresovaným stranám, požiadavkám, rozhraniam s inými organizáciami a rozsahu ISMS ISO/IEC 27001:2022. Pri pripravenosti na CRA to znamená, že rozsah ISMS má identifikovať produkty s digitálnymi prvkami, zodpovednosti v životnom cykle produktu, hostované komponenty, build pipeline, open-source závislosti, dodávateľov, používateľov, dovozcov, distribútorov, regulovaných zákazníkov a príslušné orgány.

Kapitoly 6.1.1 až 6.1.3 vyžadujú posudzovanie rizík a ošetrenie rizík vrátane vlastníkov rizík, následkov, pravdepodobnosti, rozhodnutí o ošetrení, vyhlásenia o aplikovateľnosti a akceptácie zvyškového rizika. Hlásenie podľa CRA by sa malo v tomto procese považovať za scenár rizika bezpečnosti produktu, nie za núdzové právne interpretačné cvičenie.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 následne poskytuje praktickú štruktúru kontrol. Najdôležitejšie kontroly pre hlásenie zraniteľností podľa CRA sú:

V Zenith Controls: The Cross-Compliance Guide Clarysec mapuje kontrolu ISO/IEC 27002:2022 8.8, Riadenie technických zraniteľností, ako preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť. Jej atribúty sú zosúladené s konceptmi kybernetickej bezpečnosti Identify a Protect, pričom prevádzkovou schopnosťou je riadenie hrozieb a zraniteľností.

Tento rámec je dôležitý. Hlásenie podľa CRA nie je iba o oznamovaní orgánom. Ide o preukázanie, že preventívna schopnosť riadenia zraniteľností existovala už pred doručením hlásenia.

Vybudujte prevádzkový model okolo CVD, SBOM a lehôt hlásenia

Dôveryhodný pracovný tok zraniteľností podľa CRA sa začína skôr, ako vás výskumník vôbec kontaktuje. Začína schopnosťou prijímať hlásenia zraniteľností, validovať ich, identifikovať dotknuté komponenty, posúdiť zneužitie, koordinovať zmiernenie, komunikovať s používateľmi a uchovávať dôkazy.

Prvým stavebným prvkom je verejný kanál na hlásenie zraniteľností. Politika koordinovaného zverejňovania zraniteľností spoločnosti Clarysec, kapitola 6.1 Požiadaviek na implementáciu, uvádza:

Verejné kanály na zverejňovanie: Organizácia musí udržiavať jasný kanál na hlásenie zraniteľností, napríklad vyhradenú e-mailovú adresu bezpečnostného kontaktu (napríklad security@company.com) alebo webový formulár. Tieto informácie musia byť zverejnené na bezpečnostnej stránke webu spoločnosti spolu s verejným kľúčom PGP organizácie, aby bolo možné zasielať šifrované podania.

Tým sa rieši bežné auditné zlyhanie. Mnohé spoločnosti tvrdia, že prijímajú hlásenia zraniteľností, ale cesta hlásenia je skrytá, neriadená alebo smerovaná cez všeobecný rad podpory. V podmienkach CRA sa kanál hlásenia stáva spúšťacím bodom právneho zistenia, posúdenia závažnosti a zaistenia dôkazov.

Druhým stavebným prvkom je triáž. Politika koordinovaného zverejňovania zraniteľností, kapitola 6.4 Požiadaviek na implementáciu, uvádza:

Triáž a potvrdenie prijatia: Po prijatí hlásenia ho VRT zaznamená a do 2 pracovných dní zašle oznamovateľovi potvrdenie prijatia s priradeným referenčným číslom. VRT vykoná predbežné posúdenie závažnosti, napríklad pomocou skórovania CVSS, a validuje problém vrátane podpory od IT a vývojových tímov, ak je to potrebné, v cieľovej lehote 5 pracovných dní. Kritické zraniteľnosti, napríklad tie, ktoré umožňujú vzdialené spustenie kódu alebo závažné porušenie ochrany údajov, sa musia riešiť zrýchlene.

Pre pripravenosť na CRA by sa mal tento záznam triáže rozšíriť o polia podporujúce rozhodnutie o právnom hlásení:

Tretím stavebným prvkom je disciplína SBOM. Politika bezpečného vývoja spoločnosti Clarysec, kapitola 5.4 Požiadaviek na správu a riadenie, uvádza:

Používanie open-source kódu alebo kódu tretích strán musí byť schválené, sledované a validované prostredníctvom: 5.4.1 analýzy zloženia softvéru (SCA) 5.4.2 preskúmania licencií (GPL, MIT, BSD atď.) 5.4.3 skenovania známych zraniteľností (CVE, OSS Index atď.)

Pre menšie organizácie Politika požiadaviek na bezpečnosť aplikácií - SME spoločnosti Clarysec, kapitola 6.4.2 Požiadaviek na implementáciu politiky, stanovuje rovnaké očakávanie v praktickej podobe:

Vývojár alebo poskytovateľ IT služieb musí udržiavať záznam o každom použitom externom komponente vrátane:

Tento záznam komponentu sa stáva minimálnym súborom dôkazov pre reakciu na zraniteľnosti založenú na SBOM. Mal by prepájať názov komponentu, verziu, zdroj, dodávateľa alebo repozitár, licenciu, verziu produktu, dátum zostavenia a stav skenu zraniteľností. Keď príde CVE, hlásenie výskumníka alebo oznámenie dodávateľa, váš tím by mal byť schopný do niekoľkých hodín odpovedať: „Ktoré vydané produkty obsahujú tento komponent?“

Zmapujte CRA, NIS2, DORA a GDPR do jednej rozhodovacej matice oznámení

Cyber Resilience Act nebude fungovať izolovane. Jedna zraniteľnosť produktu môže spustiť hlásenie podľa CRA, posúdenie incidentu podľa NIS2, povinnosť poskytnúť zákaznícke dôkazy podľa DORA, posúdenie porušenia ochrany osobných údajov podľa GDPR a zmluvné oznamovacie povinnosti.

NIS2 Article 21 vyžaduje, aby základné a dôležité subjekty implementovali primerané technické, prevádzkové a organizačné opatrenia. Tieto opatrenia zahŕňajú analýzu rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, bezpečné obstarávanie, vývoj a údržbu, riešenie a zverejňovanie zraniteľností, posudzovanie účinnosti, kybernetickú hygienu, kryptografiu, bezpečnosť ľudských zdrojov, riadenie prístupu, správu aktív, MFA a bezpečnú komunikáciu.

NIS2 Article 23 stanovuje stupňovaný model hlásenia incidentov: včasné varovanie do 24 hodín od zistenia, oznámenie incidentu do 72 hodín, priebežné aktualizácie na požiadanie a záverečnú správu najneskôr do jedného mesiaca od oznámenia incidentu. NIS2 Article 20 zároveň zavádza zodpovednosť riadiaceho orgánu za schvaľovanie opatrení riadenia kybernetických rizík a dohľad nad nimi.

DORA sa uplatňuje od 17. januára 2025 a vytvára jednotný rámec digitálnej prevádzkovej odolnosti EÚ pre finančné subjekty. Pre poskytovateľov SaaS, dodávateľov softvéru a dodávateľov IKT sa DORA často prejavuje prostredníctvom zákazníckych zmlúv. Váš zákazník z finančného sektora môže byť regulovaným subjektom podľa DORA, ale vaše riešenie zraniteľností, dôkazy SBOM, podpora pri incidente, práva na audit a oznamovacie záväzky môžu byť nevyhnutné na to, aby tento zákazník splnil vlastné povinnosti.

GDPR pridáva ďalšiu vetvu. Ak zraniteľnosť alebo incident spôsobí náhodné alebo nezákonné zničenie, stratu, zmenu, neoprávnené zverejnenie osobných údajov alebo prístup k nim, vyžaduje sa posúdenie porušenia ochrany osobných údajov. GDPR Article 5 zároveň zahŕňa integritu, dôvernosť a zodpovednosť, čo znamená, že organizácia musí byť schopná preukázať svoje rozhodovanie.

Politika reakcie na incidenty spoločnosti Clarysec, kapitola 6.4.1 Požiadaviek na implementáciu politiky, už podporuje toto viacpredpisové posúdenie:

Ak incident vedie k potvrdenému alebo pravdepodobnému sprístupneniu osobných údajov alebo iných regulovaných údajov, právne oddelenie a DPO musia posúdiť uplatniteľnosť: 6.4.1.1 GDPR Article 33 (72-hodinové oznámenie dozornému orgánu) 6.4.1.2 GDPR Article 34 (oznámenie dotknutým osobám, ak vzniká vysoké riziko) 6.4.1.3 NIS2 Article 23 (oznámenie do 24 hodín od zistenia incidentu) 6.4.1.4 DORA Article 17 (hlásenie závažných incidentov súvisiacich s IKT)

Pre pripravenosť na CRA rozšírte tento playbook o posúdenie hlásenia podľa CRA Article 14 pre aktívne zneužívané zraniteľnosti a závažné incidenty ovplyvňujúce bezpečnosť produktu.

Jednotná rozhodovacia matica bráni tímom používať oddelené a nekonzistentné playbooky hlásenia:

Pre MSP poskytuje Politika reakcie na incidenty - SME spoločnosti Clarysec, kapitola 5.3.2 Požiadaviek na správu a riadenie, rovnaký princíp jednoduchšou formou:

Lehoty reakcie vrátane obnovy údajov a oznamovacích povinností musia byť zdokumentované a zosúladené so zákonnými požiadavkami, napríklad s požiadavkou GDPR na 72-hodinové oznámenie porušenia ochrany osobných údajov.

Pripravenosť na CRA tento princíp jednoducho rozširuje z oznámenia porušenia ochrany osobných údajov na hlásenie zraniteľnosti produktu a incidentu bezpečnosti produktu.

Dôkazy od dodávateľov sú dnes dôkazmi bezpečnosti produktu

Mnohé zraniteľnosti relevantné pre CRA vzniknú mimo vašej kódovej základne. Môžu pochádzať z open-source balíkov, firmvérových modulov, SDK, hostovaných rozhraní API, build nástrojov, cloudových služieb, subdodávateľských komponentov alebo upstream knižníc. Preto je riadenie dodávateľov kľúčové pre pripravenosť na CRA.

Kapitola 8.1 ISO 27001:2022 vyžaduje, aby organizácie riadili externe poskytované procesy, produkty alebo služby relevantné pre ISMS. Kontrola ISO/IEC 27002:2022 5.21, Riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT, poskytuje kontrolnú oporu.

V Zenith Controls Clarysec mapuje kontrolu 5.21 ako preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť. Jej prevádzkovou schopnosťou je bezpečnosť vzťahov s dodávateľmi a jej oblasti zahŕňajú správu, ekosystém a ochranu. Pointa je jednoduchá: dodávateľské kontroly nie sú nákupná administratíva. Sú to kontroly ochrany ekosystému.

Politika bezpečnosti tretích strán a dodávateľov - SME spoločnosti Clarysec, kapitola 5.3 Požiadaviek na správu a riadenie, stanovuje zmluvný základ:

Zmluvy musia obsahovať povinné ustanovenia pokrývajúce:

Pre podnikové programy Zenith Blueprint: An Auditor’s 30-Step Roadmap, fáza Controls in Action, krok 23, organizačné opatrenia 5.19 až 5.37, vysvetľuje kontrolu ISO/IEC 27002:2022 5.20, Riešenie informačnej bezpečnosti v dodávateľských zmluvách:

Dôvera vo vzťahu k dodávateľom nemôže stáť na predpokladoch. Musí byť zakotvená.

Pre pripravenosť na CRA by dodávateľské zmluvy mali obsahovať ustanovenia produktovej bezpečnosti, ktoré podporujú rýchlu reakciu na zraniteľnosti:

DORA posilňuje rovnaké smerovanie. Finančné subjekty musia riadiť riziko tretích strán IKT, udržiavať registre zmlúv o službách IKT, posudzovať kritickosť, vykonávať náležitú starostlivosť, riadiť riziko koncentrácie, definovať zmluvné ochranné opatrenia, zabezpečiť práva na audit a plánovať ukončenie. Ak predávate softvér alebo služby IKT finančným subjektom, očakávajte, že zákazníci sa budú pýtať, či váš proces hlásenia zraniteľností a SBOM dokáže podporiť ich potreby dôkazov pre incidenty, odolnosť a tretie strany podľa DORA.

Pracovný tok pripravenosti Clarysec na CRA

Clarysec pomáha klientom prevádzkovo zapracovať hlásenie podľa CRA do ISMS zosúladeného s ISO 27001:2022 prostredníctvom praktického pracovného toku.

1. Pridajte povinnosti CRA do registra požiadaviek ISMS

Začnite kapitolami 4.1 až 4.4 ISO 27001:2022. Aktualizujte kontext organizácie, zainteresované strany a rozsah tak, aby zahŕňali produkty s digitálnymi prvkami, vystavenie trhu EÚ, používateľov, dovozcov, distribútorov, regulátorov, CSIRT, dodávateľov a regulovaných zákazníkov.

Vytvorte záznamy v registri požiadaviek pre hlásenie zraniteľností podľa CRA, hlásenie závažných incidentov bezpečnosti produktu podľa CRA, oznámenie incidentu podľa NIS2, povinnosti podpory zákazníkov podľa DORA, posúdenie porušenia ochrany osobných údajov podľa GDPR, zmluvné oznámenie incidentu, záväzky CVD a komunikáciu s výskumníkmi.

Audítorom to poskytne sledovateľnú cestu od externej povinnosti k internej kontrole.

2. Vytvorte vstupný formulár pre zraniteľnosti produktu

Vychádzajte z Politiky koordinovaného zverejňovania zraniteľností. Formulár má zachytiť identitu oznamovateľa, bezpečné kontaktné údaje, verziu produktu, modul, prostredie, proof of concept, kroky reprodukcie, stav zneužitia, potenciálne sprístupnenie údajov, dopad na službu, zhodu komponentu SBOM, CVSS alebo rovnocennú závažnosť, vlastníka, referenčné číslo a regulačný kontrolný bod.

Formulár má automaticky vytvoriť ticket vo fronte reakcie na zraniteľnosti. Má tiež spustiť časovač rozhodnutia o oznámení, aj keď konečná odpoveď bude „nepodlieha hláseniu“.

3. Prepojte údaje SBOM s vydaniami

Pre každú vydanú verziu produktu udržiavajte SBOM alebo rovnocennú evidenciu komponentov. Minimálne použiteľné dôkazy zahŕňajú názov komponentu, verziu, zdroj, licenciu, dodávateľa alebo repozitár, verziu produktu, dátum zostavenia a stav skenu zraniteľností.

Politika bezpečného vývoja a Politika požiadaviek na bezpečnosť aplikácií - SME poskytujú politický základ pre SCA, preskúmanie komponentov a záznamy externých komponentov.

4. Uchovávajte dôkazy od prvého dňa

Každý ticket zraniteľnosti relevantný pre CRA by mal uchovávať:

• pôvodné hlásenie,
• časovú pečiatku potvrdenia prijatia,
• poznámky z triáže,
• odôvodnenie závažnosti podľa CVSS alebo rovnocennej metódy,
• výsledky zhody SBOM,
• posúdenie zneužitia,
• logy, indikátory a forenzné snapshoty,
• komunikáciu s dodávateľmi,
• akceptáciu rizika, ak sa zmiernenie oneskorí,
• plán záplaty, poznámky k vydaniu a dôkazy testovania,
• rozhodnutia o oznámení zákazníkom a orgánom,
• vstupy do záverečnej správy a získané poznatky.

Toto je zosúladené s kapitolou 8.1 ISO 27001:2022, ktorá vyžaduje zdokumentované informácie postačujúce na preukázanie, že procesy fungovali podľa plánu, a s kapitolami 8.2 a 8.3, ktoré vyžadujú zdokumentované výsledky posúdenia rizík a ošetrenia rizík.

5. Otestujte realistický scenár závislosti

Vykonajte stolové cvičenie s použitím simulovanej aktívne zneužívanej zraniteľnosti závislosti. Zapojte engineering, bezpečnosť, právne oddelenie, ochranu súkromia, produkt, komunikáciu, riadenie dodávateľov a tímy komunikujúce so zákazníkmi. Test má preukázať, že vaša organizácia dokáže identifikovať dotknuté verzie, posúdiť zneužitie, prijať rozhodnutie o oznámení, kontaktovať dodávateľov, pripraviť usmernenie pre používateľov a uchovať dôkazy.

Ako budú audítori testovať pripravenosť na hlásenie zraniteľností podľa CRA

Preskúmanie pripravenosti na CRA sa zriedka obmedzí na kontrolný zoznam CRA. Rôzni audítori budú testovať rovnaké dôkazy cez rôzne rámce.

V Zenith Controls Clarysec mapuje kontrolu ISO/IEC 27002:2022 5.24, Plánovanie a príprava riadenia incidentov informačnej bezpečnosti, ako nápravnú kontrolu podporujúcu dôvernosť, integritu a dostupnosť. Je zosúladená s Respond a Recover, pričom prevádzkovými schopnosťami sú správa a riadenie a riadenie udalostí informačnej bezpečnosti.

Táto kontrola je mostom medzi objavením zraniteľnosti a regulačným hlásením.

NIST CSF 2.0 je osobitne užitočný ako komunikačná vrstva pre predstavenstvo. Jeho funkcie GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER pomáhajú vysvetliť, ako hlásenie zraniteľností produktu zapadá do podnikového riadenia kybernetickej bezpečnosti namiesto toho, aby zostalo technickou výnimkou.

Bežné zlyhania pripravenosti na CRA, ktoré treba odstrániť pred rokom 2026

Clarysec opakovane vidí rovnaké medzery.

Prvou je CVD bez hlásenia. Spoločnosť má bezpečnostnú e-mailovú adresu alebo súbor security.txt, ale nemá internú cestu od hlásenia výskumníka k právnemu posúdeniu oznámenia.

Druhou je SBOM bez vlastníctva. Engineering dokáže počas zostavenia vygenerovať SBOM, ale nikto nevlastní presnosť pre vydané produkty ani nevysvetľuje, ako zistenia SBOM vstupujú do reakcie na zraniteľnosti.

Treťou je certifikát ISO bez produktového rozsahu. ISMS pokrýva podnikové IT a SaaS prevádzku, ale nie vstavaný softvér, firmvér, infraštruktúru aktualizácií produktu, build pipeline alebo zverejňovanie zraniteľností.

Štvrtou sú zmluvy s dodávateľmi bez ustanovení o zraniteľnostiach. Obstarávanie vyžaduje dôvernosť a ochranu údajov, ale nie oznámenie zraniteľnosti, transparentnosť komponentov, pomoc pri incidente, koordinované zverejnenie alebo auditné dôkazy.

Piatou je reakcia na incidenty bez logiky zraniteľnosti produktu. Plán incidentov pokrýva ransomvér, phishing a porušenia ochrany osobných údajov, ale nie aktívne zneužívané zraniteľnosti produktov, pri ktorých môžu byť zákaznícke systémy ohrozené skôr, než je kompromitované vlastné prostredie výrobcu.

Šiestou sú dôkazy pre zákazníkov podľa DORA spracúvané manuálne. Obchod alebo customer success odpovedá na dotazníky finančného sektora prípad od prípadu, zatiaľ čo bezpečnosť nemá štandardný balík dôkazov preukazujúci riešenie zraniteľností, riadenie SBOM, podporu pri incidente a dodávateľské kontroly.

Každá medzera sa dá opraviť. Každá sa stáva drahou, ak sa odhalí počas aktívne riešenej zraniteľnosti.

90-dňový kontrolný zoznam pripravenosti na hlásenie zraniteľností podľa CRA

Využite nasledujúcich 90 dní na vybudovanie obhájiteľného základu:

• Identifikujte produkty s digitálnymi prvkami uvádzané alebo sprístupňované na trhu EÚ.
• Aktualizujte rozsah ISMS a analýzu zainteresovaných strán tak, aby zahŕňali zainteresované strany CRA.
• Pridajte posúdenie hlásenia podľa CRA Article 14 do registra právnych a regulačných požiadaviek.
• Zverejnite a monitorujte bezpečný kanál na hlásenie zraniteľností.
• Vytvorte tím pre reakciu na zraniteľnosti s rolami právneho oddelenia, produktu, engineeringu, bezpečnosti a komunikácie.
• Udržiavajte SBOM alebo evidencie komponentov pre vydané verzie produktov.
• Prepojte výsledky SCA s ticketmi zraniteľností a vydaniami produktov.
• Pridajte kritériá aktívneho zneužitia a závažného produktového incidentu do formulárov triáže.
• Vytvorte kombinovanú rozhodovaciu maticu oznámení pre CRA, NIS2, DORA, GDPR a zmluvy.
• Aktualizujte zmluvy s dodávateľmi o ustanovenia týkajúce sa oznámenia zraniteľnosti, SBOM, pomoci pri incidente a koordinácie zverejnenia.
• Udržiavajte logy záplat a dôkazy nápravy.
• Otestujte pracovný tok so simulovanou aktívne zneužívanou zraniteľnosťou závislosti.
• Predložte výsledky manažmentu spolu s medzerami, zvyškovými rizikami a vlastníkmi nápravy.
• Pridajte balík dôkazov do vnútorného auditu a preskúmania manažmentom.

Politika riadenia zraniteľností a záplat - SME spoločnosti Clarysec, kapitola 6.2.1 Požiadaviek na implementáciu politiky, podporuje základ monitorovania:

Funkcia IT musí monitorovať zraniteľnosti pomocou:

Tá istá politika, kapitola 5.4.1 Požiadaviek na správu a riadenie, pridáva auditnú stopu:

Záznam o záplatách musí byť udržiavaný a preskúmavaný počas auditov a činností reakcie na incidenty

Tento záznam o záplatách sa môže stať jedným z najdôležitejších artefaktov v záverečnej správe podľa CRA. Preukazuje objavenie, prioritizáciu, nápravu, testovanie a uzavretie.

Urobte september 2026 nudným

Najlepšia udalosť hlásenia podľa CRA nie je jednoduchá preto, že zraniteľnosť je jednoduchá. Je jednoduchá preto, že organizácia si pracovný tok už nacvičila.

Pred septembrom 2026 vám Clarysec môže pomôcť premeniť hlásenie zraniteľností na auditovateľný systém tým, že zmapuje váš aktuálny ISMS ISO 27001:2022, proces CVD, schopnosť SBOM, dodávateľské ustanovenia a playbooky reakcie na incidenty voči očakávaniam CRA, NIS2, DORA, GDPR a NIST CSF.

Začnite cieleným posúdením pripravenosti na hlásenie zraniteľností podľa CRA. Clarysec preskúma vaše politiky, dôkazy SBOM, dodávateľské zmluvy, tickety zraniteľností, incidentné playbooky a auditnú stopu. Následne použijeme Zenith Blueprint a Zenith Controls na vytvorenie praktickej cestovnej mapy nápravy, nie teoretického zakladača súladu.

Ak už používate politiky Clarysec, upravíme ich pre hlásenie podľa CRA. Ak nie, môžeme pomôcť implementovať správny súbor politík vrátane Politiky koordinovaného zverejňovania zraniteľností, Politiky bezpečného vývoja, Politiky reakcie na incidenty, Politiky riadenia zraniteľností a záplat - SME, Politiky požiadaviek na bezpečnosť aplikácií - SME a Politiky bezpečnosti tretích strán a dodávateľov - SME, ak je to vhodné.

September 2026 je dostatočne blízko na plánovanie a dostatočne ďaleko na disciplinovanú prípravu. Organizácie, ktoré konajú teraz, sa počas prvých 24 hodín nebudú pýtať: „Kto vlastní túto zraniteľnosť?“ Odpoveď, dôkazy aj cestu hlásenia už budú mať pripravené.

Kontaktujte Clarysec a dohodnite si posúdenie pripravenosti na hlásenie zraniteľností podľa CRA. Premeňte regulačnú zložitosť na obhájiteľnú výhodu v oblasti bezpečnosti produktov.