Yleisen tietosuoja-asetuksen (GDPR, General Data Protection Regulation) siirtymäkausi umpeutui keväällä 2018, jota edelsi kaksi vuotta kestänyt siirtymäaika. Kevättä 2018 voitaneen pitää jonkinlaisena tietosuojan ja tietoturvan uuden ajanlaskun alkuna. Oli aika ennen tietosuoja-asetusta ja aika sen jälkeen. Tietosuojaa on toki säädelty Suomessa jo paljon ennen asetuksen voimaantuloa ja useat vaatimukset ovatkin olleet linjassa asetuksen, sekä sitä täydentämään luodun tietosuojalain kanssa. Suurin ero nykytilanteeseen on kuitenkin ollut se ettei rikkeitä ole sanktioitu. Juuri sanktiointi on saanut useat yritykset liikkeelle asian suhteen.

Vaatimusten tulva

Säädökset eivät loppuneet tietosuoja-asetukseen, päinvastoin. Joulukuussa 2018 tuli voimaan jo aiemmin mainittu tietosuojalaki, joka luotiin täydentämään ja täsmentämään tietosuoja-asetusta. Vuonna 2020 voimaan tuli tiedonhallintalaki yhdenmukaistamaan tietoturvallisuutta ja digitalisointia viranomaistoiminnassa. Lista ei ole kattava ja vauhti tuntuu vaan kiihtyvän. Tällä hetkellä siirtymäkaudella ovat muun muassa NIS2-direktiivi (Network and Information Security Directive) sekä DORA-asetus (Digital Operational Resilience Act). NIS2 asettaa useille huoltovarmuuskriittisille toimijoille uusia riskienhallinta- sekä tietoturvavaatimuksia ja DORA-asetus tekee saman finanssisektorin toimijoille. Näiden lisäksi siirtymäkaudella on muun muassa CER-direktiivi (Critical Entities Resilience Directive), jolla pyritään parantamaan yhteiskunnan kriittisten palveluiden häiriönsietokykyä.

Vaatimuksia tulee siis totisesti "ovista ja ikkunoista". Miten näihin kaikkiin tulisi sitten suhtautua? Ovatko ne pakollinen paha, mikä on jostain syystä luotu hidastamaan liiketoimintaa, vai jotain mistä on oikeasti myös hyötyä? Vastaus on, että ne voivat olla molempia, riippuen siitä miten niihin suhtautuu. Avaan asiaa seuraavaksi kahden (*reilusti yksinkertaistetun) esimerkin kautta.

Esimerkki 1 

Jaska Jokunen on yrityksen XYZ toimitusjohtaja ja hän kuulee uudesta yritykseen kohdistuvasta vaatimuskehikosta. Hän nimeää projektille vetäjän ja vastuuttaa tämän johtamaan yrityksen kohti vaatimustenmukaisuutta ja sopimaan johtoryhmän kanssa palaverin, kun homma on valmis. Projektinvetäjä ottaa tehtävän työn alle, rakentaa vaadittavat riskienhallintaprosessit ja ohjaa riskit eri liiketoimintajohtajille. Kun riskien kontrollitoimenpiteet on saatu riittävälle tasolle, hän ottaa yhteyttä toimitusjohtajaan. Projekti on saatu onnistuneesti maaliin ja kaikki ovat tyytyväisiä.

Esimerkki 2 

Matti Meikäläinen on yrityksen YZX toimitusjohtaja ja hän kuulee uudesta yritykseen kohdistuvasta vaatimuskehikosta. Hän miettii että riskienhallintamalli olisi pitänyt ottaa jo koko yritystasolla käyttöön, mutta se on muiden kiireiden takia jäänyt. Nyt on kuitenkin korkea aika tehdä asialla jotain. Toimitusjohtaja kalenteroi koko johtoryhmälle riittävän määrän palavereja, joissa he käyvät läpi yrityksen kriittiset prosessit ja kuvaavat ne ylätasolla. Tämän lisäksi johtoryhmä listaa liiketoiminnan kannalta pahimmat mahdolliset skenaariot, mitkä voisivat kaataa liiketoiminnan. Kun työ on tehty, toimitusjohtaja nimeää uudelle vaatimuskehikkoprojektille vetäjän ja samalla henkilöt, jotka tulevat vastaamaan kokonaisuudesta projektivaiheen jälkeen. Pohjatietona toimitusjohtaja antaa projektinvetäjälle johtoryhmän työstämät materiaalit. Projektinvetäjä lähtee viemään työtä eteenpäin selvittäen kriittisten prosessien alitasot, niihin liittyvät henkilöt, kumppanit ja järjestelmät. Riskienhallintatyössä hän osaa nyt huomioida suoraan nämä "kruununjalokivet", sekä liiketoiminnan kannalta pahimmat mahdolliset skenaariot ja mitä potentiaalisia tietoturvariskejä niihin voi liittyä. Työ viedään loppuun ensimmäisen esimerkin tavoin ja kaikki ovat tyytyväisiä.

Molemmat esimerkkitapaukset toivat yritykselle vaatimustenmukaisuuden, mutta mitä eroa niissä oli?

Ensimmäisessä esimerkissä projekti toteutettiin täysin vaatimustenmukaisuuden näkökulmasta, eli täytettiin vaaditut asiat, koska niin oli vaatimuskehityksessä määrätty. Jälkimmäisessä johto sitoutui tekemiseen alusta alkaen ja riskit, joita lähdettiin kontrolloimaan, olivat johdon tunnistamia liiketoimintariskejä, eivät tietoturvariskejä. Tietoturva toimi toki välikappaleena, jonka heikkouksien kautta liiketoimintariski olisi voinut toteutua. Näin ollen pienentämällä havaittua tietoturvaheikkoutta pienennettiin myös liiketoimintariskiä.

 Kuten yllä kuvattujen esimerkkien kautta havaittiin, voidaan vaatimustenmukaisuus nähdä pakollisena taakkana tai vaihtoehtoisesti tehokkaana työkaluna liiketoiminnan riskien hallitsemiseen. Olennaista on muistaa tietoturvan tärkein tehtävä liiketoiminnan näkökulmasta: liiketoiminnan turvaaminen. Mikäli liiketoimintaa ei ole, sitä ei tarvitse turvata.

 *) Yllä kuvatut esimerkit ovat reilusti yksinkertaistettuja, muun muassa käytettyjen roolituksien osalta. Monissa isommissa organisaatioissa on käytössä kypsät riskienhallintamallit, kuten kolmen puolustuslinjan malli (Three lines of defence) ja sen myötä myös sopivat roolit. Monessa PK-yrityksessä tilanne ei kuitenkaan ole tämä, vaan kuvatut esimerkit voivat olla hyvinkin lähellä todellisuutta.