Cyber Resilience Act: digitoodete CRA-valmidus

Cyber Resilience Acti (CRA) töö ei ole lõpetatud siis, kui nõue lisatakse arvutustabelisse. Tootetiim peab teadma, millisele tootele nõue kehtib, kes vastutab töö eest, millal on tähtaeg, miks otsus tehti ja kust leiab tõendid.

CRA teavitamiskohustused kehtivad alates 11. septembrist 2026. Määruse põhiosa kohaldatakse alates 11. detsembrist 2027. Osa töökorraldusest peab seega toimima juba praegu, ülejäänu aga tuleb luua piisavalt vara, et tehnilist dokumentatsiooni ei oleks vaja lõpus uuesti taastada.

CRA peamised kuupäevad

Kuupäev	Mis muutub
11. september 2026	Kohaldatakse artikli 14 teavitamiskohustusi
11. detsember 2027	Kohaldatakse CRA peamisi kohustusi

Teatamisele kuuluvate sündmuste puhul algab tähtaja arvestus tootja teadlikuks saamisest. Komisjon kirjeldab varajast hoiatust 24 tunni jooksul ja täielikku teadet 72 tunni jooksul. Lõpparuande tähtaeg erineb aktiivselt ära kasutatud haavatavuse ja tõsise intsidendi puhul.

Vaata CRA 24/72 tunni teavitamise praktilist töövoogu

CRA puudutab toodet, mitte abstraktset kogu ettevõtte vastavusskoori

Esimene kasulik küsimus on: millist konkreetset digitaalsete elementidega toodet me hindame?

Määrus hõlmab tarkvara- ja riistvaratooteid ning määratletud tingimustel nende kaugandmetöötluslahendusi. Samuti on oluline organisatsiooni roll: tootja, volitatud esindaja, importija, turustaja või olulise muudatuse tegija.

Alusta ühe toote kirjega:

toote nimi ja kordumatu identifikaator;
versioon või väljaannete perekond;
tootja ja kaubamärk, mille all toode kättesaadavaks tehakse;
kuidas see ELi turul kättesaadavaks tehakse;
sihtotstarve ja põhifunktsioonid;
komponendid ja sõltuvused;
toote funktsioonide jaoks vajalikud kaugteenused;
tugiperiood;
toote turvalisuse, haavatavuste ja väljaannete eest vastutavad inimesed.

Vaata, kuidas hinnata CRA kohaldumist tootele

Seitse valdkonda, mis tuleb omavahel siduda

1. Kohaldamisala

Määra, kas toode ja organisatsiooni roll kuuluvad CRA kohaldamisalasse. Nimetus „SaaS“, „IoT“ või „tarkvara“ ei ole kohaldumise hinnang.

2. Toote risk

CRA nõuded on seotud toote küberturvariski hindamisega. See hinnang peaks jääma seotuks toote versiooniga ja olema üle vaadatud, kui arhitektuur, sihtotstarve või risk muutub.

3. Lõimitud ja vaikimisi turvalisus

Nõue peab muutuma arendustööks: projekteerimisotsus, tegevus, vastutaja, test, ülevaatus ja tõendid.

Ava CRA lõimitud turvalisuse juhend

4. Haavatavused ja SBOM

CRA nõuab tootjatelt haavatavuste ja tootekomponentide tuvastamist ning dokumenteerimist, sealhulgas tarkvara komponentide loendi ehk SBOM-i koostamist levinud masinloetavas vormingus, mis hõlmab vähemalt tipptaseme sõltuvusi.

Vaata, miks SBOM on protsessi sisend, mitte lõpptulemus

5. Teavitamine

CRA ühtne teavitusplatvorm (SRP) töötab alates 11. septembrist 2026. Praktikas vajab tootja enamat kui juurdepääsu portaalile: selge T0, eskalatsioonikriteeriumid, vastutaja, asendamise korraldus ja teate esitamiseks vajalik teave.

6. Tehniline dokumentatsioon

Tehniline dokumentatsioon ei tohiks olla eraldiseisvate failide arhiiv. See peab tegema jälgitavaks toote, versiooni, arhitektuuri, riskihinnangu, haavatavuste käsitlemise, testid, otsused ja tugiperioodi aluse.

Vaata CRA tehnilise dokumentatsiooni praktilist struktuuri

7. Tugiperiood

Tootja määrab tugiperioodi eeldatava kasutuse ja CRA-s sätestatud kriteeriumide põhjal. Üldreeglina on see vähemalt viis aastat, välja arvatud juhul, kui toodet eeldatakse kasutatavat lühemat aega.

Vaata, kuidas tugiperioodi dokumenteerida

Väikese meeskonna töökorraldus

ENISA 2026. aasta VKE-de CRA uuring näitab lõhet teadlikkuse ja elluviimise vahel. Vabatahtlikus 194 vastusega valimis oli 66% CRA-st teadlik, samas kui 54% teatas vähestest või puuduvatest teadmistest vastavushindamise kohta ja 42% vähestest või puuduvatest teadmistest nõutava dokumentatsiooni kohta. Tehnilise dokumentatsiooni toe valis 73% vastajatest.

Uuringut ei tohiks käsitleda kogu ELi turu esindusliku hinnanguna: tegu on väikese vabatahtliku valimiga. See annab siiski kasuliku signaali, et probleem ei ole pelgalt „teadmine, et CRA on olemas“. Meeskonnad vajavad korratavaid tööprotsesse.

Väike tootetiim vajab kontrollitud tooteandmeid, selgeid vastutajaid ning korratavat ülevaatust. Allpool kirjeldatud tööproovid on meie soovitatud praktiline meetod; need ei esita statistilist väidet kogu ELi ettevõtete kohta.

Kus Pulsar GRC sobitub

Pulsar GRC seob töö, mis on sageli hajutatud dokumentide, arvutustabelite, tööpiletite ja e-kirjade vahel:

nõue → risk → kontrollmeede või tegevus → vastutaja → tähtaeg → dokument või tõend → ülevaatus → otsuste ajalugu.

Pulsar seob auditid, kontrollmeetmed, riskid, dokumendid, tõendid, aruanded, CAPA, tarnijad ja ülesanded. See aitab protsessi juhtida ja tõendada, esitamata tarkvara kliendi eest õigusliku otsuse tegijana.

Pulsar ei sertifitseeri CRA-le vastavust, ei asenda õiguslikku hinnangut ega otsusta iseseisvalt, kas sündmusest tuleb teatada. Kohaldumise otsused, õiguslik liigitamine ja esitamise otsus jäävad vastutavatele inimestele.

Alusta ühest tootest

Ära alusta programmiga „rakendame CRA-d kogu ettevõttes“. Vali üks tegelik toode. Määratle selle kohaldamisala, vastutajad, praegused riskid, haavatavuste töövoog, dokumentatsioon ja tugiperiood. Just siis muutuvad tegutsemist nõudvad lüngad nähtavaks.

Vaata Pulsar GRC-d ühe tegevusliku töövoo näitel

Alusta tooteportfellist, mida saab tegelikult hinnata

CRA rakendamise esimene töönädal võiks lõppeda kontrollitud tootenimekirjaga. See on meie soovitatud töökorraldus, mitte määruse ette kirjutatud projektigraafik. Nimekiri peaks näitama turul olevaid tooteid, toote vastutajaid, tarnemudeleid ja neid küsimusi, millele organisatsioon pole veel vastust leidnud. Kui nimekiri puudub, võib üks meeskond hinnata pilveteenust ning teine paigaldatavat tarkvara ja mõlemad arvata, et nad räägivad samast tootest.

Hüpoteetiline väike tootja müüb võrguandurit ning selle haldusrakendust. Anduril on püsivara, kliendi arvutisse paigaldatav tööriist ja tootja hallatav kaugteenus. Esimese ülesandena ei koostata kõigile ettevõtte töötajatele üldist CRA-koolitust. Toote vastutaja kirjeldab, milline osa teeb millise funktsiooni ja kes iga osa arenduse eest vastutab. Alles siis saab hinnata kohaldumist ning vajalikku tegevuskava.

Jaga töö otsusteks, millel on oma tõendid

Portfelli kirje võiks sisaldada toote tunnust, müügipiirkonda, väljaannete perekonda ning kohaldumise hinnangu versiooni. Eraldi otsus määrab, kes vastutab haavatavuste käsitlemise eest. Teine otsus kinnitab tugiperioodi aluse. Kolmas otsus määrab tehnilise dokumentatsiooni ülevaatuse. Üks üldine märge „CRA projekt käib“ ei näita nende erinevate tööde valmidust ega puudusi.

Määra igale otsusele järgmine kontrollitav tulemus. Kohaldumise hinnangu tulemus on põhjendatud järeldus koos kasutatud allikatega. Teavitamise harjutuse tulemus on tõend, et meeskond suutis tuvastada algaja, leida heakskiitja ja valmistada ette nõutava teabe. Dokumentatsiooni tulemus on õigete tooteversioonidega seotud register. Need tulemused on erinevad ja vajavad erinevaid vastutajaid.

Sea järjekord sõltuvuste järgi

Tootepiir tuleb selgeks teha enne lõpliku dokumentatsioonipaketi koostamist. Haavatavuste teabe vastuvõtt ning teavitamiskohustuse hindamine vajavad aga toimivat korraldust juba praegu, kui artikkel 14 kohaldub. Seetõttu ei tohiks kogu töö oodata, kuni tulevane vastavushindamise projekt on lõpetatud. Erista praeguse reageerimisvõime puudus pikema arendusprogrammi puudusest.

Praktiline tegevuskava saab näidata sõltuvusi. SBOM-i sidumine tooteväljaandega vajab teadaolevat väljaannete registrit. Tugiperioodi põhjendus vajab sõltuvuste hoolduse teavet. Testipakett vajab nõudeid ja riskihinnangut. Kui sõltuvus on teadmata, märgi see küsimus avatud tööna ja määra inimene, kes saab vastuse anda. Tähtaeg ei lahenda puuduva tehnilise teadmise probleemi.

Väike meeskond vajab selgeid rolle

Kolmeliikmeline meeskond ei pea looma seitset osakonda, et töö oleks juhitud. Sama inimene võib vastutada mitme teema eest. Oluline on näha, millises rollis ta otsuse teeb ja kes asendab teda puudumise korral. Näiteks võib tehniline juht hinnata mõju, kuid ettevõtte määratud vastutaja kinnitab välise teate. Kui need rollid ühinevad, salvestatakse see selgelt.

Juurdepääsu olemasolu tuleks kontrollida tegeliku ülesande kaudu. Portaalikonto ei tõenda veel, et inimene oskab sobiva kirje esitada või pääseb töövälisel ajal vajalikule tooteinfole ligi. Harjutus peab hõlmama ka puuduvat põhivastutajat, aegunud kontakti ja ebaselget esialgset teadet. Muidu katsetatakse ainult kõige lihtsamat olukorda ja tegelik nõrk koht jääb alles.

Tõendite kvaliteedi kontroll kogu programmis

Iga tõend vajab allikat, ajakohasust, selget ulatust ja ülevaatajat. Riskihinnang toote eelmise arhitektuuri kohta ei pruugi toetada uut väljaannet. Testiaruanne võib olla tõeline, kuid puudutada teist seadet või konfiguratsiooni. Need erinevused tuleb nähtavaks teha enne aruande koondamist. Suur failide arv ei korva vale toote või versiooni seost.

Kasuta avatud küsimuste registrit. Küsimus, millele vastust pole, ei peaks kaduma seetõttu, et üldine aruandevärv on roheline. Määra küsimuse võimalik mõju, ajutine korraldus ja otsuse vajadus. Organisatsiooni juhtkond saab nii otsustada, milline puudus vajab kohe ressursse ja milline võib jääda põhjendatud ajakava järgi lahendamiseks. Ära väljenda ajutist riskiaktsepteerimist lõpliku vastavusotsusena.

Mõõda valmisolekut tööprooviga

Vali ühe toote väljaanne ja palu teisel inimesel leida kohaldumise hinnang, riskihinnang, SBOM-i identiteet, turvatestide tulemused, tugiperioodi otsus ja haavatavusest teatamise kontakt. See on meie soovitatud sisemine proov. Vastuvõtukriteerium on õige, üle vaadatud materjal ning selge järeldus. Kiire otsing vale versioonini ei ole edukas tulemus.

Seejärel lisa hüpoteetiline teade komponendi aktiivse ärakasutamise kohta. Meeskond peab suutma määrata mõjutatud toote, fikseerida teadlikuks saamise aja ning algatada liigitamise ja eskalatsiooni. Õppuses ei esitata päris regulatiivset teadet. Kasutage sobivat õppuse korraldust ning kontrollige kehtivaid ametlikke juhiseid enne päris esitamise töövoo kasutamist.

Ära eelda, et dokumentatsioon parandab toodet

GRC võib tuua nähtavale puuduva testi või hooldamata komponendi, kuid arendaja peab tegema tehnilise muudatuse. Kui toote uuendamise mehhanism ei toimi, ei lahenda seda paremini vormistatud riskikirje. Kirje aitab määrata vastutust, töö prioriteeti ning hilisema tulemuse tõendit. Tehniline teostus ja selle kontroll jäävad oma valdkonna tööks.

Pulsar ei ole selle juhendi alusel automaatne pilvetõendite koguja, haavatavusskanner ega õiguslik otsustaja. AI saab aidata koostada mustandeid ja korrastada olemasolevat materjali. Inimene kontrollib allikaid, hindab kohaldumist ja kinnitab otsuseid. Suveräänne andmeala ei anna organisatsioonile litsentsi kaitstud standarditeksti levitamiseks.

Piloodi realistlik lõpptulemus

Ühe toote piloodi lõpus võiks meeskond näidata kontrollitud kirjeid ning ausat puuduste nimekirja. Ta ei peaks kuulutama kogu portfelli CRA-le vastavaks. Kui valitud töövoog toimib ja selle piirid on teada, saab järgmise toote lisada sama meetodi järgi. Kui tõendid jäävad vastuoluliseks, tuleb kõigepealt parandada lähtemudelit, mitte kasvatada kirjete arvu.

Pulsar on varajase ligipääsu teenus. Neljateistkümne päeva prooviperiood nõuab makseviisi ja kehtivate tingimuste ülevaatamist. Valige enne alustamist üks toode ja üks konkreetne otsus, mille tööjälge soovite proovida. Kohapealne paigaldus ja privaatpilv on kavandatud suunad; nende praegust saadavust ei tohi eeldada.

Ühe toote tööplaan koos kontrollpunktidega

Järgmine plaan on näidis, mille tähtaegu ja rolle organisatsioon kohandab. Esimene kontrollpunkt kinnitab tootenimekirja ja vastutaja. Teine kontrollpunkt kinnitab kohaldumise hinnangu lähtefaktid. Kolmas kontrollpunkt katsetab teavitamise töövoogu. Hilisemad kontrollpunktid seovad riskid, testid, tugiperioodi ja dokumentatsiooni. Nende järjekord võib osaliselt kattuda, kuid ükski tulemus ei tohiks jääda põhjenduseta üldise valmidusprotsendi taha.

Töö	Valmimise kontroll	Ebaõnnestumise mehhanism
Tootepiir	ülevaataja nimetab hinnatud elemendid	paigaldatav komponent jääb SaaS-i nimetuse taha
Vastutus	puudumise korral on toimiv asendaja	teade ootab inimese tagasitulekut
Tõendid	õige väljaanne ja ulatus on tuvastatavad	aruanne puudutab vana arhitektuuri
Toe alus	sõltuvused ja kasutuseeldused on kontrollitud	lubadus ületab hoolduse tegeliku võime
Lõppülevaatus	avatud lüngad ja otsused on nähtavad	roheline staatus peidab tegemata testi

Määrake iga kontrollpunkti juures otsuse tegija ning materjal, mida ta vajab. Kui töö sõltub välisest laborist või tarnijast, kirjeldage sõltuvus ja varuplaan. Ei ole mõistlik lubada dokumentatsiooni lõppkuupäeva, kui katse tulemuse saabumise aeg pole teada. See ebakindlus peaks olema juhtkonnale nähtav enne tähtaja kinnitamist.

Pärast esimest töötsüklit vaadake üle kõige kallim käsitsi tehtud samm. Kas see oli tooteinfo leidmine, tõendi kontroll või otsuse kooskõlastamine? Iga probleem vajab oma parandust. Üldine automaatika lubadus ei lahenda olukorda, kus õige tehniline vastutaja pole määratud. Pulsari piloot võiks mõõta ühe konkreetse töövoo kasutatavust ning säilitada paranduste tulemuse.

Muuda lahtine eeldus juhtkonna otsuseks

Kui kogu programmi tähtaeg sõltub ühest kinnitamata asjaolust, näidake seda eraldi. Näiteks võib tootepere ühine hooldusplaan eeldada, et tarnija toetab vajalikku komponenti piisavalt kaua. Paluge vastutajal esitada kinnitav materjal või kirjeldada alternatiiv. Juhtkonna otsus peaks ütlema, millise eeldusega jätkatakse, millal seda kontrollitakse ning millist tööd tuleb teha, kui eeldus osutub valeks. See on meie praktiline töökorralduse soovitus, mitte uus õiguslik nõue.

Ärge peitke sellist küsimust üldise edenemisprotsendi sisse. Riskihinnangu olemasolu ja selle olulise eelduse usaldusväärsus on erinevad asjad. Säilitage otsuse juures ka kasutatud info kuupäev ning vastutaja kinnitatud järgmine tegevus. Nii saab järgmine ülevaataja aru, miks programm valitud järjekorras liigub. Kui tarnija vastus muudab olukorda, avage seotud ülesanded uuesti ja kirjeldage mõju konkreetsele tootele. See aitab vältida nii põhjendamatut kindlust kui ka kogu programmi tarbetut peatamist ühe piiratud küsimuse tõttu.

Allikad

Allikad ja kuupäevad üle vaadatud: 2. oktoober 2026.

Pulsar GRC — juurdepääs, andmete eraldamine ja eksport (poola keeles)