Mitä tietoturva-auditointi sisältää yrityksessä?

Kun selvität, mitä tietoturva-auditointi sisältää yrityksessä, erota vastuita, käyttöoikeuksia, varmuuskopioita ja toimintaa poikkeamatilanteessa arvioiva organisatorinen osa teknisestä osasta, jossa tarkastetaan järjestelmien asetukset, haavoittuvuudet ja koodi. Hinta riippuu tarkastettavien järjestelmien määrästä ja tarkastuksen syvyydestä: automaattinen tietoturvatarkistuksemme maksaa laajuuden mukaan 89–890 €, ja asiantuntijan manuaalinen auditointi on saatavilla alkaen 3 500 €. Selvitä ensin, kumpaa osaa tarvitset ja millaista näyttöä odotat, sillä verkkosivuston tarkastus, yrityksen tietoturvan hallinnan arviointi ja sertifiointi ovat erillisiä toimeksiantoja, joista syntyy erilainen tulos.

Kuvittele, että asiakas lähettää ennen sopimuksen allekirjoittamista vaatimuksen tietoturva-auditoinnista, mutta liitteessä on kysymyksiä sekä työntekijöiden käyttöoikeuksista että järjestelmän teknisestä tarkastuksesta. Vaatimuksen välittäminen kehittäjälle ei yksin riitä: sinun on sovittava, odottaako asiakas raporttia verkkosivustosta, dokumentoituja yrityksen prosesseja vai riippumattoman tahon sertifikaattia ja mitä järjestelmiä tai toiminnan osaa tämän osoituksen on katettava. Suosittelemme säilyttämään pyynnön tarkan sanamuodon ja selvittämään sen tarkoituksen ennen toteuttajan valintaa ja kustannusarvion hyväksymistä.

Mitä tietoturva-auditointi sisältää: kaksi työtä samalla nimellä

Osat vastaavat eri kysymyksiin. Organisatorisessa osassa selvitetään, miten yritys tekee ja toteuttaa tietoturvapäätöksiä, teknisessä osassa taas, miten tietty järjestelmä toimii ja voiko sen suojauksen ohittaa. Siksi sama aihe näyttää kummassakin hyvin erilaiselta: käyttöoikeuskäytäntöjen arvioinnissa auditoija pyytää näyttämään, kuka hyväksyy työntekijän oikeudet ja miten ne poistetaan, mutta sovelluksen testauksessa hän yrittää tavallisella käyttäjätilillä tehdä jotakin, mitä tilillä ei saa tehdä. Tuloksia kannattaa lukea yhdessä, mutta kumpikaan ei korvaa toista: asianmukainen käyttöoikeuspolitiikka ei todista sovelluksen noudattavan sitä, eikä turvallinen sovellus todista, että joku on sulkenut lähteneen työntekijän tilin.

Siksi pelkkä sana ”auditointi” kertoo toimeksiannosta vähän. Suosittelemme lisäämään siihen kaksi asiaa: arviointikriteerit ja näytön, jota odotat raporttiin. Haavoittuvuuksien arvioinnissa kyse on priorisoiduista havainnoista, penetraatiotestauksessa tietystä suojausmekanismista tai toimintarajoituksesta, joka yritetään ohittaa, ja organisatorisessa vaatimustenmukaisuusauditoinnissa vaatimusjoukosta, johon asiakirjoja ja arjen käytäntöjä verrataan.

Jos valitset vain alustavan puutekartoituksen, nimeä myös tulos sen mukaisesti eikä sertifioinniksi ja sovi jo toimeksiannossa, kenen on luettava asiakirja ja mikä päätös sen perusteella on tehtävä. Sertifioinnissa on tärkeää tietää, kuka todistuksen antaa: ISO ei itse sertifioi yrityksiä, ja se kuvaa sertifioinnin riippumattoman tahon kirjalliseksi vakuutukseksi tiettyjen vaatimusten täyttymisestä. Samassa selvityksessä ISO toteaa akkreditoinnin osoittavan sertifiointielimen pätevyyden, mutta se ei ole pakollinen; siksi väite, että vain akkreditoitu taho saa sertifioida, olisi epätarkka. Jos asiakkaasi vaatii akkreditoitua sertifiointia, selvitä tämä ehto ennen sopimusta ja tarkasta valitsemasi tahon akkreditointi, jotta et myöhemmin jää sellaisen todistuksen varaan, jota asiakas ei ole suostunut hyväksymään.

Palvelumme on verkkojärjestelmien tekninen tarkastus, ja organisatorisessa osassa voimme auttaa tietoturvapolitiikkojen laatimisessa, mutta emme sertifioi yrityksiä emmekä hoida tietoturvallisuuden hallintajärjestelmää puolestasi, ja tämä raja kannattaa kirjata myös toimeksiantoon. Jos tehtävään kuuluu sekä verkkosivuston tarkastus että yrityksen hallinnan arviointi, sovi, kuka tuottaa teknisen näytön, kuka vertaa sitä valittuihin vaatimuksiin ja kuka vastaa lopullisesta arviosta, sillä muuten saatat odottaa meiltä johtamisprosessin arviointia ja organisatoriselta auditoijalta testiä, jota et ole tilannut. Organisatorisen osan toteuttaa yleensä tietoturvallisuuden hallinnan konsultti tai ISO/IEC 27001 -auditoija, mutta sertifikaatin myöntää sertifiointielin.

Organisatorinen osa: asiakirjoja on verrattava käytäntöön

Paperille voi kirjoittaa mitä tahansa, joten organisatorisessa osassa kannattaa tarkastaa, onko tietoturvapolitiikan määräyksille nimetty vastuuhenkilö, varattu tarvittavat resurssit ja saatu näyttöä toteutuksesta sekä onko riskinarvioinnissa tunnistettuihin ongelmiin suunniteltu toimenpiteet; ENISAn opas pienille ja keskisuurille yrityksille käsittelee johdon vastuuta, työntekijöiden osallistumista ja koulutusta, tietoturvapolitiikkoja, toimittajien hallintaa, pääsyn suojaamista ja poikkeamien hallintasuunnitelmaa. Yhdistä johdon ja työntekijöiden haastatteluihin asiakirjojen ja konkreettisten käytännön esimerkkien tarkastus, jotta arviossa voidaan erottaa suunniteltu toimintatapa sen toteutuksesta ja nimetä myös näyttö, jota auditoija ei saanut ja joka on vielä valmisteltava.

Käyttöoikeuksissa hyvä auditoija tarkastelee tilien myöntämisen lisäksi niiden sulkemista, monivaiheisen tunnistautumisen käyttöä ja toimittajien oikeuksia, joten tarkastettaviin esimerkkeihin kannattaa sisällyttää työntekijän lähtö tai toimittajan vaihtuminen: juuri näissä tilanteissa tilejä usein unohtuu. Varmuuskopioiden kohdalla tilanne on samanlainen, sillä vastaus ”otamme varmuuskopioita” kertoo vähän. Varmuuskopio, josta kukaan ei ole koskaan tehnyt palautusta, voi osoittautua poikkeamatilanteessa puutteelliseksi, ja asia selviää vasta verkkosivuston jo lakattua toimimasta. Järjestelmä- ja laiteluettelot tarvitsevat vastuuhenkilöt, tapahtumalokit tarkastuskäytännön ja poikkeamien hallintasuunnitelma nimeltä mainitun henkilön, joka tekee päätökset ja viestii osapuolille, sillä muuten suunnitelma jää asiakirjaksi, jota kukaan ei poikkeamatilanteessa toteuta.

Kriteereinä voi käyttää ISO/IEC 27001:2022 -standardia, joka määrittää tietoturvallisuuden hallintajärjestelmän vaatimukset; ”järjestelmällä” tarkoitetaan tässä hallintaa eikä vain tarkastettavaa sovellusta; BSI:n standardiselvityksessä mainitaan 93 tietoturvallisuuden hallintakeinoa ja neljä aluetta: organisaatioon, ihmisiin, fyysiseen turvallisuuteen ja teknologiaan liittyvät hallintakeinot. Sovi, mitä vaatimuksia auditointi arvioi ja millaisella näytöllä, sillä kustannusarvion standardiviittaus ei vielä kerro, tilaatko hallintajärjestelmän arvioinnin vai vain teknisen tarkastuksen, jonka tuloksia käytetään myöhemmin laajemmassa auditoinnissa; kirjaa tämä valinta ennen työn aloittamista.

Toinen perusta on CIS Controls v8.1 ja sen 18 hallintakeinoryhmää, jotka kattavat alueita yrityksen resurssien luetteloinnista penetraatiotestaukseen ja sisältävät yhteensä 153 suojaustoimenpidettä. CIS kuvaa CIS Implementation Group 1 (IG1) -ryhmää tietoturvan perustasoksi, johon kuuluu 56 suojaustoimenpidettä, joten täsmennä toimeksiannossa viitekehyksen nimen lisäksi myös valittu ryhmä. Pyydä yhdistämään raportissa jokainen arvioitu vaatimus saatuun näyttöön ja havaittuun puutteeseen, jotta korjausten jälkeen voidaan tarkastaa täsmälleen sama ehto sen sijaan, että verrattaisiin kahta yleisluontoista arviota.

Milloin laki edellyttää tietoturva-auditointia

Suomen kyberturvallisuuslaki (124/2025), joka tuli voimaan 8.4.2025, ei velvoita lain soveltamisalaan kuuluvia keskeisiä tai muita toimijoita tilaamaan ulkoista auditointia määräajoin. Toimialasi valvoja määräytyy 26 §:n mukaan: Traficom valvoo liikennettä, avaruutta, digitaalista infrastruktuuria, hallinnoituja ICT- ja tietoturvapalveluja, posti- ja kuriiripalveluja, verkon markkinapaikkoja, hakukoneita, sosiaalisen median alustoja, ajoneuvojen valmistusta ja tutkimustoimintaa. Energiavirastolle kuuluvat sähkö, kaukolämmitys ja -jäähdytys, kaasun jakelu, siirto ja toimitus sekä vedyn siirto; Tukesille muut kaasualan toiminnot, öljy, vedyn tuotanto ja varastointi, kemikaalit sekä liitteen II kohtien 11–13 toimijat. Vuoden 2026 alusta Lupa- ja valvontavirasto valvoo terveydenhuollon palveluntarjoajia, EU:n vertailulaboratorioita ja pääasiallisena taloudellisena toimintana harjoitettavaa jätehuoltoa, Elinvoimakeskus puolestaan juoma- ja jätevesialaa. Ruokavirasto valvoo elintarvikeyritysten tukkukauppaa, teollista tuotantoa ja jalostusta. Fimealle kuuluvat lääkkeiden tutkimus ja valmistus, kansanterveysuhan aikana kriittiset lääkinnälliset laitteet, veripalvelulaitokset, apteekit ja niihin liittyvät toimittajat sekä liitteen II kohtien 9–10 toimijat. Valvonta kohdistuu 27 §:n mukaan keskeisiin toimijoihin; muita voidaan valvoa vain, jos on perusteltu syy epäillä velvoitteiden laiminlyöntiä. Keskeisiä ovat liitteen I toimijat, jotka ylittävät suosituksen 2003/361/EY liitteen 2 artiklan keskisuuria yrityksiä koskevat edellytykset, hyväksytyt luottamuspalvelun tarjoajat, aluetunnusrekisterien ylläpitäjät, DNS-palveluntarjoajat, nuo kokoehdot täyttävät tai ylittävät yleisten sähköisten viestintäverkkojen tai yleisesti saatavilla olevien sähköisten viestintäpalvelujen tarjoajat, 3 §:n 3 momentin toimijat sekä 1.7.2025 alkaen lain 310/2025 nojalla määritetyt kriittiset toimijat. Valvoja voi tehdä 29 §:n mukaisen tarkastuksen tarvittavine testeineen ja käyttää toista valvontaviranomaista, Traficomin hyväksymää tietoturvallisuuden arviointilaitosta tai ulkopuolista tietotekniikan asiantuntijaa; tarkastuksen tekijältä ja siihen osallistuvilta vaaditaan tehtävän edellyttämä koulutus ja kokemus. Lain 30 §:n mukaisen turvallisuusauditoinnin voi määrätä teetettäväksi vain kahdella perusteella: merkittävä poikkeama on aiheuttanut palvelujen vakavan toimintahäiriön tai huomattavaa aineellista tai aineetonta vahinkoa, tai toimija on olennaisesti ja vakavasti laiminlyönyt 8 §:n toimintamallin tai sen hallintatoimenpiteiden toteuttamisen tai muiden laissa, sen nojalla tai NIS2-direktiivin nojalla säädettyjen velvoitteiden noudattamisen. Lain esitöiden mukaan toimija maksaa auditoinnin, eikä sitä määrätä, jos tavoite voidaan saavuttaa lievemmällä keinolla. Valvoja voi velvoittaa toteuttamaan auditoinnin suosittelemat kohtuulliset ja oikeasuhtaiset parannukset. Julkishallinnon tiedonhallintayksiköitä Traficom valvoo tiedonhallintalain (906/2019) lailla 125/2025 lisätyn 4 a luvun nojalla. Sen 18 k §:n mukainen arviointi voidaan määrätä samoilla kahdella perusteella, ja se on teetettävä hyväksytyllä tietoturvallisuuden arviointilaitoksella. Pankit ja rahoitusmarkkinoiden infrastruktuuri kuuluvat DORA-asetuksen ja Finanssivalvonnan valvonnan piiriin: kyberturvallisuuslain 5 §:n mukaan vaikutuksiltaan vähintään vastaavat EU-velvoitteet korvaavat lain 2, 4 ja 5 luvun sekä 41 §:n. Jos sinulle tarjotaan ”pakollista auditointia”, pyydä myyjää nimeämään sovellettava pykälä ja kertomaan, onko yrityksesi keskeinen vai muu toimija.

Kyberturvallisuuslain 8 ja 9 § edellyttävät ajantasaista kyberturvallisuutta koskevaa riskienhallinnan toimintamallia. Toimintamallissa ja hallintatoimenpiteissä on 9 §:n 2 momentin 1 kohdan mukaan otettava huomioon ja pidettävä ajan tasalla riskienhallinnan toimintaperiaatteet ja hallintatoimenpiteiden vaikuttavuuden arviointi. Laissa ei säädetä arvioinnille kiinteää toistoväliä eikä velvollisuutta toimittaa sitä valvojalle. Toimintamalli piti 47 §:n mukaan laatia kolmen kuukauden kuluessa lain voimaantulosta 8.4.2025; myöhemmin soveltamisalaan tulevan toimijan määräaika on kolme kuukautta 3 §:n kriteerien täyttymisestä. Jos lain 310/2025 nojalla määritetty kriittinen toimija ei ennestään kuulunut soveltamisalaan, 7–9 §:ää sovelletaan siihen vasta yhdeksän kuukauden kuluttua määrittämispäätöksen tiedoksisaannista. Soveltamisalan lähtökohtana ovat liitteessä I tai II tarkoitettu toiminta sekä suosituksen 2003/361/EY liitteen 2 artiklan keskisuuria yrityksiä koskevien edellytysten täyttyminen tai ylittyminen, kun toimintaa harjoitetaan tai palveluja tarjotaan EU:n jäsenvaltiossa. Koosta riippumatta lain soveltamisalaan kuuluvat myös yleisten sähköisten viestintäverkkojen tai yleisesti saatavilla olevien sähköisten viestintäpalvelujen tarjoajat, luottamuspalvelun tarjoajat, aluetunnusrekisterien ylläpitäjät, DNS-palveluntarjoajat ja julkishallinnon ulkopuoliset kriittiset toimijat. Traficomin 8.4.2025 voimaan tullut suositus TRAFICOM/18410/09.00.02/2023 antaa valvojille ja toimijoille käytännön esimerkkejä, ei raportointiaikataulua. Kyberturvallisuuskeskuksen Kybermittari on maksuton, vapaaehtoinen itsearviointityökalu, ja myös tulosten jakaminen keskukselle on vapaaehtoista. Lain 21 § antaa CSIRT-yksikölle oikeuden kartoittaa ennakoivasti yleiseen viestintäverkkoon liitettyjen järjestelmien haavoittuvuuksia järjestelmiin tunkeutumatta ja niiden toimintaa haittaamatta; se ei velvoita yritystä ostamaan penetraatiotestausta. Lain 29 §:n tarkastukseen voi kuulua tarvittavia testejä. Finanssialalla vaatimukset ovat toiset: DORA-asetusta on sovellettu 17.1.2025 alkaen, ja vaikutuksiltaan vähintään vastaavat velvoitteet korvaavat kyberturvallisuuslain 2 luvun. Uhkaperusteinen penetraatiotestaus (TLPT) vähintään kolmen vuoden välein koskee vain DORA-asetuksen 26 artiklan 8 kohdan nojalla yksilöityjä finanssiyhteisöjä, ei mikroyrityksiä eikä 16 artiklan 1 kohdassa tarkoitettuja yhteisöjä, ja valvoja voi muuttaa testausväliä. EKP/SSM ilmoittaa velvoitteesta merkittäville pankeille, Finanssivalvonta muille valvottavilleen; Suomen Pankki hallinnoi TIBER-FI-kehikkoa. Finanssivalvonnan mukaan DORA-asetuksen 24 artikla edellyttää kriittisiä tai tärkeitä toimintoja tukevien ICT-järjestelmien ja sovellusten vuosittaista testausta riippumattomien tahojen tekemänä. Tämä on finanssialan vaatimus, ei kaikkia suomalaisyrityksiä koskeva sääntö. Kun siis saat tarjouksen ”pakollisesta auditoinnista”, pyydä nimeämään täsmällinen velvoite, sovellettava pykälä ja oma asemasi keskeisenä tai muuna toimijana, jotta et pidä 8 §:n toimintamallin laatimista ja valvontaviranomaisen 30 §:n nojalla määräämää turvallisuusauditointia tai tiedonhallintalain 18 k §:n mukaista arviointia yhtenä toimeksiantona.

Tekninen osa: julkisista osoitteista koodiin

Nimeä teknisessä toimeksiannossa julkiset osoitteet, DNS-tietueet, avoimet palvelut ja TLS-asetukset sekä palvelimen tai pilviympäristön konfiguraatio, verkkosovellukset ja lähdekoodi, jotka annat tarkastettaviksi, ja ilmoita kunkin osan kohdalla, saako toteuttaja pääsyn asetuksiin vai arvioiko hän vain ulospäin näkyvää, sillä nämä ovat eri tehtäviä. NISTin tietoturvatestausmenetelmien jaottelussa asiakirjojen, lokien ja konfiguraation katselmointi erotetaan kohteiden tunnistamisesta ja analysoinnista sekä haavoittuvuuksien todentamisesta; voit käyttää jaottelua valittujen menetelmien ja odotetun tuloksen tarkempaan kuvaamiseen kustannusarviossa.

Verkkosovelluksille OWASP Top 10:2025 tarjoaa yhteisen kielen: kymmenen riskiluokkaa, joista kaksi ensimmäistä ovat pääsynhallinnan puutteet ja turvaton konfiguraatio. Luettelo ei itsessään tarkasta mitään, joten hyvä auditoija muuttaa jokaisen luokan sovellustasi koskevaksi kysymykseksi: pääsynhallinnassa se tarkoittaa yhden roolin toimintojen yrittämistä toisen roolin tilillä, kun taas turvattoman suunnittelun luokassa valitaan liiketoimintaprosessi, jonka sääntöjä joku voisi kiertää. Täydennä OWASP-viittausta tarkastuksen laajuudella, jotta molemmille osapuolille on selvää, mitkä toiminnot ja käyttäjäroolit tähän työhön todella kuuluvat.

Sisällytä sähköpostiosuuteen SPF-, DKIM- ja DMARC-asetusten arviointi ja yhdistä tehtävä järjestelmiin, joista yrityksesi lähettää viestejä: Googlen lähettäjävaatimukset edellyttävät 1. helmikuuta 2024 alkaen kaikilta Gmail-tileille lähettäviltä SPF:n tai DKIM:n määrittämistä, mutta yli 5 000 viestiä päivässä lähettäviltä sekä SPF:n, DKIM:n että DMARC:n määrittämistä. DMARC-käytäntö voi olla ”none”, mutta suorissa lähetyksissä From-kentän verkkotunnuksen on oltava linjassa SPF- tai DKIM-verkkotunnuksen kanssa; pyydä siksi toimeksiannossa arvioimaan sekä asetukset että käyttämäsi lähetysreitit sen sijaan, että vain merkitään verkkotunnuksen tietueiden olevan olemassa.

Yleisin havainto auditoinneissamme on PHP:n, sisällönhallintajärjestelmän ytimen ja ohjelmistokehysten asentamatta jääneet päivitykset. Siksi suosittelemme sisällyttämään tekniseen toimeksiantoon katsauksen käytössä oleviin versioihin, lisäosiin ja riippuvuuksiin sekä pyytämään havaintokuvaukseen täsmällisen komponentin ja tarvittavan toimenpiteen, jotta kehittäjä saa toteutettavan tehtävän eikä yleisluontoista huomautusta vanhentuneesta verkkosivustosta. Jos sinulle tärkeintä on se, mitä käyttäjät saavat järjestelmässä tehdä, versiokatsaus ei riitä: silloin tarvitaan myös pääsynhallinnan testausta ja liiketoimintalogiikan testausta. Olemme kohdanneet kriittisiä virheitä, joiden vuoksi kuka tahansa käyttäjä saattoi saada ylläpitäjän oikeudet ja joiden korjaaminen johti järjestelmän ytimen kirjoittamiseen kokonaan uudelleen; versiokatsaus ei olisi löytänyt tällaista virhettä.

Kysymys siitä, mitä käyttäjä saa tehdä, on eri asia kuin kysymys asennetuista versioista, ja kumpikin tarvitsee raportissa oman näyttönsä. NIST määrittelee haavoittuvuusskannauksen menetelmäksi, jolla tunnistetaan isäntäkoneita, niiden ominaisuuksia ja niihin liittyviä haavoittuvuuksia, kun taas automaattisessa tietoturvatarkistuksessamme skannaus on yksi teknisen työn vaiheista. NISTin penetraatiotestauksen kuvauksessa olennaista on todellisten hyökkäysten jäljitteleminen, suojauksen ohitusmahdollisuuksien etsiminen ja usein myös sellaisten haavoittuvuusyhdistelmien etsiminen, joiden avulla pääsyä voidaan laajentaa. Testin valintaa käsittelemme tarkemmin artikkelissa penetraatiotestauksesta; auditoinnin toimeksiannossa on tässä tärkeää määrittää, mitä puutteita toteuttaja vain etsii ja minkä käytännön hyväksikäytön hän yrittää osoittaa sovituissa rajoissa sekä mitkä toimenpiteet jätetään tietoisesti työn ulkopuolelle.

Miten auditointi etenee toimeksiannosta jälkitarkastukseen

Aloita auditoinnin laajuuden kirjallisesta kuvauksesta, jossa nimetään tarkastettavat järjestelmät, sovellukset, osoitteet ja käyttäjäroolit sekä kerrotaan selvästi, mitä tässä toimeksiannossa ei tarkasteta, ja lisää tavoite ja työn rajat: mitä toimenpiteitä sallit, missä ympäristössä ne tehdään, kuka voi keskeyttää tarkastuksen ja kehen otetaan yhteyttä odottamattomassa tilanteessa; sovi esimerkiksi tilausjärjestelmän kohdalla erikseen, miten testataan toimenpiteet, jotka muuten synnyttäisivät oikean tilauksen. Myös ylläpitäjäsi on luettava tämä sopimus, jotta sallitut toimenpiteet, käyttöoikeudet ja yhteyshenkilöt on sovittu ennen teknisen työn aloittamista.

Valmistele ennen työn aloittamista asiakirjat ja haastateltavat tehtävän edellyttämässä laajuudessa: organisatoriseen osaan politiikat, esimerkit käyttöoikeuksien myöntämisestä, varmuuskopioiden palautuksen kirjaukset ja poikkeamien hallintasuunnitelma, tekniseen osaan taas järjestelmäkuvaus ja sovitut käyttöoikeudet, ja merkitse myös vielä puuttuvat asiat. Jos tarkastat kopiota, kirjaa sen erot päivittäisessä käytössä olevaan järjestelmään ja sovi, miten ne esitetään raportissa, jotta lukija voi myöhemmin ymmärtää, mitä ympäristöä tulokset koskevat ja mitkä kysymykset jäivät avoimiksi asiakirjojen, pääsyn tai kyseisen toiminnon puuttumisen vuoksi. Sovi tekniselle työlle täsmälliset testausajat ja viestintäkäytäntö, mutta varaa asiakirjojen arviointiin määräaika, johon mennessä kollegasi voivat toimittaa täsmennyksiä, jotta tarkastetut asiat erottuvat tuloksessa selvästi vielä vahvistamattomista.

Jos toteuttaja löytää työn aikana merkittävän ongelman, pyydä ilmoittamaan siitä sovitulla tavalla muun työn jatkuessa odottamatta koko raportin luovutuspäivää. Sovi myös, kuka päättää testauksen jatkamisesta kyseisessä kohdassa ja miten saadut luvat tai rajoitukset kirjataan, sillä näitä päätöksiä tarvitaan selitettäessä, kuinka pitkälle kyseinen havainto onnistuttiin todentamaan.

Aikatauluun on varattava aikaa myös korjauksille

Järjestelmällämme tehtävä auditointi kestää muutaman päivän, mutta manuaalisen auditoinnin varsinainen työ vie auditoinnin laajuuden mukaan 1–3 viikkoa, ja aloitusta voi joutua odottamaan auditoijan työtilanteen vuoksi. Palvelusivulla ilmoitettu kokonaiskesto on 1–60 päivää, joten älä tulkitse näitä kuvauksia yhdeksi taatuksi toimitusajaksi, vaan sovi ennen tilausta aloituspäivästä, raportin luovutuksesta ja jälkitarkastuksesta. Jos asiakkaasi tai hankintamenettely asettaa määräpäivän, varaa aikaa myös havaintojen käsittelyyn ja korjaamiseen sekä tiimisi vastauksiin, sillä tarkastuksen valmistumispäivä ja päivä, johon mennessä haluat puutteiden olevan korjattu, ovat erillisiä suunnittelun ajankohtia.

Asiantuntijan manuaaliseen auditointiimme sisältyy jälkitarkastus 30 päivän kuluessa korjauksista. Jotta siitä olisi hyötyä, sovi raportin luovutuksessa, kuka korjaa kunkin havainnon, kuka ilmoittaa työn valmistumisesta ja minkä näytön toteuttaja tarkastaa uudelleen; täsmennä korjausten laajuus ja maksu erikseen, sillä auditoinnin hinta ei ole sopimus kaikesta myöhemmästä kehitystyöstä. Voit tehdä korjaukset omalla tiimilläsi, minkä jälkeen tarkastamme ne, tai antaa ne meille erillisenä työnä, jonka arvioimme raportin perusteella. Pyydä jälkitarkastusraportissa erottamaan korjattu puute siirretystä tai vielä tarkastamattomasta sekä ilmoittamaan tarkastetun järjestelmän tila, jotta tiimilläsi ja raportin vastaanottajalla on jokaisesta alkuperäisestä havainnosta yksi ymmärrettävä vastaus.

Mitä auditointiraportilta kannattaa vaatia

Pyydä raportin alkuun johdolle ymmärrettävä katsaus tarkastuksen tavoitteesta, katetuista järjestelmistä ja tärkeimmistä havainnoista, jotta töistä ja resursseista voidaan päättää lukematta kaikkea teknistä aineistoa, ja pyydä nimeämään samassa kohdassa myös työn rajoitukset. Jos lähdekoodi ei ollut saatavilla tai jotakin käyttäjäroolia ei tarkasteltu, pyydä sanomaan se suoraan sen sijaan, että lukijan on arvattava, mitä lyhyt arvio järjestelmän tilasta tarkoittaa; arvioi tällaista katsausta sen perusteella, voiko johtajasi nimetä siitä seuraavan päätöksen, vastuuhenkilön ja kysymyksen, johon ei vielä ole vastausta.

Pyydä jokaisesta teknisestä havainnosta sen sijainti järjestelmässä, olosuhteet, joissa se löydettiin, käytetty käyttäjärooli, toistamisohje ja näyttö tuloksesta, mutta organisatorisessa poikkeamassa pyydä vaatimusviittauksen lisäksi nimeämään asiakirja tai käytännön esimerkki, johon arvio perustuu. Korjaussuosituksesta on käytävä ilmi, mitä täsmälleen pitää muuttaa, joten täsmennä ilmaus ”käyttöoikeudet kuntoon” niihin oikeuksiin ja toimintoon, joita kehittäjäsi on muutettava, ja ilmoita odotettu toiminta korjauksen jälkeen, jotta raporttia voidaan käyttää sekä tehtävän luovutukseen että myöhempään valvontaan ilman, että jokaisen uuden lukijan on tulkittava auditoijan tarkoitus uudelleen.

Jos raportissa käytetään CVSS:ää, pyydä ilmoittamaan myös versio: FIRST julkaisee CVSS:n, mukaan lukien version 4.0, jonka vakavuusasteikon nimitykset ovat ”ei vakavuutta” (0,0), ”matala” (0,1–3,9), ”keskitasoinen” (4,0–6,9), ”korkea” (7,0–8,9) ja ”kriittinen” (9,0–10,0); näiden sanallisten nimitysten käyttö on vapaaehtoista. Pyydä luvun rinnalle perustelu ja selitys yrityksesi toiminnan kannalta, esimerkiksi mitä toimintoa tai tietojoukkoa havainto koskee ja miksi korjausta suositellaan tässä järjestyksessä, jotta prioriteetista voidaan keskustella kuvattujen olosuhteiden eikä vain luvun perusteella.

Käytämme kokemustamme tällaisista kriittisistä virheistä vaatiaksemme selkeää seurausten kuvausta, emme väittääksemme, että jokainen verkkosivusto tarvitsee uudelleenrakentamisen: raportissa on pystyttävä erottamaan yksittäinen korjaus ongelmasta, jonka ratkaisu edellyttää järjestelmän perustoiminnan uudelleenarviointia. Jos raportissa ehdotetaan laajaa uudistamista, pyydä näyttämään, mikä näyttö suositusta tukee, mitä voidaan korjata erikseen ja mikä kysymys jää ratkaisematta, jos yritys valitsee vain osan ehdotetusta työstä.

Pyydä skannerin raakatulostiedosto liitteeksi, jos tekninen tiimisi tarvitsee sitä, mutta sido raportin hyväksyminen näyttöön, prioriteetteihin ja toteutettaviin korjaussuosituksiin, joita odotat toimeksiannoltasi; älä valitse rivimäärää laadun mittariksi. Pyydä toteuttajaa selittämään yksi havainto alusta loppuun: miten se todettiin, mitä tulos osoittaa, miten se koskee järjestelmääsi ja miten muutosten jälkeen varmistetaan sen korjaaminen, sekä nimeämään kaikki johtopäätökseen vielä sisältyvät oletukset; tällainen läpikäynti antaa konkreettisen perustan raportin hyväksymiselle ja jatkotöiden jakamiselle.

Miksi auditointien hinnat eroavat niin paljon

Hinnat eroavat ennen kaikkea siksi, että tarjoukset kattavat eri määrän järjestelmiä ja eri syvyisen tarkastuksen: automaattinen skannaus ja versiokatsaus maksavat satoja euroja, mutta manuaalinen pääsynhallinnan testaus ja liiketoimintalogiikan testaus, lähdekoodin katselmointi ja jälkitarkastus vaativat asiantuntijan työpäiviä. Verkkosivuston tietoturva-auditointipalvelumme automaattinen tietoturvatarkistus maksaa laajuuden mukaan 89–890 €, ja se on tarkoitettu WordPress-, Laravel-, Drupal-, Joomla- ja Moodle-järjestelmille. Tarjous sisältää automaattisen haavoittuvuusskannauksen, versioiden, lisäosien ja riippuvuuksien tarkastuksen, konfiguraation ja palvelinasetusten arvioinnin sekä raportin havainnoista ja prioriteeteista; käytä tätä sisältöä verratessasi hintaa toiseen tarjoukseen ja täsmennä, mitkä asennuksesi tarkastetaan. Suhteuta hintahaarukan alin summa sovittuun laajuuteen, jotta et sovella yhden verkkosivuston tarkastushintaa yrityksen koko järjestelmäkantaan, jonka rajoja toteuttaja ei vielä ole arvioinut.

Asiantuntijan manuaalinen auditointimme on saatavilla alkaen 3 500 €, ja se sisältää OWASP Top 10 -luettelon mukaisen manuaalisen tarkastuksen, pääsynhallinnan testauksen ja liiketoimintalogiikan testauksen sääntöjen kiertämisen varalta, lähdekoodin katselmoinnin ja luvallisen penetraatiotestauksen. Lähdekoodin katselmointi on tarkoitettu Laravel-, WordPress- ja yksilöllisesti kehitetyille ratkaisuille, ja järjestämme raportin havainnot todellisen riskin mukaan sekä lisäämme jokaiseen korjaussuosituksen; tarjoukseen sisältyy myös jälkitarkastus korjausten jälkeen. Sana ”alkaen” pätee silloinkin, kun järjestelmälläsi on vain yksi julkinen osoite, sillä hinnan laskemiseksi on vielä sovittava toiminnoista, rooleista ja tarkastettavasta koodista.

Täysi tarkistus järjestelmällämme maksaa yleensä 500–800 €. Tämä on summa, jonka näemme useimmin automaattisen tietoturvatarkistuksen hintahaarukassa, eikä erillinen hinta yrityksen hallinnan, kaikkien järjestelmien ja sertifioinnin yhteisarvioinnista, joten yhdistä sana ”täysi” nimenomaiseen tekniseen laajuuteen, josta olemme sopineet. Useimmille verkkosivustoille suosittelemme säännöllistä automaattista tietoturvatarkistusta, jonka voi toistaa usein, ja asiantuntijan manuaalista auditointia silloin, kun järjestelmä käsittelee maksuja tai henkilötietoja tai on liiketoiminnalle kriittinen, sillä käyttöoikeusvirheet ja liiketoimintalogiikan kiertämisen löytää vain ihminen; käytännössä säännöllinen automaattinen tietoturvatarkistus ja vuosittainen manuaalinen auditointi toimivat hyvin yhdessä.

Tämä ero auttaa myös budjettikeskustelussa: jos tarvitset vastauksia verkkosivuston komponenteista ja asetuksista, pyydä kustannusarvio tähän tehtävään, mutta jos pääkysymys on käyttäjäoikeuksien tai liiketoimintasääntöjen kiertäminen, sisällytä vastaavat manuaaliset testit ja anna toteuttajan arvioida niiden työ erikseen.

Valmistele vertailua varten yhtenäinen kuvaus järjestelmistä, sovelluksista, käyttäjärooleista ja tarvittaessa organisatorista osaa varten myös yrityksen toimipaikoista ja pyydä sitten erittelemään automaattiset ja manuaaliset toimenpiteet. Kuvittele yksi kustannusarvio vain julkiselle verkkosivustolle ja toinen samalle sivustolle yhdessä asiakasportaalin, hallintanäkymän ja lähdekoodin kanssa: selvitä kunkin tarjouksen rajat ennen summien vertailua. Kirjaa jokaisen osan kohdalle myös tarvittavat käyttöoikeudet, valitut vaatimustenmukaisuuskriteerit ja raportin vastaanottaja, sillä näin annat toteuttajalle konkreettisen perustan laskelmalle ja itsellesi mahdollisuuden huomata pois jääneen tehtävän.

Täsmennä erikseen, sisältyykö hintaan havaintojen selittäminen kehittäjällesi, niiden yhdistäminen valitun standardin vaatimuksiin ja jälkitarkastus sekä missä auditointityö päättyy ja korjausten toteutus alkaa, ja suosittelemme huomioimaan auditoinnin budjetissa myös päätöksen havaittujen puutteiden korjaamisesta. Jos hinta eroaa edelleen huomattavasti myös samanlaajuisten tarjousten välillä, pyydä toteuttajia selittämään työ ja sen rajat yhden konkreettisen toiminnon, esimerkiksi käyttäjän käyttöoikeuksien muuttamisen, avulla lisäpalvelujen nimien sijaan; näin voit valita konkreettisen tuloksen ja vastuun perusteella turvautumatta lupaukseen kaikenkattavasta turvallisuudesta.

Milloin yritys tarvitsee tietoturva-auditoinnin

Suosittelemme tilaamaan auditoinnin, kun yrityksen on tehtävä konkreettinen tietoturvapäätös tai annettava todennettava osoitus, ja nimeämään heti alussa, koskeeko päätös hallintaa, teknistä tilaa vai molempia. Jos syynä on NIS2, selvitä ensin asemasi ja sovellettavat vaatimukset käyttäen apuna myös artikkeliamme NIS2:sta ja sen soveltamisalasta ja muotoile vasta sitten toimeksianto. Järjestys on tässä tärkeä: selvitä vaatimuksen soveltuminen ja tarvittava osoitus ennen palvelun valintaa, jotta teknisen raportin tilaaminen ei jää ainoaksi vastaukseksesi kysymykseen, jossa on vielä arvioitava myös yrityksen vastuut ja prosessit. Jos verkkosivustolla ei ole käyttäjätilejä, maksuja tai henkilötietojen käsittelyä eikä kukaan vaadi osoitusta, laaja auditointi ei yleensä ole tarpeen: asenna ensin päivitykset, ja sen jälkeen automaattinen tietoturvatarkistus riittää.

Jos tarkastusta vaatii vakuutusyhtiö tai asiakas, pyydä täsmentämään odotettu tulos ja toimita toteuttajalle vaatimuksen varsinainen teksti; erota esimerkiksi työntekijöiden koulutusta tai varmuuskopion palautuksen testausta koskeva kysymys sovelluksen käyttöoikeuksien tarkastusvaatimuksesta ja valmistele vastauksiin asianmukainen näyttö. Jos toimittajakyselyssä on osoitettava laajempi tietoturvaprosessi kuin tekninen auditointisi kattaa, pyydä asiakasta sopimaan lisätiedoista ja nimeä yrityksestäsi henkilö keräämään ne sen sijaan, että laajentaisit teknisen raportin merkitystä; täsmennä samalla, odottaako vastaanottaja varsinaista raporttia, vastauksia tiettyihin kysymyksiin vai muunlaista osoitusta ja missä määräajassa.

Säilytä hankintaa varten vaadittu tarkastustyyppi ja toteuttajan pätevyysehdot täsmälleen tilaajan muotoilemina ja selvitä epäselvyydet ennen hinnan pyytämistä, jotta tarjousta ei tarvitse kirjoittaa uudelleen työn alettua. Käsittelemme valintaa tarkemmin artikkelissa hankinnassa vaaditusta tietoturvatarkastuksesta, ja teknisen toimeksiannon valmistelua varten voit lähettää meille vaatimuksen sanamuodon ja järjestelmäkuvauksen. Ilmoita myös toimituspäivä, saatavilla oleva dokumentaatio ja se, kuka puoleltasi tekee korjaukset, sillä tarkastuksen toteutuksesta keskusteltaessa on käsiteltävä raportin laatimisen lisäksi tiimisi mahdollisuutta työstää tuloksia tarvittavaan päivään mennessä.

Poikkeaman jälkeen ja suunniteltujen tarkastusten välillä

Poikkeaman jälkeen suosittelemme sovittamaan auditoinnin tehtävän konkreettiseen avoimeen kysymykseen: poistaako korjaus havaitun ongelman, onko samankaltaista käyttöoikeusvirhettä etsittävä toisesta toiminnosta ja miten yritys jatkossa tarkastaa kyseisen menettelyn noudattamisen. Anna toteuttajalle kuvaus tiedossa olevista tapahtumista ja erota vahvistetut tosiasiat oletuksista. Jos haluat selvittää tapahtumien kulun, nimeä myös tämä työ erikseen ja sovi sen tuloksesta olettamatta, että yleinen verkkosivuston auditointi vastaa automaattisesti kaikkiin poikkeamaa koskeviin kysymyksiin; säilytä samalla tarkastettavien korjausten yhteys alkuperäisiin havaintoihin, jotta muutosten jälkeen voidaan kertoa täsmälleen, mikä ongelma tarkastettiin uudelleen ja miten.

Asiakkaamme tilaavat auditoinnin yleensä kerran tai kahdesti vuodessa; tämä on kokemukseemme perustuva havainto eikä kaikille yrityksille asetettu aikaväli. Suosittelemme kirjaamaan suunnitelmaasi seuraavan päivämäärän rinnalle myös muutokset, joiden jälkeen arvioit tarkastuksen laajuuden uudelleen, esimerkiksi uuden käyttäjäroolin, uudelleen kirjoitetun käyttöoikeustoiminnon tai vaihtuneen toimittajan, jolla on oikeuksia järjestelmään. Anna vastuuhenkilön tehtäväksi verrata näitä muutoksia edellisen auditoinnin laajuuteen ja ehdottaa täsmällistä tarkastettavaa osaa, mutta säilytä edellisen raportin ratkaisemattomat havainnot seuraavassa toimeksiannossa yhdessä niiden lykkäämistä koskevien päätösten kanssa, jotta uusi tarkastus alkaa tunnetusta tilanteesta.