Presoja pripravljenosti za poročanje po CRA: kaj zahtevati

Koristna presoja pripravljenosti za poročanje po aktu o kibernetski odpornosti (CRA) mora pokazati, kako vaša ekipa obravnava konkreten primer: preveri področje uporabe, presodi oba razloga za obvezno poročanje, zabeleži seznanitev, obvesti uporabnike in izvede ustrezne faze poročanja. Te rezultate in merila za njihov prevzem vključite v pogodbo z izvajalcem presoje.

Obveznosti poročanja za proizvajalce so se začele uporabljati 11. septembra 2026, ko je začela delovati tudi enotna platforma za poročanje (SRP). Presoja naj zato preveri izvedljiv postopek poročanja glede na veljavne zahteve in aktualna navodila za platformo. Evropska komisija: obveznosti poročanja po CRA

Vodnik temelji na virih, preverjenih 21. septembra 2026. Pravne zahteve izhajajo iz navedene zakonodaje. Zasnova vaje, predlagane odgovorne osebe, interni ciljni roki in merila za prevzem so priporočila za naročnika presoje.

Najprej področje uporabe in dva ločena razloga za poročanje

Izvajalec naj na podlagi dokazov uporabi naslednje odločitveno drevo in vsak sklep utemelji:

1. Ali gre za izdelek tega proizvajalca in ali zanj velja CRA? Opredelite strojno ali programsko opremo, prizadete različice, pomembne sestavne dele in način omogočanja dostopnosti na trgu EU. Člen 2 zajema izdelke, katerih predvidena ali razumno predvidljiva uporaba vključuje neposredno ali posredno logično ali fizično podatkovno povezavo z napravo ali omrežjem, ob upoštevanju izključitev. Zapišite podlago za vključitev ali izključitev.
2. Ali izdelek vsebuje aktivno izrabljeno ranljivost? Člen 3(42) zahteva zanesljive dokaze, da je zlonamerni akter ranljivost izrabil v sistemu brez dovoljenja lastnika sistema. Ugotovitev pregledovalnika ranljivosti, visoka ocena resnosti ali dovoljen prikaz izrabljivosti sami po sebi tega pogoja ne izpolnjujejo. Pojasnite, kako dokazi izkazujejo zlonamerno izrabo in jo povezujejo z vašim izdelkom.
3. Neodvisno od tega: ali je na varnost izdelka vplival resen incident? Po členu 14(5) je incident resen, če negativno vpliva ali bi lahko negativno vplival na zmožnost izdelka, da zaščiti razpoložljivost, avtentičnost, celovitost ali zaupnost občutljivih oziroma pomembnih podatkov ali funkcij; ali če je privedel oziroma bi lahko privedel do uvedbe ali izvedbe zlonamerne kode v izdelku ali v omrežju in informacijskih sistemih njegovega uporabnika. Za to presojo ni treba najprej ugotoviti aktivno izrabljene ranljivosti.
4. Zabeležite sklep in ukrepajte. Če je izpolnjen kateri od pogojev, začnite ustrezen postopek poročanja in postopek obveščanja uporabnikov. Če sta izpolnjena oba, obravnavajte obe obveznosti. Če ni ugotovljen nobeden, opredelite manjkajoče dokaze, odgovorno osebo za preiskavo, pot za takojšnjo predajo pristojnim osebam in konkreten čas ponovne presoje. Nedokončana presoja ne more zadržati obveznosti, ki je že nastala.

Ta merila izhajajo iz členov 2, 3(42) in 14 uredbe CRA.

Pri spletnih aplikacijah in storitvah izrecno opredelite meje izdelka. Oznaka »spletno mesto« ali »SaaS« sama ne odloča o področju uporabe. Izdelek vključuje tudi ustrezne rešitve za daljinsko obdelavo podatkov: programsko opremo, ki jo je zasnoval in razvil proizvajalec ali je nastala pod njegovo odgovornostjo ter brez katere izdelek ne bi mogel opravljati ene od svojih funkcij. Spletno mesto, ki ne podpira funkcionalnosti izdelka, ne spada v ta okvir. Dejansko arhitekturo in način trženja presodite po členih 2 in 3(1)–(2), ob upoštevanju uvodne izjave 12. CRA: področje uporabe in daljinska obdelava podatkov

Zabeležite seznanitev in ločite zakonske roke od internih ciljnih rokov

Zgodnja opozorila in nadaljnja obvestila je treba predložiti brez nepotrebnega odlašanja, najpozneje v zakonsko določenih rokih 24 oziroma 72 ur od seznanitve z zadevno aktivno izrabljeno ranljivostjo ali resnim incidentom. Rok 72 ur teče od seznanitve, ne od oddaje zgodnjega opozorila. CRA, člen 14(2) in (4)

Določite osebo za beleženje seznanitve in spremljanje rokov. Ločite med trenutkom prejema informacije, tem, kar je informacija izkazovala, in trenutkom, ko se je proizvajalec seznanil z dogodkom, o katerem mora poročati. Interna odobritev ali poznejša potrditev vodstva tega trenutka ne moreta prestaviti. Če dokazi izkažejo zgodnejšo seznanitev, popravite časovnico in izračune rokov ter pojasnite razlog.

Pri nerešenem primeru poleg načrtovane ponovne presoje zahtevajte takojšnjo predajo pristojnim osebam, kadar novi dokazi lahko izkažejo obveznost poročanja. Oznaka »čaka na pravni pregled« ne sme postati razlog za odložitev že obveznega obvestila.

Zakonske roke in interne ciljne roke za oddajo vodite v ločenih poljih. Člen 14 določa roke za končna poročila v dnevih in mesecih. Člen 3 Uredbe 1182/71 razlikuje med roki, izraženimi v urah, ter roki, izraženimi v dnevih ali mesecih, in ureja njihov začetek, iztek ter upoštevanje dela prostih dni. Natančen zakonski rok za končno poročilo zato zahteva dokumentiran izračun po veljavnih pravilih; sam člen 14 ne določa izteka ob isti uri 14 dni ali en mesec pozneje. Uredba 1182/71, člen 3

Ob seznanitvi odločite tudi o obveščanju uporabnikov

Člen 14(8) proizvajalcu nalaga, da po seznanitvi z aktivno izrabljeno ranljivostjo ali resnim incidentom obvesti prizadete uporabnike in, kadar je ustrezno, vse uporabnike. Obvestilo mora zajemati ranljivost ali incident ter po potrebi zmanjšanje tveganja in popravne ukrepe, ki jih lahko sprejmejo uporabniki. Kadar je ustrezno, mora biti v strukturiranem in strojno berljivem formatu, ki omogoča preprosto avtomatsko obdelavo. Obveznost je vezana na seznanitev; ne začne se šele z razpoložljivostjo začasne rešitve. CRA, člen 14(8)

Zahtevajte odločitev o obveščanju ob seznanitvi: kdo potrebuje obvestilo, ali je smiselno obvestiti širši krog uporabnikov, po katerih kanalih jih boste dosegli, kdo bo obvestilo poslal in kdaj. Zabeležite znana dejstva, negotovosti in morebitne ukrepe, ki jih uporabniki že lahko sprejmejo. Če preverjen ukrep še ni na voljo, to povejte in določite naslednje obvestilo. Postopek obveščanja uporabnikov vodite ločeno od poročanja organom.

Kot dokazila zahtevajte začetno obvestilo za vajo, simulirani zapis o pošiljanju in poznejša obvestila. Zapis naj vsebuje različico obvestila, predvidene prejemnike, kanale, čas pošiljanja in morebitne težave z dostavo, ki zahtevajo nadaljnje ukrepanje. Presodite čas od seznanitve do obveščanja in razloge za morebitno odlašanje; samo imenovanje odgovorne osebe ne zadostuje.

Izmišljen primer zapisa odločanja

Naslednji primer je izmišljen in namenjen namizni vaji. Vsi datumi so v letu 2026, vsi časi pa so navedeni v UTC. Oddaje, pošiljanje in objave so simulirani zunaj produkcijskega okolja; dejanski uporabniki ne prejmejo obvestil za vajo.

Scenarij obravnava komercialno omrežno napravo različice 4.2, ki se prodaja v Sloveniji in Avstriji. Upravljavski API je del programske opreme naprave. Za potrebe vaje velja, da izdelek spada na področje uporabe člena 2 in zanj ne velja nobena izključitev.

Za spremljanje vaje določite interna ciljna roka za oddajo: 22. september ob 10.10 za zgodnji opozorili in 24. september ob 10.10 za 72-urni obvestili, šteto neposredno od zabeležene seznanitve. Simulirane oddaje so izvedene prej. Ta ciljna roka ne dovoljujeta nepotrebnega odlašanja.

Zakonski rok za končno poročilo o ranljivosti je najpozneje 14 dni po tem, ko je na voljo popravni ali blažilni ukrep. Zakonski rok za končno poročilo o incidentu je v enem mesecu po predložitvi obvestila o incidentu iz člena 14(4)(b). Kot interna ciljna roka vaje z varnostno rezervo določite 6. oktober ob 15.00 za poročilo o ranljivosti in 23. oktober ob 09.00 za poročilo o incidentu. Ti uri nista predstavljeni kot natančen iztek zakonskih rokov. Izvajalec naj ločeno dokumentira izračun po veljavnih pravnih pravilih, vključno z ustreznim časovnim pasom in koledarskimi pravili. CRA, člen 14(2)(c) in (4)(c), Uredba 1182/71, člen 3

Nato scenarij spremenite: odstranite dokaze o obhodu avtentikacije in uvedite primer zlorabljenega podpisnega ključa, s katerim je bila razširjena zlonamerna posodobitev. Ekipa naj neodvisno presodi merila za resen incident, tudi če izrabljena ranljivost izdelka ni bila ugotovljena. Na podlagi spremenjenih dejstev ponovite tudi odločanje o obveščanju uporabnikov.

Zahtevajte vse faze poročanja

Preglednica povzema člen 14. Pogoji, kot sta »če je na voljo« in »kadar je ustrezno«, morajo biti v zapisih pravilno upoštevani. Predlagane odgovorne osebe pomenijo notranjo razdelitev nalog; odgovornost ostaja pri proizvajalcu.

Skupina CSIRT, imenovana za koordinatorja, lahko po členu 14(6) zahteva tudi vmesno poročilo. Poleg zapisov o poročanju organom vodite ločeno dokumentacijo o obveščanju uporabnikov, ki jo zahteva vaja. CRA, člen 14

Pravne zahteve iz preglednice povežite z aktualnimi polji platforme s pomočjo slovarja SRP, dostopnega na strani agencije ENISA za platformo. Za vsako vrsto obvestila in fazo zahtevajte pregled posameznih polj z viri dokazov in izrecno označenimi neznankami. ENISA SRP: navodila in podporna gradiva

Registracijo in predajo nalog preverite po aktualnih navodilih

Vnaprej pripravite osebne račune EU Login z večfaktorsko avtentikacijo (MFA) in razdelite naloge poročanja. ENISA svetuje začetek registracije v SRP, ko je treba oddati obvestilo; registracija pred incidentom zato ne bi smela biti merilo za prevzem presoje. Za povabilo dodatnemu predstavniku mora biti povezava primarnega predstavnika s proizvajalcem potrjena. ENISA, pogosto vprašanje 9

Čakanje na potrditev povezave med predstavnikom in proizvajalcem ne preprečuje začetne oddaje. Osnutki so vidni samo avtorju. Po navodilih, posodobljenih 12. septembra 2026, zaprtih obvestil in obvestil z oddanim končnim poročilom ni več mogoče urejati. ENISA: navodila za oddajo in posodabljanje obvestil

Vaja naj zajema prvo oddajo, ko nadomestna oseba še nima dostopa, in poznejšo predajo nalog. Ekipa naj po aktualnih navodilih pojasni registracijo, povabilo in obnovitev dostopa.

Zahtevajte, da nadomestna oseba iz nadzorovano shranjene interne dokumentacije ponovno sestavi nedokončano obvestilo. Zabeležite, kateri koraki so odvisni od pravic na platformi ali pomoči skupine CSIRT. Če se napaka odkrije po zaklepu urejanja, naj postopek določa pridobitev navodil od pristojne skupine CSIRT ali podpore SRP.

Uporabite simulacijo zunaj platforme ali neprodukcijsko okolje, če je na voljo in dovoljeno za usposabljanje. Izmišljenih obvestil ne oddajajte v produkcijsko okolje. Ločite med preverjeno pripravljenostjo računov, izvedbo simuliranega postopka in dokazili o dejanski produkcijski oddaji.

Zahtevajte utemeljeno izbiro skupine CSIRT

Po členu 14(7) se glavni sedež proizvajalca določi glede na kraj, kjer se večinoma sprejemajo odločitve o kibernetski varnosti njegovih izdelkov. To ni samodejno registrirani sedež družbe. Če te države članice ni mogoče določiti, se uporabi država članica, v kateri ima proizvajalec poslovno enoto z največ zaposlenimi v EU.

Če proizvajalec nima glavnega sedeža v EU, na podlagi razpoložljivih informacij uporabite zakonski vrstni red: država članica, v kateri ima sedež pooblaščeni zastopnik, ki deluje za največje število njegovih izdelkov; če to ni uporabljivo, država sedeža uvoznika, ki daje na trg največje število izdelkov; nato država sedeža distributerja, ki omogoča dostopnost največjega števila izdelkov; nazadnje država članica z največ uporabniki. CRA, člen 14(7)

Proizvajalec mora izbrati pravilno skupino CSIRT, imenovano za koordinatorja. Napačna izbira lahko povzroči razveljavitev obvestila in zahtevo po ponovni oddaji. ENISA, pogosto vprašanje 18

Zahtevajte kratko pisno utemeljitev, ki opredeli proizvajalca, pomembne poslovne enote, dokaze o kraju odločanja, morebitno uporabljeno nadomestno merilo in izbrano skupino CSIRT. V izmišljenem primeru prodaja v Sloveniji in Avstriji sama po sebi ne bi določala pravilnega prejemnika.

Merila za prevzem vključite v pogodbo

Presojo prevzemite šele, ko dokumentacija izkazuje vse naslednje:

• Opredeljene meje izdelka in ločena sklepa o obeh razlogih za poročanje, vsak s povezavo do dokazov.
• Časovnico seznanitve in dokumentirane izračune zakonskih rokov, ločeno označene interne ciljne roke, brez prestavljanja zaradi interne odobritve ter s konkretnimi časi ponovne presoje nerešenih vprašanj.
• Izpolnjene simulirane zapise za obe vrsti poročanja do končnih poročil, s preverjeno popolnostjo posameznih polj in jasno navedenimi negotovostmi.
• Odločitev o obveščanju uporabnikov, zabeleženo ob seznanitvi, ki opredeli prizadete uporabnike, utemeljitev morebitnega širšega kroga prejemnikov, kanale, čas obveščanja, znana dejstva, negotovosti in razpoložljive ukrepe za uporabnike.
• Začetno obvestilo uporabnikom za vajo in simulirani zapis o pošiljanju, ki izkazujeta pravočasno obveščanje po seznanitvi, ter nadaljnja obvestila in zapise o pošiljanju ob pomembnih spremembah, vključno z razpoložljivostjo začasne rešitve. Vsako odlašanje ali težava z dostavo ima pojasnilo, odgovorno osebo in nadaljnji ukrep.
• Pisno utemeljitev izbire skupine CSIRT in načrt registracije, skladen z aktualnimi navodili.
• Predajo nadomestni osebi na podlagi interne dokumentacije, brez predpostavke o dostopu do tujega zasebnega osnutka ali deljenja prijavnih podatkov.
• Zapisano odločitev o blažilnem ukrepu, odgovorno osebo za popravek, odgovorno osebo za obveščanje uporabnikov in datume nadaljnjih preverjanj.

Izvajalec naj vsako merilo označi kot dokazano, delno dokazano ali nedokazano ter navede podporno dokazilo. Simulirani zapisi o oddaji in pošiljanju izkazujejo samo uspešnost pri vaji. Če so na voljo legitimni produkcijski zapisi, njihove časovne oznake in stanja presodite posebej.

Tehnično preverjanje povežite z odpravo pomanjkljivosti. Obstoječe presoje spletne varnosti — v angleščini in varnosti API-jev — v angleščini lahko podprejo oceno vpliva na izdelek in izbiro popravnih ukrepov. Vaja poročanja mora še vedno izkazati pravilno razvrstitev, spoštovanje rokov, obveščanje uporabnikov in predajo nalog.

Za vsako neizpolnjeno merilo določite izboljšavo, odgovorno osebo, rok izvedbe in ponovni preizkus. Ustrezne dele vaje ponovite po pomembnih spremembah izdelkov, osebja ali postopkov platforme. Namizna vaja izkazuje uspešnost v danem scenariju; ne more potrditi pravilnosti vseh prihodnjih odločitev o poročanju ali zagotoviti, da bo pristojni organ obvestilo štel za popolno.