NIS2:n toinen vuosi: mikä toimii, mikä ei, ja mitä kukaan ei halua myöntää

NIS2 on ollut Suomessa voimassa nyt noin vuoden. Sen aikana on ehtinyt tapahtua kaikenlaista. Osa siitä on ollut hyvää, osa ei.

Tämä ei ole kattava katsaus NIS2:een. Sen voi lukea muualta. Tämä on katsaus siihen, mitä olen nähnyt ja mitä en ole nähnyt, ja mihin asioihin kannattaa kiinnittää huomiota seuraavan parin vuoden aikana.

Valvonta ei ole sitä mitä luullaan

Liikenne- ja viestintäministeriön elokuussa 2026 julkaisema raportti on mielenkiintoista luettavaa. Siinä sanotaan, että laki on toiminut ja organisaatiot ovat parantaneet toimintaansa. Samassa raportissa sanotaan, että viranomaisilla ei ole resursseja valvoa kattavasti.

Tämä tarkoittaa, että valvonta on satunnaista. Ei siksi, että viranomaiset olisivat laiskoja, vaan siksi että niitä on liian vähän suhteessa siihen, kuinka monta organisaatiota pitäisi valvoa.

Käytännössä tämä näkyy niin, että jos olet pieni toimija jollain ei-kriittisellä sektorilla, sinua ei todennäköisesti tarkasteta seuraavaan viiteen vuoteen. Jos olet iso toimija kriittisellä sektorilla, sinut tarkastetaan varmasti.

Tämä on epäreilu asetelma, mutta se on se asetelma jossa ollaan. Se myös tarkoittaa, että jos haluat tietää, oletko valmis, sinun pitää arvioida itsesi. Viranomainen ei tule kertomaan.

Se mitä kukaan ei sano ääneen

Suurin osa NIS2-dokumentaatiosta jota olen nähnyt on tuotettu compliancea varten. Se on kirjoitettu sen takia, että se pitää olla olemassa, ei sen takia että se auttaisi ketään.

Tämä näkyy esimerkiksi riskianalyyseissä. Ne on tehty kerran, ne on hyväksytty jossain palaverissa, ja ne on arkistoitu. Kukaan ei muista mitä niissä lukee. Kukaan ei käytä niitä päätöksenteossa.

Viranomaiset tunnistavat tämän. Ne eivät sano sitä suoraan, mutta ne kysyvät sellaisia kysymyksiä, joihin ei voi vastata pelkällä dokumentilla. Milloin viimeksi päivitit riskiarvion. Kuka sen teki. Mitä siinä muuttui. Miksi.

Jos et pysty vastaamaan näihin kysymyksiin, sinulla ei ole riskienhallintaa. Sinulla on paperi.

Kriittinen infrastruktuuri on kryptografian osalta kaaoksessa

Tämä on asia, josta en näe puhuttavan tarpeeksi. Kryptografia on hajallaan. Se on siellä täällä, eikä kukaan tiedä tarkalleen missä.

Konkreettinen esimerkki. Otetaan vaikka keskikokoinen teollisuusyritys jolla on oma IT-infrastruktuuri, muutama kymmenen sovellusta, tehdasverkko ja etäyhteydet. Kysytään, missä kaikkialla käytetään salausta.

Vastaus on yleensä jotain tällaista:

TLS-yhteydet verkkosivustoilla ja API-rajapinnoissa. VPN-yhteydet etätyöntekijöille ja toimipisteiden välillä. Levyjen salaus kannettavissa tietokoneissa. Salasanat ja API-avaimet tietokannassa tai salaisuuksien hallintajärjestelmässä. Sähköpostin salaus. Koodin allekirjoitus. Tietokantayhteyksien salaus. SSH-avaimet palvelimille. Sertifikaatit, joita on kymmeniä tai satoja, ja niiden uusiminen on jonkun tehtävä, mutta kukaan ei tarkalleen tiedä kenen.

Entä tehdasverkko. Siellä on sulautettuja laitteita, jotka on asennettu 2010-luvulla. Ne käyttävät salausta, joka oli standardi silloin. Niitä ei ole päivitetty. Niitä ei voi päivitä, koska valmistaja ei enää tue niitä. Ne vain ovat siellä ja tekevät sitä mitä ne on ohjelmoitu tekemään.

Tässä ollaan nyt. Ja tässä ollaan vuonna 2030, jos mitään ei tehdä.

Postkvanttikryptografia ei ole vielä pakollista, mutta se on tulossa

En halua liioitella. PQC ei ole NIS2:n suora vaatimus. Direktiivin 21 artiklan 2 kohdan h mukaan salauskäytäntöjen pitää kattaa salauksen vanhentuminen ja kyky siirtyä uusiin standardeihin. Se on lähellä, mutta ei sama asia.

Euroopan komissio julkaisi tammikuussa 2026 ehdotuksen NIS2:n muuttamisesta. Ehdotuksessa on kohta, joka koskee PQC-siirtymää. Ehdotus on käsittelyssä, ei voimassa.

EU:n roadmap suosittelee, että korkean riskin käyttötapaukset siirretään vuoteen 2030 mennessä ja mahdollisimman moni järjestelmä vuoteen 2035 mennessä. Suositus ei ole määräys.

Mutta tässä on se juttu. Jos aloitat vuonna 2028, et ehdi vuoteen 2030 mennessä. Jos aloitat vuonna 2026, saatat ehtiä. Jos aloitit vuonna 2025, olet hyvässä asemassa.

Kryptografisten järjestelmien kokonaisvaltainen siirtymä kestää tyypillisesti 5–7 vuotta. Tämä ei johdu siitä, että algoritmien vaihtaminen olisi vaikeaa. Se johtuu siitä, että pitää tietää, missä kaikki on, ja se tieto pitää kerätä.

Käytännön ongelmat ovat tylsiä. Sertifikaatit pitää uusia uusilla algoritmeilla. HSM-moduulit pitää päivittää tai vaihtaa. VPN-ratkaisut pitää konfiguroida uudelleen. Koodi, joka on kirjoitettu kymmenen vuotta sitten, pitää käydä läpi. Sulautetut laitteet pitää käydä fyysisesti läpi, jos ne ylipäätään tukevat uusia algoritmeja.

Kukaan ei halua tehdä tätä. Se on kallista, tylsää ja siitä ei saa krediittiä. Siksi se jää tekemättä.

Toimitusketju on se osa joka oikeasti kaatuu

Riskienhallinta on tärkeää. Salaus on tärkeää. Mutta jos minun pitäisi valita yksi asia, johon organisaatiot kompastuvat seuraavan kahden vuoden aikana, se on toimitusketju.

Tämä johtuu siitä, että toimitusketju ei ole yksi asia. Se on kymmeniä tai satoja asioita, ja jokainen niistä on erilainen.

Otetaan vaikka ohjelmistokehitys. Jos organisaatio kehittää omaa ohjelmistoa, sillä on riippuvuuksia. Nykyaikainen JavaScript-projekti voi sisältää satoja tai tuhansia npm-paketteja. Jokainen niistä on mahdollinen hyökkäysvektori. Jokainen niistä voi sisältää haavoittuvuuden, joka julkaistaan huomenna.

SBOM auttaa tässä. Se on luettelo kaikista komponenteista ja niiden versioista. Mutta SBOM itsessään ei tee mitään. Se pitää integroida prosessiin. Kun uusi haavoittuvuus julkaistaan, pitää pystyä nopeasti katsomaan, koskeeko se sinua ja mitä pitää tehdä.

Harva organisaatio on tässä pisteessä. Useimmat eivät tiedä, mitä niiden ohjelmistoissa on.

Ja sitten on sopimukset. Sopimuksessa voi lukea, että toimittaja noudattaa hyvää tietoturvakäytäntöä. Se on hyvä lause. Se ei kerro mitään.

Se ei kerro, miten haavoittuvuudet ilmoitetaan. Se ei kerro, kuinka nopeasti ne korjataan. Se ei kerro, kuka vastaa, jos palvelu on poissa käytöstä. Se ei kerro, saako toimittajaa auditoida, ja jos saa, niin miten.

Nämä ovat asioita, jotka pitää sopia erikseen. Harva on sopinut.

Häiriöilmoitus on prosessi, ei dokumentti

NIS2:n 23 artikla asettaa määräajat. 24 tuntia, 72 tuntia, kuukausi.

Nämä määräajat ovat tiukat. Ja ne ovat tiukat erityisesti siksi, että ensimmäisen ilmoituksen pitää lähteä liikkeelle, kun tilanne on vielä kesken. Et tiedä, mitä on tapahtunut. Et tiedä, kuinka laajalle se ulottuu. Et tiedä, kuka siitä on vastuussa.

Silti sinun pitää ilmoittaa.

Tämä ei ole tekninen ongelma. Tämä on prosessiongelma. Jos organisaatiossa ei ole harjoiteltu ilmoituksen tekemistä, se ei onnistu. Jos ei tiedetä, kuka soittaa ja kenelle, se ei onnistu. Jos ei ole valmista pohjaa, johon täytetään tiedossa olevat asiat, se ei onnistu.

Olen nähnyt organisaatioita, jotka ovat harjoitelleet tämän. Heillä on lista, jossa lukee kuka ilmoittaa ja kenelle, missä järjestyksessä. Heillä on pohja, jossa on kohdat, jotka pitää täyttää. He ovat käyneet prosessin läpi kerran tai kaksi, niin että kun se tapahtuu oikeasti, se ei ole ensimmäinen kerta.

Tämä on ero. Sitä eroa ei näe dokumentista. Sen näkee vasta, kun jotain tapahtuu.

Mitä EU-tasolla on tulossa

Komissio julkaisi 20. tammikuuta 2026 ehdotuksen NIS2:n kohdennetuista muutoksista. Ehdotus on käsittelyssä.

Yksi konkreettinen asia on small mid-cap -yritysluokka. Se kattaisi yritykset, joissa on alle 750 työntekijää ja enintään 150 miljoonan euron liikevaihto. Tavoite on keventää pienempien toimijoiden taakkaa.

Toinen asia on soveltamisalan tarkentaminen. Digitaalisen infrastruktuurin sektoria laajennettaisiin kattamaan muun muassa digitaalisten identiteettilompakoiden tarjoajat ja merenalaisten tiedonsiirtoinfrastruktuurien operaattorit.

Kolmas asia on CSA2, uusi kyberturvallisuusasetus. Se toisi kehyksen ICT-toimitusketjun riskien arvioinnille kriittisillä sektoreilla. Komissio voisi nimetä avain-omaisuuseriä ja määritellä korkean riskin toimittajia. Tämä koskisi erityisesti pilvipalveluita, verkkolaitteita ja muita kriittisiä komponentteja.

Kaikki tämä on ehdotuksia. Mikään ei ole voimassa. Mutta suunta on selvä. Toimitusketjun läpinäkyvyys tulee lisääntymään, ja siihen kannattaa varautua nyt.

CRA ja raportointivelvoitteet

CRA eli Cyber Resilience Act ei ole osa NIS2:ta, mutta liittyy siihen. Se koskee digitaalisten tuotteiden kyberturvallisuutta.

Raportointivelvoitteet alkoivat 11. syyskuuta 2026. Päävelvoitteet tulevat voimaan joulukuussa 2027.

Raportointi koskee aktiivisesti hyödynnettyjä haavoittuvuuksia ja vakavia häiriöitä. Ensimmäinen ilmoitus pitää tehdä 24 tunnin kuluessa siitä, kun valmistaja on tullut tietoiseksi tapahtumasta.

Tämä on tiukka. Ja se koskee myös organisaatioita, jotka eivät ole ajatelleet olevansa "valmistajia". Jos kehität ohjelmistoa, jota myyt tai lisensoit, olet todennäköisesti valmistaja CRA:n näkökulmasta.

Mitä tämä tarkoittaa käytännössä

Jos olet NIS2:n piirissä, sinulla on kolme asiaa jotka pitää hoitaa.

Kartoita nykytila. Selvitä, missä olet. Ei compliance-tarkistuslistalla, vaan oikeasti. Missä kryptografia on, keitä toimittajat ovat, millaisia riippuvuuksia sinulla on, miten ilmoitusprosessi toimii. Tämä vie aikaa ja vaatii, että joku oikeasti tekee sen.

Priorisoi. Et voi tehdä kaikkea kerralla. Valitse ne asiat, joilla on suurin vaikutus ja jotka ovat realistisesti toteutettavissa. Tämä on vaikeaa, koska NIS2:n vaatimukset ovat laajoja, ja jokainen kohta tuntuu tärkeältä. Mutta ilman priorisointia projekti jumittuu.

Dokumentoi se mitä teet. Ei sen takia, että viranomainen haluaa nähdä paperin, vaan sen takia, että kun joku kysyy, sinulla on vastaus.

Mihin kannattaa varautua

Vuosi 2026 on se, jolloin valvonta alkoi. Jos et ole vielä kartoittanut tilannettasi, se on ensimmäinen askel.

Vuosi 2027 on se, jolloin puutteet pitää olla korjattu. Se on myös se vuosi, jolloin PQC-siirtymäsuunnitelma pitää olla valmis, jos aikoo ehtiä vuoteen 2030 mennessä.

Vuosi 2028 on se, jolloin PQC-siirtymän toteutus alkaa kriittisissä järjestelmissä.

Vuosi 2029 on se, jolloin siirtymä on käynnissä laajemmin.

Vuosi 2030 on se, jolloin kriittiset resurssit pitää olla siirretty.

Tämä ei ole se hetki, jolloin aloitetaan. Se on se hetki, jolloin lopetetaan.

Kehitys

Analyysi

Aws

Kvantti

Edge Tietojenkäsittely

Muuttoliike

Google pilvi

IT hallitut palvelut

tekoäly palvelut