Cyber Resilience Act · 2026/2027
CRA tugiperiood: seo lõppkuupäev jälgitavalt dokumenteeritud otsusega
Teabematerjal. See ei asenda individuaalset õigusnõu ega vastavushindamist.
Kontrolli CRA kohaldamisala ja laadi oma hinnang allaCyber Resilience Act nõuab tootjatelt digitaalsete elementidega toodetele tugiperioodi määramist. See ei ole tagantjärele täidetav „EOL“ väli. Otsus määrab muu hulgas, kui kaua peab haavatavuste tõhus käsitlemine jätkuma, ning põhjendus tuleb lisada tehnilisse dokumentatsiooni.
Üldreeglina on tugiperiood vähemalt viis aastat. Kui toodet eeldatakse kasutatavat vähem kui viis aastat, vastab tugiperiood sellele eeldatavale kasutusajale.
CRA-s sätestatud kriteeriumid
Tootja peab arvestama eelkõige:
- kasutajate mõistlikke ootusi;
- toote olemust;
- selle sihtotstarvet;
- asjakohast ELi õigust, mis määrab toote kasutusea.
CRA lubab arvestada ka:
- sarnaste funktsioonidega toodete tugiperioode;
- töökeskkonna kättesaadavust;
- integreeritud kolmandate osapoolte komponentide tugiperioode, kui need komponendid täidavad põhifunktsioone;
- komisjoni ja ADCO asjakohaseid juhiseid.
Kriteeriume tuleb rakendada proportsionaalselt.
Ära alusta kuupäevast
Nõrk protsess algab nii:
„Paneme kirja viis aastat, sest CRA ütleb nii.“
Tugevam protsess algab eeldustest:
- Kui kaua võivad kasutajad mõistlikult eeldada toote kasutamist?
- Kui kaua saab põhisõltuvusi toetada?
- Milline on riistvara või töökeskkonna elutsükkel?
- Kas toodet kasutatakse tööstus- või muus keskkonnas, kus tegelik kasutusiga on pikem?
- Millised kohustused tulenevad lepingutest ja muust kohaldatavast õigusest?
- Kas turvauuenduste protsessi saab valitud perioodi jooksul realistlikult hoida?
Kiida lõppkuupäev heaks alles pärast nende küsimuste läbimõtlemist.
Otsuse tõendid
Minimaalne kirje võib sisaldada järgmist:
| Väli | Näidissisu |
|---|---|
| Toode / versioon | kordumatu tunnus |
| Otsuse kuupäev | millal tugiperiood heaks kiideti |
| Lõppkuupäev | vähemalt kuu ja aasta |
| Eeldatav kasutusaeg | eeldus + allikas |
| Kasutajate ootused | lepingud, tooteandmed, turutõendid |
| Põhisõltuvused | kolmandate osapoolte tugiperioodid |
| Töökeskkond | nõutavad süsteemid/platvormid |
| Õiguslik/juhiste alus | otsuses kasutatud allikad |
| Heakskiitja | vastutav inimene/roll |
| Ülevaatuse kuupäev | millal eeldusi uuesti kontrollitakse |
Kasutajad vajavad selget toe lõppkuupäeva
Artikkel 13 nõuab tugiperioodi lõppkuupäeva — vähemalt kuu ja aasta — selget ja arusaadavat esitamist ostuhetkel hõlpsasti ligipääsetaval viisil ning vajaduse korral tootel, pakendil või digitaalselt.
See seob sisemise elutsükliotsuse toote kohta antava teabega. Kui kuupäev tehnilises dokumentatsioonis, hinnakirjas, kasutajaliideses ja lepingus erineb, ilmneb probleem tavapärases klienditöös ammu enne auditit.
Tugiperiood on tegevuslik kohustus, mitte ainult kuupäev
Tugiperioodi jooksul peab tootja käsitlema haavatavusi tõhusalt CRA nõuete järgi. Tugiperioodi kirje tuleks seetõttu siduda järgmisega:
- haavatavuste koordineeritud avalikustamise põhimõtted;
- haavatavuste esmane hindamine ja parandamine;
- turvaväljaanded;
- kolmandate osapoolte komponendid;
- kasutajatega suhtlemine;
- toe lõpu jälgimine.
CRA sisaldab ka nõudeid väljastatud turvauuenduste jätkuvale kättesaadavusele ning dokumentatsiooni säilitamisele määratletud perioodidel. Elutsükli juhtimist ei saa taandada ühele CRM-i või tootekataloogi väljale.
Kuidas Pulsar saab otsust hallata
Pulsar saab säilitada otsuse, põhjenduse, vastutavad inimesed, tegevused ja tõendid ning siduda need riskide ja dokumentatsiooniga. Hilisemal ülevaatusel näeb meeskond, mis on eelmise otsusega võrreldes muutunud, selle asemel et algset põhjendust taastada.
See ei tähenda, et Pulsar otsustab iseseisvalt õige tugiperioodi. Eeldused ja heakskiit jäävad tootja vastutuseks.
Vaata Pulsar GRC-d ühe otsuse elutsükli näitel
Hüpoteetiline toode, mida kasutatakse kauem kui müüakse
Ettevõte müüb tööstuslikku andurit kolm aastat, kuid kliendid eeldavad selle kasutamist seadme pika eluea jooksul. Turundus soovib toe lõppkuupäevaks lihtsat viie aasta reeglit. Tehniline tiim teab, et üks põhikomponent kaotab hoolduse varem. See stsenaarium on hüpoteetiline. Ta näitab, miks tugiperioodi otsus vajab toodet ja kasutust käsitlevaid tõendeid, mitte ainult mugavat kuupäeva.
Alusta eeldatavast kasutusest. Kirjelda toote sihtotstarvet, kasutajate ootusi, lepinguid ja keskkonna eluiga. Pädev vastutaja hindab CRA kriteeriumide kohaldamist ning vajalikku perioodi. Lühike müügitsükkel ei tähenda automaatselt lühikest kasutusaega. Samuti ei lahenda sama pikk periood kõigi toodete puhul erinevaid tegelikke asjaolusid.
Koosta põhjenduse andmestik
Kogu tootekirjeldus, asjakohased lepingu tingimused, kasutusandmed ja põhisõltuvuste toe teave. Need allikad võivad olla eri kuupäevadega. Märgi, milline neist kehtis otsuse ajal ja milline jäi kontrollimata. Ära täida puuduva tarneinfo asemele eeldust, et tarnija toetab komponenti sama kaua kui sina toodet.
Eelda andmete piiranguid ausalt. Kui kasutusaja hinnang põhineb üksikutel kliendivestlustel, kirjuta see välja. Need vestlused võivad anda kasuliku signaali, kuid ei pruugi kirjeldada kogu kasutajaskonda. Vajaduse korral määrake täiendav uurimine või konservatiivsem otsus; selle valiku teeb vastutaja ning säilitab põhjenduse.
Sõltuvuste toe lõpp vajab tegevuskava
Kaardistage komponendid, mis täidavad põhifunktsioone ja mille hoolduse lõpp võib mõjutada toodet. Kirjeldage, kes jälgib tootja või projekti teadete muutusi ning kuidas need jõuavad toote vastutajani. Pelk tugiperioodide tabel võib kiiresti aeguda, kui selle uuendamiseks pole määratud omanikku.
Kui sõltuvuse toe lõpp jõuab varem kui kavandatud toote toe lõpp, hinnake uuendamise, asendamise või muu hoolduse korraldamise võimalusi. Valik vajab tehnilist sobivust, ajakava ja ressurssi. GRC-kirje saab neid otsuseid ühendada, kuid ei asenda arendustööd. Riskikirje olemasolu ei tõenda, et ettevõte suudab tegelikult turvaparandusi väljastada.
Seo lubadus tegeliku võimekusega
Tugiperioodi jooksul on vaja inimesi, tööriistu ja tarneprotsessi. Näidake, kuidas võetakse vastu haavatavuste teavet, tehakse mõju hinnang, valmistatakse parandus ning kontrollitakse selle tulemus. Kui üks võtmeisik lahkub, peab töö jätkamiseks olema kokkulepitud asendus või muu lahendus. Üks kalendriväli ei loo seda võimekust.
Eelarve hinnang peaks olema nähtav otsuse tegijale. Kui ettevõte lubab pika toe, kuid ei arvesta hooldamise ressursiga, võib ta hiljem avastada kohustuse, mida tehniline tiim ei suuda kokkulepitud ulatuses täita. Selle artikli näide ei anna hinnangulist kulu. Organisatsioon peab kasutama oma toote ning sõltuvuste tegelikke andmeid.
Eralda eri lõppkuupäevad
Müügi lõpp, lepingu lõpp, funktsioonide arenduse lõpp ja turvatoe lõpp ei ole alati sama sündmus. Kirjutage iga kasutatav termin selgelt välja. Kui kliendile antakse üldine „EOL“ kuupäev, võib ta mõista seda teistmoodi kui tehniline meeskond. Ühest kuupäevast saab nii mitu vastuolulist lubadust.
Kontrollige kasutajaliidese, hinnakirja, dokumentatsiooni ja lepingu teavet koos. Kui need erinevad, määrake paranduse vastutaja ning hinnake mõju juba antud teabele. Vaikne veebiteksti muutmine ei selgita varasema kliendi ostuhetke tingimust. Säilitage otsuse ja välise teabe versioonid, et hilisem küsimus oleks vastatav.
Muutus vajab uut ülevaatust
Uus põhikomponent, kasutusotstarbe muutus või tarnija hooldusplaani muutus võib mõjutada tugiperioodi põhjendust. Kirjeldage, milline sündmus käivitab ülevaatuse. Ärge oodake ainult iga-aastast koosolekut, kui oluline eeldus muutus täna. Uus hinnang peab näitama, mida muutus tegelikult mõjutab ning millised varasemad otsused jäävad kehtima oma ulatuses.
Muutuse kirje eristab tehnilist teadet, hinnatud mõju ja heakskiidetud tegevust. Tarnija teade toe lõppemisest on lähteinfo; organisatsiooni otsus selle kohta, kuidas toodet edasi hooldatakse, on teine objekt. Mõlemad peavad olema leitavad, et vastutaja ei peaks hiljem põhjendust e-kirjadest taastama.
Olemasolevad uuendused ja dokumentatsioon vajavad eraldi käsitlust
Tugiperioodi lõppu ei tohi tõlgendada automaatselt kõigi materjalide kustutamise käsuna. Turvauuenduste kättesaadavuse ja dokumentatsiooni säilitamise reeglid vajavad kohaldatavate sätete kontrolli. Määrake andmerühmade jaoks oma säilitamise alus, vastutaja ja ligipääs. Selle artikli töökorraldus ei asenda täpsete perioodide õiguslikku hindamist.
Tehniline arhiiv peab säilitama väljaande identiteedi ja vajalikud seosed. Kui alles jääb ainult paranduse fail ilma toote või versiooni tunnuseta, võib hiljem olla raske teada, kellele see sobib. Arhiivi olemasolu ei tõenda seetõttu veel kasutatavust. Proovige konkreetse väljaande materjal leida ning selle tähendus selgitada.
Tõendite kvaliteedivärav
Ülevaataja kontrollib, kas põhjendus tugineb õigele tootele, kasutusele ja sõltuvustele. Ta kontrollib ka, kas välises teabes avaldatud kuupäev vastab kinnitatud otsusele. Kui info on puudulik, määratakse täiendav tegevus. Puuduva tõendi peitmine kindla kuupäeva taha teeb probleemi vähem nähtavaks, kuid ei lahenda seda.
AI võib pakkuda otsuse struktuuri või küsimusi, kuid ei saa lubada tulevast hooldust organisatsiooni eest. Inimene kontrollib allikaid, ressurssi ja eeldusi ning kinnitab otsuse. Pulsar saab hoida selle põhjenduse koos riskide ja tegevustega; ta ei muuda kavandatud perioodi automaatselt tehniliselt teostatavaks.
Vastuvõtukatse kahe lugejaga
Anna sisemine otsus toote vastutajale ja kliendile mõeldud teave teisele ülevaatajale. Mõlemad peavad suutma nimetada toote, toe lõpu ning selle tähenduse. Seejärel küsi, kuidas käsitletakse põhikomponendi varasemat toe lõppu. Kui vastust pole või lugejad mõistavad lubadust erinevalt, vajab dokumentatsioon ja töökorraldus parandust.
Valige prooviks üks toode enne kogu portfelli laiendamist. Nii saab kontrollida, kas otsuse andmed, vastutajad ja välised tekstid on seotud. Neljateistkümne päeva varajase ligipääsu prooviperiood nõuab makseviisi; enne alustamist vaadake üle teenuse tegelik ulatus. Piloot hindab töövoogu, mitte ei tõenda kogu tulevase toe täitmist.
Tugiperioodi otsuse praktiline tööleht
| Küsimus | Vajalik sisend | Kontrollimise tulemus |
|---|---|---|
| Kui kaua toodet kasutatakse? | sihtotstarve ja kasutajate ootused | eeldus koos allika ja piiranguga |
| Mis võib hooldust takistada? | põhikomponendid ning tarnijate toe teave | sõltuvus koos tegevuse omanikuga |
| Kuidas parandusi väljastatakse? | arenduse ja tarne töökorraldus | katsetatud protsess või avatud puudus |
| Mida kliendile lubatakse? | leping ning kasutajale antav teave | kooskõla kinnitatud kuupäevaga |
| Kes teeb otsuse? | pädev vastutaja ja vajalik ressursi hinnang | heakskiit koos versiooniga |
| Millal otsus muutub? | olulise eelduse muutus | määratud ülevaatuse päästik |
Selle töölehe puhul on oluline ka sõna „teadmata“. Kui tarnija ei kinnita põhikomponendi tulevast hooldust, on see nähtav sõltuvus, mitte vaikne jah-vastus. Toote vastutaja saab otsustada, kas vaja on teist komponenti, lisakontrolli või muud ressurssi. Kui teadmata asjaolu peidetakse kindla kuupäeva taha, kandub probleem kasutajatele antud lubadusse.
Kontrollige toe korraldust ühe näidisparandusega. Meeskond peab leidma toetatava väljaande, sobiva koostamisprotsessi, testimise ning kasutajale kättesaadavaks tegemise tee. Kui vana versiooni enam koostada ei saa, võib see mõjutada hoolduse tegelikku võimekust. See on tehniline küsimus, mille lahendamine vajab oma tegevust ja pädevat hinnangut.
Kirjeldage, kuidas kasutatakse arhiivis olevaid võtmeid või muid tarneprotsessi tundlikke elemente ilma nende väärtusi GRC-kirjesse lisamata. Dokumentatsioon peaks näitama vastutust ja kontrollitud protseduuri, mitte kopeerima saladusi. Nii säilib tööjälg ja väheneb kõrvalise ligipääsu oht. Vajaduse korral kasutage viidet organisatsiooni kinnitatud salajaste andmete haldamise korrale.
Ärge muutke toe lubadust ainult sisemise raskuse tõttu vaikselt lühemaks. Mõju lepingutele, kasutajainfole ning kohaldatavatele kohustustele vajab eraldi hindamist. Säilitage otsuse alus ja kasutajatele antud teabe jälg. Artikli näide ei määra, milline lepingumuudatus on konkreetse toote puhul lubatud; see näitab vajadust otsus põhjendada.
Piloodi järel võib organisatsioon tuvastada, et olemasolev tööriist juba toetab suuremat osa registrist. Sel juhul hinnake Pulsari lisaväärtust konkreetse seose või ülevaatuse kaudu, mitte dubleerimise kaudu. Hea lahendus vähendab otsuse taastamise tööd, kuid ei tekita uut vastuolulist kuupäevade allikat.
Kontrolli hooldusvõimet pärast meeskonna muutust
Tugiperioodi jooksul võib lahkuda inimene, kes oskab vana väljaannet koostada või tunneb vajalikku katseseadet. Enne üleandmist paluge järgmisel vastutajal läbida üks piiratud hooldustoiming: leida lähteversioon, vajalik juhis ja kontrollitud katsekeskkond. Ärge kasutage selleks päris turvapaiga avaldamist. Proov peaks näitama, kas teadmised ja ligipääs on üle antud ning milline tegevus vajab veel täpsustamist.
Säilitage proovist saadud puudused koos tegevuste ja vastutajatega. Litsentsitud tööriista, katseseadme või välise teenuse sõltuvus peab olema nähtav ka hooldusplaanis. Üleandmise edukus ei muuda toote toe lõppkuupäeva, kuid annab infot lubaduse täitmise võime kohta. Kui vajalik keskkond pole enam kasutatav, hinnake alternatiivi ja mõju enne järgmise turvajuhtumi saabumist. See on praktiline järjepidevuse kontroll. See ei anna tootjale automaatset õigust olemasolevat kohustust lühendada ega asenda tugiperioodi õigusliku aluse hindamist.
Seotud juhised
Allikad
Allikad ja kuupäevad üle vaadatud: 2. oktoober 2026.