CRA: poikkeamiin reagointi ja raportoinnin harjoittelu

11. syyskuuta 2026 lähtien CRA:n piiriin kuuluvien valmistajien on ilmoitettava aktiivisesti hyväksikäytetyistä haavoittuvuuksista ja vakavista poikkeamista, jotka vaikuttavat digitaalisia elementtejä sisältävien tuotteiden turvallisuuteen. Ennakkovaroitus on annettava 24 tunnin kuluessa tiedon saamisesta ja täydellinen ilmoitus 72 tunnin kuluessa.

Keskeinen toiminnallinen riski ei ole lomakkeen puuttuminen. Se on sovitun T0-hetken, päätöksen omistajan, varahenkilöiden, luotettavien tietolähteiden ja tapahtuman luokittelua perustelevan kirjauksen puuttuminen.

Ilmoittamisen aikataulu

Vaihe	Määräaika	Mitä hallitaan
Tiedon saaminen	T0	aikaleima, tietolähde ja tiedon vastaanottaja
Ennakkovaroitus	24 tunnin kuluessa	CRA:n/SRP:n tässä vaiheessa vaatimat tiedot
Täydellinen ilmoitus	72 tunnin kuluessa	tapahtuman ja vaikutusten lisätiedot
Loppuraportti — aktiivisesti hyväksikäytetty haavoittuvuus	viimeistään 14 päivää korjaavan toimen saataville tulon jälkeen	korjaaminen ja käsittelyn tulos
Loppuraportti — vakava poikkeama	1 kuukauden kuluessa 72 tunnin ilmoituksesta	poikkeaman kulku, vaikutukset, toimet ja tulos

Tarkista aina CRA:n yhteisen ilmoitusalustan ajantasaiset ohjeet. Toimintaohjeet ja portaali voivat kehittyä nopeammin kuin itse asetus.

Kaikki haavoittuvuudet eivät käynnistä 14 artiklan ilmoittamista

CRA viittaa aktiivisesti hyväksikäytettyyn haavoittuvuuteen, ei jokaiseen skannerin tuottamaan havaintoon. Samoin ”vakava poikkeama” on sääntelyn käsite eikä synonyymi mille tahansa korkean prioriteetin tietoturvatiketille.

Hyvä työnkulku erottaa seuraavat vaiheet:

1. havaitseminen tai tiedon vastaanottaminen;
2. tekninen ensiarvio;
3. sääntelyn kriteerien arviointi;
4. vastuullisen henkilön päätös;
5. ilmoituksen valmistelu;
6. toimittaminen oikean kanavan kautta;
7. korjaaminen, seuranta ja loppuraportti.

Havainnon automaattinen merkitseminen ”CRA:n mukaan ilmoitettavaksi” ilman ihmisen hyväksyntää aiheuttaa sekä aiheettomien ilmoitusten että ilmoittamatta jäävien tapahtumien riskin.

Määritä vastuut ennen määräajan alkamista

Rooli nimeltä ”tietoturvatiimi” ei riitä. Määritä kullekin tuotteelle:

• kuka vastaanottaa tiedot haavoittuvuuksista tai poikkeamista;
• kuka tekee teknisen ensiarvion;
• tuotteen omistaja;
• kuka hyväksyy sääntelyn mukaisen luokittelun;
• kuka tekee ilmoituksen SRP:ssä;
• varahenkilö kullekin aikakriittiselle roolille;
• tuotteen ja toimintamallin edellyttämä eskalointireitti työajan ulkopuolella.

Jos yhdellä henkilöllä on useita rooleja, kirjaa se selvästi. Pieni tiimi voi toimia; epäselvä vastuunjako ei.

Mitä kirjataan T0-hetkellä

Luo ensimmäinen merkintä ennen kuin keskustelu siirtyy siihen, onko tapahtuma ”todella vakava”. Säilytä vähintään:

• tarkka tiedonsaantihetki;
• tiedon lähde;
• tuote ja versio;
• ilmoittaja tai havainnut järjestelmä;
• tiivis kuvaus havainnosta;
• tiedon vastaanottanut henkilö;
• linkki alkuperäiseen aineistoon tai näyttöön.

Ilman tätä merkintää organisaatio ei ehkä useita tunteja myöhemmin pysty määrittämään, milloin oikeudellinen määräaika todella alkoi.

Käytännön toimintaketju

1. Rekisteröi

Avaa tapaus ja säilytä alkuperäinen ilmoitus. Älä kirjoita lähteen päälle ymmärryksen tarkentuessa.

2. Tee ensiarvio

Vahvista kyseinen tuote, versio, tekninen laajuus, tunnetut vaikutukset ja saatavilla oleva näyttö. Erota vahvistetut tosiasiat oletuksista.

3. Luokittele

Kirjaa perusteet ilmoittamiselle ja sitä vastaan. Päätöksessä pitäisi näkyä hyväksyjä ja hyväksymishetki.

4. Toimita 24 tunnin varoitus

Valmistele ennakkovaroitus sillä hetkellä saatavilla olevista tiedoista. Älä odota valmista juurisyyanalyysia, kun oikeudellinen määräaika on jo käynnissä.

5. Toimita 72 tunnin ilmoitus

Täydennä ajantasaisen SRP-prosessin vaatimat tiedot.

6. Korjaa ja viesti

Liitä tekninen työ, julkaisut, tietoturvapäivitykset ja asiakasviestintä samaan tapaukseen.

7. Viimeistele loppuraportti

Sulje työnkulku vasta, kun tulos, toimet, todentava näyttö ja vaadittu loppuraportti on kirjattu.

Harjoittele prosessia ennen todellista tapahtumaa

Käytä yhtä realistista mutta kuvitteellista tilannetta ja varmista:

• tiimi tietää, missä merkintä luodaan;
• T0 voidaan tunnistaa;
• hyväksyvä henkilö tunnetaan;
• varahenkilöt on määritetty;
• tuotteen tiedot ja lokit voidaan kerätä nopeasti;
• ilmoituksen tekevällä henkilöllä on toimiva SRP-pääsy;
• harjoituksesta jää päätösmerkintä ja parannustoimia.

Pulsar GRC:n rooli

Pulsar voi yhdistää poikkeaman tai haavoittuvuuden riskeihin, toimenpiteisiin, omistajiin, asiakirjoihin, näyttöön, raportteihin ja päätöshistoriaan. Riskit, tehtävät, asiakirjat, näyttö ja raportit säilyttävät vastausten ja päätösten asiayhteyden.

Organisaatiosi arvioi 14 artiklan soveltumisen, hyväksyy ilmoituksen ja toimittaa sen SRP:hen asianmukaisen kanavan kautta. Merkintöjen valmistelu Pulsarissa ei korvaa ilmoituksen toimittamista.

Tutustu Pulsar GRC:hen toiminnallisen työnkulun kautta

Aiheeseen liittyvät oppaat

• SBOM CRA:n yhteydessä
• CRA:n tekninen dokumentaatio
• Takaisin CRA-oppaaseen

Kuvitteellinen tapahtuma epäselvällä alkuviestillä

Perjantaina kello 16.40 tuotevastuuhenkilö saa ilmoituksen, jonka mukaan asiakkaan käyttämän komponentin haavoittuvuutta on ehkä hyödynnetty. Viestissä on lokikatkelma ja yksi versionumero, mutta laiteluettelo puuttuu. Tämä on harjoitustilanne. Tiimin tulee säilyttää alkuperäinen tieto ennen lopullisen syyn etsimistä. Myöhempi tekstin korvaaminen voi hävittää tärkeän aikajäljen.

Ensimmäinen merkintä erottaa ilmoittajan väitteen, vahvistetun havainnon ja oletuksen. ”Ilmoittaja kertoo hyväksikäytöstä” ei tarkoita samaa kuin ”valmistaja vahvisti hyväksikäytön”. Molemmat voivat olla tärkeitä aikajanassa. Säilytä, kuka sai tiedon, milloin ja mitä hän tiesi. Näin tietoisuutta voidaan arvioida asiayhteydessä muistin varaan jäämisen sijaan.

Tekninen arvio tarvitsee yhteyden tuotteeseen

Selvitä tuotteet ja julkaisut, joissa komponentti esiintyy. SBOM voi auttaa, mutta sen on koskettava todella toimitettua julkaisua. Kirjasto lähdekoodissa ei aina tarkoita, että ongelmallinen toiminto on käytettävissä tuotteessa. Pätevän teknisen arvioijan tulee näyttää, mitä tiedot vahvistavat ja mitä vielä tutkitaan.

Älä odota täydellistä portfoliokartoitusta ennen ensimmäistä eskalointia. Määritä henkilö arvioimaan ilmoituskriteerejä ja toinen kokoamaan tuotetietoja. Työ voi edetä rinnakkain. Näytä riippuvuudet, jotta yksi avoin yksityiskohta ei pysäytä kaikkia tehtäviä ilman perustetta. Aikakriittinen työ tarvitsee tietoisia päätöksiä, ei oletusta siitä, että joku muu jatkaa.

Säilytä aikajanan muutokset

Alkuperäinen saapumisaika, ensimmäinen arvio, luokittelupäätös ja ulkoinen ilmoitus ovat eri tapahtumia. Pidä ne erillään. Sisäisen työpyynnön luontiaika ei välttämättä ole oikeudellisesti merkityksellinen tietoisuuden alkuaika. Arvioi ero pätevästi ja säilytä peruste. Uusi tekninen tieto ei saa poistaa aiempaa historiaa.

Käytä johdonmukaista aikavyöhykettä. Jos lähteet näyttävät paikallista aikaa, kirjaa muunnoksen perusta. Vastuuhenkilön pitää voida selittää valittu hetki. Oikeudellinen määräaika arvioidaan asetuksesta ja voimassa olevista virallisista ohjeista. Tämän esimerkin kellonaika ei ole automaattinen yleissääntö kaikille tapahtumille.

Ilmoitusluonnoksen laadun tarkastus

Ennen esittämistä tarkista tuote, tapahtuman kuvaus, tunnettu vaikutus, aikamerkinnät ja kontakti. Väitteellä on oltava lähde tai selvä merkintä alustavasta arviosta. Puuttuvaa tietoa ei täytetä varmalla oletuksella. Käytä kullakin ilmoitusvaiheella käytettävissä olevaa ja asianmukaisesti tarkastettua tietoa vaatimusten mukaisesti.

Sovi, miten hyväksyjä näkee ensimmäisen luonnoksen jälkeen tehdyt muutokset. Jos tekninen tiimi tarkentaa versioiden laajuutta, muutos pitää tuoda ilmoituksen omistajalle. Yhteinen asiakirja voi muuten jättää epäselväksi, mikä versio hyväksyttiin. Säilytä hyväksytty versio ja sen tarkastuksen jälki erikseen.

Lähettäminen tarvitsee oman todisteen

Sisäisessä järjestelmässä valmisteltu merkintä ei ole viranomaisilmoituksen lähettäminen. Vastuuhenkilö käyttää virallista kanavaa ja säilyttää sopivan vastaanottovahvistuksen. Tarkista, hyväksyttiinkö lähetys ja pyydettiinkö lisätietoa. Tila ”luonnos valmis” ja tila ”ilmoitus lähetetty” tarkoittavat eri asiaa.

Älä lisää GRC-merkintään portaalin salaisia tunnistetietoja. Tallenna ilmoituksen tunnus, tarvittava vahvistus ja vastuun rooli. Jos hyväksyjä puuttuu, sijaisen reitin pitää olla sovittu aiemmin. Kiire ei ole sopiva hetki selvittää, kenellä on oikeus tehdä yrityksen ulkoinen päätös.

Korjaus ja asiakkaalle annettava ohje

Yhdistä tekninen korjaus muutokseen, julkaisuun ja testitulokseen. Asiakasviestissä erotetaan väliaikainen lievennys ja lopullinen korjaus. Jos käyttäjän pitää toimia, anna tarkastettu ohje rajauksineen. Oikein laadittu ilmoitus ei osoita, että käyttäjä sai päivityksen tai pystyi asentamaan sen.

Tiedon jakamisen laajuus pitää arvioida erikseen. Sisäisen analyysin yksityiskohdat eivät välttämättä ole sama sisältö kuin ulkoinen viesti. Säilytä aineistot erottuvina ja määritä hyväksyjä. Laajin olemassa oleva kansiolinkki ei ole peruste antaa kaikkia teknisiä tietoja jokaiselle vastaanottajalle.

Valmistele loppuraporttia työn aikana

Kerää korjauksen valmistumisen ja saatavuuden ajat, testit, vaikutusarvion tarkennukset ja asiakasviestinnän jälki. Näin loppuraportti syntyy todellisesta työstä eikä uudesta historian palautuksesta. Jos johtopäätös jäi epävarmaksi, säilytä raja ja kerro, mitä organisaatio pystyi vahvistamaan.

Sulkemisen arvioija tarkistaa sekä sisäiset tehtävät että ulkoiset ilmoitusvaiheet. Yhden tehtävän valmistuminen ei päätä koko tapausta. Seuranta tai asiakkaan lisätoimi voi jäädä avoimeksi perustellusti. Näytä omistaja, määräaika ja seuraava päätöspiste, jotta työ ei huku yleiseen suljettuun tilaan.

Hyväksymistesti sijaisen kanssa

Toista harjoitus ilman pääkontaktia. Sijaisen pitää löytää tuotetieto, aikajana, luokittelun vastuuhenkilö ja virallisen lähettämisen järjestely. Mittaa aika tarkastettuun tulokseen, mutta katso myös väärät versiot ja oletukset. Nopea väärä luokittelu ei ole onnistuminen. Harjoitus ei sisällä keksityn tapahtuman lähettämistä oikeaan kanavaan.

Määritä löydöistä tehtävät. Jos pääsy toimii mutta julkaisuja ei tunnisteta, korjaa tuotetietoa. Jos tiedot ovat kunnossa mutta hyväksyjä puuttuu, korjaa sijaisten järjestely. Pulsar voi yhdistää työn ja päätökset. Oikeudellinen arvio, tekninen analyysi sekä oikean ilmoituksen esittäminen jäävät organisaation vastuulle.

Ilmoitusharjoituksen tarkastuskortti

Vaihe	Odotettu näyttö	Puutteen mekanismi
Ensimmäinen tieto	lähde, sisältö ja vastaanottoaika säilyvät	muisti korvaa alkuperäisen viestin
Tuoteyhteys	julkaisu ja kokoonpano on tunnistettu	vaikutus liitetään väärään versioon
Luokittelu	faktat, oletukset ja päätös erottuvat	skannerin osuma muuttuu oikeudelliseksi väitteeksi
Hyväksyntä	hyväksyjä ja ilmoitusversio näkyvät	muuttunut teksti lähetetään ilman tarkastusta
Esittäminen	oikean kanavan vastaanottovahvistus löytyy	valmis luonnos sekoittuu tehtyyn ilmoitukseen
Jälkityö	korjaus, testi ja loppuraportti on määrätty	tapaus suljetaan ensimmäisen tehtävän jälkeen

Sovi harjoituksen vetäjälle erillinen havaintoluettelo. Hänen pitää näyttää, missä vaiheessa tietoa puuttui ja miten tiimi reagoi. Yleinen arvio ”onnistui hyvin” ei ohjaa korjausta. Jos väärä julkaisu valittiin, selvitä lähteen syy. Jos sijainen ei saanut pääsyä, korjaa oikeus ja testaa juuri sama vaihe uudelleen.

Sama tapahtuma voi tulla useasta kanavasta

Tekninen tiimi saa tiedon keskustelussa ja turvakontakti sähköpostissa. Yhdistä viestit samaan tapaukseen, mutta säilytä niiden omat ajat sekä sisältö. Duplikaatin poistaminen ei saa hävittää tietoisuuden arvioon tarvittavaa historiaa. Yksi yhteinen tapaus voi sisältää useita alkuperäisiä lähteitä ilman niiden merkityksen katoamista.

Jos tieto muuttuu, lisää uusi tapahtuma aikajanaan. Esimerkiksi ensimmäinen viesti koski yhtä asiakasta ja uusi tieto useaa tuotetta. Säilytä, mitä päätettiin aiemmalla tiedolla ja mikä käynnisti uuden arvioinnin. Päätöksen korvaaminen ilman historiaa voi näyttää myöhemmin siltä, että tiimi tiesi alusta asti enemmän kuin se todella tiesi.

Myös kielteinen ilmoituspäätös tarvitsee perustan

Kun tiimi päättää, etteivät kriteerit täyty, tallenna arvioidut faktat ja hyväksyjä. Tämä ei tarkoita pitkää oikeudellista muistioa jokaiseen pieneen osumaan. Merkinnän tulee silti kertoa, miksi päätös tehtiin. Uusi olennainen tieto voi vaatia uuden tarkastuksen, joten päätös ei saa sulkea myöhempää tiedon käsittelyä pois.

Erota tekninen prioriteetti ja oikeudellinen luokittelu. Kiireellinen korjaus voi olla tarpeen myös ilman tietyn ilmoituskriteerin täyttymistä. Vastaavasti ilmoitusvaiheen työ ei korvaa tuotteen teknistä korjausta. Yksi kiireellisyysnumero ei riitä näiden eri tehtävien ohjaukseen, ellei merkinnässä näy niiden peruste ja omistaja.

Harjoittele tiedon laadun puutetta

Lisää kokeeseen ristiriitainen versionumero ja puuttuva lokin aikavyöhyke. Tiimin tulee merkitä epävarmuus, hakea vahvistus ja jatkaa muita tehtäviä perustellusti. Tavoite ei ole ratkaista kaikki välittömästi vaan ohjata oikea työ oikealle tekijälle. Arvioijan pitää erottaa vahvistettu ja vielä avoin sisältö ennen ulkoista käyttöä.

Lisää myös yksi sivullisen asiakkaan lokikatkelma. Vastuun tulee tunnistaa, ettei sitä anneta kaikille vastaanottajille sellaisenaan. Säilytä tarpeellinen tekninen merkitys ja määritä sopiva rajaus. Tietosuojan ja luottamuksellisuuden arvio ei saa kadota kiireellisen raportin taakse, mutta se ei saa myöskään muuttua tekosyyksi jättää tarpeellista ilmoitusta tekemättä.

Tallenna ulkoisen viestin versio

Sisäisen analyysin päivitys ei automaattisesti muuta jo esitettyä ilmoitusta. Säilytä lähetetty sisältö, vastaanottovahvistus ja myöhemmän lisätiedon jälki. Näin voidaan selittää, mitä ulkoinen vastaanottaja tiesi kussakin vaiheessa. Pelkkä nykyinen yhteenveto ei vastaa tähän kysymykseen, jos tapaus muuttui työn aikana.

Harjoituksen nopeutta ei pidä luvata oikean tapahtuman vasteeksi. Valmiiksi annettu aineisto ja tuttu tilanne helpottavat koetta. Todellinen tapahtuma voi sisältää poissaolon, ristiriidan tai puuttuvan teknisen datan. Raportoi saavutettu kyky ja kokeen rajat. Tämä antaa päätökselle paremman perustan kuin yksi näyttävä harjoitusaika ilman selitystä.

Päätä seuraava tarkastus löydön perusteella

Jos ongelma oli tuoteversiossa, seuraava koe tarkastaa uuden tuoterekisterin. Jos ongelma oli hyväksyjän saatavuudessa, kokeile sijaisen reittiä. Älä toista koko helppoa harjoitusta vain onnistumisen vahvistamiseksi. Kohdennettu uusi koe näyttää, korjasiko tiimi havaitun mekanismin. Pulsar voi pitää nämä tehtävät ja tulokset yhteydessä samaan harjoitustapaukseen.

Harjoittele poikkeamaa lähettämättä todellista viranomaisilmoitusta

Valitse kuvitteellinen tuote, jonka harjoituksen oletetaan kuuluvan CRA:n soveltamisalaan. Jos esimerkki sisältää SaaS:n tai taustajärjestelmän, dokumentoi, miksi se on olennainen kyseiselle tuotteelle. Älä oleta, että kaikki vain selainpalvelut kuuluvat CRA:n piiriin. Käytä virka-ajan ulkopuolella saatua synteettistä ilmoitusta, teknistä havaintoa ja päätöstä, joka vaatii valtuutetun arvioijan.

Merkitse muistiin, kun harjoituksen osallistujat tiedostavat tosiasiat, ja erota tämä kohta ilmoituksen kirjaamisesta. Nimeä tutkija, päätöksen omistaja ja sijainen. Seuraa, mitkä tosiasiat on vahvistettu ja mitkä jäävät tarkastettavaksi. 14 artiklan määräajat liittyvät sovellettaviin tietoisuus- ja raportointiehtoihin, eivät pelkästään siihen aikaan, jolloin johtaja sattuu avaamaan hakemuksen.

Pidä aktiivisesti hyödynnetty haavoittuvuushaara erillään vakavasta vaaratilanteesta. Niiden loppuraportointiehdot vaihtelevat: haavoittuvuusraportissa on määräaika, joka liittyy korjaavan tai lieventävän toimenpiteen saatavuuteen, kun taas vakavan vaaratilanteen haaralla on oma loppuraportin aikajana. Käytä voimassa olevaa lakitekstiä ja virallisia raportointiohjeita määrittämällesi tapaukselle.

Valmistele Pulsarissa harjoitustoimenpiteet, omistajat, määräajat ja synteettiset todisteet. Kirjaa ylös arvioijan päätös ja kaikki puuttuvat tiedot. Tarkista lopullinen tila tallennuksen jälkeen. Hyödyllinen tulos on dokumentoitu harjoitus, joka paljastaa puuttuvan korvaavan tai todisteen vaatimuksen ennen todellisen tapahtuman toteutumista.

Älä lähetä harjoitusta ENISAlle, CSIRT:lle tai todelliselle asiakkaalle. Pulsarin tietue ei ole virallinen hakemuskuitti, eikä julkinen kokeilujakso lupaa automaattista raportointia viranomaisille. Säilytä todellinen lähetys, sen virallinen kanava ja kuitti erillisinä toimenpiteinä todellisessa tapahtumassa. Tarkista 14 päivän kokeilujakson maksutapa ja peruutusehdot ennen rekisteröitymistä.

Lähteet

• ENISA — CRA:n yhteinen ilmoitusalusta Lähteet tarkistettu: 2. lokakuuta 2026.
• Pulsar GRC — pääsy, tietojen eristäminen ja vienti (puolaksi) Lähteet tarkistettu: 2026-10-10.
• CRA — Regulation (EU) 2024/2847 — Tuotteen laajuus ja sovellettavat velvoitteet.
• European Commission — CRA reporting — Raportointiehdot, sivuliikkeet ja päivämäärät.
• European Commission — CRA legislative summary — Laajuus, haavoittuvuuden käsittely ja hakupäivämäärät.
• Pulsar GRC — features — Sisäiset toimet ja todisteet.
• Julkaistu tuotevalikoima ja kokeiluehdot — Julkaistu tuotevalikoima ja kokeiluehdot. Tarkista ehdot ja aloita 14 päivän kokeilu

CRA SaaS-tuotteelle: soveltamisala, vastuuhenkilöt ja näyttö

IoT-komponenttien haavoittuvuudet: toimittajat, päätökset ja korjaukset

Puolalainen KSC/NIS2 IT-toimittajille: arviointi ja toimintarekisteri