CRA 2026 -tuoteturvallisuusaineisto ISO 27001:n avulla

Kytkettyjä laitteita valmistava yritys kutsuu tietoturvajohtajansa Marian perjantai-iltapäivän kokoukseen. Myynti on juuri varmistanut eurooppalaisen jakelusopimuksen. Lakiosasto kysyy, pystyykö yritys tukemaan Cyber Resilience Act -säädöksen mukaista vaatimustenmukaisuutta. Tuotekehitys toteaa, että turvallinen kehittäminen on ”pääosin katettu”, koska käytössä ovat koodikatselmoinnit, SAST ja korjauspäivitykset. Hankinta kertoo toimittajien olevan ”NDA:n piirissä”. Tuotetiimeillä on laiteohjelmistoriippuvuudet yhdessä työkalussa, pilvi-API-inventaariot toisessa ja haavoittuvuustiketit Jirassa. Vaatimustenmukaisuudesta vastaavalla toiminnolla on ISO/IEC 27001:2022 -sertifiointinäyttöä, mutta se on järjestetty yrityksen ISMS:n ympärille, ei jokaisen EU:n markkinoille saatettavan tuotteen ympärille.

Sitten esitetään hankala kysymys: ”Jos EU:n viranomainen, asiakas, ilmoitettu laitos tai merkittävä jakelija pyytää tuoteturvallisuusaineistoa vuonna 2026, pystymmekö toimittamaan sen viikossa?”

Monille ohjelmistotoimittajille, älylaitevalmistajille ja kytkettyjen palvelujen tarjoajille rehellinen vastaus on ei. Ei siksi, että tietoturvakontrollit puuttuisivat, vaan siksi, että tuoteturvallisuutta koskeva näyttö on hajallaan. Turvallisen kehittämisen tallenteet ovat tuotekehityksellä. SBOM:t tuotetaan build-kohtaisesti, mutta niitä ei hallinnoida. Haavoittuvuuksien koordinoitu julkistaminen on olemassa verkkosivuna, mutta se ei aina kytkeydy triageen, korjauksiin, tiedotteisiin ja markkinoille saattamisen jälkeiseen seurantaan. Toimittajaturvallisuus on piilossa hankintasopimuksissa. Poikkeamien ilmoittaminen kuuluu tietoturvaoperaatioille, kun taas vaatimustenmukaisuuden dokumentointi kuuluu tuotevaatimustenmukaisuudelle.

EU:n Cyber Resilience Act muuttaa toimintamallia. Tuotteiden kyberturvallisuus ei ole enää vain paras käytäntö tai sopimusperusteinen lupaus. Siitä tulee elinkaaren kattava näyttövelvoite. Organisaatioiden on pystyttävä osoittamaan, miten kyberturvallisuusvaatimukset sisällytetään suunnitteluun, kehittämiseen, julkaisuun, haavoittuvuuksien käsittelyyn, päivityksiin ja seurantaan sen jälkeen, kun tuote on saatettu markkinoille.

Tässä ISO/IEC 27001:2022 on oikein käytettynä vahva väline. Se ei yksinään ole tuotteen sertifiointijärjestelmä, mutta sen ISMS sekä riski-, omaisuus-, toimittaja-, turvallisen kehittämisen, haavoittuvuus- ja poikkeamakontrollit voivat muodostaa CRA-tuoteturvallisuusaineiston rungon. Tavoitteena ei ole luoda uutta vaatimustenmukaisuussiiloa. Tavoitteena on muuntaa olemassa oleva ISMS tuotetason näyttöjärjestelmäksi.

Kuten Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta toteaa vaiheessa 2, vaiheessa 8, näyttöarkkitehtuurista:

”Näyttöä ei tule kerätä auditointisyklin lopussa. Se tulee suunnitella osaksi kontrollia, osoittaa omistajalle, aikaleimata prosessissa ja tehdä uudelleenkäytettäväksi kaikissa velvoitteissa, jotka kysyvät samaa asiaa eri sanoin.”

Tämä lause tiivistää CRA-valmiuden ytimen. Kysymys ei ole vain: ”Onko meillä turvallinen kehittäminen?” Kysymys on: ”Pystymmekö todentamaan turvallisen kehittämisen, komponenttitietoisuuden, haavoittuvuuksien käsittelyn ja markkinoille saattamisen jälkeisen seurannan tämän tuotteen, tämän version, tämän julkaisun ja näiden markkinoiden osalta?”

CRA-tuoteturvallisuusaineisto on elävä näyttöjärjestelmä

CRA-tuoteturvallisuusaineistoa ei pidä käsitellä staattisena PDF-tiedostona, joka tuotetaan kerran ennen julkaisua ja unohdetaan. Sen tulee olla jäsennelty dokumentaatioaineisto, joka kertoo tuotteen tietoturvatarinan konseptista tuen päättymiseen.

Hyödyllinen aineisto selittää:

1. Mikä tuote on ja miten sitä on tarkoitus käyttää.
2. Mitä ohjelmistoja, laiteohjelmistoja, pilvipalveluja ja kolmansien osapuolten riippuvuuksia se sisältää.
3. Mitkä kyberturvallisuusriskit arvioitiin.
4. Mitä tietoturvavaatimuksia sovellettiin.
5. Miten turvallinen kehittäminen toteutettiin.
6. Miten haavoittuvuuksia vastaanotetaan, triagoidaan, korjataan ja julkistetaan.
7. Miten turvalliset päivitykset toimitetaan.
8. Miten toimittajia ja avoimen lähdekoodin komponentteja valvotaan.
9. Miten poikkeamat ja aktiivisesti hyväksikäytetyt haavoittuvuudet eskaloidaan.
10. Miten tuotetta seurataan sen jälkeen, kun se on saatettu markkinoille.

Tietoturvajohtajalle tämä on ISMS-näyttöön liittyvä haaste. Tuotevaatimustenmukaisuuspäällikölle se on teknistä dokumentaatiota. Tuotekehitykselle se on DevSecOpsia ja julkaisujen hallintaa. Johdolle se on markkinoille pääsyä ja vastuuriskin hallintaa.

Virhe on käsitellä näitä erillisinä työvirtoina. Parempi malli on rakentaa tuotetason näyttöaineisto, joka kartoitetaan ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrolleihin, ja sen jälkeen ristiinkartoittaa sama näyttö soveltuvin osin NIS2:een, DORA:an, GDPR:ään, NISTiin ja COBIT 2019:ään.

Clarysecin Zenith Controls: vaatimustenmukaisuuksien välinen opas kuvaa tätä kontrollista näyttöön ja auditoijalle ulottuvana ketjuna:

”Vaatimustenmukaisuuksien välinen näyttöaineisto tulee kartoittaa jokaisesta velvoitteesta käytössä olevaan kontrolliin, toistuvaan näyttöobjektiin, vastuunalaiseen omistajaan ja auditointinäkökulmaan, jolla sitä haastetaan.”

Tällaista kurinalaisuutta CRA-valmistautuminen edellyttää. Tuoteturvallisuusaineisto ei ole pelkkä kansio. Se on tulkintakerros tuotekehityksen, tietoturvan hallinnoinnin, vaatimustenmukaisuuden arvioinnin ja asiakkaiden varmentamispyyntöjen välillä.

Rakenna ensin tuotteen näyttörunko

Aineisto tarvitsee yhdenmukaisen rakenteen ennen kuin tiimit alkavat tallentaa siihen aineistoa. Ilman selkeää runkoa näytöstä tulee kasa kuvakaappauksia, vientitiedostoja ja politiikka-PDF:iä, joita auditoija ei pysty seuraamaan.

CRA-valmiustyöpajoissa Clarysec suosittelee yleensä seuraavaa tuoteturvallisuusaineiston rakennetta organisaatioille, joilla on jo käytössä ISO/IEC 27001:2022 -standardin mukainen ISMS.

Tämä taulukko ei korvaa lakisääteisiä teknisen dokumentaation velvoitteita. Se antaa liiketoiminnalle toimintamallin niiden todentamiseen.

Zenith Blueprint -mallissa vaihe 1, vaihe 3 keskittyy soveltamisalan ja rajojen määrittelyyn. CRA:n kohdalla siitä tulee tuotekohtainen. Määritä tuoteperhe, ohjelmistoversiot, käyttöönotto-oletukset, käyttäjäroolit, kytketyt palvelut, päivityskanavat ja tukiaika. Jos ISMS:n soveltamisala on ”Corporate SaaS and device management platform”, CRA-aineiston on silti vastattava suppeampaan kysymykseen: ”Mikä digitaalisia elementtejä sisältävä tuote saatetaan EU:n markkinoille, ja mitä kyseiseen tuotteeseen sisältyy?”

Kartoita turvallinen kehittäminen tuotetason tallenteisiin

Tuoteturvallisuusaineiston ydin on näyttö sisäänrakennetusta tietoturvasta. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän. ISO/IEC 27002:2022 tarjoaa toteutusohjeistusta kontrollien, kuten A.8.25 Turvallisen kehittämisen elinkaari, A.8.27 Turvallinen järjestelmäarkkitehtuuri ja tekniset periaatteet, A.8.28 Turvallinen ohjelmointi ja A.8.29 Tietoturvatestaus kehityksessä ja hyväksynnässä, kautta.

Keskeinen muutos on siirtyminen yleisistä turvallisen kehittämisen väitteistä julkaisukohtaisiin tallenteisiin. ”Teemme koodikatselmointia” ei riitä. Aineiston tulee osoittaa, mikä julkaisu katselmoitiin, mitkä riskit huomioitiin, mitkä tietoturvatestit läpäistiin, mitkä haavoittuvuudet hyväksyttiin tai korjattiin ja kuka hyväksyi julkaisun.

Clarysecin Enterprise Turvallisen kehittämisen politiikka on suunniteltu varmistamaan tällainen näyttöketju. Sen kohdassa 6.1, Turvallisen kehittämisen elinkaarivaatimukset, todetaan:

”Jokaisesta tuote- tai palvelujulkaisusta on ylläpidettävä dokumentoitua näyttöä tietoturvavaatimuksista, suunnittelukatselmoinnista, turvallisen ohjelmoinnin toimista, tietoturvatestauksesta, haavoittuvuuksien korjaamista koskevista päätöksistä ja julkaisun hyväksynnästä ennen tuotantokäyttöönottoa.”

Tämä kohta on hyödyllinen CRA:n kannalta, koska se muuttaa turvallisen kehittämisen toistettavaksi näyttömalliksi. Auditoijan ei tarvitse päätellä, tapahtuiko turvallista kehittämistä. Hän voi tarkastaa julkaisutallenteen.

Älytermostaatin, lääketieteellisen IoT-laitteen, teollisen anturin tai SaaS-kytketyn tuotteen osalta turvallisen kehittämisen näytön tulisi sisältää:

• Tuotteen tietoturvavaatimukset kartoitettuna tunnistettuihin riskeihin.
• Uhkamalli tai väärinkäyttötapausanalyysi tuotteelle ja kytketyille palveluille.
• Arkkitehtuurikatselmointi, mukaan lukien luottamusrajat ja ulkoiset rajapinnat.
• Turvallisen ohjelmoinnin standardi sekä näyttö kehittäjän hyväksynnästä tai koulutuksesta.
• SAST, DAST, ohjelmistokoostumusanalyysi, salaisuuksien skannaus ja laiteohjelmistoanalyysi soveltuvin osin.
• Korjaustiketit korkean riskin havainnoille.
• Riskin hyväksymistä koskevat tallenteet liiketoiminnan ja tietoturvan hyväksynnällä.
• Julkaisuportin tarkistuslista, joka osoittaa tietoturvakriteerien täyttyneen.
• Kryptografinen allekirjoitus ja päivityksen eheyden osoittava näyttö.
• Tukiaikaa ja elinkaaren päättymistä koskevat oletukset.

Muut standardit vahvistavat menetelmää. ISO/IEC 27005 tukee näiden tallenteiden taustalla olevaa riskilähtöistä lähestymistapaa. ISO/IEC 27017 on hyödyllinen, kun pilvipalvelut ovat osa tuotteen ekosysteemiä. ISO/IEC 27035 tukee poikkeamien käsittelyä. ISO/IEC 29147 ja ISO/IEC 30111 ovat erityisen olennaisia haavoittuvuuksien julkistamisen ja haavoittuvuuksien käsittelyn kannalta. ISO/IEC 27036 tukee toimittajaturvallisuutta, jolla on merkitystä, kun tuote sisältää ulkoistettuja ohjelmistoja, sulautettuja moduuleja, hallittuja pilvipalveluja tai kolmannen osapuolen kirjastoja.

Zenith Controls -oppaassa CRA:n turvallisen kehittämisen näyttö kartoitetaan yleensä ISO/IEC 27002:2022 -standardin kontrolliteemojen, kuten tietoturvallisuus projektinhallinnassa, turvallisen kehittämisen elinkaari, turvallinen ohjelmointi, tietoturvatestaus, muutoksenhallinta ja teknisten haavoittuvuuksien hallinta, ympärille. Opas kytkee nämä myös omaisuusluetteloon ja toimittajakontrolleihin, koska mikään turvallisen kehittämisen prosessi ei ole täydellinen, jos organisaatio ei pysty tunnistamaan toimittamiaan komponentteja.

Käsittele SBOM:ää säänneltynä tuotenäyttönä

Software Bill of Materials käsitellään usein teknisenä artefaktina. CRA-valmiudessa sitä tulee käsitellä tuotenäyttönä.

Hyödyllinen SBOM kertoo, mitä komponentteja tuotteessa on, mitä versioita käytetään, mistä ne ovat peräisin, mitä lisenssejä niihin sovelletaan, mitkä haavoittuvuudet vaikuttavat niihin ja mitkä julkaisut sisältävät ne. Laiteohjelmisto- ja sulautetuissa tuotteissa tämä voi sisältää käyttöjärjestelmäpaketteja, käynnistyslataimia, kirjastoja, ajureita, kontteja, kolmannen osapuolen moduuleja ja tuotteen toiminnan edellyttämiä pilvipuolen riippuvuuksia.

Ongelma on, että monet organisaatiot tuottavat SBOM:eja mutta eivät hallinnoi niitä. Build-putki voi tuottaa SPDX- tai CycloneDX-tiedoston, mutta kukaan ei validoi kattavuutta. Tietoturvatyökalut voivat merkitä haavoittuvuuksia, mutta tuloksia ei sidota tuoteversioihin. Hankinta voi hyväksyä toimittajan, mutta toimittajan komponenttiluetteloa ei täsmäytetä julkaistuun tuotteeseen.

Clarysecin Enterprise Omaisuudenhallintapolitiikka käsittelee tätä hallinnointivajetta kohdassa 5.2, Tietojen ja niihin liittyvän omaisuuden luettelo:

”Tietovarat ja niihin liittyvät teknologiakomponentit on tunnistettava, niille on osoitettava omistaja, ne on luokiteltava soveltuvin osin ja niitä on ylläpidettävä luettelossa, joka tukee riskien arviointia, haavoittuvuuksien hallintaa, muutosten hallintaa ja auditointinäyttöä.”

CRA:n kannalta tästä kohdasta tulee tuotekohtainen. SBOM on osa siihen liittyvien teknologiakomponenttien inventaariota. Se tarvitsee omistajan, säilytyssäännön, validointiprosessin ja yhteyden haavoittuvuuksien hallintaan.

Käytännöllinen SBOM-näyttösääntö on yksinkertainen: jokaisella julkaistulla tuoteversiolla on oltava hyväksytty komponentti-inventaario, joka voidaan täsmäyttää julkaisuartefaktiin. Jos organisaatio ei pysty yhdistämään SBOM:ää täsmälliseen laiteohjelmistokuvaan, sovelluspakettiin, konttitiivisteeseen tai SaaS-julkaisuun, SBOM on heikkoa näyttöä.

Jos yli kaksi riviä ei läpäise, ongelma ei yleensä ole SBOM-työkalu. Ongelma on hallinnointi. Tuoteturvallisuusaineiston tulee kirjata korjaava toimenpide ISMS:ään, koska CRA-näytön heikkous on myös ISO/IEC 27001:2022 -kontrollin tehokkuuteen liittyvä ongelma.

Kytke CVD haavoittuvuuksien käsittelyyn ja julkaisujen hallintaan

Haavoittuvuuksien koordinoitu julkistaminen on yksi näkyvimmistä CRA-valmiuden osa-alueista, koska ulkoiset tutkijat, asiakkaat ja viranomaiset voivat testata sitä suoraan. Haavoittuvuuksien julkistamissivun tai security.txt-tiedoston julkaiseminen on hyödyllistä, mutta se on vain etuovi. Tuoteturvallisuusaineiston on osoitettava, että taustaprosessi toimii.

Puolustettavissa olevan CVD- ja haavoittuvuuksien käsittelyn näyttökokonaisuuden tulisi sisältää:

• Julkinen ilmoituskanava ja toimittamisohjeet.
• Tutkijan ilmoituksen hyväksyntäprosessi.
• Triagekriteerit, mukaan lukien vakavuuden ja hyväksikäytettävyyden arviointi.
• Tuotevaikutusten analyysi.
• Korjaavien toimenpiteiden omistajuus ja tavoiteaikataulut.
• Asiakastiedotteen ja päivitysviestinnän mallit.
• Näyttö turvallisesta korjauspäivityksen kehittämisestä ja testauksesta.
• Tallenteet koordinoidusta julkaisusta soveltuvin osin.
• Opit ja toistuvien haavoittuvuustrendien analyysi.

Clarysecin Enterprise Haavoittuvuuksien hallintapolitiikka kohdassa 6.3, Haavoittuvuuksien vastaanotto, triage ja korjaavat toimenpiteet, todetaan:

”Ilmoitetut haavoittuvuudet on kirjattava lokiin, arvioitava niiden vaikutus omaisuuseriin ja tuotteisiin, priorisoitava riskin ja hyväksikäytettävyyden perusteella, osoitettava vastuunalaiselle omistajalle ja seurattava korjaavien toimenpiteiden, varmennuksen, viestinnän ja sulkemisen läpi.”

Tämä kohta kytkee CVD:n SBOM:ään, omaisuusluetteloon, tuotekehitystiketteihin, julkaisunhallintaan ja markkinoille saattamisen jälkeiseen seurantaan. Se on myös kohta, jota auditoijat luontevasti testaavat: näytä vastaanottotallenne, näytä vaikutuksen piirissä olevat tuotteet, näytä triage, näytä korjaus, näytä asiakasviestintä, näytä sulkeminen.

Olemassa oleva Tietoturvapoikkeamien hallintapolitiikka tulisi myös laajentaa kattamaan tuotehaavoittuvuudet, joista tulee poikkeamia tai jotka edellyttävät ulkoista ilmoittamista. ISO/IEC 27002:2022 A.5.24 kattaa poikkeamien hallinnan suunnittelun ja valmistelun, A.5.25 kattaa tietoturvatapahtumien arvioinnin ja niistä päättämisen, A.5.26 kattaa tietoturvapoikkeamiin reagoinnin ja A.5.27 kattaa poikkeamista oppimisen.

Zenith Controls -oppaassa haavoittuvuuksien hallintaa käsitellään sekä ennaltaehkäisevänä että korjaavana toimintona. Ennaltaehkäisevään puoleen kuuluvat inventaario, turvallinen kehittäminen, toimittajien seuranta ja turvallinen konfigurointi. Korjaavaan puoleen kuuluvat havaitseminen, triage, korjauspäivitykset, viestintä ja poikkeamien eskalointi. Tällä erolla on merkitystä, koska markkinoille saattamisen jälkeinen haavoittuvuuksien käsittely on osa tuotteen elinkaarivelvoitetta, ei jälkikäteen lisättävä tehtävä.

Toimittajanäyttö on piilevä heikkous

Tuoteturvallisuusaineistoa haastetaan usein voimakkaimmin siellä, missä valmistaja tukeutuu muihin. Tämä koskee sulautettuja moduuleja, ulkoistettua laiteohjelmistokehitystä, white label -komponentteja, pilvihostingia, mobiili-SDK:ita, maksupalveluja, kryptografisia kirjastoja ja hallinnoituja tukipalveluntarjoajia.

Yleinen epäonnistumismalli on sopimusperusteinen abstrahointi. Valmistaja sanoo: ”Toimittajamme vastaa siitä.” Tuoteturvallisuuden tarkastelussa tämä ei riitä. Organisaation on osoitettava, että toimittajariski tunnistetaan, tietoturvavaatimukset viestitään, näyttö kerätään, haavoittuvuudet koordinoidaan ja muutoksia hallitaan.

Clarysecin Enterprise Kolmansien osapuolten ja toimittajien tietoturvapolitiikka kohdassa 7.1, Toimittajaturvallisuusvaatimukset, todetaan:

”Toimittajat, jotka kehittävät, operoivat, käsittelevät, tukevat tai olennaisesti vaikuttavat tietojärjestelmiin, tuotteisiin tai palveluihin, on arvioitava riskiperusteisesti, ja niihin on sovellettava tietoturvavaatimuksia, jotka kattavat pääsyn, haavoittuvuuksien hallinnan, poikkeamailmoitukset, alihankinnan, jatkuvuuden ja näytön toimittamisen.”

CRA:n kannalta ilmaus ”olennaisesti vaikuttavat tuotteisiin” on kriittinen. Jos toimittajakomponentti voi tuoda haavoittuvuuden, häiritä päivityksiä, altistaa asiakastietoja tai vaarantaa laitteen eheyden, se kuuluu tuoteturvallisuusaineistoon.

Sama politiikka voi tukea myös SBOM-sopimusehtoja. Kohdassa 7.3 todetaan:

”Kaikkien yrityksen ’digitaalisia elementtejä sisältäviin tuotteisiin’ integroitavien kolmannen osapuolen ohjelmistokomponenttien, kirjastojen tai käyttöjärjestelmien osalta toimittajan on pyynnöstä toimitettava koneluettava Software Bill of Materials (SBOM) vakiomuodossa, kuten SPDX tai CycloneDX. Tämä vaatimus on sisällytettävä kaikkiin hankinta- ja toimittajasopimuksiin.”

Vahvan toimittajanäyttöpaketin tulisi sisältää toimittajien luokittelu tuotevaikutuksen perusteella, sopimusten tietoturvavaatimukset, toimittajan turvallisen kehittämisen näyttö kriittisille komponenteille, toimittajan sitoumukset haavoittuvuuksien julkistamiseen, SBOM tai komponenttivakuutukset soveltuvin osin, korjauspäivitystuki ja elinkaaren päättymisen aikataulut, säännöllisten katselmointien tallenteet sekä eskalointipolut toimittajaperäisille haavoittuvuuksille.

ISO/IEC 27002:2022 A.5.19, A.5.20 ja A.5.21 tarjoavat keskeiset toimittajakontrollien teemat. ISO/IEC 27036 syventää toimittajasuhteiden turvallisuutta. Vaatimustenmukaisuuksien välisessä tarkastelussa NIS2 korostaa toimitusketjua ja haavoittuvuuksien käsittelyä. DORA korostaa ICT-kolmannen osapuolen riskiä finanssialan toimijoille. GDPR on merkityksellinen, kun tuote tai sen pilvipalvelut käsittelevät henkilötietoja. COBIT 2019 kehystää toimittajahallinnan yrityksen teknologian hallinnointikysymyksenä, ei vain tietoturvaoperaatioiden kysymyksenä.

Markkinoille saattamisen jälkeinen seuranta muuttaa näytön toiminnaksi

Kypsimmät tuoteturvallisuusorganisaatiot katsovat julkaisua pidemmälle. Ne kysyvät: ”Miten tiedämme, jos tästä tuotteesta tulee riskialtis kentällä?”

Markkinoille saattamisen jälkeisen seurannan tulee kerätä signaaleja haavoittuvuussyötteistä, hyväksikäyttöä koskevasta uhkatiedustelusta, asiakastuesta, telemetriatiedoista, bug bounty -ohjelmista tai tutkijoiden raporteista, toimittajailmoituksista, pilvilokeista, poikkeamatallenteista ja kenttäsuorituskyvyn tiedoista. Sen tulee sisältää myös säännöllinen tuoteriskien katselmointi, kun uhkaolosuhteet muuttuvat.

Clarysecin Enterprise Lokitus- ja valvontapolitiikka kohdassa 5.4, Tietoturvavalvonta ja katselmointi, todetaan:

”Tietoturvan kannalta merkitykselliset tapahtumat on kerättävä, katselmoitava, eskaloitava ja säilytettävä tavalla, joka tukee oikea-aikaista havaitsemista, tutkintaa, tietoturvapoikkeamiin reagointia, vaatimustenmukaisuusraportointia ja jatkuvaa parantamista.”

Kytkettyjen tuotteiden osalta tätä on tulkittava huolellisesti. Seurannan on noudatettava tietosuojaa, tietojen minimointia ja lakisääteisiä rajoitteita erityisesti silloin, kun telemetriatiedot sisältävät henkilötietoja tai asiakkaan operatiivisia tietoja. GDPR-kartoitus on tärkeä. Tuoteturvallisuustiimien tulee työskennellä tietosuojatiimien kanssa määrittääkseen, mikä telemetria on tietoturvan kannalta tarpeellista, miten se minimoidaan, kuinka pitkään sitä säilytetään ja miten asiakkaille tiedotetaan.

Markkinoille saattamisen jälkeisen seurannan näytön tulisi sisältää tuoteturvallisuuden seurantasuunnitelma, haavoittuvuustiedustelun lähteet, asiakkaiden ilmoitusten vastaanottokanavat, toimittajien ilmoituskanavat, telemetrian tai lokien katselmoinnin laajuus, säännöllisten tuoteriskikatselmointien pöytäkirjat, korjauspäivitysten käyttöönoton seuranta, poikkeamatrendien analyysi ja johdon katselmoinnin syötteet.

Zenith Blueprint -mallissa vaihe 5, vaihe 30 keskittyy jatkuvaan parantamiseen ja valvontavalmiuteen. CRA:n kohdalla tässä tuoteturvallisuusaineistosta tulee elävä aineisto. Jokaisen tuotejulkaisun, haavoittuvuuden, toimittajamuutoksen ja kenttäsignaalin tulee päivittää näyttötallennetta.

Yksi näyttöaineisto, monta vaatimustenmukaisuuskysymystä

Hyvin suunniteltu CRA-tuoteturvallisuusaineisto vähentää päällekkäisyyttä, koska sama näyttö vastaa useisiin vaatimustenmukaisuuskysymyksiin. Kieli muuttuu, mutta kontrollitodellisuus on usein samankaltainen.

Zenith Controls on suunniteltu tällaista uudelleenkäyttöä varten. Se kartoittaa ISO/IEC 27002:2022 -kontrolliteemat attribuutteihin, kuten ennaltaehkäisevään, havaitsevaan ja korjaavaan kontrollitarkoitukseen, kyberturvallisuuskäsitteisiin, operatiivisiin kyvykkyyksiin ja tietoturvaominaisuuksiin. CRA:n kannalta tämä auttaa tietoturvajohtajaa selittämään, miksi yksittäinen näyttöobjekti, kuten julkaisun tietoturvakatselmointi, tukee turvallista kehittämistä, riskien käsittelyä, muutosten hallintaa, haavoittuvuuksien hallintaa ja auditointivalmiutta.

Valmistaudu erilaisiin auditointinäkökulmiin

CRA-tuoteturvallisuusaineistoa voi haastaa ISO-auditoija, sisäinen tarkastusryhmä, asiakkaiden varmentamistiimi, tuotteen vaatimustenmukaisuuden arvioija, viranomainen, NIST-pohjainen arvioija tai ISACA-koulutettu COBIT-auditoija. Jokainen kysyy samankaltaisia kysymyksiä eri näkökulmasta.

Sama heikko kohta paljastuu eri tavoin. Jos SBOM:eja tuotetaan mutta ei säilytetä, ISO-auditoija näkee tallenteiden hallintaan ja operatiiviseen kontrolliin liittyvän ongelman. NIST-arvioija näkee omaisuuden ja haavoittuvuuksien hallinnan heikkouden. COBIT-auditoija näkee heikon tietovarojen hallinnoinnin. Tuotearvioija näkee riittämättömän teknisen dokumentaation.

CRA-valmiuteen sovitettu 30-vaiheinen tiekartta

Zenith Blueprint estää vaatimustenmukaisuustiimejä hyppäämästä suoraan asiakirjojen keräämiseen. CRA:n kohdalla 30-vaiheisesta tiekartasta tulee tuoteturvallisuuden näyttöohjelma.

Vaihe 1 alkaa velvoitteiden ja soveltamisalan kartoituksella. Tunnista soveltamisalaan kuuluvat tuotteet, versiot, komponentit, pilvipalvelut ja tukiprosessit. Vahvista aiottu käyttö, käyttäjäryhmät, markkinat ja tietoturvatuen ajanjakso.

Vaihe 2 rakentaa näyttöarkkitehtuurin. Määritä tuoteturvallisuusaineiston hakemisto, näytön omistajat, säilytysvaatimukset, tietovarastorakenne ja hyväksyntätyönkulku. Sovita se yhteen tuotekehitysjärjestelmien kanssa sen sijaan, että pakotat manuaalisia latauksia.

Vaihe 3 toteuttaa operatiiviset kontrollit. Turvallisen kehittämisen, SBOM:n tuottamisen, haavoittuvuuksien käsittelyn, toimittajanäytön, julkaisuporttien, turvallisten päivitysten ja poikkeamien eskaloinnin on toimittava todellisina prosesseina.

Vaihe 4 testaa auditointivalmiutta. Valitse tuotejulkaisu ja toteuta harjoitusauditointi. Pystyykö tiimi noutamaan SBOM:n? Pystyykö se todentamaan tietoturvatestauksen? Pystyykö se näyttämään, miten haavoittuvuus triagoitiin? Pystyykö se yhdistämään toimittajanäytön tuotekomponentteihin?

Vaihe 5 juurruttaa valvonnan ja parantamisen. Markkinoille saattamisen jälkeinen seuranta, haavoittuvuustrendien analyysi, toimittajakatselmoinnit ja johdon katselmoinnin syötteet pitävät aineiston ajan tasalla.

Tämä sprintti paljastaa yleensä totuuden nopeasti. Organisaatiot epäonnistuvat harvoin siksi, että niiltä puuttuvat kaikki kontrollit. Ne epäonnistuvat siksi, että kontrollit eivät kytkeydy toisiinsa tuotetasolla.

Yleiset CRA-valmiuden puutteet ennen vuotta 2026

Ohjelmistotoimittajilla, laitevalmistajilla ja kytkettyjen palvelujen tarjoajilla toistuvat puutteet ovat samankaltaisia.

Ensinnäkin ISMS:n soveltamisala on liian yritystasoinen. Se kattaa organisaation, mutta ei riittävästi tuotteen elinkaaren yksityiskohtia. Korjaus on tuotetason liitteiden ja näyttöaineistojen luominen.

Toiseksi SBOM:eja on olemassa, mutta niihin ei luoteta. Työkalut tuottavat niitä, mutta niitä ei katselmoida, hyväksytä, säilytetä tai kytketä haavoittuvuuspäätöksiin. Korjaus on SBOM-hallinnointi, ei pelkästään SBOM:n tuottaminen.

Kolmanneksi CVD näkyy ulospäin, mutta se ei ole operatiivisesti kypsä. Ilmoituksia saapuu, mutta triagekriteerit, reagointitavoitteet, tiedotehyväksynnät ja sulkemisnäyttö ovat epäjohdonmukaisia. Korjaus on CVD:n integrointi haavoittuvuuksien hallintaan, poikkeamien hallintaan ja julkaisunhallintaan.

Neljänneksi toimittajanäyttö on liian pinnallista. Kriittiset toimittajat hyväksytään kaupallisesti, mutta niitä ei arvioida tuoteturvallisuusvaikutuksen perusteella. Korjaus on toimittajien luokittelu tuoteriskin perusteella ja pakollinen näyttö kriittisille komponenteille.

Viidenneksi markkinoille saattamisen jälkeinen seuranta on reaktiivista. Tiimit reagoivat kiireellisiin haavoittuvuuksiin, mutta eivät tee säännöllisiä tuoteriskikatselmointeja. Korjaus on aikataulutettu markkinoille saattamisen jälkeinen tietoturvakatselmointi, joka kytketään johdon raportointiin.

Kuudenneksi auditointinäyttö on liian manuaalista. Vaatimustenmukaisuustiimit jahtaavat kuvakaappauksia. Korjaus on näyttö osana suunnittelua, jossa tuotekehitysjärjestelmät, tikettityönkulut ja tietovarastot toimivat ajantasaisina lähteinä.

Rakenna näyttöaineisto ennen kuin määräaika rakentaa sen puolestasi

Cyber Resilience Act palkitsee organisaatiot, jotka pystyvät osoittamaan tuoteturvallisuuden operatiivisena käytäntönä. Se luo riskin organisaatioille, jotka käsittelevät näyttöä viime hetken vaatimustenmukaisuusharjoituksena.

Aloita yhdestä tuotteesta. Rakenna yksi tuoteturvallisuusaineisto. Kartoita se ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -standardeihin. Liitä siihen turvallisen kehittämisen näyttö, SBOM, CVD-tallenteet, toimittajavarmennus ja markkinoille saattamisen jälkeinen seuranta. Tee auditointisimulaatio ennen kuin joku ulkopuolinen tekee sen puolestasi.

Clarysec voi auttaa nopeuttamaan tätä matkaa Zenith Blueprint -mallin, Zenith Controls -oppaan, Enterprise Turvallisen kehittämisen politiikan, Haavoittuvuuksien hallintapolitiikan, Omaisuudenhallintapolitiikan, Kolmansien osapuolten ja toimittajien tietoturvapolitiikan, Lokitus- ja valvontapolitiikan ja Tietoturvapoikkeamien hallintapolitiikan avulla.

Tärkein CRA 2026 -kysymyksesi ei ole: ”Onko meillä tietoturvakontrollit?”

Se on: ”Pystymmekö todentamaan tuoteturvallisuuden julkaisu julkaisulta, komponentti komponentilta ja haavoittuvuus haavoittuvuudelta sen jälkeen, kun tuote on jo markkinoilla?”

Rakenna näyttöaineisto nyt, kytke se ISMS:ään ja tee jokaisesta tulevasta tuotejulkaisusta lähtökohtaisesti auditointivalmis.