CRA:n tukijaksot: yhdistä päättymispäivä dokumentoituun päätökseen

Cyber Resilience Act edellyttää valmistajilta tukijakson määrittämistä digitaalisia elementtejä sisältäville tuotteille. Kyse ei ole jälkikäteen täytettävästä ”EOL”-kentästä. Päätös määrittää muun muassa, kuinka kauan tehokkaan haavoittuvuuksien käsittelyn on jatkuttava, ja perustelu on sisällytettävä tekniseen dokumentaatioon.

Pääsääntöisesti tukijakso on vähintään viisi vuotta. Jos tuotteen odotetaan olevan käytössä alle viisi vuotta, tukijakso vastaa odotettua käyttöaikaa.

CRA:ssa asetetut kriteerit

Valmistajan on huomioitava erityisesti:

• käyttäjien kohtuulliset odotukset;
• tuotteen luonne;
• sen käyttötarkoitus;
• tuotteen elinkaaren määrittävä asianomainen EU-lainsäädäntö.

CRA sallii myös seuraavien huomioimisen:

• vastaavia toimintoja tarjoavien tuotteiden tukijaksot;
• toimintaympäristön saatavuus;
• ydintoimintoja tarjoavien integroitujen kolmannen osapuolen komponenttien tukijaksot;
• asianomainen komission ja ADCO:n ohjeistus.

Kriteerejä on sovellettava oikeasuhteisesti.

Älä aloita päivämäärästä

Heikko prosessi alkaa näin:

”Merkitään viisi vuotta, koska CRA sanoo niin.”

Vahvempi prosessi alkaa oletuksista:

1. Kuinka kauan käyttäjät voivat kohtuudella odottaa käyttävänsä tuotetta?
2. Kuinka kauan keskeisiä riippuvuuksia voidaan tukea?
3. Mikä on laitteiston tai toimintaympäristön elinkaari?
4. Käytetäänkö tuotetta teollisessa tai muussa ympäristössä, jossa käytännön elinikä on pidempi?
5. Mitä sitoumuksia sopimuksista ja muusta sovellettavasta lainsäädännöstä seuraa?
6. Voidaanko tietoturvapäivitysten prosessia realistisesti ylläpitää valitun jakson ajan?

Hyväksy päättymispäivä vasta näiden kysymysten käsittelyn jälkeen.

Päätöksen näyttö

Vähimmäismerkintä voi sisältää:

Kenttä	Esimerkkisisältö
Tuote / versio	yksilöllinen tunniste
Päätöspäivä	milloin tukijakso hyväksyttiin
Päättymispäivä	vähintään kuukausi ja vuosi
Odotettu käyttöaika	oletus + lähde
Käyttäjien odotukset	sopimukset, tuotetiedot, markkinoilta saatu näyttö
Keskeiset riippuvuudet	kolmansien osapuolten tukijaksot
Toimintaympäristö	vaaditut järjestelmät/alustat
Oikeudellinen/ohjeistuksen peruste	päätöksessä käytetyt lähteet
Hyväksyjä	vastuullinen henkilö/rooli
Tarkistuspäivämäärä	milloin oletukset tarkistetaan uudelleen

Käyttäjät tarvitsevat selkeän tuen päättymispäivän

Asetuksen 13 artikla edellyttää tukijakson päättymispäivän — vähintään kuukauden ja vuoden — ilmoittamista ostohetkellä selkeästi, ymmärrettävästi ja helposti saatavilla olevalla tavalla sekä tarvittaessa tuotteessa, pakkauksessa tai digitaalisesti.

Tämä yhdistää sisäisen elinkaaripäätöksen tuoteviestintään. Jos teknisen dokumentaation, hinnoittelun, käyttöliittymän ja sopimuksen päivämäärät eroavat, ongelma tulee esiin normaalissa asiakastoiminnassa paljon ennen auditointia.

Tukijakso on toiminnallinen sitoumus, ei vain päivämäärä

Tukijakson aikana valmistajan on käsiteltävä haavoittuvuuksia tehokkaasti CRA:n vaatimusten mukaisesti. Tukijaksomerkinnän pitäisi siksi yhdistyä seuraaviin:

• koordinoidun haavoittuvuuksien julkistamisen toimintaperiaate;
• haavoittuvuuksien ensiarvio ja korjaaminen;
• tietoturvajulkaisut;
• kolmannen osapuolen komponentit;
• käyttäjäviestintä;
• tuen päättymisen seuranta.

CRA sisältää myös vaatimuksia julkaistujen tietoturvapäivitysten jatkuvasta saatavuudesta ja dokumentaation säilyttämisestä määritettyjen jaksojen ajan. Elinkaaren hallintaa ei voi tiivistää yhteen CRM:n tai tuoteluettelon kenttään.

Miten Pulsar voi hallita päätöstä

Pulsar voi säilyttää päätöksen, perustelun, vastuuhenkilöt, toimet ja näytön sekä yhdistää ne riskeihin ja dokumentaatioon. Myöhemmässä tarkastuksessa tiimi näkee, mikä muuttui edellisestä päätöksestä, sen sijaan että kokoaisi alkuperäiset perustelut uudelleen.

Tämä ei tarkoita, että Pulsar päättäisi oikean tukijakson itsenäisesti. Oletukset ja hyväksyntä säilyvät valmistajan vastuulla.

Tutustu Pulsar GRC:hen yhden päätöksen elinkaaren kautta

Aiheeseen liittyvät oppaat

• CRA:n tekninen dokumentaatio
• SBOM ja tuotteen riippuvuudet
• Takaisin CRA-oppaaseen

Kuvitteellinen tuote elää myyntijaksoa kauemmin

Yritys myy teollisuusanturia kolme vuotta, mutta asiakkaat odottavat pitkää käyttöä. Myynti haluaa yksinkertaisen viiden vuoden loppuajan. Tekniikka tietää tärkeän riippuvuuden ylläpidon loppuvan aiemmin. Tämä on kuvitteellinen tilanne. Se kertoo, miksi tukijakson päätös tarvitsee tuotteen ja käytön aineistoa, ei vain helppoa päivämäärää.

Aloita odotetusta käytöstä. Kuvaa tarkoitus, asiakkaan odotukset, sopimukset ja käyttöympäristön elinkaari. Pätevä omistaja arvioi asetuksen kriteerit. Lyhyt myyntiaika ei automaattisesti tarkoita lyhyttä käyttöaikaa. Sama jakso kaikille tuotteille ei ratkaise erilaista todellista tilannetta. Perustelun tulee kertoa, miksi aika sopii kyseiseen tuotteeseen.

Kokoa päätöksen lähtöaineisto

Hanki tuotekuvaus, sopimuksen ehdot, käyttöä koskeva tieto ja tärkeiden riippuvuuksien ylläpito. Lähteillä voi olla eri päivämäärät. Merkitse päätöksessä käytetty versio ja puuttuva tarkastus. Älä oleta toimittajan tukevan osaa yhtä kauan kuin itse lupaat tukea tuotetta. Puuttuva tieto on näkyvä riippuvuus.

Jos käytön arvio perustuu muutamaan keskusteluun, kerro raja. Keskustelut voivat auttaa mutta eivät välttämättä kuvaa kaikkia käyttäjiä. Omistaja voi määrätä lisäselvityksen tai toisen perustellun valinnan. Säilytä syy ja seuraava tarkastus. Tarkka päivämäärä ilman kestävää perustaa ei poista epävarmuutta.

Riippuvuuden tuen loppu tarvitsee tehtävän

Tunnista keskeiset osat, joiden ylläpito vaikuttaa tuotteeseen. Määritä henkilö seuraamaan toimittajan tai projektin viestejä. Tieto ohjataan tuotteen omistajalle. Ylläpitoajat voivat muuttua, joten taulukko ilman päivitysvastuuta vanhenee nopeasti. Yksi kerran tehty arvio ei hallitse koko myöhempää jaksoa.

Jos osan tuki loppuu liian aikaisin, arvioi päivitys, korvaaminen tai muu ylläpito. Päätös tarvitsee teknisen sopivuuden, ajan ja resurssin. GRC yhdistää työvaiheet mutta ei tee kehitystä. Riskimerkintä ei osoita kykyä todella tuottaa turvapäivityksiä. Valinnan tulee johtaa toteutettavaan tehtävään ja tarkastettavaan tulokseen.

Yhdistä lupaus todelliseen kykyyn

Tukijakso tarvitsee henkilöt, työkalut ja toimitusprosessin. Näytä tiedon vastaanotto, vaikutusarvio, korjaus ja testi. Yhden avainhenkilön lähtö ei saa tehdä sovitusta järjestelystä käyttökelvotonta. Sovi sijainen tai muu järjestely. Kalenterikenttä ei luo tätä kykyä, vaikka se näkyisi asiakkaalle selvästi.

Resurssiarvion tulee olla päätöksen tekijällä. Pitkä lupaus ilman ylläpidon suunnitelmaa voi tuottaa velvollisuuden, jota tiimi ei kykene hoitamaan. Tämä artikkeli ei anna yleistä kustannuslukua. Käytä oman tuotteen, henkilöstön ja riippuvuuksien tietoa. Kirjaa rajoitukset, jotta johto arvioi todellista vaihtoehtoa.

Erota erilaiset päättymiset

Myynnin loppu, sopimuksen loppu, uusien toimintojen kehityksen loppu ja turvatuen loppu eivät aina ole sama päivä. Määrittele käytetty termi. Yleinen ”EOL” voi merkitä asiakkaalle muuta kuin kehittäjälle. Yhdestä kentästä voi silloin syntyä useita ristiriitaisia lupauksia ja hankala myöhempi keskustelu.

Tarkista käyttöliittymän, hinnaston, dokumentaation ja sopimuksen tieto yhdessä. Jos ne eroavat, määritä korjaus ja arvioi jo annettu tieto. Verkkotekstin hiljainen muutos ei selitä aiemman oston ehtoa. Säilytä päätöksen ja ulkoisen tekstin versiot. Näin voidaan vastata tietystä ostotilanteesta eikä vain näyttää nykyistä sivua.

Muuttunut oletus käynnistää uuden arvion

Uusi pääkomponentti, käyttötarkoitus tai toimittajan suunnitelma voi muuttaa perustaa. Määritä tapahtuma, joka käynnistää tarkastuksen. Älä odota vuosikokousta, jos tärkeä tieto muuttui tänään. Uusi arvio näyttää vaikutuksen ja aiempien päätösten säilyvän laajuuden. Pelkkä päivämäärän vaihtaminen ei ole sisällöllinen tarkastus.

Erota toimittajan viesti, arvioitu vaikutus ja oma hyväksytty tehtävä. Viesti on lähtötieto. Yrityksen ratkaisu jatkaa tuotteen ylläpitoa on toinen objekti. Molempien pitää löytyä. Muuten vastuuhenkilö joutuu palauttamaan perustelun sähköpostista juuri silloin, kun tarvitaan nopea vastaus asiakkaalle tai arvioijalle.

Arkisto tarvitsee oman säännön

Tukijakson loppu ei ole automaattinen kaikkien aineistojen poistokäsky. Päivitysten saatavuus ja dokumentaation säilytys arvioidaan sovellettavista säännöistä. Määritä aineistoryhmälle perusta, omistaja ja pääsy. Tämä työtapa ei korvaa täsmällisten ajanjaksojen oikeudellista tarkastusta, mutta tekee sen tuloksen käytettäväksi.

Säilytä julkaisun tunniste ja tarpeelliset yhteydet. Korjaustiedosto ilman tuotetta tai versiota voi myöhemmin olla mahdoton käyttää oikein. Arkiston olemassaolo ei osoita käytettävyyttä. Kokeile löytää yhden julkaisun aineisto ja selittää sen merkitys. Määritä löydetylle puutteelle tehtävä ennen seuraavaa asiakaskysymystä.

Päätöksen laadun tarkastus

Arvioija tarkistaa tuotteen, käytön ja riippuvuuksien perusteet sekä asiakkaalle julkaistun päivämäärän. Jos aineisto puuttuu, tee lisätehtävä. Tekoäly voi auttaa rakenteessa mutta ei luvata tulevaa ylläpitoa yrityksen puolesta. Ihminen arvioi lähteet, resurssin ja oletukset. Pulsar säilyttää perusteen eikä muuta sitä automaattisesti toteuttamiskelpoiseksi.

Hyväksymistesti kahdelle lukijalle

Anna sisäinen päätös tuotteen omistajalle ja ulkoinen teksti toiselle arvioijalle. Molempien tulee nimetä tuote, tuen loppu ja sen merkitys. Kysy sitten tärkeän osan aikaisemmasta tuen lopusta. Jos vastausta ei löydy tai lupaus ymmärretään eri tavoin, dokumentaatio ja työjärjestely tarvitsevat korjausta ennen laajentamista.

Tukijakson päätöksen työlehti

Kysymys	Tarvittava lähtötieto	Tarkastettava tulos
Kauanko tuotetta käytetään?	tarkoitus ja käyttäjän odotus	perusteltu oletus lähteineen
Mikä voi estää ylläpidon?	tärkeä osa ja toimittajan tukitieto	riippuvuus omistajan sekä tehtävän kanssa
Miten korjaus toimitetaan?	kehityksen ja jakelun menettely	tehty koe tai näkyvä avoin puute
Mitä asiakas odottaa?	sopimus ja käyttäjälle annettu tieto	yhteys hyväksyttyyn päivään
Kuka päättää?	pätevä vastuu ja resurssin arvio	hyväksyntä oikealla versiolla
Milloin arvio muuttuu?	olennaisen oletuksen muutos	nimetty tarkastuksen käynnistäjä

Sana ”tuntematon” on tässä työlehdessä hyödyllinen. Jos toimittaja ei vahvista ylläpitoa, asia on näkyvä riippuvuus. Tuotteen omistaja voi arvioida toisen osan, lisätyön tai muun järjestelyn. Jos tuntematon asia piilotetaan tarkkaan päivään, epävarmuus siirtyy asiakkaalle annettuun lupaukseen. Päätöksen tulee osoittaa myös tämä raja.

Kokeile yhden vanhan julkaisun korjausta

Tiimin pitää löytää julkaisu, rakennusmenettely, testi ja jakelun reitti. Jos vanhaa versiota ei voi enää rakentaa, ylläpidon todellinen kyky tarvitsee korjausta. Tämä voi liittyä työkaluun, riippuvuuteen tai ympäristöön. Määritä tekninen tehtävä ja tuloksen hyväksyjä. Pelkkä arkistoidun lähdekoodin löytyminen ei osoita toimivaa korjausprosessia.

Tarkista myös rakennuksen toistettavuuden raja. Uusi ympäristö voi tuottaa eri artefaktin, vaikka lähdekoodi on sama. Pätevän tiimin tulee arvioida vaikutus ja sopiva koe. GRC ei ratkaise tätä teknistä ongelmaa, mutta voi säilyttää sen päätöksen sekä avoimen työn. Näin resurssin tarve näkyy ennen seuraavaa kiireellistä haavoittuvuutta.

Kuvaa salaisuuksien hallinta kopioimatta niitä

Julkaisussa voi tarvita allekirjoitusavainta tai muuta arkaluonteista elementtiä. Dokumentoi vastuu ja hyväksytty käyttömenettely. Älä kopioi salaisuuden arvoa riskimerkintään tai yleiseen raporttiin. Tarvittaessa viittaa organisaation hyväksyttyyn säilytysratkaisuun. Päätöksen jälki tarvitsee kontrollin kuvauksen, ei avaimen sisältöä.

Kokeile sijaisen oikeaa toimintareittiä. Sijainen ei välttämättä tarvitse pysyvää pääsyä kaikkeen, mutta hänen pitää tietää, miten hyväksytty pääsy saadaan. Harjoitus voi näyttää poissaolon aiheuttaman riskin ilman salaisen materiaalin levittämistä. Jos menettely ei toimi, määrää korjaus siihen kontrolliin eikä yleinen lisäoikeus kaikille käyttäjille.

Älä muuta lupausta hiljaa

Sisäinen vaikeus ei yksin oikeuta lyhentämään asiakkaan tietoa. Sopimusten, annettujen ehtojen ja sovellettavien velvoitteiden vaikutus arvioidaan erikseen. Säilytä päätöksen perusta ja asiakkaalle annettu versio. Tämä artikkeli ei määritä, mikä sopimusmuutos on tietylle tuotteelle sallittu; se osoittaa perustellun arvioinnin tarpeen.

Jos ulkoiset tekstit ovat ristiriidassa, anna korjaukselle omistaja. Tekninen dokumentaatio voi näyttää yhtä kuukautta ja käyttöliittymä toista. Yhteinen päivämäärärekisteri voi auttaa, mutta senkin sisältö tarvitsee hyväksynnän. Automaattinen tekstien kopiointi monistaa myös virheen, jos alkuperäinen päätös oli väärin kirjattu tai ehto jäi epäselväksi.

Vältä kahta ristiriitaista päivämäärälähdettä

Organisaation nykyinen tuotejärjestelmä voi jo hallita elinkaarta hyvin. Arvioi silloin GRC:n lisäarvo päätöksen, lähteen ja tehtävän yhteydestä. Päivien käsin kopiointi toiseen rekisteriin ei ole arvo itsessään. Sovi kanoninen lähde ja se, miten hyväksytty versio säilyy. Näin myöhempi muutos ei jätä kahta eri vastausta.

Pilotin hyväksymiskriteeri voi olla yhden tuotteen päätöksen löytäminen ilman uutta sähköpostikierrosta. Mittaa myös oikea versio sekä tulkinnan selkeys. Nopeampi haku ei auta, jos käyttäjät ymmärtävät tuen eri tavoin. Raportoi tulos ja avoimet puutteet ilman lupausta koko tulevan tukijakson onnistumisesta. Pilotti näyttää nykyisen työnkulun, ei vuosien todellista ylläpitoa.

Tarkista seuraavan jakson resurssi

Tukipäätöksen omistaja voi tarkastaa sovitusti, riittääkö ihmiset ja tekninen ympäristö nykyiseen lupaukseen. Resurssin muutos ei automaattisesti muuta velvoitetta, mutta se voi vaatia uuden toteutusratkaisun. Kirjaa vaihtoehto ja sen vaikutus. Näin johto näkee riskin mekanismin ajoissa eikä vasta, kun korjaus jää toimittamatta.

Tarkasta riippuvuus henkilön poissa ollessa

Tukiprosessin koe voi käyttää tilannetta, jossa pääkehittäjä ei ole saatavilla. Sijaisen tulee löytää oikea julkaisu, ylläpidon tehtävä ja tarvittavan aineiston hyväksytty pääsyreitti. Jos tieto jää henkilön muistiin, kirjaa puute ja korjaa dokumentaatio. Yleinen lupaus varahenkilöstä ei osoita tehtävän todellista jatkuvuutta.

Kokeen tulos arvioidaan rajatusti. Yhden korjauksen onnistunut valmistelu ei todista koko tulevan jakson onnistumista. Se antaa kuitenkin suoran näytön nykyisestä järjestelystä ja näyttää mahdollisen pullonkaulan. Päätöksen omistaja voi käyttää havaintoa resurssin tai työnkulun täsmentämiseen ennen seuraavaa todellista tapahtumaa.

Lähteet

• Asetus (EU) 2024/2847 — 13 artikla ja liite VII
• Euroopan komissio — CRA-ohjeistus, 27. heinäkuuta 2026

Lähteet tarkistettu: 2. lokakuuta 2026.

• Pulsar GRC — pääsy, tietojen eristäminen ja vienti (puolaksi)