Paperilla kaikki on kunnossa: ohjeet on kirjoitettu, NIS2:n GAP-analyysi tehty ja tehtävät kuitattu vihreiksi. Mutta tietääkö kukaan, mitä tapahtuu, kun kriittisestä järjestelmästä löytyy haavoittuvuus? Tietoturvaa johdetaan vasta silloin, kun dokumenteista siirrytään arjen tekemiseen.
Aiheesta keskustelivat Graniten webinaarissa GRC-konsultti Jukka Mäkitalo ja asiakkuustiimiä vetävä Customer Success Lead Kasper Kälviäinen. Tähän artikkeliin on koottu webinaarin keskeiset opit: mitä toimiva tietoturvan hallintajärjestelmä (ISMS) edellyttää, mikä on dokumentaation rooli ja miltä tietoturvan johtaminen näyttää käytännössä Graniten riskienhallintajärjestelmässä.
Standardien kuittaus ei ole johtamista
Mäkitalo törmää usein samaan väärinkäsitykseen: sertifikaattia ja dokumenttipinoa pidetään hallintajärjestelmänä. Todellisuudessa standardit, kuten ISO 27001, NIS2 tai CRA, vain asettavat hallintajärjestelmälle vaatimukset. Jos standardi edellyttää poikkeamien käsittelyä, prosessikuvaus ei riitä. Prosessin mukaan on myös toimittava, ja sen on näyttävä jälkikäteen.
”Vaatimukset ovat johtamisen lähtökohta, mutta ne eivät itsessään vielä tuota lopputulosta.” – Jukka Mäkitalo
Tyypillinen esimerkki löytyy NIS2-hankkeista. GAP-analyysin tehtävälistalla lukee: varmista, että poikkeamille on käsittelyprosessi ja ilmoituskanava. Organisaatio perustaa tietoturva@-osoitteen, kirjaa sen dokumenttiin ja kuittaa tehtävän. Johdolle raportoidaan, että NIS2 on hoidettu. Kukaan ei kysy, käsitelläänkö ilmoituksia koskaan tai johtavatko ne jatkotoimenpiteisiin. Tämä sama toistuu herkästi myös muiden vaatimusten kohdalla, jolloin lain tai vaatimuksen tarkoitus, eli tietoturvallisuuden kehittäminen, ei toteudu.
Millainen on toimiva tietoturvan hallintajärjestelmä?
Toimivan hallintajärjestelmän tunnistaa siitä, että päätökset näkyvät tekemisessä. Riskeillä on omistajat, poikkeamat käsitellään ja korjaukset viedään loppuun.
Mäkitalon mukaan organisaation pitää pystyä vastaamaan kuuteen kysymykseen:
- Mitä suojaamme? Järjestelmät, prosessit ja palvelut sekä se, miten ne riippuvat toisistaan.
- Mikä niitä uhkaa? Onko palvelu avoimessa verkossa? Sijaitseeko toimittaja ulkomailla?
- Miten riskejä hallitaan? Usein juuri ISO 27001:n tai NIS2:n hallintakeinoilla. Vaatimuskehikko on siis itsessään riskienhallinnan väline. Näiden lisäksi on paljon riskikohtaisia hallintatoimia, joihin vaatimuskehikot eivät suoraan anna vastausta, vaan organisaation on ratkaistava ne itse.
- Kuka vastaa? Jokaisella riskillä ja toimenpiteellä on nimetty omistaja.
- Toimivatko suojaukset? Huomataanko poikkeamat ja haavoittuvuudet, ja korjataanko ne? Mitä auditoinnit ja testit kertovat?
- Miten näytämme tilanteen? Todisteet tehdystä työstä, raportti milloin tahansa ja johdolle ajantasainen kuva.
Kun prosessit pyörivät sille tarkoitetussa tietojärjestelmässä, vastuuhenkilön ei tarvitse kaivaa ohjeita esiin joka kerta. Hän näkee yhdellä silmäyksellä, mitä on auki, mikä on kriittistä ja mikä myöhässä. Tällöin järjestelmä tukee hallintajärjestelmän käytännön toteuttamista.
Pelkkä dokumentteihin, GAP-analyyseihin ja kerran kuitattuihin tehtäviin perustuva hallintajärjestelmä ei siis tuota organisaatioissa sitä, mitä sen pitäisi. “Jos riskeille ei ole tehty mitään, se tarkoittaa, ettei teillä ole oikeasti toimivaa hallintajärjestelmää”, toteaa Jukka Mäkitalo.
Mitä tietoturvadokumentaatiolla tehdään käytännössä?
Dokumentaatio kertoo, miten organisaatio on luvannut toimia. Se tekee toimintamallit näkyviksi ja antaa auditoijalle jotain, mihin verrata. Sitä, pidetäänkö lupaukset, dokumentti ei kuitenkaan kerro. ”Dokumentaatio on välttämätöntä, mutta johtaminen syntyy vasta toiminnan puolella”, sanoo Jukka Mäkitalo.
Auditoija haluaa Mäkitalon mukaan tietää kolme asiaa:
- Mitä on sovittu? Politiikat, prosessit ja ohjeet.
- Toimitaanko niin? Onko poikkeamat esimerkiksi käsitelty määräajassa?
- Toimiiko se? Pienenikö riski, kun toimenpide tehtiin?
Ideaalitilanteessa jokainen muutos tallentuu automaattisesti hallintajärjestelmän lokiin, jolloin tehty työ on helppo osoittaa. Tällöin auditoija näkee myös selvästi, mikä on jäänyt tekemättä. Jos poikkeama on maannut kuukausia käsittelemättä, auditoija huomaa sen, ja syy voidaan selvittää yhdessä. ”Auditoijan silmissä mitään ei ole tapahtunut, mitä ei ole kirjattu,” toteaa Kasper Kälviäinen.
Kälviäinen muistuttaa, ettei kirjaamista kannata tehdä auditoijan takia. Kun käytännön kirjoittaa auki, sen heikkoudet tulevat usein esiin. Hän vertaa tilannetta asiantuntijaan, joka ymmärtää asiansa todella vasta, kun osaa selittää sen muille.
Tietoturvan johtaminen Graniten GRC-järjestelmässä
Graniten GRC-järjestelmän ajatus on yksinkertainen: tietoturvan kaikki palat ovat samassa paikassa ja kytköksissä toisiinsa. Omaisuusluettelon järjestelmän kautta näkee siihen liittyvät riskit, riskin kautta sitä hallitsevat ISO 27001- ja NIS2-vaatimukset sekä avoimet tehtävät ja jo toteutetut toimenpiteet.
Käytännössä tämä tarkoittaa:
- Vaatimus pienentää riskiä. Kun organisaatio on päättänyt toteuttaa ISO 27001:n hallintakeinot, ne näkyvät riskin alla ja laskevat riskitasoa. Vaatimuskehikko ei ole erillinen tarkistuslista vaan osa riskienhallintaa.
- Vastuu on siellä, missä tieto on. Järjestelmien omistajat hoitavat omat riskinsä ja tehtävänsä. Tietoturvatiimin ei tarvitse eikä kannata omistaa kaikkea, mutta seuraavat, että tietoturva toteutuu.
- Arjen työ kertyy johdon näkymäksi. Koko organisaation riskikuva kokoontuu automaattisesti raportiksi ilman erillistä keruukierrosta.
Samaan malliin voi Kälviäisen mukaan tuoda myös muun riskienhallinnan. Silloin tietoturva on osa kokonaisturvallisuutta eikä oma saarekkeensa.
Esimerkki: Digitaalisen asiointipalvelun tietoturva
Mäkitalo esitteli webinaarissa kuvitteellisen organisaation digitaalisen asiointipalvelun, jonka kautta asiakkaat ja henkilöstö hoitavat yhteydenotot ja sopimukset. Palvelu on organisaatiolle kriittinen, ja Mäkitalo toimi esimerkissä sen omistajana.
- Kohde kirjataan. Asiointipalvelu on Graniten omaisuusluettelossa kuvauksineen ja riippuvuuksineen. Näin täyttyy myös NIS2:n vaatimus tuntea oma toimintaympäristö ja sen kriittiset järjestelmät.
- Riskit liitetään kohteeseen. Asiointipalvelun sisältä näkyvät sen riskit: henkilöstö ei noudata ohjeita, ohjelmistossa on haavoittuvuus, palvelin pettää. Yksi riskeistä on hyökkäys organisaation käyttämään pilvipalveluun.
- Riskiin kytketään hallintakeinot. Pilvipalveluriskin alla näkyy ISO 27001:n pilvipalveluiden tietoturvaa koskeva hallintakeino sekä riskiin vaikuttavat NIS2-vaatimukset. Koska organisaatio toteuttaa ne jo, ne pienentävät riskiä ilman erillistä toimenpidettä, mutta niiden toteutuminen tulee varmistaa myös asiointipalvelun osalta.
- Puutteesta tulee tehtävä. Jos olemassa olevat keinot eivät riitä, riskille luodaan tehtävä, jolla on tekijä ja määräaika. Tavoite on pienentää riskin todennäköisyyttä tai seurauksia. Tehtävän voi kohdistaa myös suoraan järjestelmälle.
- Vaikutukset arvioidaan. Vaikutusanalyysi kertoo, mitä palvelun katkos tarkoittaa ja kuinka nopeasti tilanne muuttuu kestämättömäksi. Esimerkin palvelu on asteikon toiseksi korkeimmalla tasolla eli kriittinen. Kun järjestelmiä on satoja, vain yhteinen malli tekee arvioista vertailukelpoisia ja kertoo, mitkä ovat ensisijaisia suojattavia toimintoja organisaatiossa.
- Häiriöön varaudutaan. Asiointipalveluun on liitetty jatkuvuussuunnitelma ”Tietojärjestelmän häiriö”. Se kertoo, milloin suunnitelma otetaan käyttöön, kuka vastaa ja mitä tehdään. Häiriön hetkellä toimintamalli on jo ennalta määritelty ja organisaatio voi nopeasti muuttaa toimintaansa. Myös suunnitelman testaukset kirjataan, joten auditoijalle voi näyttää, milloin suunnitelmaa on harjoiteltu ja tehtiinkö sen yhteydessä havaintoja.
- Johto näkee koko kuvan. Kun jokainen järjestelmänomistaja toimii samoin, raportointinäkymä kokoaa koko organisaation eri toiminnot ja tietoturvariskit kriittisyysjärjestykseen. Johto saa vastauksen esimerkiksi siihen, mitkä ovat 20 suurinta riskiä ja kriittiset järjestelmät, ja voi päättää investoinneista sen pohjalta.
Pelkkä dokumenttipohjainen tietoturvan hallintajärjestelmä ei Mäkitalon mukaan vastaa kunnolla yhteenkään näistä kohdista. Se kertoo yleensä ainoastaan sen, miten asia on suunniteltu. Tietojärjestelmään vietynä ja aktiivisesti ylläpidettynä pystytään sen sijaan vastaamaan siihen, miten oikeasti toimitaan.
Ilman yhteistä työkalua jää arvoitukseksi, miten tieto järjestelmän omistajan arjesta koskaan päätyy ylimmälle johdolle.
Näin aloitat tietoturvariskien hallinnan
Kaikkea ei tarvitse ottaa haltuun kerralla. Mäkitalo neuvoo aloittamaan esimerkiksi kahdella työkalulla: tietoturvariskien hallinnalla ja poikkeamailmoituksilla. Niitä tarvitaan joka organisaatiossa, ja ne ovat arjessa tärkeimmät. Kun toiminta kypsyy, mukaan voi ottaa esimerkiksi omaisuusluettelon ja kytkeä riskit suoraan järjestelmiin.
Kälviäinen tiivistää: aloita siitä, mikä tuottaa ensimmäisenä eniten hyötyä, ja täydennä kokonaisuutta vähitellen. On kuitenkin syytä muistaa, että esimerkiksi NIS2:n velvoitteet saattavat jo vaatia organisaatiolta paljon laajempaa tietoturvallisuuden hallintaa, jolloin esimerkiksi toimintaympäristö tulee olla tunnistettuna eikä pelkkä tietoturvariskien hallinta täytä vaatimusta
Muistilista riskienhallinnan ammattilaiselle
- Testaa toiminta. Valitse GAP-analyysista yksi valmiiksi merkitty kohta. Pystytkö näyttämään, että sen mukaan on toimittu viimeisen kolmen kuukauden aikana?
- Anna jokaiselle riskille omistaja. Vie vastuu järjestelmien omistajille, älä kasaa kaikkea tietoturvatiimille.
- Kytke vaatimukset riskeihin. Kerro, mitä riskiä kukin ISO 27001 tai NIS2-vaatimus pienentää.
- Kirjaa myös keskeneräinen. Näkyvää ongelmaa voi priorisoida, piilotettua ei.
- Arvioi järjestelmät samoilla kriteereillä. Vaikutukset, palautumisajat ja kriittisyys yhdellä mallilla.
- Testaa jatkuvuussuunnitelmat ja kirjaa testit. Testaamaton suunnitelma ei vakuuta auditoijaa tai muitakaan sidosryhmiä.
- Päivitä dokumentit käytännön mukaan. Kun uusi toimintatapa toimii, vie se politiikkoihin ja ohjeisiin.
- Anna johdon tilannekuvan syntyä arjen työstä. Erikseen kerätty raportti on vanha jo valmistuessaan.
Blogi julkaistu 28.10.2026