CRA ziņošana: 24 stundas, 72 stundas un kā nepazaudēt prasības jēgu

• No 2026. gada 11. septembra CRA 14. panta obligātā ziņošana attiecas uz ražotājiem; lielākā daļa pārējo CRA prasību sāk piemēroties 2027. gada 11. decembrī.3
• CRA 14. pants paredz divus atšķirīgus obligātās ziņošanas objektus: aktīvi izmantotu ievainojamību un nopietnu incidentu, kas ietekmē produkta ar digitāliem elementiem drošību.4
• 24 un 72 stundu termiņi sākas no brīža, kad ražotājs ir uzzinājis par attiecīgo notikumu; Komisijas nesaistošā praktiskā vadlīnija šo brīdi sasaista ar sākotnējo novērtējumu un saprātīgu pārliecības pakāpi, nevis ar pirmā signāla saņemšanas sekundi vai valdes lēmumu.5
• Aktīvi izmantotas ievainojamības gala ziņojumam un nopietna incidenta gala ziņojumam ir atšķirīgi termiņa sākumpunkti.4
• Lietotāju informēšana saskaņā ar 14. panta 8. punktu ir atsevišķs pienākums. CRA nenosaka, ka lietotāji obligāti jāinformē tieši 72 stundu laikā.4
• Juridiski paziņojums ir adresēts par koordinatoru izraudzītajai CSIRT un ENISA, bet praktiski tas tiek iesniegts vienreiz caur SRP, izmantojot attiecīgās CSIRT elektronisko galapunktu.4
• CRA 15. pants paredz brīvprātīgu ziņošanu, taču uz 2026. gada 25. septembri ENISA norāda, ka pašreizējā SRP versija atbalsta obligātos ražotāju paziņojumus; 15. panta brīvprātīgā funkcionalitāte paredzēta vēlākam platformas posmam.2
• Atvērtā pirmkoda programmatūras pārziņu jeb open-source software stewards 24. panta 3. punkta ziņošanas pienākumi sāk piemēroties 2027. gada 11. decembrī, nevis 2026. gada 11. septembrī.13

Šis ir pirmais saīsinājums, kas jālieto uzmanīgi.

Pareizi ir teikt, ka no 2026. gada 11. septembra sāk piemērot CRA 14. pantā noteiktos ražotāju ziņošanas pienākumus. Nav pareizi šo datumu aprakstīt kā brīdi, kad “stājas spēkā viss CRA”. Regula stājās spēkā jau 2024. gada decembrī, savukārt lielākā daļa tās prasību sāk piemēroties 2027. gada 11. decembrī. Ziņošana ir viens no agrāk piemērojamajiem blokiem.3

Šai atšķirībai ir praktiska nozīme. Iekšējā CRA readiness dokumentā var atrasties gan prasības, kas jau ir piemērojamas, gan kontroles, kuras uzņēmums ievieš priekšlaicīgi, gatavojoties 2027. gadam. Ja abas grupas tiek saliktas vienā tabulā bez piemērošanas datumiem, “recommended now” viegli pārvēršas par “legally required now”.

Tas pats attiecas uz open source. Ražotāja 14. panta ziņošana sākās 2026. gada 11. septembrī. Savukārt atvērtā pirmkoda programmatūras pārziņu 24. panta 3. punkta ziņošanas pienākumi, kā pašlaik skaidri norāda gan Komisija, gan ENISA, sāk piemēroties 2027. gada 11. decembrī.13

Tāpēc pirmais jautājums jebkurā playbookā nav “24 vai 72 stundas?”. Pirmais jautājums ir: kurai juridiskajai personai un kurā lomā šis pienākums vispār ir piemērojams?

Ikdienas drošības darbā vārds “vulnerability” aptver ļoti plašu situāciju loku: skenera atradumu, CVE, pētnieka ziņojumu, PoC, konfigurācijas kļūdu, ievainojamu trešās puses komponenti vai jau notikušu izmantošanu uzbrukumā. CRA 14. pants nepadara tos visus par vienādu regulatīvu notikumu.

Regula atdala divus ziņošanas objektus.

CRA definē “aktīvi izmantotu ievainojamību” diezgan precīzi: vajadzīgi uzticami pierādījumi par ļaunprātīgu izmantošanu bez sistēmas īpašnieka atļaujas.6 Tāpēc publisks proof-of-concept, drošības pētnieka reproducēts defekts vai iekšējā penetrācijas testa atradums var prasīt steidzamu tehnisku rīcību, bet tie automātiski neatbilst 14. panta 1. punkta ziņošanas nosacījumam.

Šī robeža ir saistīta arī ar labticīgas kiberdrošības izpētes jautājumu. Regulas apsvērumi tieši nošķir labticīgu testēšanu un izpēti no ļaunprātīgas ekspluatācijas. Tas ir vēl viens iemesls, kāpēc organizācijas incidenta triāžā nedrīkst lietot vienu bināru lauku “exploited = yes/no”, nezinot, kas, kur un ar kādu atļauju faktiski noticis.4

CRA termiņu sākumpunkts ir brīdis, kad ražotājs ir uzzinājis par aktīvi izmantotu ievainojamību vai nopietnu incidentu. Tieši šeit juridiska prasība sastopas ar incident response realitāti.

Piektdien 17:03 uz security@company.eu var pienākt e-pasts ar loga fragmentu un apgalvojumu, ka produkts tiek aktīvi izmantots uzbrukumos. Šis e-pasts vēl var būt kļūdains, nepilnīgs vai attiekties uz citu konfigurāciju. Taču uzņēmums arī nevar vienkārši pateikt: “mēs vēl izmeklējam”, un ar šo frāzi pārcelt sākumpunktu uz pirmdienu.

Komisijas 2026. gada praktiskā vadlīnija šo starpstāvokli apraksta noderīgi: pēc aizdomīga notikuma vai trešās personas ziņojuma ražotājam nekavējoties jāveic sākotnējais novērtējums. Par “uzzināšanas” brīdi tas tiek uzskatīts tad, kad pēc šā novērtējuma ir saprātīga pārliecības pakāpe, ka ievainojamība produktā tiek aktīvi izmantota vai ka ir noticis nopietns incidents, kas kompromitējis produkta drošību.5

Praksē es glabātu vismaz trīs atsevišķus laika zīmogus:

1. signāls saņemts — kad informācija pirmoreiz nonāca organizācijas rīcībā;
2. sākotnējais novērtējums — ko pārbaudījām, ar kādiem pierādījumiem un kādas versijas/konfigurācijas attiecās;
3. uzzināšanas slieksnis sasniegts — kad pierādījumi bija pietiekami, lai konkrēto 14. panta filiāli klasificētu kā piemērojamu.

Regula neprasa tieši šādu trīs lauku datu modeli. Tā ir praktiska kontrole, kas palīdz vēlāk parādīt, kāpēc termiņa skaitīšana sākta konkrētajā laikā, ne agrāk un ne vēlāk.

Bīstamākais iekšējais noteikums būtu uzzināšanas brīdi definēt kā brīdi, kad par notikumu ir informēts CISO, jurists vai valde. Organizācijas apstiprināšanas ķēde drīkst palīdzēt pieņemt lēmumu; tā nedrīkst mākslīgi pārbīdīt juridisko faktu.

Abām ziņošanas filiālēm pirmie divi termiņi izskatās līdzīgi, bet gala posms atšķiras.

Avots ir pats CRA 14. pants.4

Šeit tipiska kļūda ir uzrakstīt vienu rindu: “Final report within 14 days.” Tas ir pareizi tikai vienai filiālei, turklāt arī tur 14 dienas nesākas no uzzināšanas brīža vai 72 stundu paziņojuma. Pulkstenis sākas, kad kļūst pieejams korektīvs vai risku mazinošs pasākums.

Tikpat neprecīza būtu universāla formula “final report = 30 days”. Nopietna incidenta gadījumā regula lieto vienu mēnesi pēc 72 stundu paziņojuma, nevis 30 dienas pēc incidenta atklāšanas.

Šādi šķietami sīki labojumi incidenta procesā ir būtiski, jo termiņš ir ne tikai skaitlis. Tam vienmēr ir sākumpunkts, objekts un noteikta informācijas kopa.

CRA 14. panta 2. punkta b) apakšpunkts un 4. punkta b) apakšpunkts attiecas uz 72 stundu regulatīvo paziņojumu. Tajā cita starpā iekļauj pieejamo informāciju par korektīvajiem vai risku mazinošajiem pasākumiem un to, ko var darīt lietotāji.4

Tas nav tas pats, kas tiešais pienākums informēt lietotājus.

Lietotāju informēšana atrodas 14. panta 8. punktā. Pēc tam, kad ražotājs ir uzzinājis par attiecīgo notikumu, tam ir jāinformē skartie lietotāji un, attiecīgā gadījumā, visi lietotāji par ievainojamību vai incidentu un par nepieciešamajiem riska mazināšanas vai korektīvajiem pasākumiem. Regula prasa to darīt savlaicīgi, bet 14. panta 8. punkts pats nenosaka “72 stundu klientu paziņošanas termiņu”.4

Atšķirība nav akadēmiska. Ja playbookā rakstām “72h: informēt klientus”, komanda var secināt divas nepareizas lietas vienlaikus: ka klientu informēšana drīkst vienmēr gaidīt līdz 72. stundai un ka 72 stundu regulatora ziņojuma galvenais adresāts ir klients.

Pareizāk ir vadīt abus darbus paralēli: regulatora paziņojuma filiāli un lietotāju aizsardzības/komunikācijas filiāli. Tiem ir saistīta informācija, bet atšķirīgs juridiskais uzdevums.

Arī šeit jānošķir juridiskā adresācija no tehniskā procesa.

CRA 14. panta 1. un 3. punkts saka, ka ražotājs paziņo attiecīgajai par koordinatoru izraudzītajai CSIRT un ENISA. Savukārt 14. panta 7. punkts nosaka praktisko mehānismu: paziņojumu iesniedz vienotajā ziņošanas platformā, izmantojot attiecīgās koordinatora CSIRT elektronisko galapunktu. Parastajā plūsmā informācija vienlaikus ir pieejama ENISA; regula atsevišķi paredz ierobežotus izņēmuma mehānismus sensitīvas informācijas tālākai izplatīšanai.4

Tātad iekšējā procedūrā nav jākonstruē divi neatkarīgi “send report” procesi tikai tāpēc, ka normā ir divi saņēmēji.

Uz 2026. gada 25. septembri ENISA SRP ir darbībā. ENISA publicē atsevišķas instrukcijas par Assigned Representative reģistrāciju, paziņojumu iesniegšanu un atjaunināšanu, kā arī uztur aktuālu FAQ.27

Latvijā CERT.LV 11. septembrī publicēja praktisku norādi, ka Latvijai paredzēto SRP paziņojumu apstrādi veic CERT.LV. Ja tehniskas problēmas dēļ SRP nav pieejama, CERT.LV norāda izmantot cert@cert.lv un pēc platformas darbības atjaunošanas ziņojumu reģistrēt arī SRP.8

Šī Latvijas detaļa ir operacionāli svarīga, bet tā nemaina Eiropas pamatmodeli: SRP ir CRA 14. panta parastais iesniegšanas ceļš; CERT.LV e-pasts ir nepārtrauktības risinājums platformas tehniskas nepieejamības gadījumam.

CRA 15. pants ļauj ražotājiem un citām fiziskām vai juridiskām personām brīvprātīgi ziņot par ievainojamībām, kiberdraudiem, incidentiem un gandrīz notikušiem incidentiem par koordinatoru izraudzītajai CSIRT vai ENISA.4

Tas ir juridiskais slānis.

Operacionālais slānis 2026. gada septembrī vēl nav pilnīgi identisks. ENISA aktuālajā SRP FAQ norāda, ka sākotnējā platformas versija atbalsta obligātos ražotāju paziņojumus saskaņā ar 14. pantu, bet 15. panta brīvprātīgā ziņošana tiks ieviesta vēlāk. Personām, kas nav ražotāji un vēlas ziņot par ievainojamību vai drošības problēmu, ENISA šobrīd iesaka sazināties ar attiecīgo nacionālo CSIRT.2

Šis ir labs piemērs, kāpēc juridiskais teksts, Komisijas skaidrojums un platformas dokumentācija jālasa kopā. No normas “may notify voluntarily” nevar automātiski secināt, ka konkrētā SRP poga jau šodien ir pieejama visām personu kategorijām.

Viens no praktiski bīstamākajiem CRA īsinājumiem 2026. gada vasarā bija teikums, ka 11. septembrī vienādi sākas ražotāju un atvērtā pirmkoda programmatūras pārziņu ziņošana.

Tā nav pašreizējā Komisijas un ENISA interpretācija.

Ražotājiem 14. pants ir piemērojams no 2026. gada 11. septembra. Atvērtā pirmkoda programmatūras pārziņu pienākums izriet no 24. panta 3. punkta, un Komisijas un ENISA aktuālie materiāli tā piemērošanas sākumu nosaka 2027. gada 11. decembrī.13

Tas nenozīmē, ka pārziņa organizācijai līdz tam “nekas nav jādara”. Praktiska sagatavotība, drošības kontaktpunkts, ievainojamību apstrāde un sadarbība ar ražotājiem, kuri izmanto attiecīgo programmatūru, ir vērtīgi jau tagad. Taču “ieteicams sagatavoties” un “juridiski piemērojams no šodienas” nav viens apgalvojums.

Šī atšķirība pašlaik redzama arī OpenSSF publicētajos materiālos: ražotāju ceļvedis 11. septembri sasaista ar ražotājiem, bet pārziņu ceļvedis skaidri norāda 2027. gada 11. decembri.910

2026. gada 8.–9. septembrī, pārskatot OpenSSF ražotāju/PSIRT un atvērtā pirmkoda programmatūras pārziņu CRA materiālus, es pārbaudīju saīsinātos formulējumus pret Regulu (ES) 2024/2847, Komisijas aktuālajiem ieviešanas materiāliem un ENISA SRP dokumentāciju.

Svarīgākais šajā pārbaudē nebija kļūdu skaits. Daudz vērtīgāk bija redzēt, kur tieši mainās prasības jēga, kad garu normu saspiež vienā kontrolsaraksta rindā.

Atkārtojās vairāki modeļi:

• steward 2027. gada piemērošanas datums tika sajaukts ar agrāko ražotāju 14. panta datumu;
• 72 stundu regulatora paziņojums tika formulēts tā, it kā tas būtu 72 stundu termiņš tiešai klientu informēšanai;
• aktīvi izmantota ievainojamība un nopietns incidents tika sapludināti vienā “severe vulnerability” kategorijā;
• abu gala ziņojumu atšķirīgie termiņa sākumpunkti tika vienkāršoti līdz vienam skaitlim;
• 15. panta brīvprātīgā ziņošana checklistes struktūrā varēja izskatīties pēc obligāta steward pienākuma;
• formulējums “CSIRT + ENISA” varēja radīt iespaidu par divām atsevišķām iesniegšanas plūsmām.

OpenSSF EU Policy Advisor atbildēja uz komentāriem punktu pa punktam un aicināja iesniegt konkrētus labojumu formulējumus. Pašreizējie publiskie OpenSSF ražotāju un pārziņu ceļveži skaidri nošķir vairākus no šiem elementiem, tostarp pārziņu piemērošanas datumu, abas gala ziņojuma filiāles un 15. panta brīvprātīgo raksturu.910

No šī es neizdaru secinājumu, ka vienkāršot CRA nevajag. Tieši pretēji: incidenta laikā neviens negrib lasīt vairākus desmitus regulas lappušu. Bet saīsināšanai ir vajadzīga kvalitātes kontrole.

Pirms normu pārvērstu vienā teikumā, es pārbaudītu septiņas lietas.

Ja pēc saīsināšanas kāds no šiem laukiem ir mainījies, playbooka rinda vairs nav tikai īsāka. Tā saka kaut ko citu.

Šo pašu principu var izmantot arī ārpus CRA. Tas noder visur, kur regulējumu pārvērš automatizētā darbplūsmā, SOP, Jira formā, SIEM rīcības plānā vai pārvaldības kontrolē.

Vienkāršs tests ir labāks par vēl vienu politiku.

Piektdien pulksten 17:00 produkta drošības komanda saņem ticamu informāciju, ka uzņēmuma programmatūras ievainojamība, iespējams, tiek aktīvi izmantota pret klientiem vairākās ES valstīs. Nav pabeigta atribūcija. Nav drošības labojuma. Nav galīgā ietekmes novērtējuma. Daļa produkta komandas jau ir prom.

Es sagaidītu, ka organizācija bez improvizācijas spēj noskaidrot:

1. kurš produkts un kuras versijas ir skartas;
2. kura juridiskā persona CRA izpratnē ir ražotājs;
3. kas ir sākotnējais pierādījuma avots un vai oriģināls ir saglabāts;
4. kas veic sākotnējo tehnisko novērtējumu;
5. kurā brīdī ir sasniegta saprātīga pārliecības pakāpe par aktīvi izmantotu ievainojamību vai nopietnu incidentu;
6. kas fiksē uzzināšanas brīdi un tā pamatojumu;
7. kam ir pieeja SRP un rezerves iespēja, ja primārā persona nav pieejama;
8. ko var godīgi iesniegt 24 stundu agrīnajā brīdinājumā, nepārvēršot pieņēmumus par faktiem;
9. kā paralēli turpinās izmeklēšana, novēršana un lietotāju aizsardzība;
10. kas kontrolē 72 stundu un pareizo gala ziņojuma pulksteni.

Ja vairākas atbildes sākas ar “incidenta laikā noskaidrosim”, uzņēmumam vēl nav CRA ziņošanas procesa. Tam ir prasības apraksts.

CRA nav noteicis konkrētu mapju struktūru, ar kuru jāvada 14. panta notikums. Tomēr, ja organizācijai vēlāk jāparāda, kas bija zināms un kāpēc tika pieņemts konkrēts lēmums, izkaisīti Slack ziņojumi, e-pasti un manuāli pārrakstīti laiki ir slikts pamats.

Praktiski es uzturētu vienu kanonisku incidenta/paziņošanas pierādījumu kopu, kurā saglabājas:

• sākotnējais signāls un tā avots;
• oriģinālie tehniskie pierādījumi;
• skartā produkta un versiju kartējums;
• trešo pušu komponentes, ja tās ir nozīmīgas;
• signāla saņemšanas, novērtējuma un uzzināšanas laiki;
• klasifikācijas pamatojums un vēlākas klasifikācijas izmaiņas;
• 24 stundu iesniegums un tā versija;
• izmeklēšanas rezultāti;
• 72 stundu iesniegums;
• lietotāju komunikācijas un mazināšanas pasākumi;
• drošības labojums, pagaidu risinājums vai cits korektīvais pasākums un laiks, kad tas kļuva pieejams;
• gala ziņojums;
• labojumi vai papildinājumi, kas radušies vēlāk.

Mērķis nav uzkrāt dokumentus dokumentu dēļ. Mērķis ir, lai cits kompetents cilvēks vēlāk varētu rekonstruēt: ko organizācija zināja, kad tā to zināja, ko secināja un kāpēc rīkojās tieši tā.

Tā pati domāšana ir pamatā arī pamatotai ievainojamību prioritizācijai: signāla nozīmi nevajag izšķīdināt vienā vērtējumā vai statusā, ja vēlāk jāspēj saprast lēmuma pamats.

CRA 14. panta ziņošana pieskaras citiem procesiem, bet tā nav to aizstājējs.

Ievainojamību pārvaldība atbild uz jautājumu, kā ievainojamību identificē, novērtē, prioritizē, labo un pārtestē.

CVD organizē ārēji vai iekšēji atklātas ievainojamības saņemšanu un koordinētu apstrādi. CVD ziņojums var kļūt par signālu CRA izvērtējumam, bet CVD un Article 14 nav viens process.

Incidentu vadība vada tehnisko izmeklēšanu, ierobežošanu, atjaunošanu un pierādījumu saglabāšanu. CRA ziņošana izmanto šā procesa informāciju, bet regulatora termiņš negaida pilnīgu forensisko analīzi.

Lietotāju informēšana aizsargā produkta lietotājus un atrodas atsevišķā 14. panta 8. punkta pienākumā.

Citi regulējumi un līgumi var radīt paralēlus paziņošanas pienākumus ar citiem adresātiem, sliekšņiem un pulksteņiem. CRA iesniegums automātiski neaizstāj GDPR, NIS2, DORA, nozares regulatora vai līgumisku paziņošanu, ja konkrētajā situācijā tie ir piemērojami.

Laba incidenta arhitektūra šos procesus sasaista ar kopīgu pierādījumu bāzi, nevis izliekas, ka tie ir viens un tas pats.

Pirms es teiktu, ka uzņēmums ir gatavs CRA 14. pantam, es gribētu saņemt skaidru atbildi uz šiem jautājumiem:

• Vai katram potenciāli CRA tvērumā esošam produktam ir zināma juridiskā persona, kas ir ražotājs?
• Vai komanda prot atšķirt ievainojamību, exploitable vulnerability, aktīvi izmantotu ievainojamību un nopietnu incidentu?
• Vai ir definēts, kurš veic sākotnējo novērtējumu ārpus darba laika?
• Vai uzzināšanas brīdis un tā pamatojums tiek fiksēts atsevišķi no signāla saņemšanas laika?
• Vai ir aktīvi SRP Assigned Representatives un rezerves cilvēki?
• Vai 24h un 72h formu sagatavošana ir izmēģināta ar nepilnīgu, nevis ideālu informāciju?
• Vai lietotāju informēšana ir atsevišķa darba plūsma, nevis kļūdains 72h kontrolsaraksta punkts?
• Vai sistēma zina, kuru no abiem gala ziņojuma pulksteņiem sākt?
• Vai 15. panta brīvprātīgā ziņošana nav sajaukta ar 14. panta obligāto procesu?
• Vai atvērtā pirmkoda programmatūras pārziņa loma ir kartēta atsevišķi no ražotāja lomas?

Ja uz šiem jautājumiem ir atbildes, 24 stundu termiņš kļūst par operacionālu problēmu, kuru var vadīt. Ja nav, pati lielākā problēma nav termiņa īsums. Tā ir nenoteiktība par to, kas vispār jādara, kurā brīdī un kāpēc.