Tietoturva suunnittelussa CRA:n mukaan: vaatimuksista tarkastettuihin tuloksiin

”Sisäänrakennettu tietoturva” ei ole allekirjoitettava toimintaperiaateasiakirja. Digitaalisia elementtejä sisältävässä tuotteessa sen pitäisi näkyä suunnittelupäätöksissä, hyökkäyspinnan pienentämisessä, turvallisissa oletusasetuksissa, päivitysten käsittelyssä, testauksessa ja haavoittuvuuksien hallinnassa koko tuotteen elinkaaren ajan.

Käytännön malli on selkeä: riski → vaatimus → suunnittelupäätös → toimi → testi → tulos → näyttö → tarkastus.

Muuta olennaiset vaatimukset tuotetyöksi

CRA:n liite I sisältää olennaiset kyberturvallisuusvaatimukset. Käytännön tuotetyössä tiimien on käsiteltävä muun muassa seuraavia alueita:

• tuotteen suunnittelu riskiin nähden asianmukaisella kyberturvallisuuden tasolla;
• suojaus luvattomalta pääsyltä;
• tietojen ja toimintojen luottamuksellisuus, eheys ja saatavuus;
• hyökkäyspinnan pienentäminen;
• poikkeaman vaikutuksia vähentävät mekanismit;
• merkityksellisen tietoturvatoiminnan kirjaaminen ja seuranta;
• tietojen ja asetusten turvallinen poistaminen;
• päivitysten turvallinen jakelu;
• säännölliset tietoturvatestit ja tarkastukset;
• koordinoitu haavoittuvuuksien julkistaminen.

Tarkistuslista on lähtökohta. Se ei ole näyttö toteutuksesta.

Esimerkki: ”suojaa luvattomalta pääsyltä”

Heikko merkintä sanoo:

”Järjestelmässä on tunnistautuminen.”

Toiminnallinen merkintä voi osoittaa:

1. Riski: ylläpitotilin vaarantuminen voisi muuttaa tietoturvan kannalta kriittistä määritystä.
2. Päätös: etuoikeutetut roolit edellyttävät määritettyä tunnistautumisen ja istunnon hallinnan mekanismia.
3. Omistaja: nimetty henkilö tai tiimi.
4. Toteutus: linkki tekniseen muutokseen.
5. Testi: vaaditun toiminnan todentava tilanne.
6. Tulos: hyväksytty/hylätty sekä tuotteen versio ja päivämäärä.
7. Näyttö: raportti, loki, kuvakaappaus tai testiaineisto.
8. Tarkastus: arviointi uusitaan tunnistautumisen tai riskiprofiilin muutosten jälkeen.

Kuukausia myöhemmin organisaatio voi osoittaa aikomustensa lisäksi sen, mitä todella todennettiin.

Oletusarvoinen tietoturva

Oletusmäärityksellä on merkitystä, koska monet käyttäjät eivät muuta tietoturva-asetuksia käyttöönoton jälkeen. CRA:n vaatimukset käsittelevät muun muassa turvallista määritystä, päivityksiä ja suojausmekanismeja.

Kysy jokaisesta tietoturvan kannalta merkittävästä toiminnosta:

• minkä määrityksen uusi käyttäjä saa oletuksena;
• miksi oletus sopii normaaliin käyttöön;
• mitä suojauksia voidaan heikentää tai poistaa käytöstä;
• ovatko riskialttiit muutokset käyttäjälle ymmärrettäviä;
• voiko tuote palautua turvalliseen tilaan;
• mikä testi todentaa toiminnan asennuksen ja päivityksen jälkeen.

Sisällytä tietoturva julkaisuprosessiin, älä vasta julkaisun jälkeiseen dokumentaatioon

Julkaisun tarkastuksen pitäisi varmistaa vähintään:

• muuttuiko uhkamalli tai riskiprofiili;
• lisättiinkö uusia riippuvuuksia;
• kattavatko tietoturvatestit muutoksen;
• onko tunnetuista haavoittuvuuksista dokumentoidut päätökset;
• ovatko käyttäjän tietoturvatiedot edelleen oikein;
• ovatko tukijakson oletukset ja riippuvuudet yhä realistisia;
• onko näyttö liitetty oikeaan tuoteversioon.

Jos kysymykset esitetään ensimmäisen kerran auditoinnissa, organisaatiolla on dokumentaatioprosessi eikä sisäänrakennettua tietoturvaa.

ENISA: toistettavia toimia iskulauseiden sijaan

ENISA julkaisi pk-yrityksille tarkoitetun ”Secure by Design and Default Playbook” -oppaansa 30. heinäkuuta 2026. Aineisto keskittyy periaatteiden muuttamiseen toistettaviksi toimiksi olemassa olevissa teknisissä prosesseissa, tuoteprosesseissa ja julkaisuprosesseissa. Sama periaate toimii CRA:n täytäntöönpanossa: käytä tiimin todellista toimitusprosessia ja tee sitten vastuut ja näyttö selviksi.

Miten Pulsar tukee näyttöön perustuvaa työnkulkua

Pulsarin riskit, hallintakeinot, tehtävät, asiakirjat, näyttö, auditoinnit ja raportit voivat yhdistää suunnittelupäätöksen toteutukseen, todentamiseen ja tarkastukseen.

Pulsarin tekoälyn pitäisi säilyä luonnosten valmistelun avustajana. Sen ei pitäisi hyväksyä riskinarviointia, tietoturvapoikkeusta tai tuotteen vaatimustenmukaisuuspäätöstä itsenäisesti.

Tutustu Pulsar GRC:hen vaatimuksesta näyttöön etenevän työnkulun kautta

Aiheeseen liittyvät oppaat

• SBOM CRA:n yhteydessä
• CRA:n tekninen dokumentaatio
• CRA:n 24/72 tunnin ilmoittaminen

Kuvitteellinen muutos uuteen hallintaliittymään

Tuotetiimi lisää laitteeseen verkkohallinnan. Se helpottaa asetuksia mutta muuttaa myös hyökkäyspintaa ja oikeuksia. Jos turvallisuusarvio jää lopuksi politiikan allekirjoittamiseen, tärkeä puuttuva suoja voi löytyä vasta ennen julkaisua. Tämä esimerkki kuvaa suosittelemamme työnkulun, ei todellisen asiakkaan lopputulosta tai tiettyä kaikille sopivaa ratkaisua.

Kuvaa ensin suojattava tieto ja toiminto sekä käyttäjät. Lisää tavallinen käyttö, kohtuudella ennakoitava väärinkäyttö ja nykyiset suojat. Osa kysymyksistä vaatii teknistä koetta, osa rakennemuutosta ja osa käyttäjäohjetta. Yleinen tehtävä ”tarkista turvallisuus” ei kerro, kuka tekee nämä työt ja millä aineistolla.

Muuta riski testattavaksi käyttäytymiseksi

Perusteeton hallintaoikeus voi mahdollistaa tärkeän asetuksen muuttamisen. Tiimi määrää sallitun roolin ja tarkastustavan. Käyttäytymisvaatimuksen tulee olla testattava: alempi rooli ei voi suorittaa toimintoa, ja tulos on havaittava. Tämä esimerkki ei määrää yhtä kirjautumismekanismia kaikille tuotteille, vaan näyttää päätöksen ja testin yhteyden.

Liitä vaatimukseen julkaisu, omistaja ja odotettu näyttö. Kehitysmuutos kertoo toteutuksesta. Testi kertoo valitun toiminnan tarkastuksesta. Arvio kertoo, riittääkö tulos riskin kannalta. Jos yksi puuttuu, tila ei saa antaa vaikutelmaa täydestä katteesta. Erota suunniteltu suoja jo toteutetusta suojasta.

Kokeile myös kiellettyä toimintaa

Negatiivinen koe käyttää alempaa roolia ja tarkastaa oikeusrajan. Käytä todellista kokoonpanoa vastaavaa turvallista testiympäristöä. Kuvakaappaus piilotetusta painikkeesta ei yksin osoita suojaa toista pääsyreittiä vastaan. Pätevän testaajan tulee valita asialliset menetelmät ja kirjata kokeen todellinen ulottuvuus.

Määritä kokeen liitännät ja syötteet. Jos koe koskee verkkosivua muttei samaa toimintoa API:ssa, kerro tämä ja määritä lisätesti. Tarkoitus ei ole kasvattaa listaa mahdollisimman pitkäksi. Tarkoitus on kokeilla käyttäytymisiä, joiden puute voi aiheuttaa kuvatun haitan. Tulos arvioidaan niiden perusteella.

Tarkasta oletukset asennuksen ja päivityksen jälkeen

Uusi käyttäjä saa tietyn oletuskokoonpanon. Katso avoimet liitännät, oikeudet ja käyttäjälle näkyvä tieto. Kokeile ensiasennusta ja päivitystä vanhasta versiosta. Uusi turvallinen oletus ei välttämättä tule vanhaan kokoonpanoon samalla tavalla. Päivityksen jälkeinen toiminta tarvitsee siksi oman tarkastuksen.

Jos käyttäjä voi heikentää suojaa, arvioi mahdollisuus ja annettava tieto. Lause ”käyttäjä vastaa asetuksista” ei korvaa tuotteen riskiarviota. Säilytä perustelu valitulle käytökselle ja ohjeen rajat. Käyttäjäohje ei saa kuvata suojaa, jota kyseinen julkaisu ei todellisuudessa tue.

Turvapäivitys tarvitsee tarkastetun toimituksen

Koodikorjauksen valmistuminen ei tarkoita turvallista saatavuutta käyttäjälle. Kuvaa luominen, tarkastus ja jakelu. Määritä testi, joka näyttää tarvittavan eheyden ja toiminnan. Arvioi myös epäonnistuva päivitys, jos se liittyy riskikuvaan. Testin laajuuden valitsee pätevä tekninen vastuuhenkilö.

Säilytä julkaisu ja sen yhteys korjaukseen sekä tulokseen. Jos käyttäjä tekee oman vaiheen, tarvitaan selvä ohje. Jos vanhaa versiota ei voi päivittää, asia tarvitsee erillisen päätöksen ja vaikutusarvion. Yleinen väite ”päivityksiä on saatavilla” ei näytä kaikkien käytössä olevien tuotteiden tilannetta.

Julkaisun tarkastus näyttää myös poikkeukset

Ennen julkaisua katso uudet riskit, avoimet puutteet, testit ja riippuvuudet. Jos testi jäi tekemättä, säilytä syy, vaikutus ja hyväksyjä. Puuttuva koe ei muutu vihreäksi julkaisuajan lähestyessä. Tilapäinen poikkeus tarvitsee rajauksen ja uudelleenarvioinnin. Tekoälyluonnos ei korvaa tätä hyväksyntää.

Määritä tapahtuma, joka päättää poikkeuksen tai käynnistää uuden arvioinnin. Se voi olla uusi tieto, muutos tai sovittu aika. Työkalu säilyttää yhteyden, mutta ihminen määrää ehdot. Näin vanha hyväksyntä ei jää pysyväksi tavaksi vain siksi, että sen omistaja unohti asian.

Muutos voi tehdä vanhasta näytöstä riittämättömän

Kirjautumisen, istunnon tai oikeusmallin muutos voi vaikuttaa aiempaan testiin. Liitä muutos riskeihin ja määritä uudelleentesti. Yleinen ”uusin turvatesti” -linkki voi muuten kattaa väärin käyttäytymisen, jota raportti ei koskaan kokeillut. Näytä testattu versio, ympäristö, aika ja arvioija.

Osittainen näyttö on hyödyllinen, kun sen raja tunnetaan. Ongelmana on perusteeton täydellisyyden merkintä. Jos testi kattoi yhden asetuksen, johtopäätös pitää rajata siihen. Johdon päätöksen tulee nähdä sekä osoitettu suoja että puuttuva tarkastus. Runsas dokumentointi ei poista tätä erottelua.

Käytä tiimin nykyistä kehitysprosessia

Riskin tarkastus voidaan liittää tavalliseen muutokseen, testiin ja julkaisuun. Määritä tarkat vastuut sekä kontrollipisteet. Dokumentaatio syntyy silloin tehdyn työn jälkenä. Jos se kirjoitetaan toimituksen jälkeen, olennaisia päätöksen tietoja voi puuttua. Prosessin muutos auttaa enemmän kuin loppuraportin koristeellinen rakenne.

Pulsar ei korvaa lähdekoodin katselmointia, teknistä testiä, skanneria tai julkaisumekanismia. Se yhdistää riskin, vaatimuksen, päätöksen, tehtävän ja näytön. Organisaatio suorittaa teknisen työn ja arvioi tuloksen. Palvelu ei takaa tuotteen turvallisuutta tai sertifikaattia pelkästään sillä, että rekisteri on täytetty.

Hyväksymistesti yhdellä hallintatoiminnolla

Pyydä toista arvioijaa löytämään riski, käyttäytymisvaatimus, muutos, negatiivisen kokeen tulos ja julkaisupäätös. Lisää kuvitteellinen oikeusmallin muutos. Hänen pitää tunnistaa uudelleen tarkastettava näyttö. Kirjaa myös epäonnistuneet vaiheet. Selkeä dokumentaatio ei tee epäonnistuneesta teknisestä kokeesta onnistunutta suojausta; molemmat tarvitsevat oman jatkotehtävän.

Testituloksen työlehti

Kenttä	Kirjattava tieto	Miksi tieto tarvitaan
Riski	suojattava kohde ja mahdollinen haitta	koe valitaan asiallisen vaikutuksen perusteella
Käyttäytyminen	sallittu sekä kielletty toiminta	yleinen turvalause ei ole testattava
Tuote	julkaisu ja tärkeä kokoonpano	tulos ei automaattisesti kata toista versiota
Ympäristö	kokeen merkittävät ehdot	asetus voi muuttaa suojan toimintaa
Havainto	todellinen tulos ja rajoitus	suunnitelma ei osoita tehtyä koetta
Päätös	arvioija ja hyväksynnän syy	vihreä tila ei korvaa perustelua
Muutos	uuden kokeen käynnistävä tapahtuma	vanha näyttö voi menettää sopivuutensa

Kirjaa testaajan oikeudet. Hallintakäyttäjän onnistunut toiminta ei osoita alemman roolin suojaa. Ehdot kuuluvat näyttöön, koska toinen arvioija voi muuten ymmärtää raportin eri tavalla. Tekninen vastuuhenkilö valitsee merkittävät tiedot kyseisen riskin perusteella. Ei ole tarpeen kopioida jokaista testikoneen tietoa GRC:hen, jos se ei muuta johtopäätöstä.

Käyttäjäohje kuuluu turvakäyttäytymisen tarkastukseen

Tuote voi edellyttää oikeaa asetusta ja käyttäjän tulee ymmärtää ohje. Jos ohje näyttää vanhaa liitäntää tai väärää oletusta, todellinen käyttö voi olla testitilannetta heikompi. Liitä ohjeen versio julkaisuun. Kokeile tehtävää ihmisellä, joka ei kirjoittanut ohjetta. Hänen virheensä voi paljastaa tiedon epäselvyyden ennen varsinaista asiakasongelmaa.

Kun ohjeessa on riskialtis valinta, kuvaa seuraus selvästi. Epämääräinen varoitus voi jäädä ymmärtämättä tai tulla ohitetuksi tottumuksesta. Täsmällinen tieto kertoo, mitä käyttäytymistä muutetaan ja mikä suoja heikkenee. Pätevän tiimin tulee arvioida myös itse tuotteen ratkaisu. Ohje ei ole automaattinen korvaus teknisesti tarpeelliselle suojalle.

Uusi tapahtuma voi muuttaa aiempaa arviota

Toimituksen jälkeen löydetty puute yhdistetään alkuperäiseen riskiin sekä julkaisupäätökseen. Tämä ei automaattisesti tarkoita, että aiempi arvio oli perusteeton. Se tarkoittaa uuden tiedon käyttämistä tarkastukseen. Säilytetty historia kertoo, mitä tiedettiin ennen ja mitä havaittiin nyt. Tarvittava korjaus ja ilmoitusarvio ovat omia tehtäviään.

Kirjaa, vaikuttaako uusi tieto muihin tuotteisiin tai julkaisuihin. Yksi yhteinen kirjasto tai oikeusmalli voi yhdistää useita tarjouksia. Älä päätä vaikutusta vain siitä, että sama nimi esiintyy. Tekninen arvio tunnistaa todellisen käytön ja kokoonpanon. GRC auttaa seuraamaan näitä päätöksiä sekä erottamaan vahvistetun vaikutuksen avoimesta kysymyksestä.

Johdon raportti tarvitsee puutteen tyypin

Avoin tekninen puute ja puuttuva todistusaineisto ovat eri tilanteita. Ensimmäisessä suoja voi olla todella heikko. Toisessa suoja voi toimia, mutta sitä ei ole osoitettu sopivalla aineistolla. Molemmat tarvitsevat työtä, mutta resurssi ja kiire voivat erota. Yksi yleinen lukumäärä ei kerro tätä eroa, joten näytä myös mekanismi ja tarvittava toiminta.

Tarkista riskin hyväksynnän rajat. Jos päätös koski sisäistä testiympäristöä, sitä ei pidä käyttää asiakasjulkaisun tukena ilman arviointia. Jos päätös oli määräaikainen, tarkista voimassaolo ennen uutta toimitusta. Vanhan hyväksynnän kopiointi voi näyttää työn valmiilta samalla kun alkuperäinen ehto ei enää pidä paikkaansa. Tämä on seurannan, ei raportin ulkoasun ongelma.

Testaa myös epäonnistumisen dokumentointi

Palvelun pilotissa käytä yhtä valmista tapausta, yhtä epäonnistunutta testiä ja yhtä puuttuvaa aineistoa. Tiimin tulee näyttää niiden erot ja määrätä jatko. Jos käyttömalli tekee kaikki automaattisesti valmiiksi, korjaa tilakriteeri. Riskin arvioinnin tulee säilyttää todellinen puute, vaikka valmis raportti näyttäisi sen vuoksi vähemmän siistiltä.

Älä mittaa onnistumista pelkällä tehtävien sulkemisella. Katso, siirtyikö muutos testattuun julkaisuun ja ymmärsikö seuraava arvioija sen perusteen. Tehtävä voidaan sulkea hallinnollisesti ilman todellista suojaa, jos näyttöä ei tarkasteta. Päätöksen laatu syntyy lähteestä, teostuksesta, testistä ja pätevästä arviosta samassa asiayhteydessä.

Harjoituksen palautekierros

Kysy kehittäjältä, testaajalta ja tuotteen omistajalta, mikä tieto jäi puuttumaan. Näkemykset voivat olla erilaisia, koska heidän työnsä tarvitsee eri aineistoa. Yhdistä palautteet samaan muutostapaukseen ja valitse korjaus mekanismin mukaan. Uusi pakollinen kenttä ei ratkaise ongelmaa, jos oikeaa teknistä testiä ei ollut koskaan tehty.

Lähteet

• Asetus (EU) 2024/2847 — liite I
• ENISA — Secure by Design and Default Playbook

Lähteet tarkistettu: 2. lokakuuta 2026.

• Pulsar GRC — pääsy, tietojen eristäminen ja vienti (puolaksi)