Vodič za spremnost na prijavu ranjivosti prema EU CRA 2026

Ponedjeljak je, 08:17, u rujnu 2026. Anna, CISO brzorastuće europske SaaS tvrtke, još razmišlja o prošlotjednoj sjednici upravnog odbora. Glavni izvršni direktor postavio je pitanje koje sada čuje svaki voditelj sigurnosti: „Ako smo se već pripremili za NIS2, a naši fintech klijenti stalno traže dokaze za DORA, što mijenja Akt o kibernetičkoj otpornosti?”

Zatim odgovor stiže u njezin pretinac e-pošte.

Neovisni istraživač prijavljuje ranjivost koja se može iskoristiti na daljinu u komponenti za ažuriranje firmvera koju koristi jedan od povezanih proizvoda tvrtke. Poruka uključuje dokaz koncepta, naziv ovisnosti i upozorenje da je slično iskorištavanje zabilježeno u stvarnom okruženju.

U nekoliko minuta svi traže drukčiji odgovor. CTO pita je li ranjivost stvarna. Pravna služba pita je li aktivirana obveza prijave prema Aktu EU-a o kibernetičkoj otpornosti. Tim proizvoda pita koje su verzije zahvaćene. CISO pita pojavljuje li se ovisnost u bilo kojem SBOM-u. Prodaja pita trebaju li klijenti iz financijskog sektora dokaze za DORA. Voditelj usklađenosti otvara ISO 27001 registar rizika i pronalazi proces upravljanja ranjivostima, ali ne i jasan put odlučivanja za prijavu povezanu s proizvodom.

To je stvarni problem spremnosti za CRA. Većina organizacija ne kreće od nule. Već ima politike odgovora na incidente, rutine upravljanja zakrpama, prakse sigurnog razvoja, preglede dobavljača, skenere ranjivosti i ISO 27001 dokaze. No CRA ne nagrađuje izolirane dokumente. Zahtijeva brz, dokaziv tijek rada koji može istodobno odgovoriti na pet pitanja:

1. Je li riječ o aktivno iskorištavanoj ranjivosti ili ozbiljnom incidentu koji utječe na sigurnost proizvoda?
2. Koji su proizvodi, verzije, klijenti, ovisnosti i dobavljači zahvaćeni?
3. Koje tijelo, klijent ili ugovorni primatelj mora biti obaviješten i kada?
4. Koji dokazi potvrđuju da su trijaža, ublažavanje i objava provedeni kontrolirano?
5. Kako je to usklađeno s ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF i revizijskim očekivanjima?

Odgovor nije zasebna „CRA mapa”. Odgovor je ugraditi prijavu ranjivosti prema CRA u ISMS, proces koordinirane objave ranjivosti, disciplinu SBOM-a, upravljanje dobavljačima i lanac dokaza za odgovor na incidente koji su vam ionako potrebni za zrelo upravljanje kibernetičkom sigurnošću.

Zašto Akt EU-a o kibernetičkoj otpornosti mijenja model prijave

Akt EU-a o kibernetičkoj otpornosti, Uredba (EU) 2024/2847, uvodi sigurnost proizvoda u glavni tok usklađenosti. Primjenjuje se na proizvode s digitalnim elementima koji se stavljaju na tržište EU-a, što može uključivati povezane uređaje, softver, firmver, ugrađene sustave i poslovne softverske proizvode.

Operativna promjena koja je najvažnija za CISO-e, voditelje sigurnosti proizvoda i timove za usklađenost počinje 11. rujna 2026. CRA Article 14 zahtijeva faznu prijavu aktivno iskorištavanih ranjivosti i ozbiljnih incidenata koji utječu na sigurnost proizvoda s digitalnim elementima. U praksi proizvođači moraju biti spremni za:

Točnu pravnu procjenu uvijek treba provesti kvalificirani pravni savjetnik, ali operativna je pouka jasna. Prvih 24 do 72 sata vrijede samo onoliko koliko vrijedi priprema dovršena mjesecima ranije.

Ako su vaši SBOM-ovi nepotpuni, ako se CVD pretinac prati neformalno, ako ugovori s dobavljačima ne zahtijevaju obavješćivanje o ranjivostima ili ako vaša politika odgovora na incidente ne razlikuje prijavu ranjivosti proizvoda od incidenata privatnosti ili operativnih incidenata, pravni rok teći će brže od vašeg procesa upravljanja dokazima.

Koristite ISO/IEC 27001:2022 kao osnovu za spremnost na CRA

ISO/IEC 27001:2022 nije zamjena za pravnu usklađenost s CRA, ali je najbolja upravljačka osnova za integraciju obveza CRA u svakodnevno upravljanje.

Točke 4.1 do 4.4 zahtijevaju da organizacija razumije unutarnji i vanjski kontekst, zainteresirane strane, zahtjeve, sučelja s drugim organizacijama i opseg ISMS-a ISO/IEC 27001:2022. Za spremnost na CRA to znači da opseg ISMS-a treba identificirati proizvode s digitalnim elementima, odgovornosti u životnom ciklusu proizvoda, hostirane komponente, cjevovode izrade, ovisnosti otvorenog koda, dobavljače, korisnike, uvoznike, distributere, regulirane klijente i relevantna tijela.

Točke 6.1.1 do 6.1.3 zahtijevaju procjenu rizika i obradu rizika, uključujući vlasnike rizika, posljedice, vjerojatnost, odluke o obradi rizika, Izjavu o primjenjivosti i prihvaćanje preostalog rizika. Prijavu prema CRA treba tretirati kao scenarij rizika sigurnosti proizvoda unutar tog procesa, a ne kao hitnu vježbu pravnog tumačenja.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 zatim daje praktičnu strukturu kontrola. Najvažnije kontrole za prijavu ranjivosti prema CRA jesu:

U Zenith Controls: vodiču za međusobno mapiranje, Clarysec mapira ISO/IEC 27002:2022 kontrolu 8.8, Upravljanje tehničkim ranjivostima, kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost. Njezini atributi usklađeni su s konceptima kibernetičke sigurnosti Identify i Protect, pri čemu je upravljanje prijetnjama i ranjivostima operativna sposobnost.

Taj je okvir važan. Prijava prema CRA nije samo obavješćivanje tijela. Riječ je o dokazivanju da je preventivna sposobnost upravljanja ranjivostima postojala prije nego što je prijava stigla.

Izgradite operativni model oko CVD-a, SBOM-a i roka za prijavu

Vjerodostojan tijek rada za ranjivosti prema CRA počinje prije nego što vas istraživač uopće kontaktira. Počinje sposobnošću zaprimanja prijava ranjivosti, njihove provjere, identificiranja zahvaćenih komponenti, procjene iskorištavanja, koordinacije ublažavanja, komunikacije s korisnicima i očuvanja dokaza.

Prvi je gradivni element javni kanal za prijavu ranjivosti. Clarysecova Politika koordinirane objave ranjivosti, točka 6.1 zahtjeva za implementaciju, navodi:

Javni kanali za objavu: Organizacija mora održavati jasan kanal za prijavu ranjivosti, kao što je namjenska adresa e-pošte za sigurnosni kontakt (na primjer, security@company.com) ili web obrazac. Te informacije moraju biti objavljene na sigurnosnoj stranici web-mjesta organizacije zajedno s javnim PGP ključem organizacije kako bi se omogućilo šifrirano podnošenje prijava.

Time se rješava čest revizijski nalaz. Mnoga društva navode da prihvaćaju prijave ranjivosti, ali je put prijave skriven, neupravljan ili usmjeren kroz opći red čekanja korisničke podrške. U uvjetima CRA kanal za prijavu postaje okidač za pravno saznanje, procjenu ozbiljnosti i prikupljanje dokaza.

Drugi je gradivni element trijaža. Politika koordinirane objave ranjivosti, točka 6.4 zahtjeva za implementaciju, navodi:

Trijaža i potvrda primitka: Po primitku prijave VRT je mora evidentirati i poslati potvrdu primitka prijavitelju u roku od 2 radna dana, uz dodjelu referentne oznake za praćenje. VRT mora provesti preliminarnu procjenu ozbiljnosti, primjerice primjenom CVSS bodovanja, i provjeriti problem, uključujući podršku IT i razvojnih timova gdje je potrebno, u ciljanom roku od 5 radnih dana. Kritične ranjivosti, kao što su one koje omogućuju udaljeno izvršavanje koda ili veću povredu podataka, moraju se rješavati ubrzano.

Za spremnost na CRA taj zapis trijaže treba proširiti poljima koja podupiru pravnu odluku o prijavi:

Treći je gradivni element disciplina SBOM-a. Clarysecova Politika sigurnog razvoja, točka 5.4 zahtjeva upravljanja, navodi:

Korištenje otvorenog koda ili koda trećih strana mora biti odobreno, praćeno i provjereno putem: 5.4.1 analize sastava softvera (SCA) 5.4.2 pregleda licenci (GPL, MIT, BSD itd.) 5.4.3 skeniranja poznatih ranjivosti (CVE-ovi, OSS Index itd.)

Za manje organizacije Clarysecova Politika zahtjeva sigurnosti aplikacija za mala i srednja poduzeća, točka 6.4.2 zahtjeva za implementaciju politike, postavlja isto očekivanje u praktičnom obliku:

Razvojni inženjer ili pružatelj IT usluga mora održavati zapis o svakoj korištenoj vanjskoj komponenti, uključujući:

Taj zapis o komponenti postaje minimalni skup dokaza za odgovor na ranjivosti vođen SBOM-om. Trebao bi povezivati naziv komponente, verziju, izvor, dobavljača ili repozitorij, licencu, verziju proizvoda, datum izrade i status skeniranja ranjivosti. Kada stigne CVE, prijava istraživača ili obavijest dobavljača, vaš tim treba u roku od nekoliko sati moći odgovoriti: „Koji objavljeni proizvodi sadržavaju ovu komponentu?”

Mapirajte CRA, NIS2, DORA i GDPR u jedinstvenu matricu odlučivanja o obavješćivanju

Akt o kibernetičkoj otpornosti neće djelovati izolirano. Jedna ranjivost proizvoda može pokrenuti prijavu prema CRA, procjenu incidenta prema NIS2, obveze dokazivanja prema klijentima prema DORA, procjenu povrede prema GDPR i ugovorne obveze obavješćivanja.

NIS2 Article 21 zahtijeva od ključnih i važnih subjekata provedbu odgovarajućih tehničkih, operativnih i organizacijskih mjera. Te mjere uključuju analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, razvoj i održavanje, postupanje s ranjivostima i njihovu objavu, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom, MFA i sigurne komunikacije.

NIS2 Article 23 uspostavlja fazni model prijave incidenata: rano upozorenje u roku od 24 sata od saznanja, obavijest o incidentu u roku od 72 sata, međuvremena ažuriranja ako se zatraže i završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu. NIS2 Article 20 također uspostavlja odgovornost upravljačkog tijela za odobravanje i nadzor mjera upravljanja kibernetičkim rizicima.

DORA se primjenjuje od 17. siječnja 2025. i uspostavlja jedinstveni okvir digitalne operativne otpornosti EU-a za financijske subjekte. Za pružatelje SaaS usluga, dobavljače softvera i IKT dobavljače, DORA se često pojavljuje kroz ugovore s klijentima. Vaš klijent iz financijskog sektora može biti regulirani DORA subjekt, ali vaše postupanje s ranjivostima, SBOM dokazi, podrška za incidente, prava na reviziju i obveze obavješćivanja mogu biti nužni kako bi taj klijent ispunio vlastite obveze.

GDPR dodaje još jednu granu. Ako ranjivost ili incident uzrokuje slučajno ili nezakonito uništenje, gubitak, izmjenu, neovlašteno otkrivanje osobnih podataka ili pristup osobnim podacima, potrebna je procjena povrede osobnih podataka. GDPR Article 5 također uključuje cjelovitost, povjerljivost i odgovornost, što znači da organizacija mora moći dokazati svoje odlučivanje.

Clarysecova Politika odgovora na incidente, točka 6.4.1 zahtjeva za implementaciju politike, već podupire ovu višerežimsku procjenu:

Ako incident rezultira potvrđenom ili vjerojatnom izloženošću osobnih podataka ili drugih reguliranih podataka, Pravna služba i službenik za zaštitu podataka (DPO) moraju procijeniti primjenjivost: 6.4.1.1 GDPR Article 33 (72-satna obavijest nadzornom tijelu) 6.4.1.2 GDPR Article 34 (obavješćivanje ispitanika kada postoji visok rizik) 6.4.1.3 NIS2 Article 23 (obavijest u roku od 24 sata od saznanja za incident) 6.4.1.4 DORA Article 17 (prijava ozbiljnih incidenata povezanih s IKT-om)

Za spremnost na CRA proširite ove operativne upute tako da uključe procjenu prijave prema CRA Article 14 za aktivno iskorištavane ranjivosti i ozbiljne incidente koji utječu na sigurnost proizvoda.

Jedinstvena matrica odlučivanja sprječava timove da vode odvojene i nedosljedne operativne upute za prijavu:

Za mala i srednja poduzeća Clarysecova Politika odgovora na incidente za mala i srednja poduzeća, točka 5.3.2 zahtjeva upravljanja, daje isto načelo u jednostavnijem obliku:

Rokovi odgovora, uključujući obnovu podataka i obveze obavješćivanja, moraju biti dokumentirani i usklađeni s pravnim zahtjevima, kao što je zahtjev GDPR-a za 72-satnu prijavu povrede osobnih podataka.

Spremnost na CRA jednostavno proširuje to načelo s prijave povrede osobnih podataka na prijavu ranjivosti proizvoda i sigurnosnih incidenata proizvoda.

Dokazi dobavljača sada su dokazi sigurnosti proizvoda

Mnoge ranjivosti relevantne za CRA potjecat će izvan vaše baze koda. Mogu dolaziti iz paketa otvorenog koda, modula firmvera, SDK-ova, hostiranih sučelja za programiranje aplikacija, alata za izradu, usluga u oblaku, podugovorenih komponenti ili uzvodnih biblioteka. Zato je upravljanje dobavljačima središnje za spremnost na CRA.

ISO 27001:2022 točka 8.1 zahtijeva da organizacije kontroliraju vanjski osigurane procese, proizvode ili usluge relevantne za ISMS. ISO/IEC 27002:2022 kontrola 5.21, Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, pruža kontrolno uporište.

U Zenith Controls, Clarysec mapira kontrolu 5.21 kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost. Njezina operativna sposobnost jest sigurnost odnosa s dobavljačima, a domene uključuju upravljanje, ekosustav i zaštitu. Poruka je jednostavna: kontrole dobavljača nisu nabavna dokumentacija. One su kontrole zaštite ekosustava.

Clarysecova Politika sigurnosti trećih strana i dobavljača za mala i srednja poduzeća, točka 5.3 zahtjeva upravljanja, postavlja ugovornu osnovu:

Ugovori moraju sadržavati obvezne odredbe koje obuhvaćaju:

Za programe u velikim organizacijama Zenith Blueprint: revizorov plan provedbe u 30 koraka, faza Kontrole u praksi, korak 23, organizacijske kontrole 5.19 do 5.37, objašnjava ISO/IEC 27002:2022 kontrolu 5.20, Uređivanje informacijske sigurnosti u ugovorima s dobavljačima:

Povjerenje, kada je riječ o dobavljačima, ne može počivati na pretpostavkama. Mora biti kodificirano.

Za spremnost na CRA ugovori s dobavljačima trebaju uključivati odredbe o sigurnosti proizvoda koje podupiru brz odgovor na ranjivosti:

DORA pojačava isti smjer. Financijski subjekti moraju upravljati IKT rizikom trećih strana, održavati registre ugovora o IKT uslugama, procjenjivati kritičnost, provoditi dubinsku analizu dobavljača, upravljati rizikom koncentracije, definirati ugovorne zaštitne mjere, osigurati prava na reviziju i planirati izlazne strategije. Ako prodajete softver ili IKT usluge financijskim subjektima, očekujte da će klijenti pitati može li vaš proces prijave ranjivosti i SBOM proces poduprijeti njihove potrebe za dokazima u vezi s DORA incidentima, otpornošću i trećim stranama.

Clarysec tijek rada za spremnost na CRA

Clarysec pomaže klijentima da prijavu prema CRA provedu unutar ISMS-a usklađenog s ISO 27001:2022 putem praktičnog tijeka rada.

1. Dodajte obveze CRA u registar zahtjeva ISMS-a

Počnite s ISO 27001:2022 točkama 4.1 do 4.4. Ažurirajte organizacijski kontekst, zainteresirane strane i opseg tako da obuhvate proizvode s digitalnim elementima, izloženost tržištu EU-a, korisnike, uvoznike, distributere, regulatore, CSIRT-ove, dobavljače i regulirane klijente.

Izradite unose u registru zahtjeva za prijavu ranjivosti prema CRA, prijavu ozbiljnih sigurnosnih incidenata proizvoda prema CRA, obavješćivanje o incidentima prema NIS2, obveze podrške klijentima prema DORA, procjenu povrede osobnih podataka prema GDPR, ugovornu obavijest o incidentu, CVD obveze i komunikaciju s istraživačima.

Time se revizorima daje sljediv put od vanjske obveze do interne kontrole.

2. Izradite obrazac za zaprimanje ranjivosti proizvoda

Temeljite obrazac za zaprimanje na Politici koordinirane objave ranjivosti. Treba obuhvatiti identitet prijavitelja, sigurne kontaktne podatke, verziju proizvoda, modul, okruženje, dokaz koncepta, korake za reprodukciju, status iskorištavanja, moguću izloženost podataka, utjecaj na uslugu, podudaranje SBOM komponente, CVSS ili ekvivalentnu ozbiljnost, vlasnika, referentnu oznaku za praćenje i regulatornu kontrolnu točku.

Obrazac treba automatski otvoriti prijavu u redu za odgovor na ranjivosti. Također treba pokrenuti mjerač vremena za odluku o obavješćivanju, čak i ako je konačan odgovor „nije prijavljivo”.

3. Povežite SBOM podatke s izdanjima

Za svaku objavljenu verziju proizvoda održavajte SBOM ili ekvivalentni popis komponenti. Minimalni korisni dokazi uključuju naziv komponente, verziju, izvor, licencu, dobavljača ili repozitorij, verziju proizvoda, datum izrade i status skeniranja ranjivosti.

Politika sigurnog razvoja i Politika zahtjeva sigurnosti aplikacija za mala i srednja poduzeća pružaju osnovu politike za SCA, pregled komponenti i zapise o vanjskim komponentama.

4. Čuvajte dokaze od prvog dana

Svaka prijava ranjivosti relevantna za CRA treba zadržati:

• Izvornu prijavu
• Vremensku oznaku potvrde primitka
• Bilješke trijaže
• CVSS ili ekvivalentno obrazloženje ozbiljnosti
• Rezultate podudaranja SBOM-a
• Procjenu iskorištavanja
• Zapise dnevnika, pokazatelje i forenzičke snimke
• Komunikaciju s dobavljačima
• Prihvaćanje rizika, ako je ublažavanje odgođeno
• Plan zakrpe, napomene o izdanju i dokaze testiranja
• Odluke o obavješćivanju klijenata i tijela
• Ulazne podatke za završno izvješće i naučene lekcije

To je usklađeno s ISO 27001:2022 točkom 8.1, koja zahtijeva dokumentirane informacije dostatne za dokazivanje da su procesi provedeni kako je planirano, te točkama 8.2 i 8.3, koje zahtijevaju dokumentirane rezultate procjene rizika i obrade rizika.

5. Testirajte na realističnom scenariju ovisnosti

Provedite stolnu vježbu koristeći simuliranu aktivno iskorištavanu ranjivost ovisnosti. Uključite inženjering, sigurnost, pravnu službu, privatnost, proizvod, komunikacije, upravljanje dobavljačima i timove koji rade s klijentima. Test treba dokazati da organizacija može identificirati zahvaćene verzije, procijeniti iskorištavanje, donijeti odluku o obavješćivanju, kontaktirati dobavljače, pripremiti upute za korisnike i očuvati dokaze.

Kako će revizori testirati spremnost na prijavu ranjivosti prema CRA

Pregled spremnosti za CRA rijetko će biti ograničen na kontrolni popis CRA. Različiti revizori testirat će iste dokaze kroz različite okvire.

U Zenith Controls, Clarysec mapira ISO/IEC 27002:2022 kontrolu 5.24, Planiranje i priprema upravljanja incidentima informacijske sigurnosti, kao korektivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost. Usklađena je s Respond i Recover, pri čemu su upravljanje i upravljanje događajima informacijske sigurnosti operativne sposobnosti.

Ta je kontrola most između otkrivanja ranjivosti i regulatorne prijave.

NIST CSF 2.0 posebno je koristan kao komunikacijski sloj na razini upravnog odbora. Njegove funkcije GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER pomažu objasniti kako se prijava ranjivosti proizvoda uklapa u korporativno upravljanje kibernetičkom sigurnošću, umjesto da stoji kao inženjerska iznimka.

Česti nedostaci u spremnosti za CRA koje treba otkloniti prije 2026.

Clarysec opetovano vidi iste praznine.

Prva je CVD bez prijave. Društvo ima sigurnosnu adresu e-pošte ili security.txt datoteku, ali nema interni put od prijave istraživača do procjene pravne obavijesti.

Druga je SBOM bez vlasništva. Inženjering može generirati SBOM tijekom izrade, ali nitko nije vlasnik točnosti za objavljene proizvode niti objašnjava kako se nalazi SBOM-a ulijevaju u odgovor na ranjivosti.

Treća je ISO certifikat bez opsega proizvoda. ISMS obuhvaća korporativni IT i SaaS operacije, ali ne i ugrađeni softver, firmver, infrastrukturu za ažuriranje proizvoda, cjevovode izrade ili objavu ranjivosti.

Četvrta su ugovori s dobavljačima bez odredbi o ranjivostima. Nabava zahtijeva povjerljivost i zaštitu podataka, ali ne i obavješćivanje o ranjivostima, transparentnost komponenti, pomoć pri incidentima, koordiniranu objavu ili revizijske dokaze.

Peta je odgovor na incidente bez logike ranjivosti proizvoda. Plan za incidente obuhvaća ransomware, phishing i povrede osobnih podataka, ali ne i aktivno iskorištavane ranjivosti proizvoda kod kojih sustavi klijenata mogu biti u riziku prije nego što je kompromitirano vlastito okruženje proizvođača.

Šesta su DORA dokazi za klijente obrađeni ručno. Prodaja ili tim za uspjeh korisnika odgovara na upitnike financijskog sektora od slučaja do slučaja, dok sigurnost nema standardni paket dokaza koji prikazuje postupanje s ranjivostima, upravljanje SBOM-om, podršku za incidente i kontrole dobavljača.

Svaka se praznina može otkloniti. Svaka postaje skupa ako se otkrije tijekom aktivne ranjivosti.

Kontrolni popis za 90-dnevnu spremnost na prijavu ranjivosti prema CRA

Iskoristite sljedećih 90 dana za uspostavu dokazive osnove:

• Identificirajte proizvode s digitalnim elementima koji su stavljeni na tržište EU-a ili su dostupni na njemu.
• Ažurirajte opseg ISMS-a i analizu zainteresiranih strana tako da uključe dionike CRA.
• Dodajte procjenu prijave prema CRA Article 14 u registar pravnih i regulatornih zahtjeva.
• Objavite i pratite siguran kanal za prijavu ranjivosti.
• Uspostavite tim za odgovor na ranjivosti s ulogama pravne službe, proizvoda, inženjeringa, sigurnosti i komunikacija.
• Održavajte SBOM-ove ili popise komponenti za objavljene verzije proizvoda.
• Povežite SCA rezultate s prijavama ranjivosti i izdanjima proizvoda.
• Dodajte kriterije aktivnog iskorištavanja i ozbiljnog incidenta proizvoda u obrasce trijaže.
• Izradite kombiniranu matricu odluka o obavješćivanju za CRA, NIS2, DORA, GDPR i ugovore.
• Ažurirajte ugovore s dobavljačima odredbama o obavijesti o ranjivostima, SBOM-u, pomoći pri incidentima i koordinaciji objave.
• Održavajte zapise zakrpa i dokaze otklanjanja.
• Testirajte tijek rada simuliranom aktivno iskorištavanom ranjivošću ovisnosti.
• Predstavite rezultate upravi s prazninama, preostalim rizicima i vlasnicima otklanjanja.
• Dodajte paket dokaza internoj reviziji i preispitivanju uprave.

Clarysecova Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća, točka 6.2.1 zahtjeva za implementaciju politike, podupire osnovu praćenja:

IT funkcija mora pratiti ranjivosti korištenjem:

Ista politika, točka 5.4.1 zahtjeva upravljanja, dodaje revizijski trag:

Zapisnik zakrpa mora se održavati i pregledavati tijekom revizija i aktivnosti odgovora na incidente

Taj zapisnik zakrpa može postati jedan od najvažnijih artefakata u završnom izvješću prema CRA. Dokazuje otkrivanje, prioritizaciju, otklanjanje, testiranje i zatvaranje.

Neka rujan 2026. bude rutinski

Najbolji događaj prijave prema CRA nije jednostavan zato što je ranjivost jednostavna. Jednostavan je zato što je organizacija već uvježbala tijek rada.

Prije rujna 2026. Clarysec vam može pomoći pretvoriti prijavu ranjivosti u sustav spreman za reviziju mapiranjem vašeg postojećeg ISO 27001:2022 ISMS-a, CVD procesa, SBOM sposobnosti, odredbi za dobavljače i operativnih uputa za odgovor na incidente prema očekivanjima CRA, NIS2, DORA, GDPR i NIST CSF.

Počnite fokusiranom procjenom spremnosti za prijavu ranjivosti prema CRA. Clarysec će pregledati vaše politike, SBOM dokaze, ugovore s dobavljačima, prijave ranjivosti, operativne upute za incidente i revizijski trag. Zatim ćemo koristiti Zenith Blueprint i Zenith Controls za izradu praktičnog plana otklanjanja nedostataka, a ne teorijskog registratora usklađenosti.

Ako već koristite Clarysec politike, prilagodit ćemo ih za prijavu prema CRA. Ako ih ne koristite, možemo pomoći implementirati odgovarajući skup politika, uključujući Politiku koordinirane objave ranjivosti, Politiku sigurnog razvoja, Politiku odgovora na incidente, Politiku upravljanja ranjivostima i zakrpama za mala i srednja poduzeća, Politiku zahtjeva sigurnosti aplikacija za mala i srednja poduzeća i Politiku sigurnosti trećih strana i dobavljača za mala i srednja poduzeća gdje je primjereno.

Rujan 2026. dovoljno je blizu za planiranje i dovoljno daleko za discipliniranu pripremu. Organizacije koje djeluju sada neće se u prva 24 sata pitati: „Tko je vlasnik ove ranjivosti?” Već će imati odgovor, dokaze i put prijave.

Kontaktirajte Clarysec kako biste zakazali procjenu spremnosti za prijavu ranjivosti prema CRA i pretvorili regulatornu složenost u dokazivu prednost sigurnosti proizvoda.