Vodnik za pripravljenost na poročanje o ranljivostih po EU CRA 2026

Ponedeljek zjutraj je, 08:17, septembra 2026. Anna, vodja informacijske varnosti v hitro rastočem evropskem SaaS podjetju, še vedno razmišlja o sestanku upravnega odbora iz prejšnjega tedna. Generalni direktor je zastavil vprašanje, ki ga zdaj sliši vsak vodja varnosti: »Če smo se že pripravili na NIS2 in nas fintech stranke nenehno sprašujejo po DORA, kaj spremeni Akt o kibernetski odpornosti?«

Nato odgovor pristane v njenem nabiralniku.

Neodvisni raziskovalec prijavi ranljivost, ki jo je mogoče izkoristiti na daljavo, v komponenti za posodabljanje vdelane programske opreme, uporabljeni v enem od povezanih izdelkov podjetja. Sporočilo vključuje dokaz koncepta, ime odvisnosti in opozorilo, da je bilo podobno izkoriščanje opaženo v realnem okolju.

V nekaj minutah vsak zahteva drugačen odgovor. CTO sprašuje, ali je ranljivost resnična. Pravna služba sprašuje, ali je bilo sproženo poročanje po Aktu EU o kibernetski odpornosti. Produktna ekipa sprašuje, katere različice so prizadete. Vodja informacijske varnosti sprašuje, ali se odvisnost pojavlja v katerem koli SBOM. Prodaja sprašuje, ali stranke iz finančnega sektorja potrebujejo dokazila po DORA. Odgovorna oseba za skladnost odpre register tveganj ISO 27001 in najde proces upravljanja ranljivosti, vendar brez jasne odločitvene poti za poročanje o izdelku.

To je dejanski problem pripravljenosti na CRA. Večina organizacij ne začenja z ničle. Že imajo politike odzivanja na incidente, rutine upravljanja popravkov, prakse varnega razvoja kode, preglede dobaviteljev, skenerje ranljivosti in dokazila ISO 27001. Vendar CRA ne nagrajuje ločenih dokumentov. Zahteva hiter in utemeljljiv potek dela, ki lahko hkrati odgovori na pet vprašanj:

1. Ali gre za aktivno izkoriščano ranljivost ali hud incident, ki vpliva na varnost izdelka?
2. Kateri izdelki, različice, stranke, odvisnosti in dobavitelji so prizadeti?
3. Kateri organ, stranko ali pogodbenega prejemnika je treba obvestiti in kdaj?
4. Katera dokazila potrjujejo, da so bili triaža, omilitveni ukrepi in razkritje nadzorovani?
5. Kako se to ujema z ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF in pričakovanji presoje?

Odgovor ni ločena »mapa CRA«. Odgovor je povezati poročanje o ranljivostih po CRA z ISMS, procesom usklajenega razkrivanja ranljivosti, disciplino SBOM, upravljanjem dobaviteljev in verigo dokazil odzivanja na incidente, ki jih že potrebujete za zrelo upravljanje kibernetske varnosti.

Zakaj Akt EU o kibernetski odpornosti spreminja model poročanja

Akt EU o kibernetski odpornosti, Uredba (EU) 2024/2847, varnost izdelkov umešča v osrednji tok skladnosti. Uporablja se za izdelke z digitalnimi elementi, dane na trg EU, kar lahko vključuje povezane naprave, programsko opremo, vdelano programsko opremo, vgrajene sisteme in podjetniške programske izdelke.

Operativna sprememba, ki je najpomembnejša za vodje informacijske varnosti, vodje varnosti izdelkov in ekipe za skladnost, se začne 11. septembra 2026. CRA Article 14 zahteva fazno poročanje za aktivno izkoriščane ranljivosti in hude incidente, ki vplivajo na varnost izdelkov z digitalnimi elementi. V praksi morajo biti proizvajalci pripravljeni na:

Natančno pravno presojo mora vedno opraviti usposobljen pravni svetovalec, vendar je operativno sporočilo jasno. Prvih 24 do 72 ur je uspešnih le toliko, kolikor je bila priprava opravljena mesece prej.

Če so vaši SBOM nepopolni, če je nabiralnik CVD spremljan neformalno, če pogodbe z dobavitelji ne zahtevajo obveščanja o ranljivostih ali če vaša politika odzivanja na incidente ne razlikuje poročanja o ranljivostih izdelkov od zasebnostnih ali operativnih incidentov, bo pravni rok tekel hitreje kot vaš proces dokazovanja.

Uporabite ISO/IEC 27001:2022 kot ogrodje za pripravljenost na CRA

ISO/IEC 27001:2022 ni nadomestilo za pravno skladnost s CRA, vendar je najboljše ogrodje sistema upravljanja za vključitev obveznosti CRA v vsakodnevno upravljanje.

Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume notranji in zunanji kontekst, zainteresirane strani, zahteve, vmesnike z drugimi organizacijami in obseg ISMS ISO/IEC 27001:2022. Za pripravljenost na CRA to pomeni, da mora obseg ISMS opredeliti izdelke z digitalnimi elementi, odgovornosti v življenjskem ciklu izdelkov, gostovane komponente, CI/CD cevovode, odprtokodne odvisnosti, dobavitelje, uporabnike, uvoznike, distributerje, regulirane stranke in pristojne organe.

Klavzule 6.1.1 do 6.1.3 zahtevajo ocenjevanje tveganj in obravnavo tveganj, vključno z lastniki tveganj, posledicami, verjetnostjo, odločitvami o obravnavi, izjavo o uporabljivosti in sprejemom preostalega tveganja. Poročanje po CRA je treba obravnavati kot scenarij tveganja varnosti izdelka znotraj tega procesa, ne kot ad hoc pravno interpretacijo.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 nato zagotovi praktično strukturo kontrol. Najpomembnejše kontrole za poročanje o ranljivostih po CRA so:

V Zenith Controls: vodniku za navzkrižno skladnost Clarysec preslika kontrolo ISO/IEC 27002:2022 8.8, Upravljanje tehničnih ranljivosti, kot preventivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost. Njeni atributi se ujemajo s konceptoma kibernetske varnosti Identify in Protect, pri čemer je upravljanje groženj in ranljivosti operativna zmožnost.

Ta okvir je pomemben. Poročanje po CRA ni samo obveščanje organov. Gre za dokazovanje, da je preventivna zmožnost upravljanja ranljivosti obstajala že pred prejemom prijave.

Operativni model zgradite okoli CVD, SBOM in rokov poročanja

Verodostojen potek dela za ranljivosti po CRA se začne, preden vas raziskovalec sploh kontaktira. Začne se z zmožnostjo sprejemanja prijav ranljivosti, njihovega preverjanja, prepoznavanja prizadetih komponent, ocene izkoriščanja, koordinacije omilitvenih ukrepov, komuniciranja z uporabniki in ohranjanja dokazil.

Prvi gradnik je javni kanal za poročanje o ranljivostih. Clarysecova Politika usklajenega razkrivanja ranljivosti, klavzula 6.1 zahtev za implementacijo, določa:

Javni kanali razkritja: Organizacija mora vzdrževati jasen kanal za poročanje o ranljivostih, kot je namenski varnostni e-naslov za stik (na primer security@company.com) ali spletni obrazec. Te informacije morajo biti objavljene na varnostni strani spletnega mesta podjetja skupaj z javnim ključem PGP organizacije, da se omogočijo šifrirane oddaje.

To odpravlja pogosto revizijsko pomanjkljivost. Mnoga podjetja pravijo, da sprejemajo prijave ranljivosti, vendar je pot poročanja skrita, neupravljana ali usmerjena v splošno čakalno vrsto podpore. V razmerah CRA kanal za poročanje postane sprožilna točka za pravno seznanitev, presojo resnosti in zajem dokazil.

Drugi gradnik je triaža. Politika usklajenega razkrivanja ranljivosti, klavzula 6.4 zahtev za implementacijo, določa:

Triaža in potrditev prejema: Ob prejemu prijave jo mora VRT evidentirati in prijavitelju v 2 delovnih dneh poslati potrditev prejema ter dodeliti referenco za sledenje. VRT mora izvesti predhodno presojo resnosti, na primer z uporabo točkovanja CVSS, in preveriti težavo, po potrebi tudi s podporo ekip IT in razvojnih ekip, v ciljnem roku 5 delovnih dni. Kritične ranljivosti, kot so tiste, ki omogočajo oddaljeno izvajanje kode ali večjo kršitev varnosti osebnih podatkov, je treba obravnavati pospešeno.

Za pripravljenost na CRA je treba ta zapis triaže razširiti s polji, ki podpirajo pravno odločitev o poročanju:

Tretji gradnik je disciplina SBOM. Clarysecova Politika varnega razvoja, klavzula 5.4 zahtev upravljanja, določa:

Uporaba odprtokodne kode ali kode tretjih oseb mora biti odobrena, spremljana in preverjena prek: 5.4.1 analiza sestave programske opreme (SCA) 5.4.2 pregled licence (GPL, MIT, BSD itd.) 5.4.3 skeniranje znanih ranljivosti (CVE, OSS Index itd.)

Za manjše organizacije Clarysecova Politika zahtev za varnost aplikacij - SME, klavzula 6.4.2 zahtev za implementacijo politike, postavlja enako pričakovanje v praktični obliki:

Razvijalec ali ponudnik IT mora vzdrževati zapis o vsaki uporabljeni zunanji komponenti, vključno z:

Ta zapis komponent postane minimalni nabor dokazil za odziv na ranljivosti, ki temelji na SBOM. Povezovati mora ime komponente, različico, vir, dobavitelja ali repozitorij, licenco, različico izdelka, datum gradnje in status skeniranja ranljivosti. Ko prispe CVE, prijava raziskovalca ali obvestilo dobavitelja, mora ekipa v nekaj urah odgovoriti: »Kateri izdani izdelki vsebujejo to komponento?«

CRA, NIS2, DORA in GDPR preslikajte v enotno odločitveno matriko obveščanja

Akt o kibernetski odpornosti ne bo deloval ločeno. Ena ranljivost izdelka lahko sproži poročanje po CRA, presojo incidenta po NIS2, obveznosti dokazovanja za stranke po DORA, presojo kršitve po GDPR in pogodbene obveznosti obveščanja.

NIS2 Article 21 od bistvenih in pomembnih subjektov zahteva uvedbo ustreznih tehničnih, operativnih in organizacijskih ukrepov. Ti ukrepi vključujejo analizo tveganja, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno pridobivanje, razvoj in vzdrževanje, obravnavo in razkritje ranljivosti, presojo učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev, MFA in varne komunikacije.

NIS2 Article 23 določa fazni model poročanja o incidentih: zgodnje opozorilo v 24 urah od seznanitve, obvestilo o incidentu v 72 urah, vmesne posodobitve na zahtevo in končno poročilo najpozneje en mesec po obvestilu o incidentu. NIS2 Article 20 ustvarja tudi odgovornost poslovodnega organa za odobritev in nadzor ukrepov upravljanja tveganj kibernetske varnosti.

DORA se uporablja od 17. januarja 2025 in vzpostavlja enoten okvir digitalne operativne odpornosti EU za finančne subjekte. Pri ponudnikih SaaS, dobaviteljih programske opreme in dobaviteljih IKT se DORA pogosto pojavi prek pogodb s strankami. Vaša stranka iz finančnega sektorja je lahko regulirani subjekt po DORA, vendar so vaše ravnanje z ranljivostmi, dokazila SBOM, podpora pri incidentih, pravice do revizije in zaveze glede obveščanja lahko potrebni, da ta stranka izpolni svoje obveznosti.

GDPR doda še eno vejo. Če ranljivost ali incident povzroči nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih, je potrebna presoja kršitve varnosti osebnih podatkov. GDPR Article 5 vključuje tudi celovitost, zaupnost in odgovornost, kar pomeni, da mora biti organizacija zmožna dokazati svoje odločanje.

Clarysecova Politika odzivanja na incidente, klavzula 6.4.1 zahtev za implementacijo politike, že podpira to večrežimsko presojo:

Če incident povzroči potrjeno ali verjetno izpostavljenost osebnih podatkov ali drugih reguliranih podatkov, morata pravna služba in DPO presoditi uporabo: 6.4.1.1 GDPR Article 33 (72-urno obveščanje nadzornega organa) 6.4.1.2 GDPR Article 34 (obveščanje posameznikov, na katere se nanašajo osebni podatki, kadar obstaja veliko tveganje) 6.4.1.3 NIS2 Article 23 (obvestilo v 24 urah od seznanitve z incidentom) 6.4.1.4 DORA Article 17 (poročanje o hudih incidentih, povezanih z IKT)

Za pripravljenost na CRA razširite ta postopek odzivanja tako, da vključuje presojo poročanja po CRA Article 14 za aktivno izkoriščane ranljivosti in hude incidente, ki vplivajo na varnost izdelkov.

Enotna odločitvena matrika preprečuje, da bi ekipe izvajale ločene in nedosledne postopke poročanja:

Za SME Clarysecova Politika odzivanja na incidente - SME, klavzula 5.3.2 zahtev upravljanja, podaja isto načelo v enostavnejši obliki:

Časovni roki odziva, vključno z obnovitvijo podatkov in obveznostmi obveščanja, morajo biti dokumentirani in usklajeni z zakonskimi zahtevami, kot je zahteva GDPR za 72-urno obveščanje o kršitvi varnosti osebnih podatkov.

Pripravljenost na CRA to načelo preprosto razširi z obveščanja o kršitvi varnosti osebnih podatkov na poročanje o ranljivostih izdelkov in incidentih varnosti izdelkov.

Dokazila dobaviteljev so zdaj dokazila varnosti izdelkov

Veliko ranljivosti, relevantnih za CRA, bo izviralo zunaj vaše kode. Izhajajo lahko iz odprtokodnih paketov, modulov vdelane programske opreme, SDK, gostovanih vmesnikov za aplikacijsko programiranje, orodij za gradnjo, storitev v oblaku, podizvajalskih komponent ali knjižnic iz dobavne verige navzgor. Zato je upravljanje dobaviteljev ključno za pripravljenost na CRA.

Klavzula 8.1 standarda ISO 27001:2022 zahteva, da organizacije nadzorujejo zunanje zagotovljene procese, izdelke ali storitve, ki so relevantni za ISMS. Kontrola ISO/IEC 27002:2022 5.21, Upravljanje informacijske varnosti v dobavni verigi IKT, zagotavlja kontrolno sidro.

V Zenith Controls Clarysec preslika kontrolo 5.21 kot preventivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost. Njena operativna zmožnost je varnost odnosov z dobavitelji, njena področja pa vključujejo upravljanje, ekosistem in zaščito. Bistvo je preprosto: kontrole dobaviteljev niso nabavna dokumentacija. So kontrole zaščite ekosistema.

Clarysecova Politika varnosti tretjih oseb in dobaviteljev - SME, klavzula 5.3 zahtev upravljanja, določa pogodbeno podlago:

Pogodbe morajo vključevati obvezne klavzule, ki zajemajo:

Za programe na ravni podjetja Zenith Blueprint: 30-koračni časovni načrt za presojevalce, faza Kontrole v praksi, korak 23, Organizacijski ukrepi 5.19 do 5.37, pojasnjuje kontrolo ISO/IEC 27002:2022 5.20, Obravnava informacijske varnosti v pogodbah z dobavitelji:

Zaupanje pri dobaviteljih ne sme temeljiti na predpostavkah. Mora biti kodificirano.

Za pripravljenost na CRA morajo pogodbe z dobavitelji vključevati klavzule o varnosti izdelkov, ki podpirajo hiter odziv na ranljivosti:

DORA krepi isto usmeritev. Finančni subjekti morajo upravljati tveganje tretjih oseb IKT, vzdrževati registre pogodb za IKT storitve, ocenjevati kritičnost, izvajati skrbni pregled, upravljati tveganje koncentracije, opredeliti pogodbene zaščitne ukrepe, zagotoviti pravice do revizije in načrtovati izstop. Če prodajate programsko opremo ali IKT storitve finančnim subjektom, pričakujte, da bodo stranke vprašale, ali lahko vaš proces poročanja o ranljivostih in SBOM podpira njihove potrebe po dokazilih za incidente, odpornost in tretje osebe po DORA.

Clarysecov potek dela za pripravljenost na CRA

Clarysec strankam pomaga operacionalizirati poročanje po CRA znotraj ISMS, usklajenega z ISO 27001:2022, prek praktičnega poteka dela.

1. Dodajte obveznosti CRA v register zahtev ISMS

Začnite s klavzulami ISO 27001:2022 4.1 do 4.4. Posodobite organizacijski kontekst, zainteresirane strani in obseg, da vključujejo izdelke z digitalnimi elementi, izpostavljenost trgu EU, uporabnike, uvoznike, distributerje, regulatorje, CSIRT, dobavitelje in regulirane stranke.

Ustvarite vnose v registru zahtev za poročanje o ranljivostih po CRA, poročanje o hudih incidentih varnosti izdelkov po CRA, obveščanje o incidentih po NIS2, obveznosti podpore strankam po DORA, presojo kršitev varnosti osebnih podatkov po GDPR, pogodbena obvestila o incidentih, zaveze CVD in komunikacijo z raziskovalci.

To presojevalcem zagotovi sledljivo pot od zunanje obveznosti do notranje kontrole.

2. Ustvarite obrazec za sprejem ranljivosti izdelka

Obrazec za sprejem naj temelji na Politiki usklajenega razkrivanja ranljivosti. Zajemati mora identiteto prijavitelja, varne kontaktne podatke, različico izdelka, modul, okolje, dokaz koncepta, korake za reprodukcijo, status izkoriščanja, morebitno izpostavljenost podatkov, vpliv na storitev, ujemanje komponente SBOM, resnost po CVSS ali enakovredno, lastnika, referenco za sledenje in regulativno kontrolno točko.

Obrazec mora samodejno ustvariti zahtevek v čakalni vrsti za odziv na ranljivosti. Prav tako mora zagnati časovnik za odločitev o obveščanju, tudi če je končni odgovor »ni predmet poročanja«.

3. Povežite podatke SBOM z izdajami

Za vsako izdano različico izdelka vzdržujte SBOM ali enakovreden popis komponent. Najmanjši uporabni nabor dokazil vključuje ime komponente, različico, vir, licenco, dobavitelja ali repozitorij, različico izdelka, datum gradnje in status skeniranja ranljivosti.

Politika varnega razvoja in Politika zahtev za varnost aplikacij - SME zagotavljata podlago politike za SCA, pregled komponent in zapise zunanjih komponent.

4. Ohranjajte dokazila od prvega dne

Vsak zahtevek za ranljivost, relevanten za CRA, mora hraniti:

• Prvotno prijavo
• Časovni žig potrditve prejema
• Opombe triaže
• Utemeljitev resnosti po CVSS ali enakovredno
• Rezultate ujemanja SBOM
• Presojo izkoriščanja
• Dnevnike, kazalnike in forenzične posnetke
• Komunikacijo z dobavitelji
• Sprejem tveganja, če je omilitev odložena
• Načrt popravkov, opombe ob izdaji in dokazila testiranja
• Odločitve o obveščanju strank in organov
• Vhodne podatke za končno poročilo in pridobljene izkušnje

To je skladno s klavzulo ISO 27001:2022 8.1, ki zahteva dokumentirane informacije, zadostne za dokazovanje, da so procesi delovali po načrtu, ter s klavzulama 8.2 in 8.3, ki zahtevata dokumentirane rezultate ocene tveganja in obravnave tveganja.

5. Testirajte z realističnim scenarijem odvisnosti

Izvedite namizno vajo s simulirano aktivno izkoriščano ranljivostjo odvisnosti. Vključite inženiring, varnost, pravno službo, zasebnost, produkt, komuniciranje, upravljanje dobaviteljev in ekipe, ki delajo s strankami. Test mora dokazati, da lahko organizacija prepozna prizadete različice, presodi izkoriščanje, sprejme odločitev o obveščanju, kontaktira dobavitelje, pripravi navodila za uporabnike in ohrani dokazila.

Kako bodo presojevalci preverjali pripravljenost na poročanje o ranljivostih po CRA

Pregled pripravljenosti na CRA bo redko omejen na kontrolni seznam CRA. Različni presojevalci bodo ista dokazila preverjali skozi različne okvire.

V Zenith Controls Clarysec preslika kontrolo ISO/IEC 27002:2022 5.24, Načrtovanje in priprava upravljanja incidentov informacijske varnosti, kot korektivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost. Ujema se s funkcijama Respond in Recover, pri čemer sta upravljanje in upravljanje dogodkov informacijske varnosti operativni zmožnosti.

Ta kontrola je most med odkritjem ranljivosti in regulativnim poročanjem.

NIST CSF 2.0 je posebej uporaben kot komunikacijska plast na ravni upravnega odbora. Njegove funkcije GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER pomagajo pojasniti, kako poročanje o ranljivostih izdelkov sodi v korporativno upravljanje kibernetske varnosti, namesto da bi ostalo inženirska izjema.

Pogoste pomanjkljivosti pripravljenosti na CRA, ki jih odpravite pred letom 2026

Clarysec ponavljajoče zaznava iste vrzeli.

Prva je CVD brez poročanja. Podjetje ima varnostni e-naslov ali datoteko security.txt, vendar nima notranje poti od prijave raziskovalca do pravne presoje obveščanja.

Druga je SBOM brez lastništva. Inženiring lahko med gradnjo ustvari SBOM, vendar nihče ne odgovarja za točnost pri izdanih izdelkih ali ne pojasni, kako ugotovitve SBOM napajajo odziv na ranljivosti.

Tretja je ISO certifikat brez obsega izdelkov. ISMS pokriva korporativni IT in SaaS operacije, ne pa vgrajene programske opreme, vdelane programske opreme, infrastrukture za posodabljanje izdelkov, CI/CD cevovodov ali razkrivanja ranljivosti.

Četrta so pogodbe z dobavitelji brez klavzul o ranljivostih. Nabava zahteva zaupnost in varstvo podatkov, ne pa obveščanja o ranljivostih, preglednosti komponent, pomoči pri incidentih, usklajenega razkritja ali revizijskih dokazil.

Peta je odziv na incidente brez logike ranljivosti izdelkov. Načrt za incidente pokriva izsiljevalsko programsko opremo, spletno ribarjenje in kršitve varnosti osebnih podatkov, ne pa aktivno izkoriščanih ranljivosti izdelkov, pri katerih so lahko sistemi strank ogroženi, še preden je ogroženo lastno okolje proizvajalca.

Šesta so dokazila za stranke po DORA, obravnavana ročno. Prodaja ali služba za uspeh strank se na vprašalnike finančnega sektorja odziva od primera do primera, medtem ko varnost nima standardnega paketa dokazil, ki prikazuje ravnanje z ranljivostmi, upravljanje SBOM, podporo pri incidentih in kontrole dobaviteljev.

Vsako vrzel je mogoče odpraviti. Vsaka postane draga, če se odkrije med živo ranljivostjo.

90-dnevni kontrolni seznam pripravljenosti na poročanje o ranljivostih po CRA

Naslednjih 90 dni uporabite za vzpostavitev utemeljljive podlage:

• Prepoznajte izdelke z digitalnimi elementi, dane na trg EU ali na njem omogočene.
• Posodobite obseg ISMS in analizo zainteresiranih strani, da vključujeta deležnike CRA.
• Dodajte presojo poročanja po CRA Article 14 v register pravnih in regulativnih zahtev.
• Objavite in spremljajte varen kanal za poročanje o ranljivostih.
• Ustanovite skupino za odziv na ranljivosti z vlogami pravne službe, produkta, inženiringa, varnosti in komuniciranja.
• Vzdržujte SBOM ali popise komponent za izdane različice izdelkov.
• Povežite rezultate SCA z zahtevki za ranljivosti in izdajami izdelkov.
• Dodajte merila aktivnega izkoriščanja in hudega incidenta izdelka v obrazce triaže.
• Ustvarite združeno odločitveno matriko za obveščanje po CRA, NIS2, DORA, GDPR in pogodbah.
• Posodobite pogodbe z dobavitelji s klavzulami o obvestilih o ranljivostih, SBOM, pomoči pri incidentih in koordinaciji razkritja.
• Vzdržujte evidence popravkov in dokazila o sanaciji.
• Testirajte potek dela s simulirano aktivno izkoriščano ranljivostjo odvisnosti.
• Predstavite rezultate vodstvu z vrzelmi, preostalimi tveganji in lastniki sanacije.
• Dodajte paket dokazil v notranjo presojo in vodstveni pregled.

Clarysecova Politika upravljanja ranljivosti in popravkov - SME, klavzula 6.2.1 zahtev za implementacijo politike, podpira osnovo spremljanja:

Funkcija IT mora spremljati ranljivosti z uporabo:

Ista politika, klavzula 5.4.1 zahtev upravljanja, dodaja revizijsko sled:

Evidenco popravkov je treba vzdrževati in pregledovati med presojami ter dejavnostmi odziva na incidente.

Ta evidenca popravkov lahko postane eden najpomembnejših artefaktov v končnem poročilu po CRA. Dokazuje odkritje, prednostno razvrstitev, sanacijo, testiranje in zaprtje.

Naj bo september 2026 dolgočasen

Najboljši dogodek poročanja po CRA ni enostaven zato, ker je ranljivost preprosta. Enostaven je zato, ker je organizacija potek dela že preizkusila.

Pred septembrom 2026 vam lahko Clarysec pomaga spremeniti poročanje o ranljivostih v sistem, pripravljen za presojo, tako da vaš trenutni ISMS ISO 27001:2022, proces CVD, zmožnost SBOM, klavzule dobaviteljev in postopke odzivanja na incidente preslika glede na pričakovanja CRA, NIS2, DORA, GDPR in NIST CSF.

Začnite z osredotočeno presojo pripravljenosti na poročanje o ranljivostih po CRA. Clarysec bo pregledal vaše politike, dokazila SBOM, pogodbe z dobavitelji, zahtevke za ranljivosti, postopke odzivanja na incidente in revizijsko sled. Nato bomo uporabili Zenith Blueprint in Zenith Controls za pripravo praktičnega časovnega načrta sanacije, ne teoretične mape skladnosti.

Če že uporabljate politike Clarysec, jih bomo prilagodili za poročanje po CRA. Če jih ne, vam lahko pomagamo implementirati ustrezen nabor politik, vključno z Politiko usklajenega razkrivanja ranljivosti, Politiko varnega razvoja, Politiko odzivanja na incidente, Politiko upravljanja ranljivosti in popravkov - SME, Politiko zahtev za varnost aplikacij - SME in Politiko varnosti tretjih oseb in dobaviteljev - SME, kjer je to primerno.

September 2026 je dovolj blizu za načrtovanje in dovolj daleč za disciplinirano pripravo. Organizacije, ki ukrepajo zdaj, v prvih 24 urah ne bodo spraševale: »Kdo je lastnik te ranljivosti?« Odgovor, dokazila in pot poročanja bodo že imele.

Kontaktirajte Clarysec za načrtovanje presoje pripravljenosti na poročanje o ranljivostih po CRA in spremenite regulativno kompleksnost v utemeljljivo prednost varnosti izdelkov.