Cyber Resilience Act · 2026/2027

Koskeeko Cyber Resilience Act tuotettani?

Kirjoittaja: Piotr AdamskiOperatiivinen ja tietoturvatarkastus: Brillnet C-Team

Tietoa antava sisältö. Se ei korvaa yksilöllistä oikeudellista neuvontaa tai vaatimustenmukaisuuden arviointia.

Tarkista CRA:n soveltamisala ja lataa arviosi

CRA:n soveltuvuustarkistus: yhden tuotteen alustava arvio

Vastaa neljään kysymykseen saadaksesi tarkastuksen perustan ja näyttölistan. Vastaukset jäävät tähän selaimeen; lataa raportti ilman tiliä.

Tämä on alustava soveltamisalan arvio, ei oikeudellista neuvontaa tai vaatimustenmukaisuuden vahvistus. Tuotteen vastuuhenkilön on tarkastettava tulos. Se ei määritä avoimen lähdekoodin ohjelmistojen hallinnoijien erityisiä velvoitteita.

Kysymysten peruste: CRA:n 2 ja 3 artikla

CRA:n soveltamisalaa ei määritä pelkkä yrityksen toimiala tai nimitys kuten ”SaaS”, ”IoT” tai ”ohjelmistotoimittaja”. Aloita nimenomaisesta digitaalisia elementtejä sisältävästä tuotteesta, tavasta, jolla se asetetaan saataville EU:n markkinoilla, organisaation roolista ja tuotteen toimintoihin kuuluvasta etätietojenkäsittelystä.

Tuloksen pitäisi olla dokumentoitu soveltamisalan arviointi, jonka päätelmän peruste näkyy — ei perustelematon kyllä/ei-tulos.

Vaihe 1. Tunnista tuote

Aloita siitä, mitä käyttäjä todella ostaa, lataa, asentaa, integroi tai saa komponenttina.

Kirjaa:

  • tuotteen nimi ja tunniste;
  • versio tai versioperhe;
  • käyttötarkoitus;
  • päätoiminnot;
  • toimitusmalli;
  • tuotemerkki, jolla se tulee markkinoille;
  • markkinat, joilla se asetetaan saataville.

Jos tiimi ei pysty rajaamaan tuotetta, muu arviointi perustuu oletuksiin, joita on vaikea tarkistaa myöhemmin.

Vaihe 2. Tarkista digitaalisia elementtejä sisältävän tuotteen määritelmä

CRA määrittelee digitaalisia elementtejä sisältävän tuotteen ohjelmisto- tai laitteistotuotteeksi ja sen etätietojenkäsittelyratkaisuiksi. Määritelmään voivat kuulua myös erikseen markkinoille saatetut ohjelmisto- tai laitteistokomponentit.

Etäpalveluissa toiminnallinen yhteys ratkaisee. Asetus kuvaa etätietojenkäsittelyä etänä tapahtuvaksi käsittelyksi, jonka ohjelmiston valmistaja on suunnitellut ja kehittänyt itse tai jonka suunnittelu ja kehitys on tehty valmistajan vastuulla ja jonka puuttuminen estäisi tuotetta suorittamasta jotakin toimintoaan.

Siksi ”se toimii pilvessä” ei ole riittävä soveltamisalatesti. Kartoita ensin tuote ja riippuvuudet.

Vaihe 3. Määritä organisaation rooli

Merkityksellinen rooli voi olla:

  • valmistaja;
  • valtuutettu edustaja;
  • maahantuoja;
  • jakelija;
  • muu henkilö, joka tekee olennaisen muutoksen ja asettaa tuotteen saataville markkinoilla.

Tärkeä tapaus on maahantuoja tai jakelija, joka saattaa tuotteen markkinoille omalla nimellään tai tavaramerkillään tai muuttaa sitä olennaisesti. CRA:n mukaan valmistajan velvoitteet voivat silloin koskea tätä toimijaa.

Vaihe 4. Älä sivuuta jo markkinoilla olevia tuotteita

CRA:n pääasiallisia vaatimuksia sovelletaan 11. joulukuuta 2027 alkaen, mutta tämä ei tarkoita, että jo markkinoilla olevat tuotteet voisi sivuuttaa tämän päivän ilmoitusmenettelyssä.

Asetuksen 69 artiklan 3 kohdan mukaan 14 artiklan ilmoitusvelvollisuudet koskevat asetuksen soveltamisalaan kuuluvia digitaalisia elementtejä sisältäviä tuotteita, vaikka ne olisi saatettu markkinoille ennen 11. joulukuuta 2027.

Jo olemassa olevalle ja edelleen käytössä olevalle tuotteelle haavoittuvuuksien ja poikkeamien ilmoitustyönkulku on siis ajankohtainen toiminnallinen kysymys.

Vaihe 5. Tarkista poikkeukset ja alakohtainen lainsäädäntö

Älä luota lyhyeen verkossa olevaan luetteloon ”CRA:n ulkopuolisista toimialoista”. Asetuksella on oma soveltamisalansa, poikkeuksensa ja yhteytensä EU:n alakohtaiseen lainsäädäntöön.

Perusteltavissa oleva prosessi on seuraava:

  1. kirjaa arvioinnissa käytetty oikeussäännös ja lähde;
  2. kirjaa tarkistuspäivämäärä;
  3. erota tosiasiat oletuksista;
  4. merkitse pätevää oikeudellista arviointia vaativat kysymykset sen sijaan, että muuttaisit epävarmuuden varmaksi tuoteväitteeksi.

Soveltamisalan arvioinnin vähimmäistiedot

Kenttä Mitä kirjataan
Tuote nimi, versio, tunniste
Organisaation rooli valmistaja / maahantuoja / jakelija / muu
Markkinat missä tuote asetetaan saataville
Digitaaliset toiminnot ohjelmisto, laitteisto, rajapinnat, komponentit
Etätietojenkäsittely mitä käsitellään etänä ja tarvitaanko sitä tuotteen toimintoon
Peruste CRA:n säännös, komission ohjeistus, oletukset
Tulos todennäköisesti soveltamisalassa / todennäköisesti sen ulkopuolella / vaatii syvempää arviointia
Päätöksen omistaja arvioinnin hyväksyvä henkilö
Tarkistuspäivämäärä milloin päätöstä pitäisi tarkastella uudelleen

Milloin arviointi uusitaan

Soveltamisalan arvioinnista ei pitäisi tulla unohdettua PDF-tiedostoa. Tarkastele sitä uudelleen esimerkiksi, kun:

  • käyttötarkoitus muuttuu;
  • uusi etäpalvelu tulee välttämättömäksi tuotteen toiminnolle;
  • tuotetta muutetaan olennaisesti;
  • jakelumalli tai tuotemerkki muuttuu;
  • organisaatio siirtyy toiseen talouden toimijan rooliin;
  • uusi komission tai viranomaisen ohjeistus muuttaa päätöksen perustetta.

Miten Pulsar säilyttää päätöksen jäljitettävyyden

Pulsar voi säilyttää arvioinnin perusteen tukiasiakirjoineen ja liittää tuloksen riskeihin, toimenpiteisiin ja näyttöön. Arvo ei synny perustelemattomasta automaattisesta vastauksesta. Se syntyy mahdollisuudesta osoittaa myöhemmin mitä arvioitiin, mitä lähteitä käytettiin, kuka hyväksyi tuloksen ja mitä toimia siitä seurasi.

Pulsar ei korvaa tapauskohtaista oikeudellista arviointia.

Katso, miten yksi arviointi toteutetaan Pulsar GRC:ssä

Aiheeseen liittyvät oppaat

Kuvitteellinen portfolio eri rooleilla

Yritys myy verkonhallintalaitetta omalla nimellään, välittää toisen valmistajan ohjelmistoa ja kehittää mobiilisovellusta. Myyntikanava voi olla sama, mutta yrityksen rooli ja tuotteen raja eroavat. Tämä esimerkki selittää arvioinnin työjärjestystä. Se ei määritä näiden tuotteiden lopullista oikeudellista luokittelua.

Tee jokaisesta tarjouksesta oma työobjekti. Kuvaa asiakkaan saama tuote, kehitysvastuu ja markkinoille käytetty nimi. Tarkista sopimukset sekä tekninen kuvaus. Myynnin sana ”jälleenmyynti” ei osoita jakelijan roolia, jos yritys muuttaa tuotetta tai julkaisee sen omalla nimellään. Rooli pitää perustella todellisista seikoista.

Näytä tuotteen raja ymmärrettävästi

Tuotekortti kertoo toimitettavan laitteen, ohjelmiston, osat ja toiminnot. Etäkäsittelyn osalta kuvaa toiminto ja kehitysvastuu. Pelkkä pilvialustan nimi ei riitä. Sama alusta voi palvella montaa tuotetta, mutta arvio tarvitsee tietyn toiminnallisen yhteyden siihen tuotteeseen, jota päätös koskee.

Tuoteperhekin tarvitsee rajauksen. Pieni virhekorjaus voi käyttää yhteistä lähtötietoa. Uusi ulkoinen liitäntä tai käyttötarkoituksen muutos voi vaikuttaa arvioon. Perustele, mitä julkaisuja yksi päätös kattaa. Yksi yrityksen yleismerkintä jättää nämä erot näkymättömiksi ja vaikeuttaa myöhempää vaikutusarviota.

Tarkasta markkinoille antamisen seikat

Kuvaa lataus, lisensointi, laitemyynti ja komponentin toimittaminen. Maksuttomuus tai tilausmalli ei yksin ratkaise soveltumista. Myöskään yksittäisen latauksen tuotto ei ole yleinen vastaus. Käytä asetuksen sovellettavia määritelmiä ja yrityksen todellista toimintaa. Varmista tarvittavat yksityiskohdat, älä päättele niitä markkinointinimestä.

Kirjaa myös alueet, joilla tuote annetaan saataville. Avoin verkkosivu ja todellinen kaupallinen tarjonta voivat vaatia eri tarkastuksen. Jos asia ei ole vahvistettu, merkitse oletus ja vastuuhenkilö. Hiljainen oletus ei saa olla keino saavuttaa nopeasti haluttu lopputulos.

Poikkeus tarvitsee täsmällisen perustan

Jos mahdollinen poissulku löytyy, tallenna sääntö ja sitä tukevat seikat. ”Meillä on erityinen toimiala” ei riitä. Toisen EU-säädöksen yhteys voi koskea vain tiettyjä tuotteita tai luokkaa. Pätevä arvioija tarkistaa todellisen ulottuvuuden eikä siirrä yhtä poikkeusta koko yritykseen.

Älä käytä verkon lyhyttä listaa lopullisena päätöksenä. Tarkista asetus, ajantasaiset komission ohjeet ja tarvittaessa asiantuntijan arvio. Säilytä lähteiden tarkistusaika ja käytetty versio. Tämän artikkelin työehdotukset eivät ole kaikkien poikkeusten täydellinen luettelo eivätkä korvaa tuotekohtaista arviointia.

Jo käytössä oleva tuote tarvitsee nykyisen arvion

Kirjaa vanhan tuotteen julkaisut, käyttäjien tilanne ja haavoittuvuustiedon vastaanotto. Myyntitarjouksen arkistointi ei automaattisesti tarkoita tuotteen käytön loppua. Jos yritys ei tiedä käytössä olevia versioita, kyseessä on todellinen tietopuute. Se voi haitata ilmoituksen teknisen laajuuden selvittämistä.

Päävelvoitteiden tuleva päivämäärä ei oikeuta sivuuttamaan nykyistä ilmoitusvelvollisuutta. Tarkista artiklan 14 ja siirtymäsäännösten suhde tuotteeseen. Reagointityön laajuus voi erota tulevasta kokonaisarvioinnista. Pidä ne tehtäväsuunnitelmassa erillisinä, jotta kiireellinen asia ei jää pitkän hankkeen taakse.

Tee oletukset näkyviksi

Suosittelemamme päätös erottaa faktat, oletukset ja avoimet kysymykset. Fakta voi olla toimitetun paketin sisältö. Oletus voi koskea vielä kokeilematonta käyttötapaa. Avoin kysymys voi vaatia oikeudellisen tai teknisen arvioijan. Näitä ei pidä yhdistää lopussa yhdeksi varmaksi väitteeksi.

Kirjaa johtopäätöksen raja ja tarkastuksen käynnistävät muutokset. Päätös voi koskea tiettyä arkkitehtuuria ja myyntimallia. Uusi nimi, etätoiminto tai olennainen muutos voi vaatia uuden arvion. Muutoksen tekijän tulee tietää, miten tieto toimitetaan päätöksen omistajalle ennen käyttöä.

Tarvitset teknisen ja kaupallisen tiedon

Kehittäjä tuntee toiminnon, tuotetiimi toimituksen ja sopimuksen. Molemmat ovat tarpeen. Oikeudellinen arvioija ei voi korjata virheellistä arkkitehtuurikuvaa pelkällä lain lukemisella. Hyväksyntä tarkastaa sekä faktimallin että johtopäätöksen perustan. Pienessä yrityksessä henkilö voi kantaa monta roolia, mutta tarkastetut seikat säilytetään silti.

Aineisto tarvitsee oikean version, lähteen, rajauksen ja hyväksyjän. Sopimus voi osoittaa jakeluroolin mutta ei teknistä riippuvuutta. Arkkitehtuurikuva voi näyttää toiminnon mutta ei markkinoille antamisen seikkoja. Yhdistä näiden lähteiden sopiva sisältö; älä nimeä yhtä tiedostoa kaikkien kysymysten todisteeksi.

Hyväksymistesti yhdellä muutoksella

Anna arvio toiselle henkilölle ja pyydä selittämään tuote, rooli ja etätoiminto. Lisää kuvitteellinen uusi asennettava osa. Arvioijan tulee näyttää muuttuva oletus ja uudelleen tarkastettava päätös. Tämä testi arvioi käytettävyyttä, ei vahvista oikeudellista lopputulosta. Pulsar säilyttää päätöksen jäljen; ihminen hyväksyy sisällön.

Kolme työtilaa tarvitsee eri jatkon

Soveltumista tukeva tulos, soveltumattomuutta tukeva tulos ja lisäselvityksen tarve ovat käytännön työtiloja. Ne eivät ole virallisia oikeudellisia luokkia. Jokainen tarvitsee perustan ja rajauksen. Selityksetön ”ei sovellu” voi olla yhtä heikko kuin selityksetön ”soveltuu”. Päätöksen pitää näyttää tarkastettu tuote eikä vain haluttu lopputulos.

Jos soveltuminen saa tukea, määrää toimintasuunnitelman omistaja ja nykyisen ilmoitusmenettelyn tarkastus. Jos soveltumattomuus saa tukea, säilytä tuoteraja sekä uuden arvion käynnistävät muutokset. Avoin kysymys tarvitsee asiantuntijan, täsmällisen tehtävän ja lähtöaineiston. Epävarmuus ei saa jäädä pysyväksi tilaksi ilman henkilöä, joka vie asiaa eteenpäin.

Päätöksen osa Käyttökelpoinen sisältö Heikko korvike
Tuote toimitettu agentti tunnistetulla versiolla yrityksen yleinen nimi
Toiminto teknisesti tarkastettu käyttäytyminen pelkkä myyntilause
Oletus avoin etäriippuvuus omistajan kanssa vahvistamaton varma väite
Lähde virallinen ohje ja tarkistusaika hakutuloksen lyhyt katkelma
Rajaus tietty kokoonpano sekä markkina kaikkien tarjousten yleistys
Hyväksyntä vastuuhenkilö ja päätöksen versio yhteinen tila ilman omistajaa
Muutos uusi toimitettava osa käynnistää arvion unohdettu historiallinen PDF

Jaa muutoksen tunnistaminen oikeille henkilöille

Hyväksynnän jälkeen kehitys, myynti ja hankinta tarvitsevat lyhyen käytännön ohjeen. Heidän tulee tietää, mikä muutos ilmoitetaan ja kenelle. Kaikkien ei tarvitse lukea koko oikeudellista analyysiä. Olennaisen faktin muutos pitää silti päästä päätöksen vastuuhenkilölle ennen kuin vanha arvio otetaan uuden tarjouksen tueksi.

Kokeile ohjetta yhdellä esimerkillä. Myynti suunnittelee samaan nimikkeeseen asiakkaan oman tuotemerkin. Hankinta vaihtaa osan, joka tekee tärkeän etätoiminnon. Kehitys lisää uuden asennettavan moduulin. Kukin tunnistaa omasta työstään päätökseen mahdollisesti vaikuttavan asian. Jos yksi jää havaitsematta, täsmennä ohje siihen tilanteeseen eikä vain lisää yleistä koulutusta.

Tarkista lähteiden ristiriita tietoisesti

Sopimus voi kuvata jälleenmyyjän, mutta verkkosivu esitellä yrityksen valmistajana. Arkkitehtuurikuva voi olla uusi ja käyttöohje vanha. Älä ratkaise ristiriitaa automaattisesti lähteen määrällä tai sopivalla sanamuodolla. Selvitä, mikä aineisto kuvaa nykyistä todellista toimintaa. Päätöksen hyväksyjä tarvitsee tämän eron ennen johtopäätöstä.

Jos oikeudellinen ohje päivittyy, arvioi sen vaikutus valittuun tuotteeseen. Pelkkä uuden linkin lisääminen ei osoita sisällön tarkastusta. Kirjaa muuttunut kohta, oma tulkinta ja pätevän hyväksyjän ratkaisu. Suojatun standardin tekstiä ei tarvitse kopioida julkiseksi todisteeksi. Viite ja sallittu sisäinen aineisto käytetään organisaation käyttöoikeuksien mukaisesti.

Näytä, mikä ei kuulu arvioon

Tuotekortti voi rajata asiakkaan itsenäisesti kehittämän lisäosan tarkastuksen ulkopuolelle. Sen pitää kertoa syy sekä rajan käytännön merkitys. Ulkopuolinen osa voi silti vaikuttaa tuotteen tekniseen riskiin, joten soveltumisraja ja turvallisuusarvio eivät ole automaattisesti sama asia. Näitä kysymyksiä ei pidä ratkaista yhdellä poistomerkinnällä.

Samoin sisäinen työkalu ja markkinoille annettu komponentti voivat tarvita eri tarkastusta. Nimi ”sisäinen” pitää perustua todelliseen toimitukseen eikä siihen, kuka kirjoitti koodin. Jos asiakas saa osan osana palvelua, kuvaa se arvioijalle. Tarkka faktimalli vähentää tarvetta arvata tarkoitusta ja antaa paremmat lähtötiedot pätevälle arvioinnille.

Sisäinen hyväksyntä ei ole ulkoisen tahon vahvistus

Pulsarin päätösmerkintä kertoo organisaation työstä ja vastuusta. Se ei ole viranomaisen hyväksyntä. Oikeudellinen ja tekninen sisältö arvioidaan pätevästi käytetystä ohjelmistosta riippumatta. Sama koskee tekoälyn luonnosta: viite lähteeseen ei yksin takaa johtopäätöksen oikeellisuutta, jos tuotteen tärkeä fakta oli väärä tai puuttui.

Pilotin lopussa pyydä henkilöä nimeämään päätöksen olennaisin avoin kysymys ja sen seuraava askel. Hänen tulee löytää tekijä, tarvittava aineisto ja tarkastuspäivä. Tämä koe näyttää, pystyykö työ jatkumaan käytännössä. Puutteen hyväksyminen näkyvästi ei ole täydellisen vastauksen korvike, mutta se on parempi kuin tuntemattoman asian piilottaminen valmiiseen tilaan.

Kun seuraava arvio valmistuu, säilytä aiempi versio tarkoituksenmukaisesti. Uusi päätös ei saa näyttää siltä, että se olisi ollut voimassa ennen käytettyjen faktojen muuttumista. Aikajälki auttaa selittämään aiemman toiminnan sekä nykyisen rajauksen. Organisaatio tarvitsee molemmat näkökulmat, jos samaa tuotetta tarkastetaan myöhemmin uudelleen.

Lähteet

Lähteet tarkistettu: 2. lokakuuta 2026.