CRA-valmius ulottuu yrityksissä paljon lakitekstiä pidemmälle. Se näkyy siinä, miten tietoturvariskit huomioidaan tuotekehityksessä, tunnetaanko tuotteessa käytetyt komponentit, miten haavoittuvuuksia seurataan ja käsitellään sekä onko vastuut sovittu ennen kuin ensimmäinen vakava tilanne tulee vastaan.
luotettavuusOhjelmistokehitysvaatimustenmukaisuus
CRAOhjelmistoturvallisuus
CRA-valmius tarkoittaa, että yritys pystyy viemään kyberturvallisuusvaatimukset käytäntöön osaksi tuotetta, tuotekehitystä ja sen elinkaaren aikaista ylläpitoa. Käytännössä tämä edellyttää esimerkiksi tuotteeseen liittyvien riskien ja ohjelmistokomponenttien tuntemista, toimivia käytäntöjä haavoittuvuuksien käsittelyyn ja raportointiin sekä selkeitä vastuita organisaatiossa. CRA-valmiudelle ei ole yhtä valmista mallia, vaan tarvittavat toimenpiteet on määritettävä oman tuotteen ja nykyisten toimintatapojen perusteella.
Cyber Resilience Act (CRA) on EU:n kyberkestävyyssäädös, joka asettaa vaatimuksia digitaalisia elementtejä sisältävien tuotteiden, kuten ohjelmistojen ja verkkoon kytkeytyvien laitteiden kyberturvallisuudelle. Vaatimukset koskevat tuotteen suunnittelua, kehitystä, valmistusta ja ylläpitoa koko sen elinkaaren ajan. CRA:n raportointivelvoitteet alkoivat 11.9.2026, ja asetusta sovelletaan laajasti 11.12.2027 alkaen.
CRA-valmius ulottuu yrityksissä paljon lakitekstiä pidemmälle. Se näkyy siinä, miten tietoturvariskit huomioidaan tuotekehityksessä, tunnetaanko tuotteessa käytetyt komponentit, miten haavoittuvuuksia seurataan ja käsitellään sekä onko vastuut sovittu ennen kuin ensimmäinen vakava tilanne tulee vastaan.
Yrityksen käytännön valmius rakentuu tuotteen, tuotekehityksen ja organisaation toimintatapojen ympärille. Siksi CRA:n vaatimuksia on tarkasteltava oman tuotteen ja nykyisen tekemisen kautta.
Yrityksen CRA-valmiutta ei voi arvioida yhden sertifikaatin, standardin tai tarkistuslistan perusteella. Vaatimusten vaikutukset riippuvat tuotteesta, sen ominaisuuksista, toimintaympäristöstä ja elinkaaresta. Wirokitin kriittisen ohjelmistokehityksen asiantuntijan Mika Maunumaan mukaan yksi CRA-valmiuden keskeisistä lähtökohdista onkin ymmärtää, mitä vaatimukset tarkoittavat juuri omalle tuotteelle.
CRA:n vaikutusten laajuus voi vaihdella merkittävästi eri tuotteiden välillä. Yksinkertaisessa ja vähän verkottuneessa tuotteessa huomioitavaa voi olla vähemmän, kun taas verkkoyhteyksiä, palveluita ja useita ohjelmistoriippuvuuksia sisältävässä tuotteessa kokonaisuus on laajempi. Yrityksen on siis arvioitava CRA:n vaikutukset tuotekohtaisesti sen sijaan, että valmiutta yritettäisiin rakentaa yhden yleisen mallin varaan.
CRA-valmius konkretisoituu nopeasti siinä vaiheessa, kun tuotteesta löytyy haavoittuvuus. Organisaation pitäisi silloin jo tietää, kuka ottaa havainnon käsittelyyn, miten sen vakavuus ja riskit arvioidaan, täyttyvätkö CRA:n ilmoitusvelvollisuuden kriteerit ja miten tarvittavat jatkotoimet käynnistetään.
Haavoittuvuuden käsittelyyn voi kuulua samanaikaisesti useita asioita: sisäinen arviointi, viranomaisraportointi, korjaavien toimenpiteiden käynnistäminen sekä käyttäjille tai asiakkaille viestiminen. Olennaista on, että vastuut ja toimintatavat on määritelty etukäteen ja että organisaatiolla on myös tapa vastaanottaa ja käsitellä ulkopuolelta tulevia haavoittuvuusilmoituksia.
“Jos vakava haavoittuvuus löytyy, organisaation pitäisi jo tietää, kuka reagoi, kuka arvioi tilanteen ja miten asia viedään eteenpäin. Prosessia ei voi alkaa rakentaa siinä vaiheessa, kun tilanne on jo päällä”, Maunumaa kuvailee.
Valmius edellyttää myös sitä, että yritys tuntee tuotteessaan käytetyt ohjelmistokomponentit ja niiden versiot. Ilman tätä tietoa on vaikea arvioida, koskeeko uusi tunnettu haavoittuvuus juuri omaa tuotetta. Tässä esimerkiksi SBOM toimii käytännön työkaluna komponenttien ja haavoittuvuuksien hallintaan.
CRA ei välttämättä tarkoita sitä, että yrityksen pitäisi ottaa käyttöön täysin uusia teknologioita kaikissa tuotekehityksen vaiheissa. Suurempi muutos voi löytyä siitä, miten nykyistä tekemistä ohjataan ja mitä asioita tuotekehityksessä huomioidaan järjestelmällisesti. Vaatimusten määrittelyssä pitää tunnistaa tuotteeseen liittyvät tietoturvavaatimukset, arkkitehtuurissa arvioida ratkaisun soveltuvuutta uhkaympäristöön ja toteutuksessa sekä testauksessa varmistaa, että tietoturva kulkee mukana osana normaalia kehitystyötä.
Maunumaan mukaan CRA tuo käytännössä muutoksia ja tarkennuksia useisiin tuotekehitysprosessin vaiheisiin. Haaste ei siksi ole aina yksittäisen uuden teknisen ratkaisun rakentaminen, vaan totuttujen toimintatapojen muuttaminen.
“CRA:n myötä muutoksia tulee käytännössä tuotekehityksen eri vaiheisiin. Suurin haaste voi olla siinä, että totutuista toimintatavoista pitää pystyä muuttamaan niitä kohtia, joissa tietoturvaa ei ole aiemmin huomioitu riittävän järjestelmällisesti”, Maunumaa toteaa.
Monelle yritykselle CRA-valmiuden rakentaminen tarkoittaakin ennen kaikkea nykyisten tuotekehitysprosessien tarkentamista ja uusien vaatimusten juurruttamista osaksi normaalia tekemistä. Nämä toimenpiteet parantavat tietoturvaa ja samalla myös yleisesti laatua.
CRA-valmiutta ei voi rakentaa vain tietoturvatiimin tai yksittäisen asiantuntijan vastuulle. Käytännön muutokset koskevat tuotekehitystä, tietoturvaa, laadunvarmistusta ja usein myös compliance- ja tuotevastuita, joten tekeminen tarvitsee tuekseen yhteisen suunnan ja selkeän päätöksenteon.
Maunumaa korostaa erityisesti johdon roolia. Jos johdon aitoa tukea ei ole, tarvittavia muutoksia toimintatapoihin ja tuotekehitysprosesseihin on vaikea viedä käytäntöön. Pelkkä muodollinen vastuun nimeäminen ei riitä, vaan johdon pitää mahdollistaa muutokset myös resursoinnilla ja päätöksenteolla.
“Tämän tyyppinen muutos lähtee yrityksen johdosta. Jos tukea, resursseja ja päätösvaltaa ei ole, tarvittavia toimintatapojen muutoksia on vaikea saada käytäntöön”, Maunumaa toteaa.
Selkeät vastuut ovat yhtä tärkeitä kuin johdon tuki. Organisaatiossa pitää tietää, kuka omistaa CRA-valmiuden, kuka vastaa haavoittuvuuksien käsittelystä, kuka tekee tarvittavat päätökset ja miten tieto kulkee eri roolien välillä. Kun vastuut on sovittu etukäteen, CRA ei jää irralliseksi projektiksi, vaan siitä tulee osa organisaation normaalia toimintaa.
CRA-valmiuden rakentaminen kannattaa aloittaa siitä, että yritys muodostaa realistisen kuvan omasta nykytilanteestaan. Ensin on ymmärrettävä, mitä CRA tarkoittaa juuri omalle tuotteelle, mitä vaatimuksia tuotekehityksessä jo täytetään ja missä on vielä puutteita. Vasta tämän jälkeen voidaan määrittää, mitä toimintatapoja, vastuita tai teknisiä ratkaisuja pitää muuttaa.
Keskeistä on suhteuttaa toimenpiteet oman tuotteen ja toimintaympäristön todellisiin tarpeisiin. Kaikkea ei tarvitse rakentaa uusiksi, mutta olennaiset puutteet pitää tunnistaa ja korjata järjestelmällisesti. Samalla on arvioitava, löytyykö organisaatiosta tarvittava osaaminen vai tarvitaanko tueksi koulutusta tai ulkopuolista asiantuntija-apua.
Kun nykytila on hahmotettu, tarvittavat muutokset voidaan priorisoida ja viedä vaiheittain osaksi tuotekehitystä, haavoittuvuuksien hallintaa, testausta ja ylläpitoa.
Wirokit auttaa tunnistamaan, mitä CRA-vaatimukset tarkoittavat käytännössä yrityksen omalle tuotteelle, ja viemään tarvittavat muutokset osaksi tuotetta ja sen kehitysprosessia.
CRA-valmius ei synny yksittäisestä standardista, teknisestä ratkaisusta tai raportointiprosessista. Se rakentuu siitä, että yritys ymmärtää oman tuotteensa vaatimukset, tunnistaa keskeiset riskit ja puutteet sekä vie tarvittavat muutokset osaksi tuotekehitystä ja tuotteen koko elinkaarta. Kun vastuut ovat selkeät, haavoittuvuuksien käsittelyyn on toimivat käytännöt ja johdolla on valmius tukea tarvittavia muutoksia, CRA:n vaatimuksista tulee osa organisaation normaalia toimintaa ja hallittua tuotekehitystä.
Asiantunteva tuotekehityskumppanisi kriittisessä ohjelmistokehityksessä ja laadunvarmistuksessa.
Kovempaa koodia
