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

Kysymykseen ”kuuluuko SaaS CRA:n piiriin?” ei voi vastata turvallisesti pelkän tilausmallin perusteella. CRA sääntelee digitaalisia elementtejä sisältäviä tuotteita, kun taas pilvipalveluja — myös SaaS-palveluja — käsittelee myös NIS2-kehys. Keskeinen kysymys on mikä tuote on, mitä ohjelmistoa asetetaan saataville markkinoilla ja onko etäpalvelu olennainen osa tuotteen toimintoa.

Aloita arkkitehtuurista ja toimitusmallista, älä markkinointinimityksestä.

Kaksi usein sekoitettua kysymystä

Onko pilvipalvelu itsessään CRA:n mukainen digitaalisia elementtejä sisältävä tuote?

Älä oleta sitä vain siksi, että käyttäjät käyttävät ohjelmistoa selaimella.

Onko etäpalvelu osa toista digitaalisia elementtejä sisältävää tuotetta?

Se voi olla. CRA määrittelee ”etätietojenkäsittelyratkaisun” etänä tapahtuvaksi tietojenkäsittelyksi, jonka ohjelmiston valmistaja on suunnitellut ja kehittänyt itse tai jonka suunnittelu ja kehitys on tehty valmistajan vastuulla ja jonka puuttuminen estäisi digitaalisia elementtejä sisältävää tuotetta suorittamasta jotakin toimintoaan.

CRA:n johdanto-osan perustelukappaleet antavat esimerkin mobiilisovelluksesta, joka tarvitsee pääsyn valmistajan kehittämän palvelun tarjoamaan API:in tai tietokantaan. Tällöin palvelu voi kuulua tuotteen soveltamisalaan etätietojenkäsittelyratkaisuna.

Kartoita arkkitehtuuri ennen soveltamisalapäätöstä

Kuvaa SaaS-tarjonnasta erikseen:

1. asiakkaalle toimitettu ohjelmisto — agentti, työpöytä-/mobiilisovellus, laite, lisäosa, kirjasto;
2. verkkokäyttöliittymä — mitä käyttäjä käyttää selaimessa;
3. taustajärjestelmä/API — etänä toteutettavat toiminnot;
4. tietokannat ja käsittely — mitkä etäelementit tarvitaan tuotteen toimintoihin;
5. kolmannen osapuolen integraatiot — mikä kuuluu valmistajan vastuulle ja mikä ei;
6. markkinamalli — kuka asettaa ratkaisun saataville ja millä tuotemerkillä;
7. päivitykset — mitä osia valmistaja muuttaa ja miten ne vaikuttavat tietoturvaan;
8. tuki — kuinka kauan kutakin merkityksellistä komponenttia ylläpidetään.

Kartoitus tukee sekä soveltamisalan arviointia että myöhempää teknistä dokumentaatiota.

Kolme esimerkkitilannetta

A. Vain selaimella käytettävä pilvipalvelu

Käyttäjä kirjautuu palveluun selaimella ilman erillisen ohjelmisto- tai laitteistotuotteen toimitusta. Älä hyppää sanasta ”SaaS” päätelmään ”CRA soveltuu”. Tarkista CRA:n määritelmät ja komission ajantasainen ohjeistus sekä arvioi erikseen NIS2-velvoitteet, jos ne ovat organisaatiolle merkityksellisiä.

B. Ohjelmistotuote, jonka taustajärjestelmää valmistaja ylläpitää

Asiakas saa sovelluksen tai komponentin, jonka tärkeä toiminto ei toimi ilman valmistajan suunnittelemaa taustajärjestelmää. Etäkäsittely voi olla osa tuotetta CRA:n tarkoittamassa mielessä.

C. Tuote käyttää riippumatonta pilvipalvelua

Kun palvelu suunnitellaan ja kehitetään valmistajan vastuun ulkopuolella, suhde voi olla erilainen kuin omaan taustajärjestelmään. ”Tiedot ovat pilvessä” ei itsessään vastaa CRA-kysymykseen.

Nämä ovat suuntaa antavia esimerkkejä, eivät tiettyä arkkitehtuuria koskevia oikeudellisia ratkaisuja.

Miksi tällä on toiminnallista merkitystä jo nyt

Asetuksen 14 artiklaa on sovellettu 11. syyskuuta 2026 lähtien, ja se ulottuu soveltamisalaan kuuluviin tuotteisiin, jotka on saatettu markkinoille ennen 11. joulukuuta 2027.

Jos tarjonta koostuu sovelluksesta, komponentista ja taustajärjestelmästä, tiimin on tiedettävä kyseisen tuotteen ja julkaisun osalta:

• mistä haavoittuvuusilmoitukset tulevat;
• kuka tekee ensiarvion;
• miten vaikutus tuotteeseen arvioidaan;
• miten korjaukset julkaistaan;
• miten käyttäjille tiedotetaan;
• milloin CRA-ilmoittamisen arviointi käynnistyy.

Ilman selkeää tuotteen rajausta on vaikea määrittää T0, vastuullinen omistaja tai ilmoituksen laajuus.

Mitä SaaS-soveltamisalapäätökseen kirjataan

• tuotteen rajauskaavio;
• paikallisesti toimitetut osat;
• etänä suoritettavat osat;
• kunkin osan tuottama toiminto;
• estääkö etäosan poistaminen tuotteen toiminnon;
• vastuu etäosan kehittämisestä;
• jakelu- ja tuotemerkkimalli;
• organisaation rooli;
• arvioinnissa käytetty oikeudellinen tai ohjeistuksen peruste;
• tuloksen hyväksyvä henkilö;
• seuraava tarkistuspäivämäärä.

Miten Pulsar voi auttaa

Pulsar voi säilyttää soveltamisalapäätöksen ja sitä tukevan aineiston sekä yhdistää tuloksen riskeihin, asiakirjoihin, toimiin, toimittajiin ja näyttöön. Kun arkkitehtuuri muuttuu myöhemmässä julkaisussa, päätös voi palata tarkastukseen vanhentuneeksi PDF:ksi jäämisen sijaan.

Pulsarin ei pitäisi antaa itsenäisesti oikeudellisesti lopullista vastausta ”CRA soveltuu / ei sovellu” ilman tarkastettavaa perustetta ja ihmisen hyväksyntää.

Tutustu Pulsar GRC:hen yhden arviointityönkulun kautta

Aiheeseen liittyvät oppaat

• Sovelletaanko CRA:ta tuotteeseeni?
• CRA:n tekninen dokumentaatio
• Takaisin CRA-oppaaseen

Kuvitteellinen palvelu neljällä eri osalla

Yritys tarjoaa selainanalytiikkaa, asiakkaan koneeseen asennettavaa keruuagenttia, mobiilisovellusta ja erillistä ohjelmistokirjastoa. Kaikilla on sama myyntinimi. Nimi ei riitä yhteen CRA-ratkaisuun. Kuvaa jokainen toimitettava osa, sen toiminto ja yhteys etäpalveluun. Tämä esimerkki kertoo arvioinnin työtavasta eikä anna osien lopullista oikeudellista luokittelua.

Agentin tärkeä toiminto voi riippua valmistajan taustapalvelusta. Kirjasto voi toimia itsenäisesti ja selainanalytiikka olla erillinen pilvipalvelu. Yksi merkintä ”SaaS, ei sovellu” voi jättää agentin tutkimatta. Yksi merkintä ”SaaS, kaikki soveltuu” tuottaa vastakkaisen perusteettoman yleistyksen. Kummassakin puuttuu tuotekohtainen faktimalli.

Tee toimintojen kartta

Kirjaa, mitä asiakas saa ja mitä hän tekee sillä. Lisää kehitysvastuussa oleva yritys, toimitustapa, versiokäytäntö ja markkinoille saattamisen rooli. Kartan pitää olla ymmärrettävä tekniselle ja oikeudelliselle arvioijalle. Pelkät infrastruktuuripalvelujen nimet eivät näytä asiakkaalle tarjotun tuotteen toimintoja.

Kysy etäpalvelun kohdalla, mitä tapahtuu sen poistamisesta. Menettääkö tuote toiminnon, mukavuuden vai jatkaako se normaalisti? Vastaus tarvitsee arkkitehtuuria ja todellisen käyttäytymisen näyttöä. Toiminnallinen koe voi tukea arviointia, mutta se ei korvaa kaikkia asetuksen ehtoja eikä anna automaattista ratkaisua.

Erota valmistajan vastuu ulkoisesta palvelusta

Jos valmistaja kehittää etätoiminnon itse tai teettää sen vastuullaan, kirjaa tämä. Jos tuote käyttää riippumatonta kolmannen osapuolen palvelua, kuvaa sen rooli ja sopimuksen laajuus. Sana ”ulkoistettu” ei yksin poista vastuuta eikä osoita tiettyä oikeudellista tulosta. Tarvitaan todellisten seikkojen tarkastus.

Kirjaa myös asiakkaan valittavat asetukset. Sama asennettava komponentti voi käyttää eri tarjouksissa eri taustapalvelua. Yhden kokoonpanon arvio ei automaattisesti kata muita. Tunnista sallitut vaihtoehdot ja ne, jotka vaativat lisäarvion. Rajattu johtopäätös on hyödyllinen, jos sen laajuus on selvä.

Pidä CRA ja NIS2 erillisinä arvioina

CRA käsittelee tuotteiden turvallisuusvelvoitteita. NIS2 käsittelee asianomaisten toimijoiden kyberturvallisuutta ja tarvitsee erillisen soveltumisarvion kansallisine sääntöineen. Yhden kehyksen päätös ei vastaa toisen kysymykseen. Pilvipalveluyritys voi tarvita NIS2-arvion, vaikka erillisestä SaaS-palvelusta ei voi päätellä CRA:n soveltumista.

Arviot voivat käyttää samoja lähtötietoja kuten yrityksen roolia, palvelukuvausta ja markkinoita. Säilytä silti jokaisen johtopäätöksen oikeusperusta ja hyväksyjä. Yksi vaatimustenmukaisuusluku voi muuten peittää, että tarkastus koski vain yhtä velvollisuusryhmää. Suomenkielinen käyttöliittymä ei määrää sovellettavan kansallisen lain maata.

Tarkasta uusi osa ennen toimitusta

Selainpalvelu voi myöhemmin saada agentin tai laitteen. Muutos tarvitsee soveltumisarvion tarkastuksen, ei vain hinnaston päivitystä. Tuotteen omistaja kuvaa ennen toimitusta uuden osan toiminnon, kehitysvastuun ja etäyhteyden. Arviointi liittyy näin oikeaan kehitys- ja julkaisuprosessiin.

Muutosmerkintään tulee aiempi rakenne, uusi raja, arvioitu ero, lähteet ja hyväksyntä. Jos aiempi tuote ei muuttunut, sen päätös voi säilyä omassa rajauksessaan. Sen pitää kuitenkin erottua uuden osan arviosta. Yksi yrityskuvauksen päivämäärä ei kerro, mikä tuote tarkastettiin milloin.

Ilmoittaminen tarvitsee tunnistetun tuotteen

Haavoittuvuustieto voi koskea taustapalvelua, agentin versiota tai yhteistä komponenttia. Tiimin pitää tunnistaa arvioitu tuote. Vanhentunut arkkitehtuurimerkintä voi johtaa teknisen ulottuvuuden ja ilmoitusarvion eroon. Puuttuva tieto kirjataan avoimeksi kysymykseksi, eikä sitä peitetä hiljaisella oletuksella.

Harjoittele komponenttia, joka liittyy useaan tarjoukseen. Tekninen tiimi selvittää julkaisut ja toiminnot. Soveltumispäätöksen omistaja tarkistaa tuoteyhteydet. Harjoitus osoittaa, voiko luokittelun ja eskaloinnin aloittaa nykyisistä tiedoista. Se ei edellytä oikean viranomaisilmoituksen lähettämistä kuvitellusta tapahtumasta.

Aineiston laadun tarkistus

Arkkitehtuurikuvan pitää vastata toimitettua mallia. Tarkista versio, aika ja hyväksyjä. Myyntiteksti voi kuvata tulevaa mahdollisuutta, jota asiakkaan julkaisussa ei ole. Kehitysdiagrammi voi kuvata sisäistä palvelua ilman yhteyttä kyseiseen tuotteeseen. Molemmat voivat auttaa taustana, mutta niiden soveltuvuus ratkaisuun arvioidaan erikseen.

Toimittajan lause ”palvelumme täyttää CRA:n” ei määritä sinun tuotteesi velvollisuuksia. Kysy tuotetta, roolia, versiota ja väitteen näyttöä. Säilytä vahvistamattomat kysymykset näkyvinä. Aineiston tulee olla käytettävissä myös silloin, kun alkuperäinen myyjä ei enää ole tavoitettavissa.

Hyväksymistesti ennen päätöstä

Anna arvio toiselle henkilölle. Hänen tulee nimetä toimitettavat osat, etätoiminnot, kehitysvastuu ja johtopäätöksen raja. Hänen pitää erottaa oikeudellinen peruste organisaation omasta oletuksesta. Jos tuotetta ei voi tunnistaa yksiselitteisesti, arvio ei ole valmis pelkän hyväksyntämerkinnän perusteella.

Pulsar voi säilyttää päätökset ja yhdistää ne riskeihin sekä tehtäviin. Tekoäly auttaa luonnoksessa, mutta ihminen tarkastaa tekniset faktat ja oikeudellisen ratkaisun. Palvelu ei anna automaattista lopullista CRA-luokitusta eikä kerää näyttöä pilvestä ilman sovittua tukea. Paikallinen tai yksityispilven palvelu on suunniteltu suunta, ei tässä vahvistettu nykyinen vaihtoehto.

Arvion työlehti yhdelle tarjoukselle

Kysymys	Kirjattava vastaus	Tarkastaja
Mitä asiakas saa?	palvelu, agentti, sovellus tai komponentti version kanssa	tuotteen omistaja
Mitä osa tekee?	toiminto ja tarkoitettu käyttö	tekninen vastuuhenkilö
Mitä tapahtuu etänä?	taustatoiminto ja sen tarve tuotteelle	arkkitehtuurin arvioija
Kuka kehittää?	kehitysvastuu ja sopimuksen todellinen järjestely	tuotetiimi sekä oikeudellinen arvioija
Miten tuote toimitetaan?	nimi, markkina ja yrityksen rooli	kaupallinen vastuuhenkilö
Mikä on päätös?	peruste, rajat, hyväksyjä ja tarkastusaika	pätevä päätöksen tekijä

Työlehti kertoo myös erimielisyyden faktasta. Kehittäjä voi sanoa agentin toimivan ilman taustapalvelua, vaikka käyttöohje kertoo palvelun olevan välttämätön. Ratkaise ero ennen hyväksyntää. Tarkista toteutettu toiminta, ei vain sanamuoto. Helpompi vastaus ei ole parempi lähde, jos se ei vastaa toimitettua tuotetta.

Säilytä toimitetun kokoonpanon ohje

Liitä asiakkaan ohje arvioon oikealla versiolla. Se auttaa näyttämään, mikä vaihtoehto todella toimitettiin ja mitä käyttäjä odotti. Tuleva paikallinen vaihtoehto ei muuta nykyisen palvelun arviota ennen toimitusmallin muutosta. Sama koskee suunniteltua uutta agenttia tai mahdollista yksityispilveä. Suunnitelma erotetaan jo saatavilla olevasta tuotteesta.

Tarkasta myös asiakkaan itse määrittämän ympäristön rajat. Jos arvio koskee valmistajan taustapalvelua, asiakkaan oma toteutus voi vaatia toisen faktimallin. Dokumentoi tarjousten erot selvästi. Yhden asiakkaan erikoisjärjestelyn perusteella ei pidä tehdä yleistä päätöstä kaikista muista toimituksista ilman ulottuvuuden tarkastusta.

Muutos pitää saada arvioinnin omistajalle

Uusi mobiilisovellus voi muuttaa tuotteen rakennetta, vaikka hinta ja markkinointinimi pysyvät samoina. Sopikaa arjen reitti, jolla kehitys kertoo olennaisesta muutoksesta. Muutoksen tekijä ei tarvitse koko oikeudellista muistioa. Hänen tarvitsee tietää, mikä tieto ilmoitetaan, kenelle ja ennen mitä päätöstä.

Pidä hyväksytyn arvion tunniste julkaisun yhteydessä. Näin uusi versio ei vahingossa käytä vanhaa johtopäätöstä, jonka raja oli toinen. Tekninen omistaja tarkastaa muuttuneet faktat ja oikeudellinen vastuuhenkilö niiden vaikutuksen. Pelkkä päivämäärän päivittäminen ei osoita, että tämä työ tapahtui. Tallenna myös muuttumattomaksi arvioitu osa perusteluineen.

Erillinen pilvipalvelu ei ole automaattinen tuotetulos

Pelkkä selaimessa käytettävä SaaS ei kuulu CRA:n piiriin vain tilausmallinsa perusteella. Toisaalta tuote voi sisältää toiminnalle tarpeellisen valmistajan etäkäsittelyn. Siksi kysymykset pidetään erillään. Oikeudellinen arvio käyttää asetuksen määritelmiä ja voimassa olevia ohjeita. Tämä artikkeli ei anna yleistä kyllä- tai ei-vastausta tietylle asiakasarkkitehtuurille.

Myös NIS2-arviossa tarvitaan toiminta, koko, mahdollinen erityinen sääntö ja kansallinen täytäntöönpano. Pieni yritys ei saa automaattista vastausta nimen ”SaaS” perusteella. Pidä arvioiden lähteet sekä johtopäätökset erillisinä, vaikka niiden tekninen tausta olisi yhteinen. Tämä vähentää yhden päätöksen virheellistä käyttämistä toisen velvoitteen vastauksena.

Rajaa asiantuntijalle annettava kysymys

Jos tulos jää avoimeksi, kerää tarkka kuvaus ja kysymys. ”Arvioikaa CRA-vaatimustenmukaisuus” voi johtaa laajaan työhön ilman selvää päätöstä. ”Kuuluuko tämän toimitetun agentin tietty etätoiminto tuotteen arvioituun rajaan?” antaa paremman lähtöpisteen. Asiantuntija voi kertoa tarvittavan lisätiedon ja arvion todellisen rajauksen.

Kun vastaus saadaan, säilytä siihen käytetty faktimalli. Muuten yritys voi soveltaa johtopäätöstä myöhempään erilaiseen versioon. Päätöksen seuranta perustuu samaan tuotteeseen ja ehtoihin, joita arvioija käsitteli. Uusi tieto voi vaatia lisäkysymyksen eikä tarkoita, että aiempi rajattu vastaus oli alun perin virheellinen.

Vastauksen käytettävyyden lisäkoe

Pyydä myyntiä ja kehitystä lukemaan sama tuoteraja. Molempien tulee tunnistaa asiakkaalle toimitettu osa sekä tärkeä etätoiminto samalla tavalla. Jos toinen kuvaa tulevaa tarjousta ja toinen nykyistä versiota, korjaa kuvaus. Tämä pieni koe paljastaa faktiristiriidan ennen kuin se muuttuu sopimuksessa tai viranomaiskeskustelussa vahvaksi väitteeksi.

Tarkasta päätöksen jatkokäyttö

Pyydä seuraavan julkaisun omistajaa vertaamaan uutta tarjousta hyväksyttyyn tuoterajaan. Hänen tulee nimetä muuttunut toiminto ja siihen liittyvä lähde tai todeta perustellusti, että rajaus pysyi samana. Pelkkä sama myyntinimi ei osoita muuttumattomuutta. Tarkastuksen tulos säilytetään päätöksen yhteydessä.

Jos uusi osa jäi arvioimatta, pidä kysymys näkyvästi avoinna ja määrää pätevä tarkastus. Älä kopioi aiempaa ratkaisua vain aikataulun vuoksi. Nopeasti löytyvä mutta väärään tuotteeseen liittyvä päätös ei ole käyttökelpoinen näyttö. Organisaation tulee tietää, minkä version faktit todella tarkistettiin.

Harjoittele yksi vaatimus ja yksi tarkistettu tulos

Käytä kuvitteellista tuotetta, joka koostuu työpöytäohjelmasta ja valmistajan käyttämästä taustaohjelmasta. Tämä on esimerkki synteettisestä arkkitehtuurista, ei ilmoitus siitä, että jokainen SaaS-palvelu kuuluu CRA:n piiriin. Tallenna ensin tuotteen toiminto, taustajärjestelmän rooli ja kysymys, joka vaatii pätevän laajuuden tarkistuksen. Säilytä oikeudellinen lähde ja tarkistuspäätös tietueen kanssa.

Kun esimerkin sovellettavuusoletukset ovat selvät, valitse yksi relevantti vaatimus ja yksi toimenpide. Määritä omistaja ja päivämäärä ja määritä sitten, mitkä todisteet osoittaisivat toimenpiteen tuloksen. Toiminto voi esimerkiksi tarkastella tuotteen käyttöoikeussääntöä ja liittää siihen kuvitteellisen testikuvauksen ja tuloksen. Valtuutettu henkilö tarkistaa todisteet ilmoitettua kriteeriä vastaan. Toimiin liitetty tiedosto ei suorita tarkistusta itsekseen loppuun.

Lue Pulsarissa vaatimus, linkitetty toiminta, lähdeversio ja todisteet tallennuksen jälkeen. Pyydä kollegaa tunnistamaan seuraava vastuu ilman kirjoittajan selitystä. Konkreettinen koetulos on tarkasteltava fragmentti tuotetyöstä. Se ei ole automaattinen CRA-asetuksen soveltamisalan arviointi, vaatimustenmukaisuuden arviointi, CE-vakuutus tai viranomaisille toimittaminen.

Pulsar tarjoaa 14 päivän kokeilujakson, joka vaatii maksutavan. Tarkista valittu sopimus, kokeilun jälkeinen hinta ja peruutusehdot ennen vahvistamista. Käytä tässä harjoituksessa synteettisiä tietueita; todellinen tuotepäätös vaatii oman arkkitehtuurisi ja pätevän tarkastuksen.

Lähteet

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 guidance, 27 July 2026 — Viralliset ohjeet soveltamisalasta ja toteutuksesta.
• European Commission — CRA legislative summary — Laajuus, haavoittuvuuden käsittely ja hakupäivämäärät.
• Pulsar GRC — features — Kirjatut vaatimukset, toimet ja todisteet.
• Pulsar GRC — pricing — Kokeiluehdot.
• Julkaistu tuotevalikoima ja kokeiluehdot — Julkaistu tuotevalikoima ja kokeiluehdot. Tarkista ehdot ja aloita 14 päivän kokeilu

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

Puolalainen KSC/NIS2 IT-toimittajille: arviointi ja toimintarekisteri

API ja MCP GRC:ssä: määritä pääsy ennen järjestelmien yhdistämistä