Opas EU CRA 2026 -haavoittuvuusraportoinnin valmiuteen

On maanantaiaamu syyskuussa 2026, kello 08.17. Nopeasti kasvavan eurooppalaisen SaaS-yhtiön tietoturvajohtaja Anna miettii edelleen edellisen viikon hallituksen kokousta. Toimitusjohtaja oli esittänyt kysymyksen, jonka jokainen tietoturvajohtaja kuulee nyt: ”Jos olemme jo valmistautuneet NIS2:een ja fintech-asiakkaamme kysyvät jatkuvasti DORA:sta, mitä Cyber Resilience Act muuttaa?”

Vastaus tulee hänen sähköpostiinsa.

Riippumaton tutkija ilmoittaa etähyödynnettävästä haavoittuvuudesta laiteohjelmiston päivityskomponentissa, jota käytetään yhdessä yhtiön verkkoon liitetyssä tuotteessa. Viesti sisältää PoC:n, riippuvuuden nimen ja varoituksen siitä, että vastaavaa hyväksikäyttöä on havaittu aktiivisissa tuotantoympäristöissä.

Muutamassa minuutissa kaikki tarvitsevat eri vastauksen. Teknologiajohtaja kysyy, onko haavoittuvuus todellinen. Lakitoiminto kysyy, onko EU Cyber Resilience Act -raportointivelvoite käynnistynyt. Tuotetiimi kysyy, mihin versioihin haavoittuvuus vaikuttaa. Tietoturvajohtaja kysyy, esiintyykö riippuvuus missään SBOM:ssa. Myynti kysyy, tarvitsevatko finanssialan asiakkaat DORA-näyttöä. Vaatimustenmukaisuuspäällikkö avaa ISO 27001 -riskirekisterin ja löytää haavoittuvuuksien hallintaprosessin, mutta ei selkeää päätöspolkua tuotekohtaista raportointia varten.

Tämä on CRA-valmiuden todellinen ongelma. Useimmat organisaatiot eivät lähde nollasta. Niillä on jo tietoturvapoikkeamiin reagoinnin politiikat, korjauspäivitysten hallinnan käytännöt, turvallisen kehityksen menettelyt, toimittajakatselmoinnit, haavoittuvuusskannerit ja ISO 27001 -näyttöä. CRA ei kuitenkaan palkitse irrallisia asiakirjoja. Se edellyttää nopeaa ja puolustettavaa työnkulkua, joka pystyy vastaamaan viiteen kysymykseen samanaikaisesti:

1. Onko kyse aktiivisesti hyväksikäytetystä haavoittuvuudesta tai vakavasta tuoteturvallisuuteen vaikuttavasta poikkeamasta?
2. Mitkä tuotteet, versiot, asiakkaat, riippuvuudet ja toimittajat ovat vaikutuspiirissä?
3. Mille viranomaiselle, asiakkaalle tai sopimusperusteiselle vastaanottajalle on ilmoitettava ja milloin?
4. Mikä näyttö osoittaa, että luokittelu ja priorisointi, lieventäminen ja julkistaminen olivat hallittuja?
5. Miten tämä on linjassa ISO/IEC 27001:2022:n, NIS2:n, DORA:n, GDPR:n, NIST CSF:n ja auditointiodotusten kanssa?

Vastaus ei ole erillinen ”CRA-kansio”. Vastaus on kytkeä CRA-haavoittuvuusraportointi osaksi ISMS:ää, haavoittuvuuksien koordinoidun julkistamisen prosessia, SBOM-kuria, toimittajahallintaa ja tietoturvapoikkeamiin reagoinnin näyttöketjua, joita kypsä kyberturvallisuuden hallinnointi joka tapauksessa edellyttää.

Miksi EU Cyber Resilience Act muuttaa raportointimallia

EU Cyber Resilience Act, Regulation (EU) 2024/2847, tuo tuoteturvallisuuden osaksi vaatimustenmukaisuuden valtavirtaa. Sitä sovelletaan EU:n markkinoille saatettuihin digitaalisia elementtejä sisältäviin tuotteisiin, joihin voi sisältyä verkkoon liitettyjä laitteita, ohjelmistoja, laiteohjelmistoja, sulautettuja järjestelmiä ja yritysohjelmistotuotteita.

Tietoturvajohtajien, tuoteturvallisuudesta vastaavien henkilöiden ja vaatimustenmukaisuustiimien kannalta tärkein operatiivinen muutos alkaa 11. syyskuuta 2026. CRA Article 14 edellyttää vaiheittaista raportointia aktiivisesti hyväksikäytetyistä haavoittuvuuksista ja vakavista poikkeamista, jotka vaikuttavat digitaalisia elementtejä sisältävien tuotteiden turvallisuuteen. Käytännössä valmistajien on oltava valmiita seuraaviin tilanteisiin:

Tarkka oikeudellinen arviointi on aina pätevän oikeudellisen neuvonantajan tehtävä, mutta operatiivinen johtopäätös on selvä. Ensimmäiset 24–72 tuntia onnistuvat vain siinä määrin kuin valmistelut on tehty kuukausia aiemmin.

Jos SBOM:t ovat puutteellisia, CVD-postilaatikkoa valvotaan epämuodollisesti, toimittajasopimukset eivät edellytä haavoittuvuusilmoituksia tai tietoturvapoikkeamiin reagoinnin politiikka ei erota tuotehaavoittuvuuksien raportointia tietosuojaan tai operatiivisiin poikkeamiin liittyvästä raportoinnista, oikeudellinen määräaika etenee nopeammin kuin näyttöprosessi.

Käytä ISO/IEC 27001:2022 -standardia CRA-valmiuden runkona

ISO/IEC 27001:2022 ei korvaa CRA:n oikeudellista noudattamista, mutta se on paras hallintajärjestelmän runko CRA-velvoitteiden integroimiseksi päivittäiseen hallinnointiin.

Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäisen ja ulkoisen toimintaympäristön, sidosryhmät, vaatimukset, rajapinnat muihin organisaatioihin ja ISMS:n soveltamisalan ISO/IEC 27001:2022. CRA-valmiuden kannalta tämä tarkoittaa, että ISMS:n soveltamisalan on tunnistettava digitaalisia elementtejä sisältävät tuotteet, tuotteen elinkaarivastuut, ylläpidetyt komponentit, koontiputket, avoimen lähdekoodin riippuvuudet, toimittajat, käyttäjät, maahantuojat, jakelijat, säännellyt asiakkaat ja asiaankuuluvat viranomaiset.

Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia ja riskien käsittelyä, mukaan lukien riskinomistajat, seuraukset, todennäköisyys, käsittelypäätökset, soveltuvuuslausunto ja jäännösriskin hyväksyntä. CRA-raportointia on käsiteltävä tuoteturvallisuuden riskiskenaariona kyseisessä prosessissa, ei hätätilanteessa tehtävänä oikeudellisena tulkintana.

ISO/IEC 27002:2022 ISO/IEC 27002:2022 antaa käytännön hallintakeinorakenteen. CRA-haavoittuvuusraportoinnin kannalta tärkeimmät hallintakeinot ovat:

Oppaassa Zenith Controls: vaatimustenmukaisuuksien yhteiskartoituksen opas Clarysec kartoittaa ISO/IEC 27002:2022 -hallintakeinon 8.8, teknisten haavoittuvuuksien hallinta, ennaltaehkäiseväksi hallintakeinoksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Sen attribuutit kohdistuvat kyberturvallisuuden Identify- ja Protect-toimintoihin, ja operatiivisena kyvykkyytenä on uhkien ja haavoittuvuuksien hallinta.

Tällä jäsennyksellä on merkitystä. CRA-raportoinnissa ei ole kyse vain viranomaisille ilmoittamisesta. Siinä on kyse sen osoittamisesta, että ennaltaehkäisevä haavoittuvuuksien hallinnan kyvykkyys oli olemassa jo ennen ilmoituksen saapumista.

Rakenna toimintamalli CVD:n, SBOM:n ja raportointikellon ympärille

Uskottava CRA-haavoittuvuustyönkulku alkaa ennen kuin tutkija ottaa yhteyttä. Se alkaa kyvystä vastaanottaa haavoittuvuusilmoituksia, validoida ne, tunnistaa vaikutuspiirissä olevat komponentit, arvioida hyväksikäyttö, koordinoida lieventäminen, viestiä käyttäjille ja säilyttää näyttö.

Ensimmäinen rakennuspalikka on julkinen haavoittuvuuksien raportointikanava. Clarysecin Haavoittuvuuksien koordinoidun julkistamisen politiikan toteutusvaatimusten kohta 6.1 toteaa:

Julkiset ilmoituskanavat: Organisaation tulee ylläpitää selkeää kanavaa haavoittuvuuksien raportointia varten, kuten erillistä tietoturvayhteydenottojen sähköpostiosoitetta (esimerkiksi security@company.com) tai verkkolomaketta. Tämä tieto tulee julkaista yrityksen verkkosivuston tietoturvasivulla yhdessä organisaation PGP-julkisen avaimen kanssa, jotta salatut ilmoitukset ovat mahdollisia.

Tämä ratkaisee yleisen auditointipuutteen. Monet yritykset sanovat vastaanottavansa haavoittuvuusilmoituksia, mutta ilmoituspolku on piilossa, hallitsematon tai ohjattu yleiseen tukijonoon. CRA-olosuhteissa raportointikanavasta tulee oikeudellisen tietoisuuden, vakavuusarvioinnin ja näytön talteenoton käynnistyspiste.

Toinen rakennuspalikka on luokittelu ja priorisointi. Haavoittuvuuksien koordinoidun julkistamisen politiikan toteutusvaatimusten kohta 6.4 toteaa:

Luokittelu ja hyväksyntä: Kun raportti vastaanotetaan, VRT:n tulee kirjata se ja lähettää ilmoittajalle hyväksyntä 2 arkipäivän kuluessa sekä antaa seurantaviite. VRT:n tulee tehdä alustava vakavuusarviointi, esimerkiksi CVSS-pisteytyksellä, ja validoida asia tarvittaessa IT- ja kehitystiimien tuella tavoiteaikataulussa, joka on 5 arkipäivää. Kriittiset haavoittuvuudet, kuten etäkoodin suorittamisen mahdollistavat haavoittuvuudet tai merkittävän henkilötietojen tietoturvaloukkauksen mahdollistavat haavoittuvuudet, tulee käsitellä nopeutetusti.

CRA-valmiutta varten tätä luokittelu- ja priorisointitallennetta on laajennettava kentillä, jotka tukevat oikeudellista raportointipäätöstä:

Kolmas rakennuspalikka on SBOM-kuri. Clarysecin Turvallisen kehityksen politiikan hallinnointivaatimusten kohta 5.4 toteaa:

Avoimen lähdekoodin tai kolmannen osapuolen koodin käyttö on hyväksyttävä, seurattava ja validoitava seuraavilla tavoilla: 5.4.1 ohjelmistokoostumusanalyysi (SCA) 5.4.2 lisenssikatselmointi (GPL, MIT, BSD jne.) 5.4.3 tunnettujen haavoittuvuuksien skannaus (CVE:t, OSS Index jne.)

Pienemmille organisaatioille Clarysecin Sovellusturvallisuusvaatimusten politiikka - pk-yrityksille, politiikan toteutusvaatimusten kohta 6.4.2, asettaa saman odotuksen käytännön muodossa:

Kehittäjän tai IT-palveluntarjoajan tulee ylläpitää tallennetta jokaisesta käytetystä ulkoisesta komponentista, mukaan lukien:

Tästä komponenttitallenteesta tulee vähimmäisnäyttö SBOM-ohjattua haavoittuvuuksiin reagointia varten. Sen on yhdistettävä komponentin nimi, versio, lähde, toimittaja tai tietovarasto, lisenssi, tuoteversio, koontipäivämäärä ja haavoittuvuusskannauksen tila. Kun CVE, tutkijaraportti tai toimittajailmoitus saapuu, tiimin on pystyttävä vastaamaan tunneissa: ”Mitkä julkaistut tuotteet sisältävät tämän komponentin?”

Kokoa CRA, NIS2, DORA ja GDPR yhdeksi ilmoituspäätösmatriisiksi

Cyber Resilience Act ei toimi erillään muusta sääntelystä. Yksittäinen tuotehaavoittuvuus voi käynnistää CRA-raportoinnin, NIS2-poikkeama-arvioinnin, DORA:n mukaiset asiakasnäyttövelvoitteet, GDPR-loukkausarvioinnin ja sopimusperusteiset ilmoitusvelvoitteet.

NIS2 Article 21 edellyttää, että keskeiset ja tärkeät toimijat toteuttavat asianmukaiset tekniset, operatiiviset ja organisatoriset toimenpiteet. Näihin toimenpiteisiin kuuluvat riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta, kehittäminen ja ylläpito, haavoittuvuuksien käsittely ja julkistaminen, vaikuttavuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta, MFA ja suojattu viestintä.

NIS2 Article 23 asettaa vaiheistetun poikkeamien raportointimallin: ennakkovaroitus 24 tunnin kuluessa tietoon tulemisesta, poikkeamailmoitus 72 tunnin kuluessa, välipäivitykset pyydettäessä ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta. NIS2 Article 20 luo lisäksi johdon osoitusvelvollisuuden kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se luo yhtenäisen EU:n digitaalisen operatiivisen häiriönsietokyvyn viitekehyksen finanssialan toimijoille. SaaS-palveluntarjoajille, ohjelmistotoimittajille ja ICT-toimittajille DORA näkyy usein asiakassopimusten kautta. Finanssialan asiakkaasi voi olla DORA:n mukaan säännelty toimija, mutta haavoittuvuuksien käsittelysi, SBOM-näyttösi, poikkeamatukesi, auditointioikeutesi ja ilmoitussitoumuksesi voivat olla välttämättömiä, jotta asiakas täyttää omat velvoitteensa.

GDPR lisää oman haaransa. Jos haavoittuvuus tai poikkeama aiheuttaa henkilötietojen vahingossa tapahtuvan tai lainvastaisen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai niihin pääsyn, tarvitaan henkilötietojen tietoturvaloukkauksen arviointi. GDPR Article 5 sisältää myös eheyden, luottamuksellisuuden ja osoitusvelvollisuuden, mikä tarkoittaa, että organisaation on pystyttävä osoittamaan päätöksentekonsa.

Clarysecin Tietoturvapoikkeamien hallintapolitiikka, politiikan toteutusvaatimusten kohta 6.4.1, tukee jo tätä usean sääntelykokonaisuuden arviointia:

Jos poikkeama johtaa henkilötietojen tai muiden sääntelyn alaisten tietojen vahvistettuun tai todennäköiseen altistumiseen, lakiasioiden ja DPO:n tulee arvioida seuraavien soveltuvuus: 6.4.1.1 GDPR Article 33 (72 tunnin ilmoitus valvontaviranomaiselle) 6.4.1.2 GDPR Article 34 (ilmoitus rekisteröidyille, kun korkea riski soveltuu) 6.4.1.3 NIS2 Article 23 (ilmoitus 24 tunnin kuluessa poikkeaman tietoon tulemisesta) 6.4.1.4 DORA Article 17 (vakavien ICT:hen liittyvien poikkeamien raportointi)

CRA-valmiutta varten tätä toimintapelikirjaa laajennetaan sisältämään CRA Article 14 -raportointiarviointi aktiivisesti hyväksikäytetyistä haavoittuvuuksista ja vakavista tuoteturvallisuuteen vaikuttavista poikkeamista.

Yhtenäinen päätösmatriisi estää tiimejä käyttämästä erillisiä ja keskenään ristiriitaisia raportoinnin toimintapelikirjoja:

Pk-yrityksille Clarysecin Tietoturvapoikkeamien hallintapolitiikka - pk-yrityksille, hallinnointivaatimusten kohta 5.3.2, antaa saman periaatteen yksinkertaisemmassa muodossa:

Reagoinnin aikataulut, mukaan lukien tietojen palautus ja ilmoitusvelvoitteet, tulee dokumentoida ja sovittaa lakisääteisiin vaatimuksiin, kuten GDPR:n 72 tunnin henkilötietojen tietoturvaloukkauksen ilmoitusvaatimukseen.

CRA-valmius vain laajentaa tämän periaatteen henkilötietojen tietoturvaloukkauksen ilmoittamisesta tuotehaavoittuvuuksien ja tuoteturvallisuuspoikkeamien raportointiin.

Toimittajan näyttö on nyt tuoteturvallisuuden näyttöä

Monet CRA:n kannalta merkitykselliset haavoittuvuudet ovat lähtöisin oman koodipohjan ulkopuolelta. Ne voivat tulla avoimen lähdekoodin paketeista, laiteohjelmistomoduuleista, SDK:ista, ylläpidetyistä ohjelmointirajapinnoista, koontityökaluista, pilvipalveluista, alihankituista komponenteista tai ylävirran kirjastoista. Siksi toimittajahallinta on keskeistä CRA-valmiudessa.

ISO 27001:2022 -standardin kohta 8.1 edellyttää, että organisaatiot hallitsevat ulkoisesti tuotettuja prosesseja, tuotteita tai palveluja, jotka ovat ISMS:n kannalta merkityksellisiä. ISO/IEC 27002:2022 -hallintakeino 5.21, tietoturvan hallinta ICT-toimitusketjussa, tarjoaa hallintakeinoankkurin.

Zenith Controls -oppaassa Clarysec kartoittaa hallintakeinon 5.21 ennaltaehkäiseväksi hallintakeinoksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Sen operatiivinen kyvykkyys on toimittajasuhteiden turvallisuus, ja sen osa-alueisiin kuuluvat hallinnointi, ekosysteemi ja suojaus. Asia on yksinkertainen: toimittajahallintakeinot eivät ole hankinnan paperityötä. Ne ovat ekosysteemin suojaushallintakeinoja.

Clarysecin Kolmansien osapuolten ja toimittajaturvallisuuden politiikka - pk-yrityksille, hallinnointivaatimusten kohta 5.3, asettaa sopimusperustan:

Sopimuksiin tulee sisällyttää pakolliset lausekkeet, jotka kattavat:

Yritysohjelmissa Zenith Blueprint: auditoijan 30 vaiheen tiekartta, Controls in Action -vaihe, vaihe 23, organisatoriset kontrollit 5.19–5.37, selittää ISO/IEC 27002:2022 -hallintakeinon 5.20, tietoturvan huomioiminen toimittajasopimuksissa:

Kun kyse on toimittajista, luottamus ei voi perustua oletuksiin. Se on kirjattava sitovasti.

CRA-valmiutta varten toimittajasopimuksiin on sisällytettävä tuoteturvallisuuslausekkeita, jotka tukevat nopeaa haavoittuvuuksiin reagointia:

DORA vahvistaa samaa suuntaa. Finanssialan toimijoiden on hallittava ICT-kolmansien osapuolten riskiä, ylläpidettävä rekistereitä ICT-palvelusopimuksista, arvioitava kriittisyys, tehtävä due diligence -arvioinnit, hallittava keskittymäriskiä, määritettävä sopimukselliset suojatoimet, turvattava auditointioikeudet ja suunniteltava irtautumiset. Jos myyt ohjelmistoja tai ICT-palveluja finanssialan toimijoille, asiakkaat tulevat kysymään, voiko haavoittuvuusraportointisi ja SBOM-prosessisi tukea heidän DORA:n mukaisia poikkeama-, häiriönsietokyky- ja kolmannen osapuolen näyttötarpeitaan.

Clarysecin CRA-valmiuden työnkulku

Clarysec auttaa asiakkaita viemään CRA-raportoinnin käytäntöön ISO 27001:2022 -yhteensopivan ISMS:n sisällä käytännöllisen työnkulun avulla.

1. Lisää CRA-velvoitteet ISMS:n vaatimusrekisteriin

Aloita ISO 27001:2022 -standardin kohdista 4.1–4.4. Päivitä organisaation toimintaympäristö, sidosryhmät ja soveltamisala kattamaan digitaalisia elementtejä sisältävät tuotteet, EU-markkina-altistus, käyttäjät, maahantuojat, jakelijat, sääntelyviranomaiset, CSIRT:t, toimittajat ja säännellyt asiakkaat.

Luo vaatimusrekisteriin merkinnät CRA-haavoittuvuusraportoinnista, CRA:n mukaisesta vakavien tuoteturvallisuuspoikkeamien raportoinnista, NIS2-poikkeamailmoituksista, DORA:n mukaisista asiakastukivelvoitteista, GDPR:n mukaisesta henkilötietojen tietoturvaloukkauksen arvioinnista, sopimusperusteisesta poikkeamailmoituksesta, CVD-sitoumuksista ja tutkijaviestinnästä.

Tämä antaa auditoijille jäljitettävän polun ulkoisesta velvoitteesta sisäiseen hallintakeinoon.

2. Luo tuotehaavoittuvuuksien vastaanottolomake

Perusta vastaanottolomake Haavoittuvuuksien koordinoidun julkistamisen politiikkaan. Sen tulee kerätä ilmoittajan henkilöllisyys, turvalliset yhteystiedot, tuoteversio, moduuli, ympäristö, PoC, toistovaiheet, hyväksikäytön tila, mahdollinen tietojen altistuminen, palveluvaikutus, SBOM-komponenttiosuma, CVSS tai vastaava vakavuus, omistaja, seurantaviite ja sääntelytarkistuspiste.

Lomakkeen tulee automaattisesti luoda tiketti haavoittuvuuksiin reagoinnin jonoon. Sen tulee myös käynnistää ilmoituspäätöksen ajastin, vaikka lopullinen vastaus olisi ”ei ilmoitusvelvollinen”.

3. Kytke SBOM-tiedot julkaisuihin

Ylläpidä jokaisesta julkaistusta tuoteversiosta SBOM:ia tai vastaavaa komponenttiluetteloa. Vähimmäistasolla hyödyllinen näyttö sisältää komponentin nimen, version, lähteen, lisenssin, toimittajan tai tietovaraston, tuoteversion, koontipäivämäärän ja haavoittuvuusskannauksen tilan.

Turvallisen kehityksen politiikka ja Sovellusturvallisuusvaatimusten politiikka - pk-yrityksille antavat politiikkaperustan SCA:lle, komponenttikatselmoinnille ja ulkoisten komponenttien tallenteille.

4. Säilytä näyttö ensimmäisestä päivästä alkaen

Jokaisessa CRA:n kannalta merkityksellisessä haavoittuvuustiketissä tulee säilyttää:

• Alkuperäinen ilmoitus
• Hyväksynnän aikaleima
• Luokittelu- ja priorisointimuistiinpanot
• CVSS- tai vastaavan vakavuuden perustelut
• SBOM-osumatulokset
• Hyväksikäytön arviointi
• Lokit, indikaattorit ja forensiset tilannevedokset
• Toimittajaviestintä
• Riskin hyväksyntä, jos lieventäminen viivästyy
• Korjauspäivityssuunnitelma, julkaisutiedotteet ja testausnäyttö
• Asiakas- ja viranomaisilmoituksia koskevat päätökset
• Loppuraportin syötteet ja opit

Tämä on linjassa ISO 27001:2022 -standardin kohdan 8.1 kanssa, joka edellyttää riittävää dokumentoitua tietoa osoittamaan, että prosessit toimivat suunnitellusti, sekä kohtien 8.2 ja 8.3 kanssa, jotka edellyttävät dokumentoituja riskien arvioinnin ja riskien käsittelyn tuloksia.

5. Testaa realistisella riippuvuusskenaariolla

Järjestä pöytäharjoitus, jossa käytetään simuloitua aktiivisesti hyväksikäytettyä riippuvuushaavoittuvuutta. Ota mukaan ohjelmistokehitys, tietoturva, lakitoiminto, tietosuoja, tuote, viestintä, toimittajahallinta ja asiakasrajapinnan tiimit. Testin tulee osoittaa, että organisaatio pystyy tunnistamaan vaikutuspiirissä olevat versiot, arvioimaan hyväksikäytön, tekemään ilmoituspäätöksen, ottamaan yhteyttä toimittajiin, laatimaan käyttäjäohjeistuksen ja säilyttämään näytön.

Miten auditoijat testaavat CRA-haavoittuvuusraportoinnin valmiutta

CRA-valmiuden arviointi rajoittuu harvoin CRA-tarkistuslistaan. Eri auditoijat testaavat samaa näyttöä eri viitekehysten kautta.

Zenith Controls -oppaassa Clarysec kartoittaa ISO/IEC 27002:2022 -hallintakeinon 5.24, tietoturvapoikkeamien hallinnan suunnittelu ja valmistelu, korjaavaksi hallintakeinoksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se kohdistuu Respond- ja Recover-toimintoihin, ja sen operatiivisia kyvykkyyksiä ovat hallinnointi ja tietoturvatapahtumien hallinta.

Tämä hallintakeino on silta haavoittuvuuden havaitsemisen ja sääntelyraportoinnin välillä.

NIST CSF 2.0 on erityisen hyödyllinen hallitustason viestintäkerroksena. Sen GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-toiminnot auttavat selittämään, miten tuotehaavoittuvuuksien raportointi kuuluu yrityksen kyberturvallisuuden hallinnointiin eikä ole erillinen tuotekehityksen poikkeus.

Yleiset CRA-valmiuden puutteet, jotka on korjattava ennen vuotta 2026

Clarysec näkee toistuvasti samoja puutteita.

Ensimmäinen on CVD ilman raportointia. Yrityksellä on tietoturvasähköpostiosoite tai security.txt-tiedosto, mutta ei sisäistä polkua tutkijaraportista oikeudellisen ilmoitusvelvollisuuden arviointiin.

Toinen on SBOM ilman omistajuutta. Ohjelmistokehitys pystyy tuottamaan SBOM:n koontivaiheessa, mutta kukaan ei omista julkaistujen tuotteiden tarkkuutta tai selitä, miten SBOM-havainnot syöttävät haavoittuvuuksiin reagointia.

Kolmas on ISO-sertifikaatti ilman tuotesoveltamisalaa. ISMS kattaa yrityksen IT:n ja SaaS-tuotannon, mutta ei sulautettuja ohjelmistoja, laiteohjelmistoja, tuotepäivitysinfrastruktuuria, koontiputkia tai haavoittuvuuksien julkistamista.

Neljäs on toimittajasopimukset ilman haavoittuvuuslausekkeita. Hankinta edellyttää luottamuksellisuutta ja tietosuojaa, mutta ei haavoittuvuusilmoituksia, komponenttien läpinäkyvyyttä, poikkeamatukea, koordinoitua julkistamista tai auditointinäyttöä.

Viides on tietoturvapoikkeamiin reagointi ilman tuotehaavoittuvuuslogiikkaa. Poikkeamasuunnitelma kattaa kiristyshaittaohjelmat, tietojenkalastelun ja henkilötietojen tietoturvaloukkaukset, mutta ei aktiivisesti hyväksikäytettyjä tuotehaavoittuvuuksia, joissa asiakkaiden järjestelmät voivat olla vaarassa ennen kuin valmistajan oma ympäristö on vaarantunut.

Kuudes on DORA-asiakasnäytön manuaalinen käsittely. Myynti tai asiakasmenestys vastaa finanssialan kyselyihin tapauskohtaisesti, kun taas tietoturvalta puuttuu vakiomuotoinen näyttöpaketti haavoittuvuuksien käsittelystä, SBOM-hallinnoinnista, poikkeamatuesta ja toimittajahallintakeinoista.

Jokainen puute on korjattavissa. Jokainen niistä tulee kalliiksi, jos se havaitaan käynnissä olevan haavoittuvuuden aikana.

90 päivän tarkistuslista CRA-haavoittuvuusraportoinnin valmiuteen

Käytä seuraavat 90 päivää puolustettavan perustan luomiseen:

• Tunnista digitaalisia elementtejä sisältävät tuotteet, jotka on saatettu tai asetettu saataville EU:n markkinoilla.
• Päivitä ISMS:n soveltamisala ja sidosryhmäanalyysi kattamaan CRA-sidosryhmät.
• Lisää CRA Article 14 -raportointiarviointi lakisääteisten ja sääntelyvaatimusten rekisteriin.
• Julkaise ja valvo turvallista haavoittuvuuksien raportointikanavaa.
• Perusta haavoittuvuuksiin reagointitiimi, jossa on lakitoiminnon, tuotteen, ohjelmistokehityksen, tietoturvan ja viestinnän roolit.
• Ylläpidä SBOM:eja tai komponenttiluetteloita julkaistuista tuoteversioista.
• Kytke SCA-tulokset haavoittuvuustiketteihin ja tuotejulkaisuihin.
• Lisää aktiivisen hyväksikäytön ja vakavan tuotepoikkeaman kriteerit luokittelu- ja priorisointilomakkeisiin.
• Luo yhdistetty CRA-, NIS2-, DORA-, GDPR- ja sopimusperusteinen ilmoituspäätösmatriisi.
• Päivitä toimittajasopimuksiin haavoittuvuusilmoitusta, SBOM:ia, poikkeamatukea ja julkistamisen koordinointia koskevat lausekkeet.
• Ylläpidä korjauspäivityslokeja ja korjaavien toimenpiteiden näyttöä.
• Testaa työnkulku simuloidulla aktiivisesti hyväksikäytetyllä riippuvuushaavoittuvuudella.
• Esitä tulokset johdolle sisältäen puutteet, jäännösriskit ja korjaavien toimenpiteiden omistajat.
• Lisää näyttöpaketti sisäiseen tarkastukseen ja johdon katselmukseen.

Clarysecin Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yrityksille, politiikan toteutusvaatimusten kohta 6.2.1, tukee seurannan perustaa:

IT-toiminnon tulee seurata haavoittuvuuksia käyttämällä:

Saman politiikan hallinnointivaatimusten kohta 5.4.1 lisää auditointijäljen:

Korjauspäivityslokia tulee ylläpitää ja katselmoida auditointien ja tietoturvapoikkeamiin reagoinnin aikana

Tästä korjauspäivityslokista voi tulla yksi CRA-loppuraportin tärkeimmistä artefakteista. Se osoittaa havaitsemisen, priorisoinnin, korjaamisen, testauksen ja sulkemisen.

Tee syyskuusta 2026 rutiininomainen

Paras CRA-raportointitapahtuma ei ole helppo siksi, että haavoittuvuus on yksinkertainen. Se on helppo siksi, että organisaatio on jo harjoitellut työnkulun.

Ennen syyskuuta 2026 Clarysec voi auttaa muuttamaan haavoittuvuusraportoinnin auditointivalmiiksi järjestelmäksi kartoittamalla nykyisen ISO 27001:2022 -ISMS:si, CVD-prosessisi, SBOM-kyvykkyytesi, toimittajalausekkeesi ja tietoturvapoikkeamiin reagoinnin toimintapelikirjasi suhteessa CRA-, NIS2-, DORA-, GDPR- ja NIST CSF -odotuksiin.

Aloita kohdennetulla CRA-haavoittuvuusraportoinnin valmiusarvioinnilla. Clarysec katselmoi politiikkasi, SBOM-näyttösi, toimittajasopimuksesi, haavoittuvuustikettisi, poikkeamien toimintapelikirjasi ja auditointijälkesi. Sen jälkeen käytämme Zenith Blueprint- ja Zenith Controls -kokonaisuuksia käytännöllisen korjaavien toimenpiteiden tiekartan rakentamiseen, ei teoreettisen vaatimustenmukaisuuskansion kokoamiseen.

Jos käytät jo Clarysecin politiikkoja, viritämme ne CRA-raportointia varten. Jos et käytä, voimme auttaa ottamaan käyttöön oikean politiikkakokonaisuuden, mukaan lukien Haavoittuvuuksien koordinoidun julkistamisen politiikka, Turvallisen kehityksen politiikka, Tietoturvapoikkeamien hallintapolitiikka, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yrityksille, Sovellusturvallisuusvaatimusten politiikka - pk-yrityksille ja Kolmansien osapuolten ja toimittajaturvallisuuden politiikka - pk-yrityksille soveltuvin osin.

Syyskuu 2026 on riittävän lähellä suunnittelua varten ja riittävän kaukana kurinalaista valmistautumista varten. Organisaatiot, jotka toimivat nyt, eivät kysy ensimmäisten 24 tunnin aikana: ”Kuka omistaa tämän haavoittuvuuden?” Niillä on jo vastaus, näyttö ja raportointipolku.

Ota yhteyttä Claryseciin ja sovi CRA-haavoittuvuusraportoinnin valmiusarviointi, jotta sääntelyn monimutkaisuudesta tulee puolustettava tuoteturvallisuuden kilpailuetu.