Cyber Resilience Act | Tuotevelvoitteet ja näyttö

Cyber Resilience Act (CRA) eli kyberresilienssisäädös ei tule hoidetuksi lisäämällä vaatimus laskentataulukkoon. Tuotetiimin on tiedettävä, mitä tuotetta vaatimus koskee, kuka vastaa työstä, milloin sen on oltava valmis, miksi päätös tehtiin ja mistä näyttö löytyy.

CRA:n ilmoitusvelvollisuuksia on sovellettu 11. syyskuuta 2026 lähtien. Asetuksen pääosaa sovelletaan 11. joulukuuta 2027 alkaen. Osan toimintamallista on siis toimittava jo nyt. Muu osa kannattaa rakentaa riittävän ajoissa, jotta teknistä dokumentaatiota ei tarvitse koota uudelleen lopussa.

CRA:n keskeiset päivämäärät

Päivämäärä	Mikä muuttuu
11. syyskuuta 2026	14 artiklan ilmoitusvelvollisuuksia sovelletaan
11. joulukuuta 2027	CRA:n pääasiallisia velvoitteita sovelletaan

Ilmoitettavissa tapahtumissa määräaika alkaa, kun valmistaja saa tapahtuman tietoonsa. Komissio kuvaa ennakkovaroituksen 24 tunnin kuluessa ja täydellisen ilmoituksen 72 tunnin kuluessa. Loppuraportin määräaika on erilainen aktiivisesti hyväksikäytetylle haavoittuvuudelle ja vakavalle poikkeamalle.

Tutustu CRA:n 24/72 tunnin ilmoitusmenettelyn käytännön työnkulkuun

CRA koskee tuotetta, ei yrityksen abstraktia vaatimustenmukaisuuspistemäärää

Ensimmäinen hyödyllinen kysymys on: mitä nimenomaista digitaalisia elementtejä sisältävää tuotetta arvioimme?

Asetus kattaa ohjelmisto- ja laitteistotuotteet sekä määritellyin edellytyksin niiden etätietojenkäsittelyratkaisut. Myös organisaation roolilla on merkitystä: valmistaja, valtuutettu edustaja, maahantuoja, jakelija tai olennaisen muutoksen tekevä toimija.

Aloita yhtä tuotetta koskevasta merkinnästä:

tuotteen nimi ja yksilöllinen tunniste;
versio tai julkaisuperhe;
valmistaja ja tuotemerkki, jolla tuote asetetaan saataville;
tapa, jolla se asetetaan saataville EU:n markkinoilla;
käyttötarkoitus ja päätoiminnot;
komponentit ja riippuvuudet;
tuotteen toimintoihin tarvittavat etäpalvelut;
tukijakso;
tuotteen tietoturvasta, haavoittuvuuksista ja julkaisuista vastaavat henkilöt.

Katso, miten tuotteen kuuluminen CRA:n soveltamisalaan arvioidaan

Seitsemän aluetta, joiden on yhdistyttävä

1. Soveltamisala

Määritä, kuuluvatko tuote ja organisaation rooli CRA:n piiriin. Nimitys kuten ”SaaS”, ”IoT” tai ”ohjelmisto” ei ole soveltamisalan arviointi.

2. Tuotteen riski

CRA:n vaatimukset liittyvät tuotteen kyberturvallisuusriskien arviointiin. Arvioinnin pitäisi säilyä tuotteen versioon sidottuna, ja sitä pitäisi tarkastella uudelleen arkkitehtuurin, käyttötarkoituksen tai riskin muuttuessa.

3. Sisäänrakennettu ja oletusarvoinen tietoturva

Vaatimus on muutettava tekniseksi työksi: suunnittelupäätökseksi, toimeksi, omistajaksi, testiksi, tarkastukseksi ja näytöksi.

Siirry CRA:n mukaiseen tietoturvaan suunnittelussa

4. Haavoittuvuudet ja SBOM

CRA edellyttää valmistajilta haavoittuvuuksien ja tuotekomponenttien tunnistamista ja dokumentointia. Tähän kuuluu ohjelmiston osaluettelon eli Software Bill of Materials (SBOM) -luettelon laatiminen yleisesti käytetyssä, koneellisesti luettavassa muodossa, joka kattaa vähintään ylimmän tason riippuvuudet.

Katso, miksi SBOM on prosessin lähtötieto eikä lopputulos

5. Ilmoittaminen

CRA:n yhteinen ilmoitusalusta eli Single Reporting Platform (SRP) on ollut toiminnassa 11. syyskuuta 2026 lähtien. Käytännössä valmistaja tarvitsee enemmän kuin pääsyn portaaliin: selkeän T0-hetken, eskalointikriteerit, vastuullisen omistajan, varahenkilöt ja ilmoituksen tekemiseen tarvittavat tiedot.

6. Tekninen dokumentaatio

Teknisen dokumentaation ei pitäisi olla toisistaan irrallisten tiedostojen arkisto. Sen on mahdollistettava tuotteen, version, arkkitehtuurin, riskinarvioinnin, haavoittuvuuksien käsittelyn, testien, päätösten ja tukijakson perusteen jäljitettävyys.

Tutustu CRA:n teknisen dokumentaation käytännön rakenteeseen

7. Tukijakso

Valmistaja määrittää tukijakson odotetun käytön ja CRA:ssa asetettujen kriteerien perusteella. Pääsääntöisesti se on vähintään viisi vuotta, ellei tuotteen odoteta olevan käytössä lyhyempää aikaa.

Katso, miten tukijakso dokumentoidaan

Missä pienemmillä organisaatioilla on vaikeuksia

ENISAn vuoden 2026 pk-yritysten CRA-kysely havainnollistaa tietoisuuden ja toteutuksen välistä eroa. Vapaaehtoisessa 194 vastauksen otoksessa 66 % tunsi CRA:n, mutta 54 % ilmoitti tuntevansa vaatimustenmukaisuuden arvioinnin vain rajallisesti tai ei lainkaan ja 42 % ilmoitti vastaavan puutteen vaaditun dokumentaation tuntemuksessa. Teknisen dokumentaation tuen valitsi 73 % vastaajista.

Kyselyä ei pidä käsitellä edustavana arviona koko EU:n markkinoista: otos on pieni ja vapaaehtoinen. Se on silti hyödyllinen merkki siitä, ettei ongelma ole vain ”tietää, että CRA on olemassa”. Tiimit tarvitsevat toistettavia toimintaprosesseja.

Pieni tuotetiimi tarvitsee tarkastettuja tuotetietoja, selviä vastuita ja toistettavaa arviointia. Alla olevat työtestit ovat suosittelemamme käytännön menetelmä. Ne eivät esitä tilastollista väitettä EU:n kaikista yrityksistä.

Mihin Pulsar GRC sopii

Pulsar GRC yhdistää työn, joka on usein hajautunut asiakirjoihin, laskentataulukoihin, tiketteihin ja sähköpostiin:

vaatimus → riski → hallintakeino tai toimi → omistaja → määräaika → asiakirja tai näyttö → tarkastus → päätöshistoria.

Pulsar yhdistää auditoinnit, hallintakeinot, riskit, asiakirjat, näytön, raportit, CAPA-toimet, toimittajat ja tehtävät. Tämä auttaa toteuttamaan prosessin ja osoittamaan sen toiminnan väittämättä, että ohjelmisto tekisi oikeudellisen ratkaisun asiakkaan puolesta.

Pulsar ei sertifioi CRA-vaatimustenmukaisuutta, korvaa oikeudellista arviointia tai päätä itsenäisesti, onko tapahtuma ilmoitettava. Soveltamisalaa koskevat päätökset, sääntelyn mukainen luokittelu ja ilmoituksen tekeminen säilyvät vastuullisilla ihmisillä.

Aloita yhdestä tuotteesta

Älä aloita ohjelmasta nimeltä ”otetaan CRA käyttöön koko yrityksessä”. Valitse yksi todellinen tuote. Määritä sen rajaus, omistajat, nykyiset riskit, haavoittuvuustyönkulku, dokumentaatio ja tukijakso. Tässä kohtaa toimenpiteitä vaativat puutteet tulevat näkyviksi.

Tutustu Pulsar GRC:hen yhden toiminnallisen työnkulun kautta

Aloita tuoteluettelosta, jonka voi tarkastaa

CRA-työn ensimmäinen jakso kannattaa rajata tunnistettaviin tuotteisiin. Tämä on suosittelemamme työtapa, ei asetuksen määräämä projektiaikataulu. Luettelosta pitää nähdä markkinoilla olevat tuotteet, vastuuhenkilöt, toimitusmallit ja avoimet kysymykset. Ilman tätä yksi tiimi saattaa arvioida pilvipalvelua ja toinen asennettavaa ohjelmistoa, vaikka molemmat käyttävät samaa tuotenimeä.

Kuvitteellinen valmistaja myy verkkoanturia ja sen hallintasovellusta. Anturissa on laiteohjelmisto, asiakkaan koneeseen asennettava työkalu ja valmistajan ylläpitämä etäpalvelu. Ensimmäiseksi tuotteen omistaja kuvaa kunkin osan toiminnon ja kehitysvastuun. Vasta sitten arvioidaan soveltumista ja tehtäväkokonaisuutta. Yleinen koko henkilöstön koulutus ei korvaa tätä lähtötietojen tarkastusta.

Jaa ohjelma erillisiksi päätöksiksi

Tuotemerkintä voi sisältää tunnisteen, myyntialueen, julkaisut ja soveltumisarvion version. Erillinen päätös määrää haavoittuvuuksien käsittelyn vastuun. Toinen hyväksyy tukijakson perusteen. Kolmas määrää teknisen dokumentaation tarkastuksen. Yksi tila ”CRA-projekti käynnissä” ei näytä näiden eri töiden valmistumista eikä puutteita.

Jokainen päätös tarvitsee tarkastettavan tuloksen. Soveltumisarvio päättyy perusteltuun johtopäätökseen lähteineen. Ilmoitusharjoitus näyttää, että tiimi tunnistaa alkuajan, löytää hyväksyjän ja kokoaa tiedot. Dokumentointityö tuottaa oikeisiin versioihin yhdistetyn rekisterin. Näitä tuloksia ei kannata korvata yhdellä prosentilla, jonka laskentaperuste ei ole selvä.

Määritä järjestys riippuvuuksien mukaan

Tuotteen raja tarvitaan ennen lopullisen näyttöpaketin kokoamista. Haavoittuvuustiedon vastaanotto ja ilmoitusvelvollisuuden arvio voivat kuitenkin olla nykyisiä tehtäviä jo ennen päävelvoitteiden soveltamista. Älä odota koko tulevan arviointihankkeen valmistumista, jos tämänhetkinen reagointi tarvitsee korjausta. Erota nopea toiminta ja pidempi kehitystyö selvästi toisistaan.

SBOM:n yhdistäminen julkaisuun tarvitsee julkaisuluettelon. Tukijakson perustelu tarvitsee riippuvuuksien ylläpitotiedot. Testipaketti tarvitsee riskin ja käyttäytymisvaatimuksen. Jos riippuvuus on tuntematon, määrää henkilö hankkimaan vastaus. Määräaika ei korvaa puuttuvaa teknistä tietoa. Johdon pitää nähdä tämä puute ennen aikataulun hyväksymistä.

Pieni tiimi tarvitsee toimivat roolit

Kolmen henkilön yritys ei tarvitse seitsemää osastoa. Sama henkilö voi kantaa monta vastuuta, mutta päätöksen rooli ja sijainen pitää tunnistaa. Tekninen johtaja voi arvioida vaikutuksen, ja määrätty vastuuhenkilö voi hyväksyä ulkoisen ilmoituksen. Jos nämä ovat sama henkilö, kirjaa se näkyviin ja sovi poissaolon järjestely.

Käyttöoikeus testataan todellisen tehtävän kautta. Portaalitunnus ei osoita, että henkilö osaa toimia oikeassa menettelyssä tai löytää tuotetiedon työajan ulkopuolella. Harjoittele myös puuttuva päävastuuhenkilö ja epäselvä ensimmäinen ilmoitus. Muuten koe kattaa vain helpon tilanteen ja todellinen heikkous jää piiloon.

Näytön laatu koskee koko ohjelmaa

Aineisto tarvitsee lähteen, version, ajankohdan, rajauksen ja arvioijan. Vanhan arkkitehtuurin riskiarvio ei välttämättä tue uutta julkaisua. Aito testiraportti voi koskea eri laitetta tai asetusta. Näytä nämä erot ennen koontiraporttia. Tiedostojen suuri määrä ei korvaa yhteyttä oikeaan tuotteeseen.

Pidä avoimien kysymysten luetteloa. Ratkaisematon asia ei saa kadota yleisen vihreän tilan vuoksi. Kirjaa vaikutus, väliaikainen järjestely ja päätöksen tarve. Johto voi silloin suunnata resurssin todelliseen puutteeseen. Väliaikaisen riskin hyväksyntää ei pidä nimetä lopulliseksi vaatimustenmukaisuudeksi.

Mittaa valmiutta työtestillä

Valitse yksi julkaisu. Pyydä toista henkilöä löytämään soveltumisarvio, riskiarvio, SBOM, testitulokset, tukipäätös ja haavoittuvuuden ilmoituskontakti. Tämä on sisäinen työtesti. Hyväksymiskriteeri on oikea tarkastettu materiaali sekä ymmärrettävä johtopäätös. Nopea haku väärään versioon ei tarkoita onnistumista.

Lisää sitten kuvitteellinen tieto komponentin aktiivisesta hyväksikäytöstä. Tiimin pitää tunnistaa tuote, säilyttää tiedon saapumisen aika ja käynnistää luokittelu. Harjoituksessa ei lähetetä todelliseen ilmoituskanavaan keksittyä tapahtumaa. Tarkista oikean ilmoituksen menettely ajantasaisista virallisista ohjeista ennen sen käyttöä.

Dokumentointi ei korjaa tuotetta

GRC voi näyttää puuttuvan testin tai ylläpitämättömän komponentin. Kehittäjän on silti tehtävä tekninen muutos. Jos päivitysmekanismi ei toimi, siistimpi riskiarvio ei ratkaise ongelmaa. Merkintä jäsentää omistajan, työn ja myöhemmän tuloksen, mutta toteutus jää oikealle tekniselle tiimille.

Pulsar ei ole tämän ohjeen perusteella automaattinen pilvinäytön kerääjä, haavoittuvuusskanneri tai oikeudellinen ratkaisija. Tekoäly auttaa luonnoksessa ja rakenteessa. Ihminen tarkistaa lähteen ja hyväksyy päätöksen. Eristetty tietoalue ei anna oikeutta jakaa suojattua standarditekstiä. Organisaation lisenssit ja käyttöehdot ratkaisevat sallitun käytön.

Rajatun pilotin tulos

Yhden tuotteen pilotin lopuksi tiimi voi näyttää tarkastetut merkinnät ja rehellisen puuteluettelon. Koko portfoliota ei pidä julistaa tämän perusteella vaatimustenmukaiseksi. Jos menetelmä toimii ja rajat tunnetaan, seuraava tuote voidaan lisätä. Jos lähdetiedot ovat ristiriitaisia, korjaa ne ennen luettelon kasvattamista.

Pulsar on varhaisen pääsyn palvelu. Neljäntoista päivän kokeilu edellyttää maksutapaa ja ehtojen tarkastusta. Valitse yksi tuote ja yksi päätöstyönkulku ennen aloitusta. Paikallinen asennus ja yksityispilvi ovat suunniteltuja suuntia. Niiden nykyistä saatavuutta ei pidä olettaa tämän artikkelin perusteella.

Yhden tuotteen tarkastuskortti

Työ	Valmiuden ehto	Tavallinen epäonnistuminen
Tuoteraja	arvioija tunnistaa toimitetut osat ja toiminnot	agentti katoaa yleisen SaaS-nimen alle
Rooli	sopimus ja todellinen toiminta vastaavat päätöstä	oma tuotemerkki sivuutetaan jälleenmyyntinä
Vastuu	poissaololle on kokeiltu sijainen	ilmoitus odottaa lomalla olevan paluuta
Näyttö	oikea julkaisu ja laajuus voidaan tunnistaa	vanha testi merkitään uuden tuotteen tueksi
Tuki	riippuvuudet ja käyttöoletukset tarkastetaan	lupaus ylittää todellisen ylläpidon kyvyn
Yhteenveto	avoimet tehtävät ja niiden vaikutus näkyvät	vihreä luku peittää tekemättömän kokeen

Käytä korttia työpalaverissa yhden tuotteen kanssa. Jokainen vastuuhenkilö näyttää oman vastauksensa lähteen. Pelkkä suullinen ”on kunnossa” ei vielä riitä. Jos tietoa ei saada, tee rajattu kysymys ja määrää sen selvittäjä. Palaverin tarkoitus on ratkaista työn seuraava askel, ei pyytää kaikkia kertomaan samaa yleistä tilannetta uudelleen.

Kirjaa myös tehtävän riippuvuus ulkoiseen toimijaan. Laboratoriotesti tai toimittajan vastaus voi määrittää aikataulun. Jos saapumisaika on tuntematon, näytä epävarmuus johdolle. Vastuuhenkilö ei voi luvata luotettavaa valmistumista pelkän oman kalenterin perusteella. Tarvittaessa arvioidaan toinen vaihtoehto tai työn laajuuden muutos pätevästi.

Erota nykyinen puute ja tuleva kehityssuunta

Teknisen reagoinnin puute voi tarvita tämän päivän toimen. Tulevan dokumentaation täydentäminen voi kuulua pidempään ohjelmaan. Näiden sekoittaminen yhteen hankelistaan voi peittää kiireellisen tehtävän. Kirjaa jokaiselle työlle oikea peruste, ajallinen tarve ja omistaja. Älä käytä yhteistä tulevaa päivämäärää kaikille asioille ilman tarkastusta.

Sama koskee palvelun ominaisuuksia. Nykyistä toimintoa voi kokeilla rajatussa pilotissa. Suunniteltua mahdollisuutta ei lasketa käytettävissä olevaksi kontrolliksi. Jos tiimi tarvitsee tietyn viennin tai integraation, vahvista sen laajuus ennen kuin toimintasuunnitelma riippuu siitä. Tuotekehityksen suunta ei ole näyttö nykyisestä kyvystä suorittaa tehtävä.

Pidä tuotteen päätökset johdonmukaisina

Käyttöohje, sopimus ja sisäinen tuotekortti voivat kuvata eri versioita. Tarkista ristiriita ennen loppuarviota. Esimerkiksi käyttäjäohje voi sanoa etäpalvelun pakolliseksi ja rakennekuva valinnaiseksi. Tämä muuttaa faktimallia. Päätöksen omistajan tulee hankkia suora tekninen vastaus eikä valita vain paremmin haluttuun tulokseen sopivaa lähdettä.

Tallenna ratkaistu ristiriita ja sen lähde. Se säästää seuraavan kierroksen työtä ja estää saman oletuksen palaamisen. Jos kysymys jää auki, näytä sen vaikutus päätökseen. Eri mieltä olevien henkilöiden nimet eivät ole tärkein asia; tärkeintä on oikea toiminto, toimitettu versio ja luotettava todellinen tieto.

Vältä tarpeetonta rinnakkaista rekisteriä

Jos kehitystiimin työkalu hallitsee julkaisun tekniset artefaktit jo hyvin, GRC voi säilyttää päätöksen ja tarkastetun viitteen. Sama tieto ei tarvitse toista käsin ylläpidettyä kopiota ilman syytä. Päätä, mikä lähde on kanoninen ja miten viitteen versio säilyy. Näin korjaus yhdessä paikassa ei jätä toiseen ristiriitaista tietoa.

Pilotin lopussa arvioi eniten työtä aiheuttanut vaihe. Oliko se etsiminen, sisällön tarkastus, puuttuvan toiminnan toteutus vai hyväksyntä? Jokainen tarvitsee erilaisen muutoksen. Yleinen automaatiolupaus ei ratkaise määrittämätöntä vastuuta tai tekemätöntä testiä. Jatkokehitys kannattaa kohdistaa mitattuun pullonkaulaan ja tarkistaa sen tulos seuraavassa tapauksessa.

Ohjelman hyväksymisen lisäkoe

Valitse toinen henkilö suorittamaan tuotekortin tehtävät. Anna hänelle normaalit oikeudet sekä kirjallinen ohje. Jos hän tarvitsee jatkuvasti alkuperäisen tekijän henkilökohtaisia muistiinpanoja, työ ei vielä kuulu organisaation hallittuun prosessiin. Määritä puuttuva tieto ja täydennä merkintä. Ihmisten vaihtumisen koe paljastaa eri puutteen kuin nopeuden mittaus.

Raportoi kokeen rajat. Yhden tuotteen onnistunut käsittely ei todista kaikkien tuotteiden tilaa. Harjoituksessa valmiiksi annettu tieto ei osoita epäselvän oikean tapahtuman hallintaa. Tämä ei tee kokeesta turhaa. Se tekee johtopäätöksestä rehellisen ja auttaa valitsemaan seuraavan tarkastuksen sen sijaan, että rajattu onnistuminen muutettaisiin koko yrityksen lupaukseksi.

Lähteet

Lähteet tarkistettu: 2. lokakuuta 2026.

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