Plan-Do-Check-Act eli PDCA on yksinkertainen jatkuvan parantamisen malli. Sen mukaisesti ensin suunnitellaan (Plan), mitä halutaan saavuttaa ja miten siihen päästään, sitten toteutetaan suunniteltu käytännössä (Do), arvioidaan tuloksia ja toimivuutta (Check) ja lopuksi tehdään havaintojen perusteella tarvittavat muutokset ja parannukset (Act). ISO kuvaa PDCA jatkuvana mallina, jota voidaan soveltaa sekä yksittäisiin prosesseihin että koko johtamisjärjestelmään.

Esimerkiksi tietoturvan näkökulmasta ajatus on yksinkertainen: riskienhallinta, hallintakeinot, seuranta, auditoinnit ja parannukset eivät saisi olla toisistaan irrallisia tehtäviä. Niiden pitäisi muodostaa jatkuva ketju, jossa yksi vaihe tuottaa tietoa seuraavaa varten.

PDCA-ajattelu näkyy erityisen vahvasti eri ISO-johtamisjärjestelmästandardeissa, kuten ISO 27001 tietoturvan hallintaan, ISO 22301 liiketoiminnan jatkuvuuteen, ISO 9001 laadunhallintaan ja ISO 14001 ympäristöjohtamiseen. Ajattelutapa näkyy myös standardien rakenteessa. Yhtenäisessä rakenteessa luku 6 käsittelee suunnittelua, luku 8 toimintaa, luku 9 suorituskyvyn arviointia ja luku 10 parantamista. ISO:n omassa PDCA-kuvauksessa nämä asettuvat luontevasti Plan-, Do-, Check- ja Act-vaiheisiin, kun taas organisaation konteksti, johtajuus ja tukitoiminnot muodostavat perustan koko syklille.

Vaikka standardien aihealueet vaihtelevat laadusta ympäristöjohtamiseen, tietoturvaan ja liiketoiminnan jatkuvuuteen, niiden taustalla toimii siis hyvin samanlainen ajatus: toimintaa ei vain suunnitella ja toteuteta. Sen sijaan toimivuutta tulee arvioida jatkuvasti ja järjestelmää kehitetään havaintojen perusteella.

Suurin huomio annetaan usein suunnittelulle ja toiminnalle

Riskinarviointi voidaan tehdä. Ohjeistus kirjoittaa. Vastuuhenkilö nimetä. Hallintakeino ottaa käyttöön. Tehtävä suorittaa, koulutus järjestää ja tarvittavat dokumentaatiot laatia.

Nämä ovat konkreettisia asioita, joita on helppo seurata, osoittaa ja myös auditoida. Siksi PDCA-mallin kaksi ensimmäistä vaihetta, suunnittelu ja toteutus, saavatkin usein eniten huomiota. Tietoturvan hallinnassa tämä näkyy erityisen selvästi silloin, kun organisaatio valmistautuu esimerkiksi ISO 27001 -sertifiointiin tai ottaa käyttöön uutta tietoturvakehikkoa. Alkuvaiheessa suuri osa työstä keskittyy ymmärrettävästi nykytilan arviointiin, puutteiden tunnistamiseen ja tarvittavien hallintakeinojen, vastuiden ja toimintatapojen rakentamiseen.

Ongelma alkaa, kun toteutuksesta tulee päämäärä.

Käyttöönotettu hallintakeino ei vielä kerro, onko se tehokas. Julkaistu ohjeistus ei tarkoita, että sitä noudatetaan käytännössä. Tehty riskienhallintatoimenpide ei puolestaan automaattisesti tarkoita, että riski on pienentynyt odotetusti.

Tietoturvan hallinta alkaa tuottaa enemmän arvoa silloin, kun organisaatio ei kysy ainoastaan, mitä on tehty, vaan myös mitä työn seurauksena tapahtui. Toimiiko hallintakeino niin kuin sen pitäisi? Näkyykö vaikutus riskitasossa, toiminnassa tai havaituissa poikkeamissa? Ja jos ei, mitä pitäisi muuttaa? Ja tästä alkaa PDCA-mallin usein vähemmälle huomiolle jäävä puolisko: Check ja Act.

Sen sijaan että kysyttäisiin "Onko se valmis?", kysytään "Toimiko se?"

Tässä vaiheessa arviointi eli mallin Check-vaihe nousee olennaiseksi. Huomio siirtyy tekemisestä vaikuttavuuteen:

Sen sijaan että tarkistetaan  vain, onko tietoturvakoulutus suoritettu...

...voidaan kysyä, tunnistavatko työntekijät paremmin epäilyttäviä tilanteita ja osaavatko he ilmoittaa niistä.

Sen sijaan että varmistetaan toimittaja-arviointien olevan tehtynä...

...voidaan arvioida, tunnistaako prosessi aidosti ne toimittajat, joihin liittyy suurin riski.

Sen sijaan että todetaan hallintakeinon olevan käytössä...

...voidaan selvittää, mitä näyttöä meillä on siitä, että se toimii tarkoitetulla tavalla.

Ja juuri tästä syystä ISO standardeissa huomioidaan esimerkiksi seuranta, mittaaminen, sisäiset auditoinnit ja johdon katselmukset. Niiden tarkoituksena on tukea ja auttaa organisaatiota ymmärtämään, miten hyvin johtamisjärjestelmä toimii käytännössä. Ilman tarkastelua esimerkiksi tietoturvan hallinnasta voi helposti tulla pitkä lista suoritetuista toimenpiteistä, joista tiedetään paljon vähemmän se, mitä vaikutuksia niillä todellisuudessa oli.

Havainto ei vielä ole parannustoimi

Act-vaiheessa olennaista on se, että havainto johtaa muutokseen. Pelkkä tarkastelu ei vielä tue jatkuvaa parantamista tai tue toimintaa eteenpäin. Sisäinen auditointi voi löytää puutteen, poikkeama paljastaa heikkouden tai riskien arviointi osoittaa, että tilanne on muuttunut.

Ratkaisevaa on, mitä havainnon jälkeen tapahtuu.

On helppoa luoda havaintoon liittyvä tehtävä, suorittaa se ja merkitä asia valmiiksi. Jos sama ongelma kuitenkin palaa myöhemmin, korjattiin ehkä vain yksittäinen tilanne eikä itse toimintatapaa.

Otetaan esimerkiksi vaikka väärin myönnetty pääsyoikeus. Yksittäinen virhe voidaan korjata poistamalla käyttäjältä tarpeeton pääsy. Jos kuitenkin halutaan estää saman tapahtuminen uudelleen, pitäisi katsoa pidemmälle: miksi pääsyoikeus myönnettiin virheellisesti? Puuttuiko jostain hyväksyntä, tarkistus tai selkeä vastuu?

Act-vaiheessa havainto muutetaan parannukseksi. Se voi tarkoittaa esimerkiksi hallintakeinon muuttamista, vastuun tarkentamista, prosessin päivittämistä tai riskin uudelleenarviointia.

Ei riitä tietää:

Mitä meidän pitää korjata?

Vaan myös:

Mitä meidän pitää muuttaa, jotta sama ongelma ei toistu?

Juuri tässä yksittäisestä havainnosta tulee jatkuvaa parantamista.

Hyvä johtamisjärjestelmä oppii omasta toiminnastaan

Kun PDCA-malli toimii hyvin, tietoturvan hallinnan eri osat alkavat ruokkia toisiaan.

Riskit vaikuttavat siihen, millaisia hallintakeinoja tarvitaan. Hallintakeinot tuottavat tietoa siitä, miten hyvin tekeminen toimii. Seuranta, auditoinnit ja poikkeamat puolestaan paljastavat, missä on vielä parannettavaa. Näiden havaintojen pitäisi taas vaikuttaa seuraaviin päätöksiin, prioriteetteihin ja riskiarvioihin.

Silloin tietoturvan hallinta ei ole enää kokoelma erillisiä tehtäviä, vaan jatkuva palautesilmukka.

Hyvä esimerkki tästä on sisäinen auditointi. Auditoinnissa voidaan huomata, että sovittu toimintatapa ei toteudu käytännössä tai että jokin hallintakeino ei toimi odotetulla tavalla. Havainto itsessään ei kuitenkaan vielä paranna mitään. Sen pitäisi johtaa korjaavaan toimenpiteeseen, vastuun tai toimintatavan tarkentamiseen ja myöhemmin myös siihen, että tarkistetaan, poistuiko alkuperäinen ongelma.

Tätä samaa ajatusta pyrimme tukemaan myös Cyberdayssa. Sisäisen auditoinnin havainto voidaan kytkeä suoraan kehitystoimenpiteeseen, vastuuhenkilöön ja siihen tietoturvan osa-alueeseen, jota havainto koskee. Näin auditointi ei jää irralliseksi tarkastukseksi, vaan siitä tulee osa jatkuvaa parantamista.

PDCA-ajattelun ydin on lopulta yksinkertainen: tavoitteena on oppia tehdystä työstä ja parantaa toimintaa sen perusteella.